k8s-常用工作负载控制器(更高级管理Pod)

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

k8s-常用工作负载控制器(更高级管理Pod)_第1张图片

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

k8s-常用工作负载控制器(更高级管理Pod)_第2张图片

k8s-常用工作负载控制器(更高级管理Pod)_第3张图片

k8s-常用工作负载控制器(更高级管理Pod)_第4张图片

部署

k8s-常用工作负载控制器(更高级管理Pod)_第5张图片

k8s-常用工作负载控制器(更高级管理Pod)_第6张图片

k8s-常用工作负载控制器(更高级管理Pod)_第7张图片

k8s-常用工作负载控制器(更高级管理Pod)_第8张图片

k8s-常用工作负载控制器(更高级管理Pod)_第9张图片

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

k8s-常用工作负载控制器(更高级管理Pod)_第10张图片

方式一:

k8s-常用工作负载控制器(更高级管理Pod)_第11张图片

k8s-常用工作负载控制器(更高级管理Pod)_第12张图片

k8s-常用工作负载控制器(更高级管理Pod)_第13张图片

k8s-常用工作负载控制器(更高级管理Pod)_第14张图片

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

再次修改:

k8s-常用工作负载控制器(更高级管理Pod)_第15张图片

k8s-常用工作负载控制器(更高级管理Pod)_第16张图片

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

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

k8s-常用工作负载控制器(更高级管理Pod)_第17张图片

k8s-常用工作负载控制器(更高级管理Pod)_第18张图片

k8s-常用工作负载控制器(更高级管理Pod)_第19张图片

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

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

k8s-常用工作负载控制器(更高级管理Pod)_第20张图片

如果不指定更新策略,就是默认滚动更新策略:

k8s-常用工作负载控制器(更高级管理Pod)_第21张图片

还记得前面的kubectl get replicaset吗?

k8s-常用工作负载控制器(更高级管理Pod)_第22张图片

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控制器 - 发布失败回滚

k8s-常用工作负载控制器(更高级管理Pod)_第23张图片

k8s-常用工作负载控制器(更高级管理Pod)_第24张图片

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

k8s-常用工作负载控制器(更高级管理Pod)_第25张图片

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

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

k8s-常用工作负载控制器(更高级管理Pod)_第26张图片

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

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

k8s-常用工作负载控制器(更高级管理Pod)_第27张图片

k8s-常用工作负载控制器(更高级管理Pod)_第28张图片

k8s-常用工作负载控制器(更高级管理Pod)_第29张图片

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

k8s-常用工作负载控制器(更高级管理Pod)_第30张图片

k8s-常用工作负载控制器(更高级管理Pod)_第31张图片

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

k8s-常用工作负载控制器(更高级管理Pod)_第32张图片

k8s-常用工作负载控制器(更高级管理Pod)_第33张图片

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

六、DaemonSet控制器:部署Node守护程序k8s-常用工作负载控制器(更高级管理Pod)_第34张图片

与Deployment配置差别:

1.kind不同

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

k8s-常用工作负载控制器(更高级管理Pod)_第35张图片

k8s-常用工作负载控制器(更高级管理Pod)_第36张图片

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

k8s-常用工作负载控制器(更高级管理Pod)_第37张图片

解释:

 tolerations:

 - effect: NoSchedule

   operator: Exists

只要节点存在,就容忍。

k8s-常用工作负载控制器(更高级管理Pod)_第38张图片

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

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

k8s-常用工作负载控制器(更高级管理Pod)_第39张图片

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

k8s-常用工作负载控制器(更高级管理Pod)_第40张图片

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

八、CronJob控制器:定时任务

k8s-常用工作负载控制器(更高级管理Pod)_第41张图片

k8s-常用工作负载控制器(更高级管理Pod)_第42张图片

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

你可能感兴趣的:(k8s,kubernetes,运维,容器)