目录
一、Pod控制器类别
1.1 ReplicaSet
1.2 Deployment
1.3 DaemonSet
1.4 Job
1.5 CronJob
1.6 StatufulSet
1.7 CDR
1.8 Helm
二、ReplicaSet资源清单
三、Deployment资源清单
3.1 strategy(Pod更新策略)
3.2 revisionHistoryLimit
3.3 paused
3.4 template
3.5 Deployment资源清单示例
3.5.1 更新操作
3.5.2 通过打补丁的方式更新资源清单配置
3.5.3 暂停Pod更新
3.5.4 恢复Pod更新
3.5.5 回滚操作
四、DaemonSet资源清单
一、Pod控制器类别
1.1 ReplicaSet
ReplicaSet控制器用来管理无状态的Pod资源,核心作用在于代用户创建指定数量的Pod副本,并确保Pod副本数量一直等于用户期望的数量。而且还支持Pod滚动更新、及自动扩缩容等机制;它被称新一代的ReplicationCtroller。
ReplicaSet主要有三个组件组成:
- 用户期望的Pod副本数量;
- 标签选择器,用来选定由自己管理或控制的Pod副本,如果通过标签选择器挑选到的Pod少于定义的Pod副本数量,则会利用Pod资源模版来创建Pod副本,以达到规定的Pod数量;
- Pod资源模版。
但是Kubernetes却不建议用户直接使用ReplicaSet,而是应该使用Deployment。
1.2 Deployment
Deployment也是Pod控制器,但是它是工作在ReplicaSet之上的。Deployment是通过控制ReplicaSet,从而来控制Pod。Deployment能够提供比ReplicaSet更为强大的功能。比如:Pod版本回滚、声明式配置(声明式配置是已经创建的Pod可以随时更改配置并应用到Pod)。Deployment是目前管理无状态应用最好的控制器。
1.3 DaemonSet
DaemonSet用于确保集群中的每一个节点只运行一个特定的Pod副本,这种特定的Pod通常是用来实现系统级的后台任务。把这样的任务托管在Kubernetes之上的好处是:如果这个后台任务宕了以后,会由DaemonSet控制器自动重建一个Pod;新建一个Node节点,它也会在新节点上创建一个这样的Pod运行。
约束:我们也可以根据自己的需求,在K8S群集中的部分满足条件的节点上仅运行一个Pod副本。
总结: Deployment和DaemonSet管理的Pod中运行的服务都是无状态的,且是守护进程类的(必须始终持续运行在后台)。但是对于那种只希望运行一次就结束的任务,显然以上两种控制器是不能够使用的。例如:我们需要对数据库进行备份,备份结束后,任务就应该结束了,而不是让任务持续运行在后台。那么对于这种任务只运行一次,只要任务完成就正常退出,没有完成才会重建,这就应该选择使用Job这种控制器了。
1.4 Job
Job控制器控制只能执行一次作业的任务,它确保这个任务确实是正常完成而退出的,如果是异常退出,则Job控制器会重建任务再次执行直到任务正常完成。
那么对于周期性的任务呢?显然Job控制器也是无法胜任的。这就需要CronJob了。
1.5 CronJob
CronJob与Job类似,也是运行一次就退出。不同之处在于,Job是只运行一次,CronJob是周期性运行。但每次运行都会有正常退出的时间。如果前一次任务还没执行完成,又到了下一次任务执行的时间点了怎么办呢?CronJob也可以解决这种问题。
1.6 StatufulSet
StatufulSet控制器能够管理有状态的Pod副本,而且每一个Pod副本都是被单独管理的,它拥有自己独有的标志和独有的数据集。一旦这个副本故障了,在重建Pod之前会做许多初始化操作。以Redis群集为例:如果Redis集群中三个节点中的某一个节点宕机了,为了确保每个节点宕机后数据不丢失,我们传统的做法就是对每个节点做主从复制,当主节点宕机后,需要人为的把从节点提升为主节点,想要恢复从节点,就需要很多运维操作了。
但是利用StatufulSet去定义管理Redis或Mysql或者Zookeeper,它们的配置是不一样的。例如:配置管理Redis主从复制和配置管理Mysql主从复制中间的操作步骤是不一样的。所以这样的配置没有任何规律可循。StatufulSet给我们提供了一个封装,用户把需要人为操作的复杂的执行逻辑定义成脚本,放置在StatufulSet的Pod模板中。这样在每次Pod节点故障后,能通过脚本自动恢复过来。
总结:真正想把有状态的应用托管在Kubernetes之上,还是有相当的难度。
1.7 CDR
Custom Defined Resources K8S 1.8+,用户自定义资源。
1.8 Helm
任何不把用户当傻瓜的应用,都难以取得成功。K8S资源清单定义起来,门槛过高,难度大。这就诞生了Helm,Helm对于Kubernetes来说,就相当于Linux系统中的yum。以后在再部署大型的应用,就可以用Helm直接安装部署。不过Helm到目前为止,诞生也不超过两年的时间。到目前为止,许多大型主流的应用,已经可以通过Helm去部署。
二、ReplicaSet资源清单
ReplicaSet资源清单定义时的一级字段:
apiVersion: apps/v1
kind: ReplicaSet
metadata:
spec:
spec下一级核心字段主要的有三个:
replicas # 定义Pod副本数量
selector