Pod控制器介绍

Pod控制器是用于代替我们管理Pod资源的中间层，也是K8S自动化功能的核心，它能确保其管理的Pod资源的状态，始终处于我们所定义、所期望的目标状态。

• 比如当前副本数是1，但是我们配置的是2，那么Pod控制器就会再创建一个副本，使得当前状态向期望的目标状态转移。
• 而管理Pod控制器是kube-controller-manager，它用来保证Pod控制器健康运行的。

Pod控制器类型

无状态服务控制器

无状态服务即服务不会或不需要保存运行中产生的状态。关注的是整个集群，如果某个Pod死了，那么可以直接删掉拉起一个新的Pod即可。

因为不需要保存状态就代表，内存中的数据即便丢失也完全没问题，所以即便老Pod挂了，也可以随时拉起一个新Pod将其取代，且不会对服务产生影响。

例如：nginx集群，某个节点宕了，直接拉起一个新的即可继续提供服务。

ReplicaSet控制器

• 他是新一代的ReplicationController，它用于管理无状态的Pod资源。
• 它支持副本数量控制、支持自动扩缩容机制功能。可以确保Pod副本的数量，一直保持在我们所定义、所期望的数量，如果Pod副本集少了会自动添加Pod副本，如果多了会自动移除Pod副本。

Deployment控制器

• Deployment工作在ReplicaSet之上，也就是说它是通过ReplicaSet来控制Pod的，它可以管理多个ReplicaSet，因此也可以方便的实现各类发布方式。
• 它支持副本数量控制、支持自动扩缩容机制、支持滚动更新、滚动回滚。
• 它支持声明式配置，使我们创建资源时，可以基于声明的逻辑来定义，使得我们可以随时对正在运行的资源进行目标状态配置，只要那些资源配置支持动态修改。

DaemonSet控制器

• 用于确保集群中的每一个Node都仅运行一个Pod，它的副本数随集群规模的变化而变化，一般是用来部署系统级功能的服务，例如日志服务，另外它也支持滚动更新。
• 它可以直接将节点上的某个目录作为存储卷，关联至Pod中，让Pod实现某些管理功能。

有状态控制器

服务会且需要保存运行中产生的状态，关注的是每个Pod个体。

例如：redis集群，每个节点都保存有一部分数据，所以如果某个节点宕了，直接删掉重新拉起节点会丢失之前的数据。

Job控制器

• 用于执行临时的一次性任务，比如数据库备份任务。
• 如果执行成功，控制器就会停止，不会再重建。如果执行失败，控制器就会重建Pod，然后重新执行任务。

CronJob控制器

• 用于执行周期性的任务。

StatefulSet控制器

• 它用于管理有状态的Pod资源，配置管理起来非常的复杂、困难，所以很难使用。

ReplicaSet资源配置清单

HEAD头部字段

apiVersion: apps/v1
kind: ReplicaSet

rs.spec.replicas <integer>

• 指定要目标副本数量

rs.spec.selector <object> - 必须

• 通过标签选择器，指定要管理的Pod，此处配置的标签必须与模板Pod中配置的标签匹配。
• 注意：
  • 只要标签匹配，控制器也会匹配上其他非该控制器所创建的Pod，并会对其进行管理。
  • 所以Pod的标签应当尽量做得精确，使其仅能匹配上该配置清单所配置的模板Pod。

matchLables <map[string]string>

• 直接给定键值来定义使用的标签选择器

• 例如：

  matchLables:
    标签名称: 标签值
    ... ...
  

matchExpressions <[]Object>

• 基于给定的表达式来定义使用的标签选择器，会用指定的标签的值，基于operator指定的表达式运算符，来和values指定的值进行比较。
  • 表达式格式：{key: "KEY", operator: "OPERATOR", values: [VAL1,VAL2...]}
• key <string> - 必选
• operator <string> - 必选
• values <[]string>

rs.spec.template <object> - 必须

• 指定将被创建和管理的Pod的模板。

metadata <Object>

• 指定将被创建的Pod的元数据
• name <string> - 此处指定的name无效，所以一般忽视，Pod名会强制以 "控制器资源名称+随机字符串" 命名
• labels <map[string]string> - 重要，设定的标签，必须被selector所匹配
• annotations <map[string]string>

spec <Object>

• 指定将被创建的Pod的目标状态，和Pod资源的spec清单配置方式一样。

Deployment资源配置清单

HEAD头部字段

apiVersion: apps/v1
kind: Deployment

deploy.spec.replicas <integer>

• 指定要目标副本数量

deploy.spec.strategy <object>

• 指定Pod的更新策略，可实现滚动更新。

type <string>

• 指定更新方式 (Recreate/RollingUpdate)
  • Recreate - 重建更新，容器镜像更新时，会将旧Pod一个一个删掉
  • RollingUpdate - 滚动更新 (默认方式)

rollingUpdate <object>

• 滚动更新的更新方式，用于控制滚动更新速度，只有 type=RollingUpdate 时该字段才生效。

