简介

Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 组成， 是 Kubernetes 的大脑， 它通过 apiserver 监控整个集群的状态， 并确保集群处于预期的工作状态。

kube-controller-manager 由一系列的控制器组成

1 Replication Controller
2 Node Controller
3 CronJob Controller
4 DaemonSet Controller
5 Deployment Controller
6 Endpoint Controller
7 Garbage Collector
8 Namespace Controller
9 Job Controller
10 Pod AutoScaler
11 RelicaSet
12 Service Controller
13 ServiceAccount Controller
14 StatefulSet Controller
15 Volume Controller
16 Resource quota Controller

cloud-controller-manager 在 Kubernetes 启用 Cloud Provider 的时候才需要， 用来配合云服务提供商的控制， 也包括一系列的控制器

1 Node Controller
2 Route Controller
3 Service Controller

从v1.6开始，cloud provider已经经历了几次重大重构，以便在不修改Kubernetes核心代码的同时构建 自定义的云服务商支持。

常见Pod控制器及含义

ReplicaSet:适合无状态的服务部署

用户创建指定数量的pod副本数量，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。
ReplicaSet主要三个组件组成：
（1）用户期望的pod副本数量
（2）标签选择器，判断哪个pod归自己管理
（3）当现存的pod数量不足，会根据pod资源模板进行新建
帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是 ReplicaSet不是直接使用的控制器，而是使用Deployment。

Deployment：适合无状态的服务部署

工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。

无状态服务：比如tomcat· 、nginx等等；

StatefullSet：适合有状态的服务部署。

有状态服务：比如mysql等等；

后续再系统为大家讲解，敬请关注；

DaemonSet：一次部署，所有的node节点都会部署

例如一些典型的应用场景

• 运行集群存储 daemon，例如在每个Node上运行 glusterd(集群信息管理系统)、ceph(分布式存储系统)；
• 在每个Node上运行日志收集 daemon，例如 fluentd、 logstash；
• 在每个Node上运行监控 daemon，例如 Prometheus Node Exporter；

用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务
特性：服务是无状态的；
服务必须是守护进程；

Job：一次性的执行任务。 只要完成就立即退出，不需要重启或重建。

Cronjob：周期性的执行任务。 周期性任务控制，不需要持续后台运行。

演示

Replication Controller控制器

Replication controller简称RC，是kubernetes系统中的核心概念之一，简单来说，它其实定义了一个期望的场景，即声明某种pod的副本数量在任意时刻都复合某个预期值，所以RC的定义包含以下部分：

• pod期待的副本数量 ；
• 用于筛选目标pod的Label Selector；
• 当pod的副本数量小于期望值时，用于创建新的pod的pod模板（template）；

ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收。

ReplicaSet

简称RS,在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationController。ReplicaSet跟ReplicationController没有本质的不同，只是名字不一样，并且ReplicaSet支持集合式的selector。

虽然ReplicaSet可以独立使用，但一般还是建议使用 Deployment 来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如ReplicaSet不支持rolling-update(滚动升级)但Deployment支持）。

ReplicaSet模板

apiVersion: apps/v1 #api版本定义
kind: ReplicaSet #定义资源类型为ReplicaSet
metadata:    #元数据定义
  name: replicasetdemo
  labels:
    app: replicasetdemo
spec:          #ReplicaSet的规格定义
  replicas: 1   #定义副本数量为1个
  template:     #pod的模板定义
    metadata:   #pod的元数据定义
      name: replicasetdemo  #自定义pod的名称
      labels:             #定义pod的标签，需要和下面定义的标签一致
        app: replicasetdemo
    spec:         #pod的规格定义
      containers:  #容器定义
        - name: replicasetdemo  #容器名称
          image: nginx:1.17.10-alpine #容器镜像
          imagePullPolicy: IfNotPresent
          ports:   #暴露端口
            - containerPort: 80
      restartPolicy: Always
  selector:   #标签选择器，定义匹配pod的标签
    matchLabels:
      app: replicasetdemo

可以通过kubectl命令行方式获取更加详细信息

kubectl explain rs
kubectl explain rs.spec
kubectl explain rs.spec.template.spec

运行ReplicaSet

