K8S学习笔录 - Pod的全自动调度

阅读原文

Pod全自动调度配置，主要通过使用ReplicationController、Deployment等实现

ReplicationController

Go中的结构定义

type ReplicationController struct {
    // kind、apiVersion配置
    metav1.TypeMeta `json:"metadata,omitempty"`

    // metadata配置，包括name、labels等
    metav1.ObjectMeta `json:"metadata,omitempty"`

    // Controller的定义
    Spec ReplicationControllerSpec `json:"spec,omitempty"`

    // Controller状态，由系统自行更新（跟配置实际上没啥关系）
    Status ReplicationControllerStatus `json:"status,omitempty"`
}

type ReplicationControllerSpec struct {
    // Pod副本数量
    Replicas *int32 `json:"replicas,omitempty"`

    // Pod在Ready前最小等待时间，默认是0
    MinReadySeconds int32 `json:"minReadySeconds,omitempty"`

    // Selector用于Controller查询符合条件的Pods，当数量达到Replicas配置的数量是，停止创建Pod副本
    // 为空时默认为Pod模板中的配置的labels
    Selector map[string]string `json:"selector,omitempty"`

    // Pod模板配置
    Template *PodTemplateSpec `json:"template,omitempty"`
}

Deployment

type Deployment struct {
    metav1.ObjectMeta `json:"metadata,omitempty"`

    // metadata配置，包括name、labels等
    metav1.ObjectMeta

    // Controller的定义
    Spec DeploymentSpec `json:"spec,omitempty"`

    // Controller状态，由系统自行更新（跟配置实际上没啥关系）
    Status DeploymentStatus `json:"status,omitempty"`
}
type DeploymentSpec struct {
    // Pod副本数量，默认是1
    Replicas *int32 `json:"replicas,omitempty"`

    // Selector用于Controller查询符合条件的Pods，当数量达到Replicas配置的数量是，停止创建Pod副本
    // 选择器中的值必须要匹配Pod模板的Labels的值
    Selector *metav1.LabelSelector `json:"selector"`

    // Pod模板配置
    Template v1.PodTemplateSpec `json:"template"`

    // Deployment对于已经存在的Pod的替换策略
    Strategy DeploymentStrategy `json:"strategy,omitempty" patchStrategy:"retainKeys"`

    // Deployment在Ready前最小等待时间，默认是0
    MinReadySeconds int32 `json:"minReadySeconds,omitempty"`

    // 存储的历史版本数量，用于回滚，默认是10
    RevisionHistoryLimit *int32 `json:"revisionHistoryLimit,omitempty"`

    // Deployment是否为暂停
    Paused bool `json:"paused,omitempty"`

    // 创建部署Deployment的最长等待时间，并会把失败原因展示在deployment状态上
    // 默认600s，值必须大于MinReadySeconds
    ProgressDeadlineSeconds *int32 `json:"progressDeadlineSeconds,omitempty"`
}
type LabelSelector struct {
    // labels简单匹配
    MatchLabels map[string]string `json:"matchLabels,omitempty"`

    // matchExpressions更丰富的匹配规则
    MatchExpressions []LabelSelectorRequirement `json:"matchExpressions,omitempty"`
}
type LabelSelectorRequirement struct {
    // 匹配的Pod中Label的Key
    Key string `json:"key"`

    // 匹配关系，包括In、NotIn、Exists、DoesNotExist
    Operator LabelSelectorOperator `json:"operator"`

    // 匹配的Pod中Key所对应的Value
    // operator是In或NotIn，该值必须不为空
    // opertor是Exists或DoesNotExist，该值必须为空
    Values []string `json:"values,omitempty"`
}
const (
    LabelSelectorOpIn           LabelSelectorOperator = "In"
    LabelSelectorOpNotIn        LabelSelectorOperator = "NotIn"
    LabelSelectorOpExists       LabelSelectorOperator = "Exists"
    LabelSelectorOpDoesNotExist LabelSelectorOperator = "DoesNotExist"
)
type DeploymentStrategy struct {
    // 替换策略，值为Recreate或RollingUpdate，默认为RollingUpate
    // Recreate会先停止所有的旧Pod，然后创建新的
    Type DeploymentStrategyType `json:"type,omitempty"`

    // 更新回滚配置参数，只在RollingUpdate下生效
    RollingUpdate *RollingUpdateDeployment `json:"rollingUpdate,omitempty"`
}
type RollingUpdateDeployment struct {
    // 滚动升级过程中，允许不可用的Pod数量或比例
    // 默认为25%，此时升级过程中可用的Pod数量始终为75%
    // 每成功升级一个，则允许开始升级下一个
    // MaxUnavailable为0时，MaxSurge不能为0
    MaxUnavailable *intstr.IntOrString `json:"maxUnavailable,omitempty"`

    // 滚动升级过程中，允许最多同时创建Pod的数量或比例
    // 默认为25%，此时升级过程中新旧Pod数量总和最多为正常值的125%
    // 每删除一个旧的Pod则允许创建一个新的
    // MaxSurge为0时，MaxUnavailable不能为0
    MaxSurge *intstr.IntOrString `json:"maxSurge,omitempty"`
}

ReplicationController与Deployment对比

我的理解中，Deployment内管理的实际上是ReplicateSet，而ReplicateSet管理的才是Pod。

RS类似于RC的一个升级，继承了大部分RC的功能，并扩展了一些新功能。

RC的主要功能如下

1. 确保pod数量：它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod，Replication Controller会创建新的，反之则会删除掉多余的以保证Pod数量不变。
2. 确保pod健康：当pod不健康，运行出错或者无法提供服务时，Replication Controller也会杀死不健康的pod，重新创建新的。
3. 弹性伸缩 ：在业务高峰或者低峰期的时候，可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时，配置相应的监控功能（Hroizontal Pod Autoscaler），会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况，做到自动伸缩。
4. 滚动升级：滚动升级为一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始化升级的时候就可以及时发现和解决问题，避免问题不断扩大。

RS在RC的基础上扩展了如下功能

1. 更强大的Lables的选择器，支持使用In、Exists等方法匹配Lables。
2. 事件和状态查看：可以查看Deployment的升级详细进度和状态。
3. 回滚：当升级pod镜像或者相关参数的时候发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。
4. 版本记录: 每一次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。
5. 暂停和启动：对于每一次升级，都能够随时暂停和启动。
6. 多种升级方案
   1. Recreate：删除所有已存在的Pod,重新创建新的。
   2. RollingUpdate：滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用Pod数量，最小升级间隔时间等等。

配置示例

此处列举了Deployment的例子。RC的配置文件可以根据上方的配置结构自行配置得出，不过需要注意的是，RC的 apiVersion 为v1。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 50%
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

这个配置文件规定

1. 需要存活3个Pod，匹配带有标签 app=nginx 的Pod，当存活Pod不足3个时，按照template中的规则创建新的Pod副本。
2. 升级策略为滚动升级，升级过程中不能有Pod不可用，所有Pod（新版本的和旧版本的）加起来不能超过总数的百分之150%。
3. 未配置调度策略，所以这3个Pod可能会分布在任意机器上，具体分布规则由调度器算出，用户无法干预。