一、工作负载控制器是什么？

二、Deploymennt控制器：介绍与部署应用

部署

三、Deployment控制器：滚动升级、零停机

方式一：

通个加入健康检查可以，看到，nginx容器逐个被替代，最终每个都升级完成，且发现nginx版本已经改变。

再次修改：

通过设置延迟健康检查时间，可以更慢的看到升级过程。

也可以通过kubectl describe deployment web,查看详细事件，看到升级过程

滚动更新，实质是利用了ReplicaSet控制器，时间最长的是第一次创建。一个Deployment升级时，关联了2个ReplicaSey,每次创建或更新都会创建一个新ReplicaSet,逐步将旧的副本数量降为0，新的副本数量升到配置的副本数量。

我们也可以提前配置滚动更新策略：

如果不指定更新策略，就是默认滚动更新策略：

还记得前面的kubectl get replicaset吗？

revisionHistoryLimit - 这个对应的就是replicaset数量，默认保存最新10个。

strategy.rollingUpdate.maxSurge: 25% - 我们之前不是正常副本数设置了3个，升级的时候，你可以发现启动了1个新的，这时变为4个pod了（既3+3*0.25=3.75,不够1个算1个=4），这个参数就是用来配置，滚动更新时，Pod的最大副本数量。

strategy.rollingUpdate.maxUnavailable: 25% - 滚动更新过程中，最大不可用Pod副本数量，比如总共10个副本，一下5个副本不可用，直接导致提供并发服务不够用了。这个参数在更新过程中，确保可用Pod数量。

一般默认滚动升级策略，就足够使用了。

四、Deployment控制器 - 发布失败回滚

这里，查看历史版本、回滚上一个版本，都没有明显标识，也不容易看出是回滚到哪个版本，所以一般升级的时候加个记录

查看历史版本就能看的使用的命令，但是说实话，还是不是那么明显可以看出升级的内容或信息。

这是你也可以采取第二种方式来升级更新，因为升级的镜像版本在命令行中，这样升级的内容就能记录到历史版本中，如下

但是在实际生产中，因为自带的回滚不是很好用，一般都是企业自己实现，说白了就是获取旧版本镜像重新部署。

还有一种方式，可以看到每个replicaset版本的内容

五、Deploymeny控制器：水平扩容与ReplicaSet关系

需要删除2个地方，1删除项目，2如果有service，需要删除service.

注：ReplicaSet控制器一直在死循环，这样保证Pod数量匹配配置的副本数量。

六、DaemonSet控制器：部署Node守护程序

与Deployment配置差别:

1.kind不同

2.DaemonSet不支持设置副本数量

这里只有k8s-node1、k8s-node2两个节点起了filebeat,而k8s-master节点没有部署filebeat,这是因为k8s-master设置有污点，修改下daemonSet.yaml

解释：

 tolerations:

 - effect: NoSchedule

   operator: Exists

只要节点存在，就容忍。

现在看，filebeat起了3个，k8s-master也起了一个filebeat。

七、Job控制器：执行一次性任务

Job本质也是一个Pod,所以如上图，也可以通过查看Pod，查看Job的运行状态。

注意： Job的Pod需要主动删除，因为k8s觉得这个结果可能需要保留使用，所以并没有删除。

八、CronJob控制器：定时任务

注意: cronjob也不会主动删除，需要你手动删除。