##运行ReplicaSet
kubectl apply -f replicasetdemo.yml
##查看rs控制器
kubectl get rs
##查看pod信息
kubectl get pod
##查看pod详细信息
kubectl describe pod replicasetdemo-2ngw6
##测试controller控制器下的pod删除、重新被controller控制器拉起
kubectl delete pod --all
kubectl get pod
##修改pod的副本数量:通过命令行方式
kubectl scale replicaset replicasetdemo --replicas=8
kubectl get rs
##修改pod的副本数量:通过资源清单方式 将replicas改为3
kubectl edit replicasets.apps replicasetdemo
kubectl get rs
##显示pod的标签
kubectl get pod --show-labels
##修改pod标签(label)
kubectl label pod replicasetdemo-652lc app=bcst --overwrite=True
##再次显示pod的标签：发现多了一个pod，原来的rs中又重新拉起一个pod，说明rs是通过label去管理pod
kubectl get pod --show-labels
##删除rs
kubectl delete rs replicasetdemo

修改pod的副本数量

pod的标签

注：官方给出的解释是RS通过labels或者一组label管理,所以上面三个pod都归这组label管理；

那如果pod的label 名称不一样呢？下面修改下：

删除rs

总结

kubectl命令行工具适用于RC的绝大部分命令同样适用于ReplicaSet，此外，我们当前很少单独使用 ReplicaSet，它主要被Deployment这个更高层的资源对象所使用，从而形成一整套Pod创建，删除， 更新的编排机制，我们在使用Deployment时无需关心它是如何维护和创建ReplicaSet的，这一切都是自动发生的；

最后，总结一下RS（ReplicaSet）的一些特性和作用：

• 在绝大多数情况下，我们通过定义一个RS实现Pod的创建及副本数量的自动控制
• 在RS里包括完整的Pod定义模板
• RS通过Label Selector机制实现对Pod副本的自动控制
• 通过改变RS里的Pod副本数量，可以实现Pod的扩容和缩容
• 通过改变RS里Pod模板中的镜像版本，可以实现滚动升级

Deployment

Deployment是kubernetes在1.2版本中引入的新概念，用于更好的解决Pod的编排问题，为此， Deployment在内部使用了ReplicaSet来实现目的，我们可以把Deployment理解为ReplicaSet的一次升级，两者的相似度超过90% 。

Deployment的使用场景：

• 创建一个Deployment对象来生成对应的ReplicaSet并完成Pod副本的创建；
• 检查Deployment的状态来看部署动作是否完成（Pod副本数量是否达到了预期的值）；
• 更新Deployment以创建新的Pod（比如镜像升级）；
• 如果当前Deployment不稳定，可以回滚到一个早先的Deployment版本；
• 暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment， 进行新的发布 ；
• 扩展Deployment以应对高负载 ；
• 查看Deployment的状态，以此作为发布是否成功的标志；
• 清理不在需要的旧版本ReplicaSet ；

Deployment模板说明

可以通过kubectl命令行方式获取更加详细信息

kubectl explain deploy
kubectl explain deploy.spec
kubectl explain deploy.spec.template.spec

部署Deployment

除了API生命与Kind类型有区别，Deployment的定义与Replica Set的定义很类似。 controller/deploymentdemo.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-demo
  labels:
    app: deployment-demo
spec:
  replicas: 3
  template:
    metadata:
      name: deployment-demo
      labels:
        app: deployment-demo
    spec:
      containers:
        - name: deployment-demo
          image: nginx:1.17.10-alpine
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
      restartPolicy: Always
  selector:
    matchLabels:
      app: deployment-demo

运行Deployment

kubectl apply -f deploymentdemo.yml
#查看deployment
kubectl get rs
#查看rs:deployment名称+hashcode码组成
#查看pod
kubectl get pod -o wide

总结：当我们创建一个deployment是，deployment里面是包含RS的，RS里面又包含对应的pod,DESIRED为3是表示用户期望的pod副本数。

镜像更新升级

命令行方式

#升级nginx镜像版本为1.18.0
kubectl set image deployment deployment-demo  deployment-demo=nginx:1.18.0-alpine
#查看pod升级情况
kubectl get pods -w
#进去某一个pod内部，查看nginx升级版本信息
kubectl exec -it deployment-demo-5d49f86785-ht4ww sh
nginx -v
exit

yml文件方式

#升级nginx镜像版本为1.19.2-alpine
 kubectl edit deployments.apps deployment-demo 
#查看pod升级情况
kubectl get pods -w
#进去某一个pod内部，查看nginx升级版本信息
kubectl exec -it deploymentdemo1-584f6b54dd-4l62t sh
nginx -v
exit

Deployment扩容

命令行方式

kubectl scale deployment deployment-demo --replicas= 5
kubectl get pod -w

yml文件方式

#更新 replicas: 5
kubectl edit deployments.apps deployment-demo 

滚动更新

概述

微服务部署：蓝绿部署、滚动部署、灰度发布、金丝雀发布。

