热门标签
热门文章
- 1上标和下标复制大全（含0~9、字母、特殊字符）_26个迷你小字母右上角
- 2一起自学SLAM算法：第3章-OpenCV图像处理_opencv slam
- 3基于文本模式的主题模式识别_根据内容 识别主题
- 4如何通过pycharm连接Windows Subsystem for Linux (WSL)_pycharm连接wsl
- 5上传文件new Blob_new blob type参数
- 6LeetCode69. x 的平方根(C++)
- 7idea ssh远程连接阿里云服务器失败（拒绝连接）的解决方法_failed to connect to ide backend: invalid credenti
- 8什么是多进程-多线程-多协程 ----进程和多进程
- 9CocosCreator Http、WebSocket、SocketIO用法_cocos creator 网络请求
- 10LeakyReLU激活函数_leakyrelu函数
当前位置: article > 正文
Kubernetes学习笔记（二）：Pod控制器详解：资源元信息、ReplicaSet、Deployment、DaemonSet、Job、CronJob_pod deployment replicaset区别
作者：花生_TL007 | 2024-02-28 21:51:28
赞
踩
pod deployment replicaset区别
1、资源元信息
Kubernetes的资源对象组成：主要包括了Spec、Status两部分。其中Spec部分用来描述期望的状态，Status部分用来描述观测到的状态
Kubernetes的元数据部分。该部分主要包括了用来识别资源的标签：Label；用来描述资源的注解：Annotation；用来描述多个资源之间相互关系的OwnerReference
1）、Label
Label是Kubernetes系统中的一个重要概念。它的作用就是在资源上添加标识，用来对它们进行区分和选择
Label的特点：
- 一个Label会以key/value键值对的形式附加到各种对象上，如Node、Pod、Service等等
- 一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去
- Label通常在资源对象定义时确定，当然也可以在对象创建后动态添加或者删除
可以通过Label实现资源的多维度分组，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作
一些常用的Label示例如下：
- 版本标签：“version”:“release”，“version”:“stable”
- 环境标签：“environment”:“dev”，“environment”:“test”，“environment”:“pro”
- 架构标签：“tier”:“frontend”，“tier”:“backend”
标签定义完毕之后，还要考虑到标签的选择，这就要使用到Label Selector，即：
-
Label用于给某个资源对象定义标识
-
Label Selector用于查询和筛选拥有某些标签的资源对象
当前有两种Label Selector：
-
基于等式的Label Selector
name = slave：选择所有包含Label中key="name"且value="slave"的对象env != production：选择所有包括Label中的key="env"且value不等于"production"的对象 -
基于集合的Label Selector
name in (master, slave)：选择所有包含Label中的key="name"且value="master"或"slave"的对象name not in (frontend)：选择所有包含Label中的key="name"且value不等于"frontend"的对象
标签的选择条件可以使用多个，此时将多个Label Selector进行组合，使用逗号","进行分隔即可。例如：
name = slave, env != production
name not in (frontend), env != production
1）命令方式
创建pod-label.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-label
namespace: dev
spec:
containers:
- image: nginx:1.17.1
name: pod
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
# 创建Pod [root@k8s-master ~]# kubectl create -f pod-label.yaml pod/pod-label created # 为pod资源打标签 [root@k8s-master ~]# kubectl label pod pod-label version=1.0 -n dev pod/pod-label labeled [root@k8s-master ~]# kubectl get pod pod-label -n dev --show-labels NAME READY STATUS RESTARTS AGE LABELS pod-label 1/1 Running 0 78s version=1.0 # 为pod资源更新标签 [root@k8s-master ~]# kubectl label pod pod-label version=2.0 -n dev --overwrite pod/pod-label labeled [root@k8s-master ~]# kubectl get pod pod-label -n dev --show-labels NAME READY STATUS RESTARTS AGE LABELS pod-label 1/1 Running 0 2m4s version=2.0 # 筛选标签 [root@k8s-master ~]# kubectl get pod -n dev -l version=2.0 --show-labels NAME READY STATUS RESTARTS AGE LABELS pod-label 1/1 Running 0 2m46s version=2.0 # 删除标签 [root@k8s-master ~]# kubectl label pod pod-label version- -n dev pod/pod-label labeled [root@k8s-master ~]# kubectl get pod pod-label -n dev --show-labels NAME READY STATUS RESTARTS AGE LABELS pod-label 1/1 Running 0 3m29s <none>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
2）配置方式
修改pod-label.yaml文件，修改后内容如下：
apiVersion: v1 kind: Pod metadata: name: pod-label namespace: dev labels: version: "3.0" env: "test" spec: containers: - image: nginx:1.17.1 name: pod ports: - name: nginx-port containerPort: 80 protocol: TCP
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
# 更新Pod
[root@k8s-master ~]# kubectl apply -f pod-label.yaml
pod/pod-label configured
[root@k8s-master ~]# kubectl get pod pod-label -n dev --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-label 1/1 Running 0 5m17s env=test,version=3.0
- 1
- 2
- 3
- 4
- 5
- 6
- 7
2）、Annotation
Annotations一般是系统或者工具用来存储资源的非标示性信息，可以用来扩展资源的spec/status的描述
3）、Ownereference
Ownereference一般就是指集合类的资源，比如说Pod集合，就有replicaset、statefulset
集合类资源的控制器会创建对应的归属资源。比如：replicaset控制器在操作中会创建Pod，被创建Pod的Ownereference就指向了创建Pod的replicaset，Ownereference使得用户可以方便地查找一个创建资源的对象，另外，还可以用来实现级联删除的效果
2、Pod控制器介绍
Pod是Kubernetes的最小管理单元，在Kubernetes中，按照Pod的创建方式可以将其分为两类：
- 自主式Pod：Kubernetes直接创建出来的Pod，这种Pod删除后就没有了，也不会重建
- 控制器创建的Pod：Kubernetes通过控制器创建的Pod，这种Pod删除了之后还会自动重建
什么是Pod控制器？
Pod控制器是管理Pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod
在Kubernetes中，有很多类型的Pod控制器，每种都有自己的适合的场景，常见的有下面这些：
- ReplicationController：比较原始的Pod控制器，已经被废弃，由ReplicaSet替代
- ReplicaSet：保证副本数量一直维持在期望值，并支持Pod数量扩缩容，镜像版本升级
- Deployment：通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本
- DaemonSet：在集群中的指定Node上运行且仅运行一个副本，一般用于守护进程类的任务
- Job：它创建出来的Pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务
- CronJob：它创建的Pod负责周期性任务控制，不需要持续后台运行
- StatefulSet：管理有状态应用
3、ReplicaSet（RS）
1）、ReplicaSet定义
ReplicaSet的主要作用是保证一定数量的Pod正常运行，它会持续监听这些Pod的运行状态，一旦Pod发生故障，就会重启或重建。同时它还支持对pod数量的扩缩容和镜像版本的升降级
ReplicaSet的资源清单文件：
apiVersion: apps/v1 # 版本号 kind: ReplicaSet # 类型 metadata: # 元数据 name: # rs名称 namespace: # 所属命名空间 labels: # 标签 controller: rs spec: # 详情描述 replicas: 3 # 副本数量 selector: # 选择器，通过它指定该控制器管理哪些pod matchLabels: # Labels匹配规则 app: nginx-pod matchExpressions: # Expressions匹配规则 - {key: app, operator: In, values: [nginx-pod]} template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本 metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.17.1 ports: - containerPort: 80
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
在这里面，需要新了解的配置项就是spec下面几个选项：
-
replicas：指定副本数量，其实就是当前RS创建出来的Pod的数量，默认为1
-
selector：选择器，它的作用是建立Pod控制器和Pod之间的关联关系，采用的Label Selector机制，在Pod模板上定义Label，在控制器上定义选择器，就可以表明当前控制器能管理哪些Pod了
-
template：模板，就是当前控制器创建Pod所使用的模板，就是Pod的定义
2）、创建ReplicaSet
创建pc-replicaset.yaml文件，内容如下：
apiVersion: apps/v1 kind: ReplicaSet metadata: name: pc-replicaset namespace: dev spec: replicas: 3 selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.17.1
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
# 创建rs [root@k8s-master ~]# kubectl create -f pc-replicaset.yaml replicaset.apps/pc-replicaset created # 查看rs # DESIRED:期望副本数量 # CURRENT:当前副本数量 # READY:已经准备好提供服务的副本数量 [root@k8s-master ~]# kubectl get rs pc-replicaset -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR pc-replicaset 3 3 3 25s nginx nginx:1.17.1 app=nginx-pod # 查看当前控制器创建出来的pod # 这里发现控制器创建出来的pod的名称是在控制器名称后面拼接了-xxxxx随机码 [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-8hjrb 1/1 Running 0 58s pc-replicaset-jx8zb 1/1 Running 0 58s pc-replicaset-r56fn 1/1 Running 0 58s
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
3）、扩缩容
# 编辑rs的副本数量，修改spec:replicas: 6即可 [root@k8s-master ~]# kubectl edit rs pc-replicaset -n dev replicaset.apps/pc-replicaset edited # 查看pod [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-2tnmm 1/1 Running 0 12s pc-replicaset-8hjrb 1/1 Running 0 6m4s pc-replicaset-jx8zb 1/1 Running 0 6m4s pc-replicaset-lqv6z 1/1 Running 0 12s pc-replicaset-q8p5w 1/1 Running 0 12s pc-replicaset-r56fn 1/1 Running 0 6m4s # 使用scale命令实现扩缩容，后面--replicas=n直接指定目标数量即可 [root@k8s-master ~]# kubectl scale rs pc-replicaset --replicas=2 -n dev replicaset.apps/pc-replicaset scaled # 命令运行完毕，立即查看，发现已经有4个开始准备退出了 [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-2tnmm 0/1 Terminating 0 76s pc-replicaset-8hjrb 0/1 Terminating 0 7m8s pc-replicaset-jx8zb 0/1 Terminating 0 7m8s pc-replicaset-lqv6z 0/1 Terminating 0 76s pc-replicaset-q8p5w 1/1 Running 0 76s pc-replicaset-r56fn 1/1 Running 0 7m8s # 稍等片刻，就只剩下2个了 [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-q8p5w 1/1 Running 0 101s pc-replicaset-r56fn 1/1 Running 0 7m33s
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
4）、镜像更新
# 编辑rs的容器镜像 - image: nginx:1.17.2 [root@k8s-master ~]# kubectl edit rs pc-replicaset -n dev replicaset.apps/pc-replicaset edited # 再次查看，发现镜像版本已经变更了 [root@k8s-master ~]# kubectl get rs -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR pc-replicaset 2 2 2 36m nginx nginx:1.17.2 app=nginx-pod # kubectl set image rs rs名称 容器=镜像版本 -n namespace [root@k8s-master ~]# kubectl set image rs pc-replicaset nginx=nginx:1.17.1 -n dev replicaset.apps/pc-replicaset image updated # 再次查看，发现镜像版本已经变更了 [root@k8s-master ~]# kubectl get rs -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR pc-replicaset 2 2 2 37m nginx nginx:1.17.1 app=nginx-pod
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
5）、删除ReplicaSet
# 使用kubectl delete命令会删除此rs以及它管理的pod
# 在Kubernetes删除rs前，会将rs的replicas调整为0，等待所有的pod被删除后，在执行rs对象的删除
[root@k8s-master ~]# kubectl delete rs pc-replicaset -n dev
replicaset.apps "pc-replicaset" deleted
[root@k8s-master ~]# kubectl get pod -n dev
No resources found in dev namespace.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
# 如果希望仅仅删除RS对象(保留Pod)，可以使用kubectl delete命令时添加--cascade=false选项(不推荐)
[root@k8s-master ~]# kubectl delete rs pc-replicaset -n dev --cascade=false
replicaset.apps "pc-replicaset" deleted
[root@k8s-master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-replicaset-dmhbh 1/1 Running 0 2m35s
pc-replicaset-mr9l8 1/1 Running 0 2m35s
pc-replicaset-pj6mp 1/1 Running 0 2m35s
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
# 也可以使用yaml直接删除(推荐)
[root@k8s-master ~]# kubectl delete -f pc-replicaset.yaml
replicaset.apps "pc-replicaset" deleted
- 1
- 2
- 3
4、Deployment（Deploy）
1）、Deployment定义
为了更好的解决服务编排的问题，Kubernetes在V1.2版本开始，引入了Deployment控制器。Deployment控制器并不直接管理Pod，而是通过管理ReplicaSet来简介管理Pod，即：Deployment管理ReplicaSet，ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加强大
Deployment主要功能有下面几个：
- 支持ReplicaSet的所有功能
- 支持发布的停止、继续
- 支持滚动升级和回滚版本
Deployment的资源清单文件：
apiVersion: apps/v1 # 版本号 kind: Deployment # 类型 metadata: # 元数据 name: # rs名称 namespace: # 所属命名空间 labels: # 标签 controller: deploy spec: # 详情描述 replicas: 3 # 副本数量 revisionHistoryLimit: 3 # 保留历史版本 paused: false # 暂停部署，默认是false progressDeadlineSeconds: 600 # 部署超时时间（s），默认是600 strategy: # 策略 type: RollingUpdate # 滚动更新策略 rollingUpdate: # 滚动更新 maxSurge: 30% # 最大额外可以存在的副本数，可以为百分比，也可以为整数 maxUnavailable: 30% # 最大不可用状态的Pod的最大值，可以为百分比，也可以为整数 selector: # 选择器，通过它指定该控制器管理哪些pod matchLabels: # Labels匹配规则 app: nginx-pod matchExpressions: # Expressions匹配规则 - {key: app, operator: In, values: [nginx-pod]} template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本 metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.17.1 ports: - containerPort: 80
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
2）、控制器模型
Kubernetes所有的控制器都遵循一个通用编排模式，即：控制循环（control loop），这里有一段Go语言风格的伪代码，描述这个控制循环：
for {
实际状态 := 获取集群中对象X的实际状态（Actual State）
期望状态 := 获取集群中对象X的期望状态（Desired State）
if 实际状态 == 期望状态{
什么都不做
} else {
执行编排动作，将实际状态调整为期望状态
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
在具体实现中，实际状态往往来自于Kubernetes集群本身。比如，kubectl通过心跳汇报的容器状态和节点状态，或者监控系统中保存的应用监控数据，或者控制器主动收集的它自己感兴趣的信息，这些都是常见实际状态的来源
而期望状态一般来自于用户提交的YAML文件。比如，Deployment对象中Replicas字段的值，这些信息往往都保存在Etcd中
以Deployment为例，描述下它对控制器模型的实现：
- Deployment控制器从Etcd中获取到所有携带了
app: nginx标签的Pod，然后统计它们的数量，这就是实际状态 - Deployment对象的Replicas字段的值就是期望状态
- Deployment控制器将两个状态做比较，然后根据比较结果，确定是创建Pod，还是删除已有Pod（实际是通过ReplicaSet实现对Pod的操作，后面会讲到）
类似Deployment这样的一个控制器，实际上都是由上半部分的控制器定义（包括期望状态），加上下半部分的被控制对象的模板组成的
控制器对象本身，负责定义被管理对象的期望状态。比如，Deployment里的replicas=2这个字段
而被控制对象的定义，则来自于一个模板。比如，Deployment里的template字段。可以看到，Deployment这个template字段里的内容，跟一个标准的Pod对象的API定义丝毫不差。而所有被这个Deployment管理的Pod实例，其实都是根据这个template字段的内容创建出来的
3）、创建Deployment
创建pc-deployment.yaml，内容如下：
apiVersion: apps/v1 kind: Deployment metadata: name: pc-deployment namespace: dev spec: replicas: 3 selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.17.1
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
上面pc-deployment定义的Pod副本个数是3（spec.replicas=3）。在具体的实现上，这个Deployment与ReplicaSet以及Pod的关系如下图：
Deployment控制器实际操纵的是ReplicaSet对象，而不是Pod对象。对于一个Deployment所管理的Pod，它的ownerReference是ReplicaSet
一个定义了replicas=3的Deployment，与它的ReplicaSet以及Pod的关系，实际上是一种层层控制的关系
其中，ReplicaSet负责通过控制器模式保证系统中Pod的个数永远等于指定的个数（比如3个）。这也正是Deployment只允许容器的restartPolicy=Always的主要原因：只有在容器能保证自己始终是Running状态的前提下，ReplicaSet调整Pod的个数才有意义
而在此基础上，Deployment同样通过控制器模式，来操作ReplicaSet的个数和属性，进而实现水平扩展/收缩和滚动更新这两个编排动作
# 创建deployment
[root@k8s-master ~]# kubectl create -f pc-deployment.yaml --record
deployment.apps/pc-deployment created
- 1
- 2
- 3
--record参数的作用是记录下你每次操作所执行的命令，以方便后面查看
# 查看deployment
# READY 已经准备好提供服务的副本数量
# UP-TO-DATE 最新版本的pod的数量
# AVAILABLE 当前可用的pod的数量
[root@k8s-master ~]# kubectl get deploy pc-deployment -n dev
NAME READY UP-TO-DATE AVAILABLE AGE
pc-deployment 3/3 3 3 25s
- 1
- 2
- 3
- 4
- 5
- 6
- 7
在返回结果中，我们可以看到四个状态字段，它们的含义如下：
- DESIRED：用户期望的Pod副本个数（
spec.replicas的值） - CURRENT：当前处于Running状态的Pod的个数
- UP-TO-DATE：当前处于最新版本的Pod的个数，所谓最新版本指的是Pod的Spec部分与Deployment里Pod模板里定义的完全一致
- AVAILABLE：当前已经可用的Pod的个数，即：既是Running状态，又是最新版本，并且已经处于Ready（健康检查正确）状态的Pod的个数
只有这个AVAILABLE字段，描述的才是用户所期望的最终状态
# 查看rs
# 发现rs的名称是在原来deployment的名字后面添加了一个10位数的随机串
[root@k8s-master ~]# kubectl get rs -n dev
NAME DESIRED CURRENT READY AGE
pc-deployment-858db84f89 3 3 3 42s
- 1
- 2
- 3
- 4
- 5
在用户提交了一个Deployment对象后，Deployment Controller就会立即创建一个Pod副本个数为3的ReplicaSet。这个ReplicaSet的名字，则是由Deployment的名字和一个随机字符串共同组成
这个随机字符串叫作pod-template-hash，ReplicaSet会把这个随机字符串加在它所控制的所有Pod的标签里，从而保证这些Pod不会与集群里的其他Pod混淆
而ReplicaSet的DESIRED、CURRENT和READY字段的含义，和Deployment中是一致的。所以，相比之下，Deployment只是在ReplicaSet的基础上，添加了UP-TO-DATE这个跟版本有关的状态字段
# 查看pod
[root@k8s-master ~]# kubectl get pod -n dev --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pc-deployment-858db84f89-74rr9 1/1 Running 0 68s app=nginx-pod,pod-template-hash=858db84f89
pc-deployment-858db84f89-bzsmh 1/1 Running 0 68s app=nginx-pod,pod-template-hash=858db84f89
pc-deployment-858db84f89-jgxw4 1/1 Running 0 68s app=nginx-pod,pod-template-hash=858db84f89
- 1
- 2
- 3
- 4
- 5
- 6
4）、扩缩容
# 变更副本数量为5个 [root@k8s-master ~]# kubectl scale deploy pc-deployment --replicas=5 -n dev deployment.apps/pc-deployment scaled # 查看deployment [root@k8s-master ~]# kubectl get deploy pc-deployment -n dev NAME READY UP-TO-DATE AVAILABLE AGE pc-deployment 5/5 5 5 142m # 查看pod [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-deployment-858db84f89-74rr9 1/1 Running 0 143m pc-deployment-858db84f89-bns84 1/1 Running 0 108s pc-deployment-858db84f89-bzsmh 1/1 Running 0 143m pc-deployment-858db84f89-cx6dk 1/1 Running 0 108s pc-deployment-858db84f89-jgxw4 1/1 Running 0 143m # 编辑deployment的副本数量，修改spec:replicas: 4即可 [root@k8s-master ~]# kubectl edit deploy pc-deployment -n dev deployment.apps/pc-deployment edited # 查看pod [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-deployment-858db84f89-74rr9 1/1 Running 0 144m pc-deployment-858db84f89-bzsmh 1/1 Running 0 144m pc-deployment-858db84f89-cx6dk 1/1 Running 0 3m3s pc-deployment-858db84f89-jgxw4 1/1 Running 0 144m
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
5）、镜像更新
Deployment支持两种更新策略：重建更新和滚动更新，可以通过strategy指定策略类型
strategy:
type: # 指定策略类型，支持两种策略
Recreate: # 重建更新，在创建出新的Pod之前会先杀掉所有已存在的Pod
RollingUpdate: # 滚动更新，就是杀死一部分，就启动一部分，在更新过程中，存在两个版本Pod
rollingUpdate: # 当type为RollingUpdate时生效，用于为RollingUpdate设置参数，支持两个属性
maxUnavailable: # 用来指定在升级过程中不可用Pod的最大数量，默认为25%
maxSurge: # 用来指定在升级过程中可以超过期望的Pod的最大数量，默认为25%
- 1
- 2
- 3
- 4
- 5
- 6
- 7
1）重建更新
编辑pc-deployment.yaml，在spec节点下添加更新策略，修改后内容如下：
apiVersion: apps/v1 kind: Deployment metadata: name: pc-deployment namespace: dev spec: replicas: 3 strategy: # 策略 type: Recreate # 重建更新 selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.17.1
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
# 更新deployment [root@k8s-master ~]# kubectl apply -f pc-deployment.yaml deployment.apps/pc-deployment configured # 更新镜像 [root@k8s-master ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev deployment.apps/pc-deployment image updated # 观察升级过程 [root@k8s-master ~]# kubectl get pod -n dev -w NAME READY STATUS RESTARTS AGE pc-deployment-858db84f89-8sdvp 1/1 Running 0 22s pc-deployment-858db84f89-d7cr8 1/1 Running 0 22s pc-deployment-858db84f89-jhlf7 1/1 Running 0 22s pc-deployment-858db84f89-jhlf7 1/1 Terminating 0 57s pc-deployment-858db84f89-d7cr8 1/1 Terminating 0 57s pc-deployment-858db84f89-8sdvp 1/1 Terminating 0 57s pc-deployment-6c78d7875b-wphf8 0/1 Pending 0 0s pc-deployment-6c78d7875b-jthvj 0/1 Pending 0 0s pc-deployment-6c78d7875b-dtgz5 0/1 Pending 0 0s pc-deployment-6c78d7875b-wphf8 0/1 ContainerCreating 0 0s pc-deployment-6c78d7875b-jthvj 0/1 ContainerCreating 0 1s pc-deployment-6c78d7875b-dtgz5 0/1 ContainerCreating 0 1s pc-deployment-6c78d7875b-dtgz5 1/1 Running 0 3s pc-deployment-6c78d7875b-wphf8 1/1 Running 0 3s pc-deployment-6c78d7875b-jthvj 1/1 Running 0 3s # 在创建出新的Pod之前会先杀掉所有已存在的Pod
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
2）滚动更新
编辑pc-deployment.yaml，在spec节点下修改更新策略，修改后内容如下：
apiVersion: apps/v1 kind: Deployment metadata: name: pc-deployment namespace: dev spec: replicas: 3 strategy: # 策略 type: RollingUpdate # 滚动更新策略 rollingUpdate: maxSurge: 25% maxUnavailable: 25% selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.17.1
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
# 更新deployment [root@k8s-master ~]# kubectl apply -f pc-deployment.yaml deployment.apps/pc-deployment configured # 更新镜像 [root@k8s-master ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -n dev deployment.apps/pc-deployment image updated # 观察升级过程 [root@k8s-master ~]# kubectl get pod -n dev -w NAME READY STATUS RESTARTS AGE pc-deployment-858db84f89-cg7bn 1/1 Running 0 24s pc-deployment-858db84f89-n6pqb 1/1 Running 0 20s pc-deployment-858db84f89-x7jks 1/1 Running 0 22s pc-deployment-57df6f8b8c-jsr9z 0/1 Pending 0 0s pc-deployment-57df6f8b8c-jsr9z 0/1 ContainerCreating 0 0s pc-deployment-57df6f8b8c-jsr9z 1/1 Running 0 51s pc-deployment-858db84f89-x7jks 0/1 Terminating 0 83s pc-deployment-57df6f8b8c-jkphn 0/1 Pending 0 0s pc-deployment-57df6f8b8c-jkphn 0/1 ContainerCreating 0 0s pc-deployment-57df6f8b8c-jkphn 1/1 Running 0 2s pc-deployment-858db84f89-n6pqb 0/1 Terminating 0 83s pc-deployment-57df6f8b8c-xfr9f 0/1 Pending 0 0s pc-deployment-57df6f8b8c-xfr9f 0/1 ContainerCreating 0 1s pc-deployment-57df6f8b8c-xfr9f 1/1 Running 0 1s pc-deployment-858db84f89-cg7bn 0/1 Terminating 0 89s # 至此，新版本的Pod创建完毕，旧版本的Pod销毁完毕 # 中间过程是滚动进行的，也就是边销毁边创建 # 查看rs，发现原来的rs的依旧存在，只是pod数量变为了0，而后又新产生了一个rs，pod数量为3 # 其实这就是deployment能够进行版本回退的奥妙所在，后面会详细解释 [root@k8s-master ~]# kubectl get rs -n dev NAME DESIRED CURRENT READY AGE pc-deployment-57df6f8b8c 3 3 3 8m15s pc-deployment-6c78d7875b 0 0 0 16m pc-deployment-858db84f89 0 0 0 171m
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
滚动更新过程如下图：
在上面这个Deployment的例子中，它有3个Pod副本，那么控制器在滚动更新的过程中永远都会确保至少有2个Pod处于可用状态，至多只有4个Pod同时存在于集群中
如上所示，Deployment的控制器实际上控制的是ReplicaSet的数目，以及每个ReplicaSet的属性
而一个应用的版本对应的正是一个ReplicaSet；这个版本应用的Pod数量，则由ReplicaSet通过它自己的控制器（ReplicaSet Controller）来保证。通过这样的多个ReplicaSet对象，Kubernetes项目就实现了对多个应用版本的描述
6）、版本回退
Deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能，下面具体来看
kubectl rollout：版本升级相关功能，支持下面的选项：
- status：显示当前升级状态
- history：显示升级历史记录
- pause：暂停版本升级过程
- resume：继续已经暂停的版本升级过程
- restart：重启版本升级过程
- undo：回滚到上一级版本（可以使用
--to-revision回滚到指定版本）
重新创建Deployment，并进行两次镜像升级：
# 重新创建deployment [root@k8s-master ~]# kubectl delete -f pc-deployment.yaml deployment.apps "pc-deployment" deleted [root@k8s-master ~]# kubectl create -f pc-deployment.yaml --record deployment.apps/pc-deployment created [root@k8s-master ~]# kubectl get deploy,rs,pod -n dev NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/pc-deployment 3/3 3 3 12s NAME DESIRED CURRENT READY AGE replicaset.apps/pc-deployment-858db84f89 3 3 3 12s NAME READY STATUS RESTARTS AGE pod/pc-deployment-858db84f89-4kj4h 1/1 Running 0 12s pod/pc-deployment-858db84f89-glvff 1/1 Running 0 12s pod/pc-deployment-858db84f89-mw297 1/1 Running 0 12s [root@k8s-master ~]# kubectl get deploy -n dev -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR pc-deployment 3/3 3 3 15s nginx nginx:1.17.1 app=nginx-pod # 进行镜像升级 [root@k8s-master ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev deployment.apps/pc-deployment image updated [root@k8s-master ~]# kubectl get deploy,rs,pod -n dev NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/pc-deployment 3/3 3 3 54s NAME DESIRED CURRENT READY AGE replicaset.apps/pc-deployment-6c78d7875b 3 3 3 27s replicaset.apps/pc-deployment-858db84f89 0 0 0 54s NAME READY STATUS RESTARTS AGE pod/pc-deployment-6c78d7875b-dqts7 1/1 Running 0 25s pod/pc-deployment-6c78d7875b-s64ld 1/1 Running 0 23s pod/pc-deployment-6c78d7875b-xffh2 1/1 Running 0 27s [root@k8s-master ~]# kubectl get deploy -n dev -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR pc-deployment 3/3 3 3 110s nginx nginx:1.17.2 app=nginx-pod # 再进行镜像升级 [root@k8s-master ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -n dev deployment.apps/pc-deployment image updated [root@k8s-master ~]# kubectl get deploy,rs,pod -n dev NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/pc-deployment 3/3 3 3 4m59s NAME DESIRED CURRENT READY AGE replicaset.apps/pc-deployment-57df6f8b8c 3 3 3 38s replicaset.apps/pc-deployment-6c78d7875b 0 0 0 4m32s replicaset.apps/pc-deployment-858db84f89 0 0 0 4m59s NAME READY STATUS RESTARTS AGE pod/pc-deployment-57df6f8b8c-7vmpg 1/1 Running 0 34s pod/pc-deployment-57df6f8b8c-mqlwx 1/1 Running 0 36s pod/pc-deployment-57df6f8b8c-qrs7w 1/1 Running 0 38s [root@k8s-master ~]# kubectl get deploy -n dev -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR pc-deployment 3/3 3 3 5m10s nginx nginx:1.17.3 app=nginx-pod
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
# 查看当前升级版本的状态 [root@k8s-master ~]# kubectl rollout status deploy pc-deployment -n dev deployment "pc-deployment" successfully rolled out # 查看升级历史记录 [root@k8s-master ~]# kubectl rollout history deploy pc-deployment -n dev deployment.apps/pc-deployment REVISION CHANGE-CAUSE 1 kubectl create --filename=pc-deployment.yaml --record=true 2 kubectl create --filename=pc-deployment.yaml --record=true 3 kubectl create --filename=pc-deployment.yaml --record=true # 版本回滚 # 这里直接使用--to-revision=1回滚到了1版本（nginx:1.17.1），如果省略这个选项，就是回退到上个版本，就是2版本（nginx:1.17.2） [root@k8s-master ~]# kubectl rollout undo deployment pc-deployment --to-revision=1 -n dev deployment.apps/pc-deployment rolled back # 查看发现，通过nginx镜像版本可以发现到了1版本 [root@k8s-master ~]# kubectl get deploy -n dev -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR pc-deployment 3/3 3 3 9m6s nginx nginx:1.17.1 app=nginx-pod # 查看rs，发现第一个rs中有3个pod运行，后面两个版本的rs中pod为0 # 其实deployment之所以可是实现版本的回滚，就是通过记录下历史rs来实现的 # 一旦想回滚到哪个版本，只需要将当前版本pod数量降为0，然后将回滚版本的pod提升为目标数量就可以了 [root@k8s-master ~]# kubectl get rs -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES pc-deployment-57df6f8b8c 0 0 0 5m13s nginx nginx:1.17.3 pc-deployment-6c78d7875b 0 0 0 9m7s nginx nginx:1.17.2 pc-deployment-858db84f89 3 3 3 9m34s nginx nginx:1.17.1
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
7）、金丝雀发布
Deployment控制器支持控制更新过程中的控制，如暂停（pause）或继续（resume）更新操作
比如有一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布
# 更新deployment的版本，并配置暂停deployment [root@k8s-master ~]# kubectl set image deploy pc-deployment nginx=nginx:1.17.4 -n dev && kubectl rollout pause deployment pc-deployment -n dev deployment.apps/pc-deployment image updated deployment.apps/pc-deployment paused # 观察更新状态 [root@k8s-master ~]# kubectl rollout status deploy pc-deployment -n dev Waiting for deployment "pc-deployment" rollout to finish: 1 out of 3 new replicas have been updated... [root@k8s-master ~]# kubectl get rs -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES pc-deployment-57df6f8b8c 0 0 0 15m nginx nginx:1.17.3 pc-deployment-6c78d7875b 0 0 0 19m nginx nginx:1.17.2 pc-deployment-849d4778f4 1 1 0 14s nginx nginx:1.17.4 pc-deployment-858db84f89 3 3 3 20m nginx nginx:1.17.1 # 监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令 # 继续更新 [root@k8s-master ~]# kubectl rollout resume deploy pc-deployment -n dev deployment.apps/pc-deployment resumed [root@k8s-master ~]# kubectl get rs -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES pc-deployment-57df6f8b8c 0 0 0 20m nginx nginx:1.17.3 pc-deployment-6c78d7875b 0 0 0 24m nginx nginx:1.17.2 pc-deployment-849d4778f4 3 3 3 5m16s nginx nginx:1.17.4 pc-deployment-858db84f89 0 0 0 25m nginx nginx:1.17.1
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
5、DaemonSet（DS）
1）、DaemonSet定义
DaemonSet类型的控制器可以保证在集群中的每一台（或指定）节点上都运行一个副本。一般适用于日志收集、节点监控等场景。也就是说，如果一个Pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类Pod就适合使用DaemonSet类型的控制器创建
DaemonSet创建的Pod有如下三个特征：
- 这个Pod运行在Kubernetes集群里的每一个节点（Node）上
- 每个节点上只有一个这样的Pod实例
- 当有新的节点加入Kubernetes集群后，该Pod会自动地在新节点上被创建出来；而当旧节点被删除后，它上面的Pod也相应地会被回收掉
DaemonSet的资源清单文件：
apiVersion: apps/v1 # 版本号 kind: DaemonSet # 类型 metadata: # 元数据 name: # rs名称 namespace: # 所属命名空间 labels: # 标签 controller: daemonset spec: # 详情描述 revisionHistoryLimit: 3 # 保留历史版本 updateStrategy: # 更新策略 type: RollingUpdate # 滚动更新策略 rollingUpdate: # 滚动更新 maxUnavailable: 1 # 最大不可用状态的Pod的最大值，可以为百分比，也可以为整数 selector: # 选择器，通过它指定该控制器管理哪些pod matchLabels: # Labels匹配规则 app: nginx-pod matchExpressions: # Expressions匹配规则 - {key: app, operator: In, values: [nginx-pod]} template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本 metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.17.1 ports: - containerPort: 80
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
2）、创建DaemonSet
创建pc-daemonset.yaml，内容如下：
apiVersion: apps/v1 kind: DaemonSet metadata: name: pc-daemonset namespace: dev spec: selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.17.1
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
# 创建daemonset
[root@k8s-master ~]# kubectl create -f pc-daemonset.yaml --record
daemonset.apps/pc-daemonset created
# 查看daemonset
[root@k8s-master ~]# kubectl get ds -n dev -o wide
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
pc-daemonset 2 2 2 2 2 <none> 15s nginx nginx:1.17.1 app=nginx-pod
# 查看pod，发现在每个Node上都运行一个pod
[root@k8s-master ~]# kubectl get pod -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pc-daemonset-gbzw8 1/1 Running 0 23s 10.244.1.35 k8s-node2 <none> <none>
pc-daemonset-h6zfz 1/1 Running 0 23s 10.244.2.74 k8s-node1 <none> <none>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
3）、DaemonSet实现原理
DaemonSet如何保证每个Node上有且只有一个被管理的Pod呢？
DaemonSet Controller首先从Etcd里获取所有的Node列表，然后遍历所有的Nod，然后去检查，当前这个Node上是不是有一个携带了app: nginx-pod标签的Pod在运行
检查结果可能有这么三种情况：
- 没有这种Pod，那么就意味着要在这个Node上创建这样一个Pod
- 有这种Pod，但是数量大于1，那就说明要把多余的Pod从这个Node上删除掉
- 正好只有一个这种Pod，那说明这个节点是正常的
DaemonSet是如何在指定的Node上创建新Pod呢？
通过kubectl edit来看下DaemonSet创建Pod的详细信息：
[root@k8s-master ~]# kubectl edit pod pc-daemonset-pq6n7 -n dev
- 1
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution: # Node节点必须满足指定的所有规则才可以，相当于硬限制
nodeSelectorTerms:
- matchFields:
- key: metadata.name
operator: In
values:
- k8s-node1
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
上面定义的nodeAffinity的含义是：这里Pod只允许运行在metadata.name是k8s-node1的节点上
DaemonSet Controller会在创建Pod的时候，自动在这个Pod的API对象里，加上这样一个nodeAffinity定义。其中，需要绑定的节点名字，正是当前正在遍历的这个Node
此外，DaemonSet还会给这个Pod自动加上另外一个与调度相关的字段，叫作tolerations。这个字段意味着这个Pod，会容忍（Toleration）某些Node的污点（Taint）
spec:
tolerations:
- effect: NoSchedule
key: node.kubernetes.io/unschedulable
operator: Exists
- 1
- 2
- 3
- 4
- 5
上面定义的tolerations的含义是：容忍所有被标记为unschedulable污点的Node；容忍的效果是允许调度
而在正常情况下，被标记了unschedulable污点的Node，是不会有任何Pod被调度上去的（effect: NoSchedule）。可是，DaemonSet自动地给被管理的Pod加上了这个特殊的tolerations，就使得这些Pod可以忽略这个限制，继而保证每个节点上都会被调度一个Pod。当然，如果这个节点有故障的话，这个Pod可能会启动失败，而DaemonSet则会始终尝试下去，直到Pod启动成功
DaemonSet创建的Pod自动添加的tolerations配置如下：
spec: tolerations: - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists - effect: NoSchedule key: node.kubernetes.io/disk-pressure operator: Exists - effect: NoSchedule key: node.kubernetes.io/memory-pressure operator: Exists - effect: NoSchedule key: node.kubernetes.io/pid-pressure operator: Exists - effect: NoSchedule key: node.kubernetes.io/unschedulable operator: Exists
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
如果这个DaemonSet是一个网络插件的Agent组件，这个时候整个Kubernetes集群里还没有可用的容器网络，所有Worker节点的状态都是NotReady（NetworkReady=false）。但因为DaemonSet创建的Pod会容忍所有被标记为not-ready污点的Node，所以即使在所有Worker节点的状态都是NotReady时，DaemonSet创建的Pod依然能被调度
4）、镜像更新与版本回退
# 镜像更新
[root@k8s-master ~]# kubectl set image daemonset pc-daemonset nginx=nginx:1.17.2 -n dev
daemonset.apps/pc-daemonset image updated
[root@k8s-master ~]# kubectl get ds -n dev -o wide
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
pc-daemonset 2 2 2 2 2 <none> 2m8s nginx nginx:1.17.2 app=nginx-pod
# 查看升级历史记录
[root@k8s-master ~]# kubectl rollout history ds pc-daemonset -n dev
daemonset.apps/pc-daemonset
REVISION CHANGE-CAUSE
1 kubectl create --filename=pc-daemonset.yaml --record=true
2 kubectl create --filename=pc-daemonset.yaml --record=true
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
Deployment管理这些版本，靠的是一个版本对应一个ReplicaSet对象。可是，DaemonSet控制器操作的直接就是Pod，不可能有ReplicaSet这样的对象参与其中。那么，它的这些版本又是如何维护的呢？
Kubernetes v1.7之后添加了一个API对象，名叫ControllerRevision，专门用来记录某种Controller对象的版本。比如，可以通过如下命令查看pc-daemonset对应的ControllerRevision：
[root@k8s-master ~]# kubectl get controllerrevision -n dev
NAME CONTROLLER REVISION AGE
pc-daemonset-6c78d7875b daemonset.apps/pc-daemonset 2 107s
pc-daemonset-858db84f89 daemonset.apps/pc-daemonset 1 2m30s
- 1
- 2
- 3
- 4
使用kubectl describe查看这个ControllerRevision对象：
[root@k8s-master ~]# kubectl describe controllerrevision pc-daemonset-6c78d7875b -n dev Name: pc-daemonset-6c78d7875b Namespace: dev Labels: app=nginx-pod controller-revision-hash=6c78d7875b Annotations: deprecated.daemonset.template.generation: 2 kubernetes.io/change-cause: kubectl create --filename=pc-daemonset.yaml --record=true API Version: apps/v1 Data: Spec: Template: $patch: replace Metadata: Creation Timestamp: <nil> Labels: App: nginx-pod Spec: Containers: Image: nginx:1.17.2 Image Pull Policy: IfNotPresent Name: nginx Resources: Termination Message Path: /dev/termination-log Termination Message Policy: File Dns Policy: ClusterFirst Restart Policy: Always Scheduler Name: default-scheduler Security Context: Termination Grace Period Seconds: 30 ...... Revision: 2 Events: <none>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
这个ControllerRevision对象实际上是在Data字段保存了该版本对应的完整的DaemonSet的API对象。并且，在Annotation字段保存了创建这个对象所使用的kubectl命令
# 版本回滚
[root@k8s-master ~]# kubectl rollout undo ds pc-daemonset --to-revision=1 -n dev
daemonset.apps/pc-daemonset rolled back
# 查看发现，通过nginx镜像版本可以发现到了1版本
[root@k8s-master ~]# kubectl get ds -n dev -o wide
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
pc-daemonset 2 2 1 1 1 <none> 6m11s nginx nginx:1.17.1 app=nginx-pod
# 查看升级历史记录
[root@k8s-master ~]# kubectl rollout history ds pc-daemonset -n dev
daemonset.apps/pc-daemonset
REVISION CHANGE-CAUSE
2 kubectl create --filename=pc-daemonset.yaml --record=true
3 kubectl create --filename=pc-daemonset.yaml --record=true
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
这个kubectl rollout undo操作，实际上相当于读取到了Revision=1的ControllerRevision对象保存的Data字段。而这个Data字段里保存的信息，就是Revision=1时这个DaemonSet的完整API对象
所以，现在DaemonSet Controller就可以使用这个历史API对象，对现有的DaemonSet做一次PATCH操作（等价于执行一次kubectl apply -f “旧的DaemonSet对象”），从而把这个DaemonSet更新到一个旧版本
所以，在执行完这次回滚完成后，DaemonSet的Revision并不会从Revision=2退回到1，而是会增加成Revision=3。这是因为，一个新的 ControllerRevision被创建了出来
6、Job
1）、Job定义
Job主要用于负责批量处理（一次要处理指定数量任务）短暂的一次性（每个任务仅运行一次就结束）任务。Job特点如下：
- 当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量
- 当成功结束的pod达到指定的数量时，Job将完成执行
Job的资源清单文件：
apiVersion: batch/v1 # 版本号 kind: Job # 类型 metadata: # 元数据 name: # rs名称 namespace: # 所属命名空间 labels: # 标签 controller: job spec: # 详情描述 completions: 1 # 指定job需要成功运行Pods的次数。默认值:1 parallelism: 1 # 指定job在任一时刻应该并发运行Pods的数量。默认值:1 activeDeadlineSeconds: 30 # 指定job可运行的时间期限，超过时间还未结束，系统将会尝试进行终止 backoffLimit: 6 # 指定job失败后进行重试的次数。默认是6 manualSelector: true # 是否可以使用selector选择器选择pod，默认是false selector: # 选择器，通过它指定该控制器管理哪些pod matchLabels: # Labels匹配规则 app: counter-pod matchExpressions: # Expressions匹配规则 - {key: app, operator: In, values: [counter-pod]} template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本 metadata: labels: app: counter-pod spec: restartPolicy: Never # 重启策略只能设置为Never或者OnFailure containers: - name: counter image: busybox:1.30 command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;done"]
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
关于重启策略设置的说明：
- 如果指定为OnFailure，则job会在pod出现故障时重启容器，而不是创建pod，failed次数不变
- 如果指定为Never，则job会在pod出现故障时创建新的pod，并且故障pod不会消失，也不会重启，failed次数加1
- 如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了，当然不对，所以不能设置为Always
2）、创建Job
创建pc-job.yaml，内容如下：
apiVersion: batch/v1
kind: Job
metadata:
name: pc-job
namespace: dev
spec:
template:
spec:
containers:
- name: pi
image: resouer/ubuntu-bc
command: ["sh", "-c", "echo 'scale=10000; 4*a(1)' | bc -l "]
restartPolicy: Never
backoffLimit: 4
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
上面定义了计算π值的Pod，输出到小数点后10000位
跟其他控制器不同的是，Job控制器并不要求定义一个spec.selector来描述要控制哪些Pod
# 创建job [root@k8s-master ~]# kubectl create -f pc-job.yaml job.batch/pc-job created # 查看job详情 [root@k8s-master ~]# kubectl describe job pc-job -n dev Name: pc-job Namespace: dev Selector: controller-uid=85b24167-0e3f-465d-bc8d-ac10aa5df734 Labels: controller-uid=85b24167-0e3f-465d-bc8d-ac10aa5df734 job-name=pc-job Annotations: <none> Parallelism: 1 Completions: 1 Start Time: Wed, 09 Feb 2022 22:32:11 +0800 Pods Statuses: 1 Running / 0 Succeeded / 0 Failed Pod Template: Labels: controller-uid=85b24167-0e3f-465d-bc8d-ac10aa5df734 job-name=pc-job Containers: pi: Image: resouer/ubuntu-bc Port: <none> Host Port: <none> Command: sh -c echo 'scale=10000; 4*a(1)' | bc -l Environment: <none> Mounts: <none> Volumes: <none> ......
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
这个Job对象在创建后，它的Pod模板，被自动加上了一个controller-uid=< 一个随机字符串 >这样的Label。而这个Job对象本身，则被自动加上了这个Label对应的Selector，从而保证了Job与它所管理的Pod之间的匹配关系。而Job Controller之所以要使用这种携带了UID的Label，就是为了避免不同Job对象所管理的Pod发生重合
# pod进入Running状态，意味着它正在计算π的值
[root@k8s-master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-job-vc25v 1/1 Running 0 19s
# 几分钟后计算结束，这个pod就会进入Completed状态
[root@k8s-master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-job-vc25v 0/1 Completed 0 2m13s
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
这也是需要在Pod模板中定义restartPolicy=Never的原因：离线计算的Pod永远都不应该被重启，否则它们会再重新计算一遍
事实上，restartPolicy在Job对象里只允许被设置为Never和OnFailure；而在Deployment对象里，restartPolicy则只允许被设置为Always
3）、Job并行控制
在Job对象中，负责并行控制的参数有两个：
spec.parallelism：它定义的是一个Job在任意时间最多可以启动多少个Pod同时运行spec.completions：它定义的是Job至少要完成的Pod数目，即Job的最小完成数
修改pc-job.yaml，修改后内容如下：
apiVersion: batch/v1 kind: Job metadata: name: pc-job namespace: dev spec: parallelism: 2 completions: 4 template: spec: containers: - name: pi image: resouer/ubuntu-bc command: ["sh", "-c", "echo 'scale=10000; 4*a(1)' | bc -l "] restartPolicy: Never backoffLimit: 4
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
指定了这个Job最大的并行数是2，而最小的完成数是4
# 重新创建job [root@k8s-master ~]# kubectl delete job pc-job -n dev job.batch "pc-job" deleted [root@k8s-master ~]# kubectl create -f pc-job.yaml job.batch/pc-job created [root@k8s-master ~]# kubectl get job -n dev NAME COMPLETIONS DURATION AGE pc-job 0/4 23s 23s # job首先创建了两个并行运行的pod来计算π [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-job-cjlvf 1/1 Running 0 38s pc-job-jkf2r 1/1 Running 0 38s # 前两个pod完成计算后，进入Completed状态 # job第二次创建出来的两个并行的pod进入了Running状态 [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-job-brd6n 1/1 Running 0 26s pc-job-cjlvf 0/1 Completed 0 2m34s pc-job-czbp8 1/1 Running 0 10s pc-job-jkf2r 0/1 Completed 0 2m34s [root@k8s-master ~]# kubectl get job -n dev NAME COMPLETIONS DURATION AGE pc-job 2/4 2m52s 2m52s # 所有的pod均已经成功退出 [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-job-brd6n 0/1 Completed 0 5m53s pc-job-cjlvf 0/1 Completed 0 8m1s pc-job-czbp8 0/1 Completed 0 5m37s pc-job-jkf2r 0/1 Completed 0 8m1s # job执行完成 [root@k8s-master ~]# kubectl get job -n dev NAME COMPLETIONS DURATION AGE pc-job 4/4 4m18s 8m5s
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
7、CronJob（CJ）
1）、CronJob定义
CronJob控制器以Job控制器资源为其管控对象，并借助它管理Pod资源对象，Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。也就是说，CronJob可以在特定的时间点（反复的）去运行Job任务
CronJob的资源清单文件：
apiVersion: batch/v1beta1 # 版本号 kind: CronJob # 类型 metadata: # 元数据 name: # rs名称 namespace: # 所属命名空间 labels: # 标签 controller: cronjob spec: # 详情描述 schedule: # cron格式的作业调度运行时间点,用于控制任务在什么时间执行 concurrencyPolicy: # 并发执行策略，用于定义前一次作业运行尚未完成时是否以及如何运行后一次的作业 failedJobHistoryLimit: # 为失败的任务执行保留的历史记录数，默认为1 successfulJobHistoryLimit: # 为成功的任务执行保留的历史记录数，默认为3 startingDeadlineSeconds: # 启动作业错误的超时时长 jobTemplate: # job控制器模板，用于为cronjob控制器生成job对象;下面其实就是job的定义 metadata: spec: completions: 1 parallelism: 1 activeDeadlineSeconds: 30 backoffLimit: 6 manualSelector: true selector: matchLabels: app: counter-pod matchExpressions: 规则 - {key: app, operator: In, values: [counter-pod]} template: metadata: labels: app: counter-pod spec: restartPolicy: Never containers: - name: counter image: busybox:1.30 command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 20;done"]
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
需要重点解释的几个选项：
schedule: cron表达式，用于指定任务的执行时间
*/1 * * * *
<分钟> <小时> <日> <月份> <星期>
分钟值从0到59
小时值从0到23
日值从1到31
月值从1到12
星期值从0到6，0代表星期日
多个时间可以用逗号隔开，范围可以用连字符给出，*可以作为通配符，/表示每...
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
concurrencyPolicy：
- Allow：允许Jobs并发运行（默认）
- Forbid：禁止并发运行，如果上一次运行尚未完成，则跳过下一次运行
- Replace：替换，取消当前正在运行的作业并用新作业替换它
2）、创建CronJob
创建pc-cronjob.yaml，内容如下：
apiVersion: batch/v1beta1 kind: CronJob metadata: name: pc-cronjob namespace: dev labels: controller: cronjob spec: schedule: "*/1 * * * *" jobTemplate: metadata: spec: template: spec: restartPolicy: Never containers: - name: counter image: busybox:1.30 command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
每分钟执行一次
# 创建cronjob [root@k8s-master ~]# kubectl create -f pc-cronjob.yaml cronjob.batch/pc-cronjob created # 查看cronjob [root@k8s-master ~]# kubectl get cj -n dev NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE pc-cronjob */1 * * * * False 0 <none> 17s [root@k8s-master ~]# kubectl get job -n dev NAME COMPLETIONS DURATION AGE pc-cronjob-1644420420 1/1 29s 2m8s pc-cronjob-1644420480 1/1 29s 68s pc-cronjob-1644420540 0/1 8s 8s # 查看pod [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-cronjob-1644420420-jv2v6 0/1 Completed 0 2m12s pc-cronjob-1644420480-s7chz 0/1 Completed 0 72s pc-cronjob-1644420540-mwk76 1/1 Running 0 12s # 删除cronjob [root@k8s-master ~]# kubectl delete cj pc-cronjob -n dev cronjob.batch "pc-cronjob" deleted
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
参考：
声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/花生_TL007/article/detail/162044
推荐阅读
相关标签
