一、工作负载控制器是什么？
二、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也不会主动删除，需要你手动删除。