1. 蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。 蓝绿部署无需停机，并且风险较小。
2. 滚动发布：一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。 这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。
3. 灰度发布：是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。

金丝雀发布

Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用， 主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布(Canary Release)。

#更新deployment的nginx:1.18.0-alpine版本，并配置暂停deployment
kubectl set image deployment deployment-demo deployment-demo=nginx:1.18.0-alpine && kubectl rollout pause deployment deployment-demo 
#观察更新状态
kubectl rollout status deployment deployment-demo 

#监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是
#因为使用了pause暂停命令
kubectl get pods -l app=deployment-demo -w
#查看pod标签
 kubectl get pod --show-labels
#确保更新的pod没问题了，继续更新
kubectl rollout resume deploy deployment-demo 
#查看最后的更新情况
kubectl get pods -l app=deployment-demo  -w

#进去某一个pod内部，查看nginx更新版本信息
kubectl exec -it deployment-demo-5d49f86785-ncv5p sh
nginx -v

Deployment版本回退

概述

默认情况下，kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录，以便可以随时回退（您可以修改 revision history limit 来更改保存的revision数）。

注意： 只要 Deployment 的 rollout 被触发就会创建一个 revision。也就是说当且仅当 Deployment 的 Pod template（如 .spec.template ）被更改，例如更新template 中的 label 和容器镜像时，就会创建出一个新的 revision。

其他的更新，比如扩容 Deployment 不会创建 revision——因此我们可以很方便的手动或者自动扩容。 这意味着当您回退到历史 revision 时，只有 Deployment 中的 Pod template 部分才会回退。

rollout常见命令

history操作

#查看历史版本信息
kubectl rollout history deployment deployment-demo 

status操作

kubectl rollout status deployment deployment-demo 

undo操作

#回滚到上一个版本
kubectl rollout undo deployment deployment-demo
#kubectl rollout undo deployment deployment-demo --to-revision=1   
#回滚到版本1，需要指定namespace，“--to-revision”是指定回滚到哪个版本
#查看pod回滚情况
kubectl get pods -w
#进去某一个pod内部，查看nginx回滚版本信息
kubectl exec -it deploymentdemo1-df6bc5d4c-flc7b sh
nginx -v

Deployment 更新策略

Deployment可以保证在升级时只有一定数量的Pod 是down 的。默认的，它会确保至少有比期望的Pod数量少

Deployment 同时也可以确保只创建出超过期望数量的一定数量的Pod。默认的，它会确保最多比期望 的Pod数

Kuberentes 版本v1.17.5中，从1-1变成25%-25%

kubectl describe deployments.apps deployment-demo
#查看到属性：
RollingUpdateStrategy: 25% max unavailable, 25% max surge

总结

Deployment为Pod和ReplicaSet（下一代Replication Controller）提供声明式更新。 只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和 ReplicaSet 的实际状态改变到您的目标状态。也可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。

Replicas（副本数量）：

.spec.replicas 是可以选字段，指定期望的pod数量，默认是1。

Selector（选择器）：

.spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。

The Deployment "nodeportdemo" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"nodeportdemo-test"}: `selector` does not match template `labels`

如果 .spec.selector 没有被指定， .spec.selector.matchLabels 默认是.spec.template.metadata.labels。 在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下， Deployment会杀掉label跟selector不同的Pod。

Pod Template（Pod模板）

.spec.template 是 .spec中唯一要求的字段。 .spec.template 是 pod template. 它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要 apiVersion 和 kind字段。

另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他 controller重复了，参考selector）和适当的重启策略。

.spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。

strategy（更新策略）

.spec.strategy 指定新的Pod替换旧的Pod的策略。 .spec.strategy.type 可以是"Recreate"或者是 "RollingUpdate"。"RollingUpdate"是默认值。

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

rollingUpdate：滚动更新，简单定义更新期间pod最多有几个等。可以指定 maxUnavailable 和 maxSurge 来控制 rolling update 进程。

maxSurge： .spec.strategy.rollingUpdate.maxSurge 是可选配置项，用来指定可以超过期望的Pod数量的最大个数。该值可以是一个绝对值（例如5）或者是期望的Pod数量的百分比（例如 10%）。当 MaxUnavailable 为0时该值不可以为0。通过百分比计算的绝对值向上取整。默认值是1。

例如，该值设置成30%，启动rolling update后新的ReplicatSet将会立即扩容，新老Pod的总数不能超过期望的Pod数量的130%。旧的Pod被杀掉后，新的ReplicaSet将继续扩容，旧的ReplicaSet会进 一步缩容，确保在升级的所有时刻所有的Pod数量和不会超过期望Pod数量的130%。

