kubernetespod控制器详解上
pod调度策略之污点和容忍
污点（Taints）
通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否允许Pod调度过来。
Node被设置上污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。
污点的格式为：key=value:effect, key和value是污点的标签，effect描述污点的作用，支持如下三个选项：
• PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度
• NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod
• NoExecute：kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已存在的Pod驱离
使用kubectl设置和去除污点的命令示例如下：
# 设置污点
kubectl taint nodes node1 key=value:effect
# 去除污点
kubectl taint nodes node1 key:effect-
# 去除所有污点
kubectl taint nodes node1 key-
接下来，演示下污点的效果：
- 准备节点node1（为了演示效果更加明显，暂时停止node2节点）
- 为node1节点设置一个污点: tag=chenyu:PreferNoSchedule；然后创建pod1( pod1 可以 )
- 修改为node1节点设置一个污点: tag=lh:NoSchedule；然后创建pod2( pod1 正常 pod2 失败 )
- 修改为node1节点设置一个污点: tag=lh:NoExecute；然后创建pod3 ( 3个pod都失败 )
为node1设置污点(PreferNoSchedule)并创建容器查看效果
[root@master ~]# kubectl taint nodes node1.example.com tag=lh:PreferNoSchedule
node/node1.example.com tainted
[root@master ~]# kubectl run taint1 --image=nginx:1.17.1 -n lh
pod/taint1 created
[root@master ~]# kubectl get pods -n lh -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
taint1 1/1 Running 0 29s 10.244.1.20 node1.example.com <none> <none>
为node1设置污点(取消PreferNoSchedule，设置NoSchedule)并创建pod2查看效果
[root@master ~]# kubectl taint nodes node1.example.com tag:PreferNoSchedule-
node/node1.example.com untainted
[root@master ~]# kubectl taint nodes node1.example.com tag=lh:NoSchedule
[root@master ~]# kubectl run taint2 --image=nginx:1.17.1 -n lh
[root@master ~]# kubectl get pods taint2 -n lh -o wide
NAME READY STATUS RESTARTS AGE IP NODE
taint1 1/1 Running 0 3m56s 10.244.1.20 node1.example.com
taint2 0/1 Pending 0 43s <none> <none>
为node1设置污点(取消NoSchedule，设置NoExecute)并创建pod3查看效果
[root@master ~]# kubectl taint nodes node1.example.com tag:NoSchedule-
[root@master ~]# kubectl taint nodes node1.example.com tag=lh:NoExecute
[root@master ~]# kubectl run taint3 --image=nginx:1.17.1 -n dev
[root@master ~]# kubectl get pods -n lh -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED
taint1 0/1 Pending 0 24s <none> <none> <none>
taint2 0/1 Pending 0 24s <none> <none> <none>
taint3 0/1 Pending 0 3s <none> <none> <none>
使用kubeadm搭建的集群，默认就会给master节点添加一个污点标记,所以pod就不会调度到master节点上.
容忍（Toleration）
上面介绍了污点的作用，我们可以在node上添加污点用于拒绝pod调度上来，但是如果就是想将一个pod调度到一个有污点的node上去，这时候应该怎么做呢？这就要使用到容忍。
污点就是拒绝，容忍就是忽略，Node通过污点拒绝pod调度上去，Pod通过容忍忽略拒绝
下面先通过一个案例看下效果：
1、上面，已经在node1节点上打上了NoExecute的污点，此时pod是调度不上去的
2、下面，可以通过给pod添加容忍，然后将其调度上去
创建pod-toleration.yaml,内容如下
apiVersion: v1
kind: Pod
metadata:
name: pod-toleration
namespace: lh
spec:
containers:
- name: nginx
image: nginx:1.17.1
tolerations:
- key: "tag"
operator: "Equal"
value: "lh"
effect: "NoExecute"
添加容忍之前的pod
[root@master ~]# kubectl get pods -n lh -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED
pod-toleration 0/1 Pending 0 24s <none> <none> <none>
添加容忍之后的pod
[root@k8s-master01 ~]# kubectl get pods -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED
pod-toleration 1/1 Running 0 24s 10.244.1.62 node1 <none>
下面看一下容忍的详细配置:
[root@k8s-master01 ~]# kubectl explain pod.spec.tolerations
......
FIELDS:
key # 对应着要容忍的污点的键，空意味着匹配所有的键
value # 对应着要容忍的污点的值
operator # key-value的运算符，支持Equal和Exists（默认）
effect # 对应污点的effect，空意味着匹配所有影响
tolerationSeconds # 容忍时间, 当effect为NoExecute时生效，表示pod在Node上的停留时间
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，并支持滚动升级、回退版本
• Horizontal Pod Autoscaler：可以根据集群负载自动水平调整Pod的数量，实现削峰填谷
• DaemonSet：在集群中的指定Node上运行且仅运行一个副本，一般用于守护进程类的任务
• Job：它创建出来的pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务
• Cronjob：它创建的Pod负责周期性任务控制，不需要持续后台运行
• StatefulSet：管理有状态应用
ReplicaSet(RS)
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
在这里面，需要新了解的配置项就是spec下面几个选项：
replicas：指定副本数量，其实就是当前rs创建出来的pod的数量，默认为1
selector：选择器，它的作用是建立pod控制器和pod之间的关联关系，采用的Label Selector机制
在pod模板上定义label，在控制器上定义选择器，就可以表明当前控制器能管理哪些pod了
template：模板，就是当前控制器创建pod所使用的模板，里面其实就是前一章学过的pod的定义
创建ReplicaSet
创建pc-replicaset.yaml文件，内容如下：
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: pc-replicaset
namespace: xn
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
创建并查看rs# DESIRED:期望副本数量 # CURRENT:当前副本数量 # READY:已经准备好提供服务的副本数量
[root@master ~]# kubectl create -f pc-replicaset.yaml
replicaset.apps/pc-replicaset created
[root@master ~]# kubectl get rs pc-replicaset -n xn -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
pc-replicaset 3 3 0 31s nginx nginx:1.17.1 app=nginx-pod
[root@master ~]# kubectl get pod -n xn
NAME READY STATUS RESTARTS AGE
pc-replicaset-4njl8 0/1 Pending 0 55s
pc-replicaset-55xxh 0/1 Pending 0 55s
pc-replicaset-zkzbw 0/1 Pending 0 55s
扩缩容
编辑rs的副本数量，修改spec:replicas: 6即可
[root@master ~]# kubectl edit rs pc-replicaset -n xn
replicaset.apps/pc-replicaset edited
[root@master ~]# kubectl get pod -n xn
NAME READY STATUS RESTARTS AGE
pc-replicaset-2x9tk 1/1 Running 0 19s
pc-replicaset-4njl8 1/1 Running 0 5m16s
pc-replicaset-55xxh 1/1 Running 0 5m16s
pc-replicaset-dzwp8 1/1 Running 0 19s
pc-replicaset-fm9p7 1/1 Running 0 19s
pc-replicaset-zkzbw 1/1 Running 0 5m16s
当然也可以直接使用命令实现# 使用scale命令实现扩缩容， 后面–replicas=n直接指定目标数量即可
[root@master ~]# kubectl scale rs pc-replicaset --replicas=3 -n xn
replicaset.apps/pc-replicaset scaled
[root@master ~]# kubectl get pod -n xn
NAME READY STATUS RESTARTS AGE
pc-replicaset-4njl8 1/1 Running 0 5m59s
pc-replicaset-55xxh 1/1 Running 0 5m59s
pc-replicaset-zkzbw 1/1 Running 0 5m59s
镜像升级
编辑rs的容器镜像 - image: nginx:1.17.2
[root@master ~]# kubectl edit rs pc-replicaset -n xn
replicaset.apps/pc-replicaset edited
[root@master ~]# kubectl get rs -n xn -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
pc-replicaset 3 3 3 7m11s nginx nginx:1.17.2 app=nginx-pod
同样的道理，也可以使用命令完成这个工作# kubectl set image rs rs名称 容器=镜像版本 -n namespace
[root@master ~]# kubectl set image rs pc-replicaset nginx=nginx:1.17.1 -n xn
replicaset.apps/pc-replicaset image updated
[root@master ~]# kubectl get rs -n xn -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
pc-replicaset 3 3 3 7m48s nginx nginx:1.17.1 app=nginx-pod
删除ReplicaSet
使用kubectl delete命令会删除此RS以及它管理的Pod# 在kubernetes删除RS前，会将RS的replicasclear调整为0，等待所有的Pod被删除后，在执行RS对象的删除
[root@master ~]# kubectl delete rs pc-replicaset -n xn
replicaset.apps "pc-replicaset" deleted
[root@master ~]# kubectl get pod -n xn
No resources found in xn namespace.
如果希望仅仅删除RS对象（保留Pod），可以使用kubectl delete命令时添加–cascade=false选项（不推荐）。
[root@master ~]# kubectl delete rs pc-replicaset -n xn --cascade=false
replicaset.apps "pc-replicaset" deleted
[root@master ~]# kubectl get pods -n xn
NAME READY STATUS RESTARTS AGE
pc-replicaset-cl82j 1/1 Running 0 75s
pc-replicaset-dslhb 1/1 Running 0 75s
也可以使用yaml直接删除(推荐)
[root@k8s-master01 ~]# kubectl delete -f pc-replicaset.yaml
replicaset.apps "pc-replicaset" deleted
Deployment(Deploy)
为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了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
创建deployment
创建pc-deployment.yaml，内容如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: pc-deployment
namespace: xn
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
创建pod查看deployment# UP-TO-DATE 最新版本的pod的数量# AVAILABLE 当前可用的pod的数量
[root@master ~]# kubectl create -f pc-deployment.yaml --record=true
deployment.apps/pc-deployment1 created
[root@master ~]# kubectl get deploy pc-deployment -n xn
NAME READY UP-TO-DATE AVAILABLE AGE
pc-deployment 3/3 3 3 2m28s
查看rs# 发现rs的名称是在原来deployment的名字后面添加了一个10位数的随机串
[root@master ~]# kubectl get rs -n xn
NAME DESIRED CURRENT READY AGE
pc-deployment-6f6bc8fc5f 3 3 3 2m51s
查看pod
[root@master ~]# kubectl get pods -n xn
NAME READY STATUS RESTARTS AGE
pc-deployment-6f6bc8fc5f-d2pgt 1/1 Running 0 3m21s
pc-deployment-6f6bc8fc5f-fb5tt 1/1 Running 0 3m21s
pc-deployment-6f6bc8fc5f-thfqz 1/1 Running 0 3m21s
扩缩容
变更副本数量为5个并查看
[root@master ~]# kubectl scale deploy pc-deployment --replicas=5 -n xn
deployment.apps/pc-deployment scaled
[root@master ~]# kubectl get deploy pc-deployment -n xn
NAME READY UP-TO-DATE AVAILABLE AGE
pc-deployment 5/5 5 5 4m7s
[root@master ~]# kubectl get pod -n xn
NAME READY STATUS RESTARTS AGE
pc-deployment-6f6bc8fc5f-8xd5j 1/1 Running 0 15s
pc-deployment-6f6bc8fc5f-d2pgt 1/1 Running 0 4m14s
pc-deployment-6f6bc8fc5f-f7hs6 1/1 Running 0 15s
pc-deployment-6f6bc8fc5f-fb5tt 1/1 Running 0 4m14s
pc-deployment-6f6bc8fc5f-thfqz 1/1 Running 0 4m14s
编辑deployment的副本数量，修改spec:replicas: 4 查看pod
[root@master ~]# kubectl edit deploy pc-deployment -n xn
deployment.apps/pc-deployment edited
[root@master ~]# kubectl get pod -n xn
NAME READY STATUS RESTARTS AGE
pc-deployment-6f6bc8fc5f-d2pgt 1/1 Running 0 5m40s
pc-deployment-6f6bc8fc5f-f7hs6 1/1 Running 0 101s
pc-deployment-6f6bc8fc5f-fb5tt 1/1 Running 0 5m40s
pc-deployment-6f6bc8fc5f-thfqz 1/1 Running 0 5m40s
镜像更新
deployment支持两种更新策略:重建更新和滚动更新,可以通过strategy指定策略类型,支持两个属性:
strategy：指定新的Pod替换旧的Pod的策略， 支持两个属性：
type：指定策略类型，支持两种策略
Recreate：在创建出新的Pod之前会先杀掉所有已存在的Pod
RollingUpdate：滚动更新，就是杀死一部分，就启动一部分，在更新过程中，存在两个版本Pod
rollingUpdate：当type为RollingUpdate时生效，用于为RollingUpdate设置参数，支持两个属性：
maxUnavailable：用来指定在升级过程中不可用Pod的最大数量，默认为25%。
maxSurge： 用来指定在升级过程中可以超过期望的Pod的最大数量，默认为25%。
重建更新
编辑pc-deployment.yaml,在spec节点下添加更新策略
spec:
strategy: # 策略
type: Recreate # 重建更新
创建deploy进行验证,并动态观看更新过程
[root@master ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n xn
deployment.apps/pc-deployment image updated
[root@master ~]# kubectl get pods -n xn -w
NAME READY STATUS RESTARTS AGE
pc-deployment-59577f776-lcsxr 0/1 ContainerCreating 0 11s
pc-deployment-59577f776-wlqks 0/1 ContainerCreating 0 11s
pc-deployment-6f6bc8fc5f-d2pgt 1/1 Running 0 7m35s
pc-deployment-6f6bc8fc5f-fb5tt 1/1 Running 0 7m35s
pc-deployment-6f6bc8fc5f-thfqz 1/1 Running 0 7m35s
pc-deployment1-6f6bc8fc5f-d9q6z 1/1 Running 0 5m29s
pc-deployment1-6f6bc8fc5f-ls68s 1/1 Running 0 5m29s
pc-deployment1-6f6bc8fc5f-mwq8x 1/1 Running 0 5m29s
pc-deployment-59577f776-lcsxr 1/1 Running 0 28s
pc-deployment-6f6bc8fc5f-d2pgt 1/1 Terminating 0 7m52s
pc-deployment-59577f776-sjrx9 0/1 Pending 0 0s
pc-deployment-59577f776-sjrx9 0/1 Pending 0 0s
pc-deployment-59577f776-sjrx9 0/1 ContainerCreating 0 0s
pc-deployment-59577f776-sjrx9 1/1 Running 0 1s
pc-deployment-6f6bc8fc5f-d2pgt 0/1 Terminating 0 7m53s
pc-deployment-6f6bc8fc5f-thfqz 1/1 Terminating 0 7m53s
pc-deployment-6f6bc8fc5f-d2pgt 0/1 Terminating 0 7m53s
pc-deployment-59577f776-w79tr 0/1 Pending 0 0s
pc-deployment-6f6bc8fc5f-d2pgt 0/1 Terminating 0 7m53s
pc-deployment-59577f776-w79tr 0/1 Pending 0 0s
pc-deployment-59577f776-w79tr 0/1 ContainerCreating 0 0s
pc-deployment-6f6bc8fc5f-thfqz 0/1 Terminating 0 7m54s
pc-deployment-6f6bc8fc5f-thfqz 0/1 Terminating 0 7m54s
pc-deployment-6f6bc8fc5f-thfqz 0/1 Terminating 0 7m54s
pc-deployment-59577f776-w79tr 1/1 Running 0 1s
pc-deployment-6f6bc8fc5f-fb5tt 1/1 Terminating 0 7m54s
pc-deployment-6f6bc8fc5f-fb5tt 0/1 Terminating 0 7m55s
pc-deployment-6f6bc8fc5f-fb5tt 0/1 Terminating 0 7m55s
pc-deployment-6f6bc8fc5f-fb5tt 0/1 Terminating 0 7m55s
pc-deployment-59577f776-wlqks 1/1 Running 0 37s
滚动更新
编辑pc-deployment.yaml,在spec节点下添加更新策略
spec:
strategy: # 策略
type: RollingUpdate # 滚动更新策略
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
创建deploy进行验证
[root@master ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -n xn
deployment.apps/pc-deployment image updated
[root@master ~]# kubectl get pods -n xn -w
NAME READY STATUS RESTARTS AGE
pc-deployment-59577f776-lcsxr 1/1 Running 0 4m2s
pc-deployment-59577f776-w79tr 1/1 Running 0 3m33s
pc-deployment-59577f776-wlqks 1/1 Running 0 4m2s
pc-deployment-6ccc4766df-k5d9c 0/1 ContainerCreating 0 7s
pc-deployment-6ccc4766df-rg78g 0/1 ContainerCreating 0 7s
pc-deployment1-6f6bc8fc5f-d9q6z 1/1 Running 0 9m20s
pc-deployment1-6f6bc8fc5f-ls68s 1/1 Running 0 9m20s
pc-deployment1-6f6bc8fc5f-mwq8x 1/1 Running 0 9m20s
pc-deployment-6ccc4766df-k5d9c 1/1 Running 0 22s
pc-deployment-59577f776-w79tr 1/1 Terminating 0 3m48s
pc-deployment-6ccc4766df-qv22h 0/1 Pending 0 0s
pc-deployment-6ccc4766df-qv22h 0/1 Pending 0 0s
pc-deployment-6ccc4766df-qv22h 0/1 ContainerCreating 0 0s
pc-deployment-6ccc4766df-qv22h 1/1 Running 0 1s
pc-deployment-59577f776-w79tr 0/1 Terminating 0 3m49s
pc-deployment-59577f776-w79tr 0/1 Terminating 0 3m49s
pc-deployment-59577f776-w79tr 0/1 Terminating 0 3m49s
pc-deployment-59577f776-wlqks 1/1 Terminating 0 4m18s
pc-deployment-6ccc4766df-stnhm 0/1 Pending 0 0s
pc-deployment-6ccc4766df-stnhm 0/1 Pending 0 0s
pc-deployment-6ccc4766df-stnhm 0/1 ContainerCreating 0 0s
pc-deployment-59577f776-wlqks 0/1 Terminating 0 4m19s
pc-deployment-59577f776-wlqks 0/1 Terminating 0 4m19s
pc-deployment-59577f776-wlqks 0/1 Terminating 0 4m19s
pc-deployment-6ccc4766df-stnhm 1/1 Running 0 2s
pc-deployment-59577f776-lcsxr 1/1 Terminating 0 4m20s
pc-deployment-59577f776-lcsxr 0/1 Terminating 0 4m20s
pc-deployment-59577f776-lcsxr 0/1 Terminating 0 4m21s
pc-deployment-59577f776-lcsxr 0/1 Terminating 0 4m21s
pc-deployment-6ccc4766df-rg78g 1/1 Running 0 26s
滚动更新的过程：
镜像更新中rs的变化
查看rs,发现原来的rs的依旧存在，只是pod数量变为了0，而后又新产生了一个rs，pod数量为4# 其实这就是deployment能够进行版本回退的奥妙所在
[root@master ~]# kubectl get rs -n xn
NAME DESIRED CURRENT READY AGE
pc-deployment-59577f776 0 0 0 6m5s
pc-deployment-6ccc4766df 4 4 4 2m10s
pc-deployment-6f6bc8fc5f 0 0 0 13m
pc-deployment1-6f6bc8fc5f 3 3 3 11m
版本回退
deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能，下面具体来看.
kubectl rollout： 版本升级相关功能，支持下面的选项：
• status 显示当前升级状态
• history 显示 升级历史记录
• pause 暂停版本升级过程
• resume 继续已经暂停的版本升级过程
• restart 重启版本升级过程
• undo 回滚到上一级版本（可以使用–to-revision回滚到指定版本）
查看当前升级版本的状态
[root@master ~]# kubectl rollout status deploy pc-deployment -n xn
deployment "pc-deployment" successfully rolled out
查看升级历史记录
[root@master ~]# kubectl rollout history deploy pc-deployment -n xn
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版本， 如果省略这个选项，就是回退到上个版本，就是2版本
[root@master ~]# kubectl rollout undo deployment pc-deployment --to-revision=1 -n xn
deployment.apps/pc-deployment rolled back
查看发现，通过nginx镜像版本可以发现到了第一版
[root@master ~]# kubectl get deploy -n xn -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
pc-deployment 4/4 4 4 16m nginx nginx:1.17.1 app=nginx-pod
查看rs，发现第一个rs中有4个pod运行，后面两个版本的rs中pod为运行# 其实deployment之所以可是实现版本的回滚，就是通过记录下历史rs来实现的，# 一旦想回滚到哪个版本，只需要将当前版本pod数量降为0，然后将回滚版本的pod提升为目标数量就可以了
[root@master ~]# kubectl get rs -n xn
NAME DESIRED CURRENT READY AGE
pc-deployment-59577f776 0 0 0 9m14s
pc-deployment-6ccc4766df 0 0 0 5m19s
pc-deployment-6f6bc8fc5f 4 4 4 16m
金丝雀发布
Deployment控制器支持控制更新过程中的控制，如“暂停(pause)”或“继续(resume)”更新操作。
比如有一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。
更新deployment的版本，并配置暂停deployment并查看
[root@master ~]# kubectl set image deploy pc-deployment nginx=nginx:1.17.4 -n xn && kubectl rollout pause deployment pc-deployment -n xn
deployment.apps/pc-deployment image updated
deployment.apps/pc-deployment paused
[root@master ~]# kubectl rollout status deploy pc-deployment -n xn
Waiting for deployment "pc-deployment" rollout to finish: 2 out of 4 new replicas have been updated...
监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
[root@master ~]# kubectl get rs -n xn -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
pc-deployment-59577f776 0 0 0 11m nginx nginx:1.17.2 app=nginx-pod,pod-template-hash=59577f776
pc-deployment-6ccc4766df 0 0 0 7m58s nginx nginx:1.17.3 app=nginx-pod,pod-template-hash=6ccc4766df
pc-deployment-6f6bc8fc5f 3 3 3 19m nginx nginx:1.17.1 app=nginx-pod,pod-template-hash=6f6bc8fc5f
pc-deployment-7c88cdf554 2 2 2 87s nginx nginx:1.17.4 app=nginx-pod,pod-template-hash=7c88cdf554
[root@master ~]# kubectl get pod -n xn
NAME READY STATUS RESTARTS AGE
pc-deployment-6f6bc8fc5f-g7jfs 1/1 Running 0 4m9s
pc-deployment-6f6bc8fc5f-nps57 1/1 Running 0 4m11s
pc-deployment-6f6bc8fc5f-sz89c 1/1 Running 0 4m9s
pc-deployment-7c88cdf554-2m5j8 1/1 Running 0 2m
pc-deployment-7c88cdf554-62f82 1/1 Running 0 2m
确保更新的pod没问题了，继续更新
[root@master ~]# kubectl rollout resume deploy pc-deployment -n xn
deployment.apps/pc-deployment resumed
[root@master ~]# kubectl get rs -n xn -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
pc-deployment-59577f776 0 0 0 13m nginx nginx:1.17.2 app=nginx-pod,pod-template-hash=59577f776
pc-deployment-6ccc4766df 0 0 0 9m19s nginx nginx:1.17.3 app=nginx-pod,pod-template-hash=6ccc4766df
pc-deployment-6f6bc8fc5f 0 0 0 20m nginx nginx:1.17.1 app=nginx-pod,pod-template-hash=6f6bc8fc5f
pc-deployment-7c88cdf554 4 4 4 2m48s nginx nginx:1.17.4 app=nginx-pod,pod-template-hash=7c88cdf554
pc-deployment1-6f6bc8fc5f 3 3 3 18m nginx nginx:1.17.1 app=nginx-pod,pod-template-hash=6f6bc8fc5f
[root@master ~]# kubectl get pod -n xn
NAME READY STATUS RESTARTS AGE
pc-deployment-7c88cdf554-2m5j8 1/1 Running 0 2m54s
pc-deployment-7c88cdf554-62f82 1/1 Running 0 2m54s
pc-deployment-7c88cdf554-b6c9s 1/1 Running 0 23s
pc-deployment-7c88cdf554-sl9xn 1/1 Running 0 23s
pc-deployment1-6f6bc8fc5f-d9q6z 1/1 Running 0 18m
pc-deployment1-6f6bc8fc5f-ls68s 1/1 Running 0 18m
pc-deployment1-6f6bc8fc5f-mwq8x 1/1 Running 0 18m
删除Deployment,删除deployment，其下的rs和pod也将被删除
[root@master ~]# kubectl delete -f pc-deployment.yaml
deployment.apps "pc-deployment1" deleted
262
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