• maxSurge <string>

  • 指定滚动更新时，用作更新的副本数最多能超出replicas所指定的目标副本数多少个，默认25%。
  • 可以直接指定最多能超出的数量，也可以指定以replicas数量为基准的百分比%，百分比如果计算不足1个，会向上取整算作1个。

• maxUnavailable <string>

  • 指定滚动更新时，最多能减少多少个replicas所指定的目标副本用来作为更新的副本，默认25%。
  • 可以直接指定最多能减少的数量，也可以指定以replicas数量为基准的百分比%，百分比如果计算不足1个，会向下取整算作0个。

• 注意：以上两者不能同时为0

  • 另外默认两个都是25%，也就就表示滚动更新时会新增25%数量的副本数用作更新，同时减少25%老版本的副本数。
  • 假如replicas指定的副本数只有一个，那么只要maxUnavailable不是100%或1，则至少会保留一个，只到新版本的副本起来。

deploy.spec.revisionHistoryLimit <integer>

• 指定历史版本的保留数，默认是10个。
• 也就是滚动更新之后，最多保留几个历史版本用于回滚。

deploy.spec.selector <object> - 必须

• 通过标签选择器，指定要管理的Pod，此处配置的标签必须与模板Pod中配置的标签匹配。
• 配置方式参考ReplicaSet。

deploy.spec.template <object> - 必须

• 指定将被创建和管理的Pod的模板。
• 配置方式参考ReplicaSet。

例子

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  namespace: default
  labels:
    app: nginx
    release: master
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
      release: master
  template:
    metadata:
      labels:
        app: nginx
        release: master
    spec:
      restartPolicy: Always
      containers:
        - name: nginx
          image: nginx:latest
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
            - name: https
              containerPort: 443
              protocol: TCP
          env:
            - name: ROLE
              value: nginx
          livenessProbe:
            tcpSocket:
              port: http
            failureThreshold: 3
            initialDelaySeconds: 10
            periodSeconds: 5
            timeoutSeconds: 5
          readinessProbe:
            httpGet:
              port: http
              scheme: HTTP
            failureThreshold: 3
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 10

Deployment生成的Pod名

• 会以deploy创建的ReplicaSet名称为前缀，加上一串随机字符串。
• 通过 kubectl get rs、kubectl get pod可以看到。
• 例如：
  • Deploy控制器创建的ReplicaSet名为myapp-deploy-784d9f8fbc，则Pod名就会以其为前缀为myapp-deploy-784d9f8fbc-926fd

Deployment滚动发布

Deployment支持滚动式自定义自控制的更新，Deployment可以通过新建一个ReplicaSet，然后逐渐将使用旧版本镜像的ReplicaSet，过渡到使用新版本镜像的ReplicaSet。

发布流程

• Deployment先删掉在旧ReplicaSet上的其中一个Pod。

  • 也可以先在新RS上加一个新版本Pod，然后再到旧RS减一个，以先加后减的方式更新。

• 然后再到新的RS上创建一个Pod，此Pod使用的是新版本镜像的Pod。

  • 此时Deployment可以将流量分配调度到V1版本或V2版本的ReplicaSet上。

• 然后逐渐的将旧ReplicaSet所有的Pod，过渡更新到新的ReplicaSet上来，这就实现了一次金丝雀发布。

• Pod全部更新到新ReplicaSet后，旧ReplicaSet仍会保留，方便后续需要时进行回滚。

  • 默认会保留10个旧版本的ReplicaSet。

• 注意：更新中Pod容器的健康检查非常重要，如果没有做健康检查，那么Pod一起来就会是就绪状态，流量就可能会调度到该Pod中，然而该Pod中的程序还没有完全启动，也就是还不能提供服务。

金丝雀发布

• Deployment支持在更新过程中暂停更新，但是并不能灵活操作，所以一般也不会直接这样用。

动态修改控制器

使用 kubectl edit 命令，可对其进行动态修改，我们可以随时对正在运行的资源进行目标状态配置，只要那些资源配置支持动态修改。

DaemonSet资源配置清单

该资源会在所有Node节点或者节点选择器选择的节点上，运行仅一个Pod用作守护进程，一般可以用于各节点的日志收集等情况。

HEAD头部字段

apiVersion: apps/v1
kind: DaemonSet

ds.spec.updateStrategy <object>

• 指定Pod的更新策略，可实现滚动更新。

• deamonSet控制器中maxUnavailable一般设为0，这是为了保证更新期间的服务可用性。

ds.spec.revisionHistoryLimit <integer>

• 指定历史版本的保留数，默认是10个。
• 也就是滚动更新之后，最多保留几个历史版本用于回滚。

ds.spec.selector <object> - 必须

• 通过标签选择器，指定要管理的Pod，此处配置的标签必须与模板Pod中配置的标签匹配。
• 配置方式参考ReplicaSet。

ds.spec.template <object> - 必须

• 指定将被创建和管理的Pod的模板。
• 配置方式参考ReplicaSet。

ds.spec.template.spec.nodeSelector <map[string]string>

• 用于限制Pod要调度的节点，传入节点的自定义标签。
• 例如：logcollecting: "on"