maxUnavailable： .spec.strategy.rollingUpdate.maxUnavailable 是可选配置项，用来指定在升级过程中不可用Pod的最大数量。该值可以是一个绝对值（例如5）,也可以是期望Pod数量的百分比（例如10%）。通过计算百分比的绝对值向下取整。 如果 .spec.strategy.rollingUpdate.maxSurge 为0时，这个值不可以为0。默认值1。

例如，该值设置成30%，启动rolling update后旧的ReplicatSet将会立即缩容到期望的Pod数量的 70%。新的Pod ready后，随着新的ReplicaSet的扩容，旧的ReplicaSet会进一步缩容确保在升级的所有时刻可以用的Pod数量至少是期望Pod数量的70%。

progressDeadlineSeconds

.spec.progressDeadlineSeconds 是可选配置项，用来指定在系统报告Deployment的failed progressing——表现为resource的状态中 type=Progressing 、 Status=False 、 Reason=ProgressDeadlineExceeded 前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来，在实现了自动回滚后， deployment controller在观察到 这种状态时就会自动回滚。

如果设置该参数，该值必须大于 .spec.minReadySeconds 。

paused

.spec.paused 是可以可选配置项，boolean值。用来指定暂停和恢复Deployment。Paused和没有 paused的Deployment之间的唯一区别就是，所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。

可通过 kubectl explain deploy.spec查看模板说明

DaemonSet

DaemonSet 确保全部Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一 个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

在每一个node节点上只调度一个Pod，因此无需指定replicas的个数，比如：

• 在每个node上都运行一个日志采集程序，负责收集node节点本身和node节点之上的各个Pod所产生的日志

(ELK)

• 在每个node上都运行一个性能监控程序，采集该node的运行性能数据 (Prometheus)

DaemonSet模板说明

可以通过kubectl命令行方式获取更加详细信息

kubectl explain daemonset
kubectl explain daemonset.spec
kubectl explain daemonset.spec.template.spec

部署DaemonSet

controller/daemonsetdemo.yml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-test-demo
  labels:
    app: daemonset-demo
spec:
  template:
    metadata:
      name: daemonset-demo
      labels:
        app: daemonset-demo
    spec:
      containers:
        - name: daemonset-demo
          image: nginx:1.17.10-alpine
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
      restartPolicy: Always
  selector:
    matchLabels:
      app: daemonset-demo

运行DaemonSet

#运行demonset
kubectl apply -f demonsetdemo.yml
kubectl get daemonset
#查看pod详细信息：只有工作节点创建pod，master节点并不会创建。
kubectl get pod -o wide

DaemonSet的滚动更新

DaemonSet有两种更新策略类型：

• OnDelete：这是向后兼容性的默认更新策略。使用OnDelete 更新策略，在更新DaemonSet模板 后，只有在手动删除旧的DaemonSet pod时才会创建新的DaemonSet pod。这与Kubernetes 1.5或更早版本中DaemonSet的行为相同。
• RollingUpdate：使用 RollingUpdate 更新策略，在更新DaemonSet模板后，旧的DaemonSet pod将被终止，并且将以受控方式自动创建新的DaemonSet pod。

可通过kubectl explain daemonset.spec.updateStrategy 查看模板说明

修改yml文件

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-test-demo
  labels:
    app: daemonset-demo
spec:
  updateStrategy:
    type: "RollingUpdate" #指定滚动更新策略
    rollingUpdate:
      maxUnavailable: 2 #升级过程中不可用Pod的最大数量
  template:
    metadata:
      name: daemonset-demo
      labels:
        app: daemonset-demo
    spec:
      containers:
        - name: daemonset-demo
          image: nginx:1.17.10-alpine
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
      restartPolicy: Always
  selector:
    matchLabels:
      app: daemonset-demo

Job

概述

Job负责处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束

应用场景：

• 如离线数据处理;
• 视频解码等业务

Job模板说明

kubectl explain job
kubectl explain job.spec

部署Job

controller/jobdemo.yml

apiVersion: batch/v1
kind: Job
metadata:
  name: jobdemo
  labels:
    app: jobdemo
spec:
  template:
    metadata:
      name: jobdemo
      labels:
        app: jobdemo
    spec:
      containers:
        - name: jobdemo
          image: busybox:1.32.0
          imagePullPolicy: IfNotPresent
          command: ["/bin/echo"]
          args: ["hello", "world"]
      restartPolicy: Never
  activeDeadlineSeconds: 15 #设置 Pod 运行的超时时间
  backoffLimit: 2  #设置 Pod 的失败重试次数
  completions: 3 #Job 完成需要运行多少个 Pod，默认是 1 个
  parallelism: 2 #它与 completions 相关，表示允许并发运行的 Pod 数量，避免过多占用资源

