k8s控制器

控制器是k8s中自动化管理与维护资源状态的工具，k8s中创建出资源本质仅仅只是往etcd数据库中写入了一条数据，针对这些数据必须要有代码负责watch该数据，帮你创建出该资源，并且要负责后续的维护，这就是控制器的功能。

控制器分为两类：

• 内置控制器
  k8s中内置了一些控制器，包括replicaset、deployment、daemonset、statefulset、job、cronjob等，每一种控制器都具备自己特定的管理逻辑/功能。

• 自定义控制器

  k8s中的内置控制器无法满足企业场景中的需求，涉及到定制化开发控制器。

Deployment

讲解deployment控制器之前，需要先介绍ReplicaSet控制器，ReplicaSet控制器用来控制Pod中的副本数。

ReplicaSet可以独立使用，但一般还是建议使用 Deployment 来自动管理ReplicaSet，这样才可以实现更高级的功能例如滚动更新。

1

Deployment 控制器  ———> ReplicaSet控制器  ———> Pod

Deployment最重要的一个功能就是滚动更新

滚动更新的策略有两种：RollingUpdate（默认值）和Recreate

• RollingUpdate：滚动更新。可以指定maxUnavailable 和 maxSurge 来控制 rolling update 进程。

  • maxSurge: 默认1，在滚动更新的过程中，在spec.replicas的基础上可以额外新建最大pod数，控制的是创建新的。
  • maxUnavailable: 默认1，在滚动更新的过程中，老pod最大同时干掉几个，控制的是干掉老的。

• Recreate： 重建式更新，删一个建一个，即首先删除现有的Pod对象，然后由控制器基于新模板重新创建新版本资源对象。类似于ReplicaSet的更新方式。

DaemonSet

DaemonSet的特点是默认会在每个节点都启动一个pod副本（可以用使用NodeSelector或者NodeAffinity来控制哪些节点上启动）

DaemonSet有以下应用场景：

1. 每个节点上都要启动一个进程，比如flanneld
2. kube-proxy组件负载pod的负载均衡流量转发，每个节点要有
3. 采集每个节点上的日志
4. 对每个节点进行监控

StatefulSet

StatefulSet：译为“有状态的集合”，专门用于管理有状态的资源。有状态指的是，应用的运行要依赖之前的数据，必须限制调度，pod只能调度到之前状态存在的节点上才可以。

StatefulSet控制器的应用场景：

1. 稳定的次序：对于N个副本的StatefulSet，每个Pod名字后缀从0-N，按次序启停
2. 稳定的网络标识（网络标识即dns域名）：每个pod都有一个固定的域名（FQDN），pod的ip地址随意变化，但这个域名不变
3. 稳定的存储：通过VolumeClaimTemplate为每个Pod创建一个PV。删除、减少副本，不会删除相关的卷。

StatefulSet有两个重要组成部分

• Headless Service
  Headless Service是一种Service类型，Headless Service没有Cluster IP，它的作用是使得每个pod有一个固定FQDN名字，上游的访问可以直接访问该域名来访问pod。

  fqdn域名格式：$(podname).$(headless Service name).$(namespace).svc.cluster.local

  1 2 3 4

  基于普通svc的访问流程 普通svc的域名 ———> coredns解析 ———> svc的cluster ip ———> ipvs转发 ———> pod的endpoint 基于无头svc的访问流程 无头svc的域名 ———> coredns解析 ———> 所关联pod的ip地址

  注意：Headless Service没有负载均衡的效果，StatefulSet控制的Pod也不需要svc做流量转发。

• volumeClaimTemplates
  创建pvc的模版，每个pod副本都会创建出一个自己独有的pvc，不与其他pod共享

Job

Job通过启动Pod来执行一次性的任务，Job中也有一个Pod模板，不一样的是Job的pod中的容器要求是一个可以执行完毕、可以退出的任务，而不是一个常驻的进程，这也导致Job的RestartPolicy仅支持设置为Never或OnFailure，不能是Always，因为job是一次性的。

Job中的Pod正常执行完毕后的状态为completed，表示pod正常执行完毕，且返回的状态码为0。如果状态是CrashLoopBackOff ，表示 Pod 内的容器在启动后反复崩溃，并且 Kubernetes 已经多次尝试重新启动但仍然失败。

下面是Job中的一些控制参数：

• spec.activeDeadlineSeconds

  超时时间，表示Job在启动之后，经过多少时间还没有运行成功，就判定为Job执行失败。

• backoffLimit

  失败次数限制，跟下面的Pod重启策略相关。

• restartPolicy

  Job中Pod的重启策略，有两种值：OnFailure和Never

  OnFailure表示当Pod运行失败后，会重启该Pod本身（不会创建新Pod），最多重启backoffLimit次。重启的频率是指数性质增长的，时间间隔会越来越慢。

  Never表示当Pod运行失败后，不会重启Pod本身了，但是Job控制器会创建新的Pod，最多新建backoffLimit个新Pod。

• completions

  Pod的成功次数，completions可以设置为大于1，也就是批处理任务。

• parallelism

  当Job中设置的completions大于1时，为了提高运行效率，可以增加并行运行的个数。默认值为1，即串行运行Pod。

• ttlSecondsAfterFinished

  Job完成后多少秒后做清理操作，删掉Job运行记录。

CronJob

CronJob是定时任务，就是在job一次性任务的基础上加了一个时间调度，通过定期执行的策略来控制 Job 资源。

1

cronjob控制器 ———> job控制器 ———> Pod

下面是Job中的一些控制参数：

• spec.concurrencyPolicy

  spec.concurrencyPolicy 字段是可选的，声明 CronJob 创建的 Job 执行时发生重叠如何处理。有三种值Allow、Forbid、Replace

  • Allow

    允许并发 Job 执行。如果一个任务还没有结束，而下一次调度时间到了，新的任务会直接启动，新旧 Job 共存。

  • Forbid

    禁止并发 Job 执行。如果新 Job 的执行时间到了而旧 Job 没有完成，新 Job 不会启动。适用于只允许一个任务实例运行的场景。

  • Replace

    如果新 Job 的执行时间到了而旧 Job 没有完成，CronJob 会用新 Job 替换当前正在运行的 Job，旧 Job 会被终止掉。

• successfulJobsHistoryLimit

  保留多少个运行成功的CronJob的历史记录

• failedJobsHistoryLimit

  保留多少个运行失败的CronJob的历史记录