k8s-deployment暂停、恢复与更新策略
一、暂停与恢复
- 使用 kubectl rollout pause 命令即可暂停 Deployment 更新：
kubectl set image deploy.v1.apps/nginx nginx=nginx:1.9.1
deployment.apps
- 然后对 Deployment 进行相关更新操作，比如先更新镜像，然后对其资源进行限制（如果使用的是 kubectl edit 命令，可以直接进行多次修改，无需暂停更新，kubectl set 命令一般会集成在CICD 流水线中
[root@k8s-master01 ~]$ kubectl set image deploy.v1.apps/nginx nginx=nginx:1.9.1
[root@k8s-master01 ~]$ kubectl set resources deployment.v1.apps/nginx -c=nginx --limits=cpu=200m,memory=512Mi
[root@k8s-master01 ~]$ kubectl edit deployment nginx
注：此时发现已经修改了资源但是pod并未重建
[root@k8s-master01 ~]$ kubectl rollout history deploy/nginx
注：通过 rollout history查看历史版本也没有新的更新
- 使用 kubectl rollout resume 恢复 Deployment 更新
[root@k8s-master01 ~]$ kubectl rollout resume deployment.v1.apps/nginx
- 可以查看到恢复更新的 Deployment 创建了一个新的 RS（ReplicaSet 缩写）：
[root@k8s-master01 ~]$ kubectl get rs
[root@k8s-master01 ~]$ kubectl get po
- 可以查看 Deployment 的 image（镜像）跟resources已改变
[root@k8s-master01 ~]$ kubectl describe deployment nginx
二、更新策略
1. 历史版本清理策略：
在默认情况下，revision 保留 10 个旧的 ReplicaSet，其余的将在后台进行垃圾回收，可以
在.spec.revisionHistoryLimit 设置保留 ReplicaSet 的个数。当设置为 0 时，不保留历史记录。
2. 更新策略：
Kubernetes 控制平面会创建新的 ReplicaSet 控制器，并且逐步替换旧的 Pod，直到所有 Pod 都被替换为止
-
spec.strategy.type==Recreate，表示重建，先删掉旧的Pod再创建新的Pod；
-
spec.strategy.type==RollingUpdate，表示滚动更新，可以指定maxUnavailable和maxSurge来控制滚动更新过程；
-
maxUnavailable：表示在进行滚动更新期间允许的最大不可用Pod数量。例如，如果设置为1，则在进行滚动更新时，允许有一个Pod处于不可用状态。默认情况下，maxUnavailable被设置为25%。
-
maxSurge：表示超出所需副本数的最大Pod数量。例如，如果当前Deployment对象需要5个Pod，并将maxSurge设置为1，则最多允许6个Pod运行。这一策略可以确保在进行滚动更新时，新版本的Pod可以逐渐替换旧版本的Pod，同时保持应用程序的可用性。
举例：
当maxUnavailable被设置为25%时，表示在进行滚动更新期间，最多允许25%的Pod处于不可用状态。这意味着如果Deployment对象中有10个Pod正在运行，则最多只能有2个Pod同时不可用。此时，Kubernetes将按照预定义的策略创建和替换Pod，以确保应用程序在更新过程中始终保持可用状态。
假设我们有一个Deployment对象需要运行4个Pod来提供服务。如果我们要进行滚动更新，并设置maxUnavailable为25%，则在更新期间，最多只能有1个Pod处于不可用状态。假设我们先启动新版本的Pod，然后逐步停止旧版本的Pod进行替换。如果在更新过程中出现问题导致两个Pod同时不可用，那么Kubernetes将暂停进一步更新操作，直到有至少一个Pod再次变得可用。这样可以确保应用程序在更新过程中始终保持最小限度的可用性。
当maxSurge被设置为25%时，表示可以在所需Pod数量的基础上运行多达25%的额外Pod。这意味着如果Deployment对象需要运行4个Pod，则最多可以创建5个Pod（即所需的4个加上超出部分的1个）。这种策略允许在进行滚动更新时，逐步增加新版本的Pod数量，以确保应用程序始终具有足够的容量来处理请求，并逐渐替换旧版本的Pod。
假设我们有一个Deployment对象需要运行4个Pod来处理请求。如果我们要进行滚动更新，并将maxSurge设置为25%，则Kubernetes最多会创建5个Pod来处理请求。在更新期间，Kubernetes会先启动新版本的Pod，然后逐步停止旧版本的Pod进行替换。在此过程中，最多有5个Pod在运行，其中4个是所需的Pod，另外1个是超出部分的Pod。当所有的旧版本Pod都被替换为新版本Pod时，超出部分的Pod将被删除。这样可以确保应用程序在更新过程中始终具有足够的容量来处理请求，同时保持应用程序的可用性和稳定性。
3. Ready 策略：
.spec.minReadySeconds 是可选参数，指定新创建的 Pod 应该在没有任何容器崩溃的情况下视为 Ready（就绪）状态的最小秒数，默认为 0，即一旦被创建就视为可用，通常和容器探针连用。