activeDeadlineSeconds，设置 Pod 运行的超时时间。

backoffLimit，设置 Pod 的失败重试次数。

completions，Job 完成需要运行多少个 Pod，默认是 1 个。

parallelism，它与 completions 相关，表示允许并发运行的 Pod 数量，避免过多占用资源。

运行job

kubectl apply -f jobdemo.yml 
kubectl get job
#删除job
kubectl delete -f jobdemo.yml
kubectl delete job jobdemo

CronJob

CronJob则就是在Job上加上了时间调度

概述

Kind是CronJob了，要注意的是.spec.schedule字段是必须填写的，用来指定任务运行的周期，另外一个字段是.spec.jobTemplate, 用来指定需要运行的任务，格式当然和Job是一致的。还有一些值得我们关注的字段.spec.successfulJobsHistoryLimit和.spec.failedJobsHistoryLimit，表示历史限制，是可选的字段。它们指定了可以保留多少完成和失败的Job，默认没有限制，所有成功和失败的Job都会被保留。然而，当运行一个Cron Job时，Job可以很快就堆积很多，所以一般推荐设置这两个字段的值。如果设置限制的值为 0，那么相关类型的Job完成后将不会被保留。

CronJob模板说明

kubectl explain CronJob

部署CronJob

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cron-jobdemo
  labels:
    app:  cron-jobdemo
spec:
  schedule: '*/1 * * * *' #1分钟执行一次
    successfulJobsHistoryLimit: 1
  failedJobsHistoryLimit: 1
  startingDeadlineSeconds: 60  #CronJob 控制器将测量从预期创建作业到现在之间的时间。如果差异高于该限制，它将跳过此执行。 例如，如果设置为200，则它允许在实际计划后最多 200 秒内创建作业。
  jobTemplate:
    spec:
      template:
        metadata:
          name: cron-jobdemo
          labels:
            app: cron-jobdemo
        spec:
          containers:
            - name: cron-jobdemo
              image: busybox:1.32.0
              imagePullPolicy: IfNotPresent
              command: ["/bin/echo"]
              args: ["hello", "world"]
          restartPolicy: Never
      backoffLimit: 4

backoffLimit说明

.spec.backoffLimit用于设置Job的容错次数，默认值为6。当Job运行的Pod失败次数到 达.spec.backoffLimit次时，Job Controller不再新建Pod，直接停止运行这个Job，将其运行结 果标记为Failure。另外，Pod运行失败后再次运行的时间间隔呈递增状态，例如10s，20s， 40s。。。

运行CronJob

kubectl apply -f cronjobdemo.yml
kubectl get CronJob

注：因为没有指定successfulJobsHistoryLimit会周期的创建pod执行任务

StatefulSet

在kubernetes系统中，Pod的管理对象RC，Deployment，DaemonSet和Job都面向无状态的服务，但 现实中有很多服务时有状态的，比如一些集群服务，例如mysql集群，集群一般都会有这四个特点：

1. 每个节点都是有固定的身份ID，集群中的成员可以相互发现并通信
2. 集群的规模是比较固定的，集群规模不能随意变动
3. 集群中的每个节点都是有状态的，通常会持久化数据到永久存储中
4. 如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损

如果你通过RC或Deployment控制Pod副本数量来实现上述有状态的集群，就会发现第一点是无法满足 的，因为Pod名称和ip是随机产生的，并且各Pod中的共享存储中的数据不能都动，因此StatefulSet在 这种情况下就派上用场了，那么StatefulSet具有以下特性：

• StatefulSet里的每个Pod都有稳定，唯一的网络标识，可以用来发现集群内的其它成员，假设， StatefulSet的名称为BCST，那么第1个Pod叫BCST-0，第2个叫BCST-1，以此类推
• StatefulSet控制的Pod副本的启停顺序是受控的，操作第N个Pod时，前N-1个Pod已经是运行且准备状态
• StatefulSet里的Pod采用稳定的持久化存储卷，通过PV或PVC来实现，删除Pod时默认不会删除与 StatefulSet相关的存储卷（为了保证数据的安全）

StatefulSet除了要与PV卷捆绑使用以存储Pod的状态数据，还要与Headless，Service配合使用，每个 StatefulSet定义中都要生命它属于哪个Handless Service，Handless Service与普通Service的关键区别 在于，它没有Cluster IP

注：本期大家只是对StatefulSet做个了解，后期我这边再深入为大家讲解；