kubernetes的八种控制器
文章目录
前言:断更了19天今天终于又更新了=_=,断更的原因是因为我沉迷荒野大镖客2(PS:真好玩yyds)还有最近这几个周一直在看尚硅谷的MYSQL,感觉没什么能写在博客里面,后续的话,我会尝试把MYSQL高级的一些知识点写在博客里面~~
Foreword: it’s been broken for 19 days, and it’s finally updated today = =, The reason for the break is that I am addicted to the wilderness escort 2 (PS: it’s fun yyds) and have been watching MySQL in Shang Silicon Valley in recent weeks. I feel that nothing can be written in the blog. In the future, I will try to write some advanced knowledge points of MySQL in the blog
一、总体概述
- 工作负载类型的控制器根据业务需求管控Pod资源的生命周期
- ReplicaSet可以确保POD资源始终处于期望状态下的副本数,并支持POD规模的scale机制,它是新一代的ReplaicationController控制器(已被替代),不过用户不会特意去管理ReplicaSet控制器,而是直接使用Deployment直接管理ReplicasSet
- Deployment是构建在ReplicasSet之上更加抽象的工作负载控制器,为ReplicasSet提供声明式的更新机制,主要适用于无状态应用
- StatefulSet是专用于编排有状态应用的控制器,它借助Headless Service为每个Pod资源赋予一个固定的标识以识别每个POD实例,支持使用SC为每个POD对象附加专用的PVC存储卷以分别存储各自的数据
- DaemonSet控制器用于编排系统级应用,类似于守护进程的概念
- Job控制器能够控制相应的作业任务得以正常完成并退出,支持并行式多任务。
- CronJob控制器为job提供与未来某个时间点或者周期性的运行机制,看名字也知道与crontab类似。
- PDB资源对象为k8s系统上的容器化应用的可用性提供了保证,简单来说,就是不允许删除到指定数量,会报错的
二、分别介绍
2.1 ReplicasSet
感觉这个副本控制器没啥可介绍的,功能就是为了让POD一直保持预期的数量,when you delete a pod ,it wille be recreated.
值得一提的是,大家都以为pod的自动重建是deployment的功劳。实际上是deploy调用replicasset控制器实现的
2.2 更新策略
2.2.1 滚动更新
概念:应用更新能够不改变现有资源,而是创建一个有着新版本POD模板的新rs资源。
2.2.2 蓝绿部署
背景:
滚动更新过程中会存在两个不同版本的应用同时向客户端提供服务,且更新和回滚的过程耗时较长。
概念:
在旧版本rs资源运行的同时,创建一个全POD副本的新版本rs,带所有的pod就绪后,一次性的将客户端流量全部迁移到新副本上.
2.2.3 金丝雀更新
可以去百度下-矿井中的金丝雀
概念:
进行第一次更新后立即暂停部署操作,则生成的第一批POD就是金丝雀。
2.3 Deployment控制器
2.3.1 概念介绍:
deploy的只要职责同样是为了保证POD资源的健康运行,其大部分功能通过调用rs控制器实现,并增加了如下特性(与RS的区别)
- 事件和状态查看
- 版本纪录
- 回滚
- 暂停和启动
- 多种更新方案(一种是Recreate;另一种是RollingUpdate(default))
两种更新方式:
recreate(重建式更新):全部删除原有pod,一次性重建
rollingupdate:字面意思,滚动更新类似金丝雀
2.3.2 重要参数介绍
注意:POD对象的副本数少于4个的话,只能按照一次一个pod的方式进行
spec:
strategy:
rollingUpdate:
maxSurge: <int>
maxSurge:指定升级期间存在的总pod数量最多的个数,int类型
如果期望值=10,maxSurge=2,表示升级期间pod最多不超过12个
spec:
strategy:
rollingUpdate:
maxSurge: <int>
maxUnavailable: <int>
maxUnavailable:升级期间正常可用的pod副本数
2.4 应用更新与回滚 > rollout命令
这里记住几条命令就好了
kubectl rollout status deploy name
kubectl rollout history deploy name
kubectl rollout status deploy name
kubectl rollout status deploy name --to-revision
2.5 StatefulSet控制器
2.5.1 概念介绍:
一组具有唯一持久身份和稳定主机名的POD对象。适合部署redis集群,zookeeper集群这种分布式的架构应用。
一套完整的statefulset资源通常有两部分组成,Headless Service和StatefulSet资源。Headless service用于为各个POD资源固定、唯一的标识符生成可解析的DNS纪录,StatefulSet用于编排对象,通常搭配StorageClass去动态从生成pv。
2.5.2 注意点
- 按照索引顺序增加pod资源,删除的时候首先删除索引号最大的POD;
- 支持分区机制,可以按照索引号进行分区,选择更新哪个分区的POD,值得一提的是,如果大于当前期望值,则所有的都不会更新
- 关联对应的service资源时,需要添加spec.servicename:
<string>
2.5.3 重要参数介绍
spec:
updateStrategy:
type: #Ondelete RollingUpdate
rollingUpdate:
partition: <int>
partition:按照索引号分区
例子:当前pod 的实例为3
partition:3 所有pod不更新,partition:2时 web-2更新了
2.6 DaemonSet控制器
2.6.1 概念介绍
个人理解就是每台node上都会运行有且只有一个的daemonset的POD,类似于守护进程
2.6.2 注意点
- daemonset的实例数不受replicas控制,而受worker节点的数量控制,所以DaeonSet没有多实例的概念,只有多节点实例的概念
2.更新策略分为Ondelete RollingUpdate
2.7 JOB控制器
2.7.1 概念介绍
管理那些运行一段时间就能够完成的任务,例如计算或备份操作。
2.7.2 重要参数介绍
spec:
completions: <int> ##期待完成的作业次数,成功运行结束的POD数量
ttlSecondAfterFinished: <int> ##终止状态作业的生存时长,超期将被删除
parallelism: <int> ##作业的最大并行度,可以并行执行
backoffLimit: <int> ##重试次数
activeDeadlineSeconds: <int> ##作业启动后可处于活动状态的时长
2.8 CornJob控制器
定时任务,由spec.schedule 设置
2.9 POD的中断预算
限制自愿中断时最大可以中断的副本数,或者最少可以保持可用的副本数,从而保证应用自身的可用性,避免误操作
PS:没卵用。实际用不到了解就好