Pod 升级可能面临的问题

当集群中的某个服务需要升级时，我们需要停止目前与该服务相关的所有 Pod，然后下载新版本镜像并创建新的 Pod。但是当集群规模比较庞大时，那么这个工作就会变成一个挑战，而且先全部停止然后再逐步升级的方式会导致较长一段时间内服务的不可用性。针对这种情况，k8s 提供了滚动升级方式来解决该问题。

Deployment 升级

Pod 对象通常由 Deployment 对象创建管理，接下来我们通过 Deployment 创建的 Pod 对象升级部署操作来展开叙述。

Deployment 创建示例

以 Nginx 的 Deployment 对象 yaml 定义为例，其中创建了一个 ReplicaSet，负责启动三个 nginx Pod，nginx-deployment.yaml 文件定义如下：

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:# 设置期望副本数replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80

1. 1. 创建 nginx-deployment.yaml 文件定义的 Deployment 对象：

kubectl create -f nginx-deployment.yaml

1. 1. 查看创建的 Deployment 对象：

kubectl get deployments

如果 Deployment 对象成功创建，则输出如下信息：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/3     0            0           1s

在检查集群中的 Deployment 时，所显示的字段有：

• • NAME：列出了名字空间中 Deployment 的名称。

• • READY：显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”。

• • UP-TO-DATE：显示为了达到期望状态已经更新的副本数。

• • AVAILABLE：显示应用可供用户使用的副本数。

• • AGE：显示应用程序运行的时间。

从上面 Deployment 对象输出的信息中，可以看到 READY 值为 0/3，说明 Deployment 对象还未创建就绪，因为创建 Deployment 对象是有时间间断的，这时我们可以通过查看 Deployment 上线状态，进一步来了解创建信息。

1. 1. 要查看 Deployment 上线状态：

kubectl rollout status deployment/nginx-deployment

输出类似信息：

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out

遇到上述情况，我们再等待一段时间，再次查看 Deployment 对象是否创建成功。

1. 1. 再次查看 Deployment 对象：

kubectl get deployments

输出如下信息：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           18s

此时 Deployment 已创建全部三个副本，并且所有副本都是最新的（它们包含最新的 Pod 模板） 并且可用。

1. 1. 查看 Deployment 对象创建的 ReplicaSet：

kubectl get rs

如果 RS 对象创建成功，输出如下信息：

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-75675f5897   3         3         3       18s

ReplicaSet 输出中包含以下字段：

• • NAME：列出名字空间中 ReplicaSet 的名称；

• • DESIRED：显示应用的期望副本个数，即在创建 Deployment 时所定义的值。此为期望状态；

• • CURRENT：显示当前运行状态中的副本个数；

• • READY：显示应用中有多少副本可以为用户提供服务；

• • AGE：显示应用已经运行的时间长度。

说明：创建的 ReplicaSet 确保总是存在三个 nginx Pod。

注意：ReplicaSet 的名称始终被格式化为：[Deployment名称]-[随机字符串]。其中的随机字符串是使用 pod-template-hash 作为种子随机生成的。

查看 Deployment 对象操作 ReplicaSet 创建的 Pod，并显示生成的标签：

kubectl get pods --show-labels

输出如下信息：

NAME                                READY     STATUS    RESTARTS   AGE       LABELS
nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453

注意：Pod 的名称和 ReplicaSet 的名称类似，被格式化为：[ReplicaSet名称]-[随机字符串]。

上面就是创建一个 Deployment 对象的完整过程，Deployment 对象创建过程中的调用链如下：

kubectl => Deployment => ReplicaSet => Pod => Container

接下来我们来看下 Deployment 更新升级操作。

Deployment 更新示例

基于上面创建的 Deployment 对象，现在需要将 Pod 的镜像更新到 nginx:1.23.1 ，可以通过下面两种方式更新操作：

• • 方式一

kubectl set image deployment/nginx-deployment nginx=nginx:1.23.1
deployment "nginx-deployment" image updated

• • 方式二

kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited

修改 Deployment 配置信息，将 spec.template.spec.containers[0].image 的值从 nginx:1.14.2 更改为 nginx:1.23.1，一旦镜像名（或 Pod 定义）发生了修改，则触发 k8s 系统完成 Deployment 所有运行 Pod 的滚动升级操作。

查看 Deployment 的上线状态，即更新过程：

kubectl rollout staus deployment/nginx-deployment

输出如下信息：

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for rollout to finish: 2 old replicas are pending termination...
Waiting for rollout to finish: 2 old replicas are pending termination...
Waiting for rollout to finish: 1 old replicas are pending termination...
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx-deployment" successfully rolled out

查看已更新的 Deployment 的更多信息：

• • 在 Deployment 上线成功后，查看 Deployment 的信息：

kubectl get deployments

输出如下信息：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           36s

• • 查看 Deployment 通过创建新的 ReplicaSet 并将其扩容到 3 个副本，将旧 ReplicaSet 缩容到 0 个副本完成了 Pod 的更新操作：

kubectl get rs

输出 新/旧 RS 的如下信息：

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   3         3         3       6s
nginx-deployment-75675f5897   0         0         0       36s

• • 查看当前运行的 Pod，发现名称已经更新了，如下信息：

kubectl get pods

输出如下信息：

NAME                                READY     STATUS    RESTARTS   AGE
nginx-deployment-1564180365-khku8   1/1       Running   0          14s
nginx-deployment-1564180365-nacti   1/1       Running   0          14s
nginx-deployment-1564180365-z9gth   1/1       Running   0          14s

• • 查看 Deployment 的更多详细信息：

kubectl describe deployments

输出如下信息：

Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Thu, 06 Sept 2022 10:56:25 +0000
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision=2
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:Labels:  app=nginxContainers:nginx:Image:        nginx:1.23.1Port:         80/TCPEnvironment:  <none>Mounts:       <none>Volumes:        <none>Conditions:Type           Status  Reason----           ------  ------Available      True    MinimumReplicasAvailableProgressing    True    NewReplicaSetAvailableOldReplicaSets:  <none>NewReplicaSet:   nginx-deployment-1564180365 (3/3 replicas created)Events:Type    Reason             Age   From                   Message----    ------             ----  ----                   -------Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-2035384211 to 3Normal  ScalingReplicaSet  24s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 1Normal  ScalingReplicaSet  22s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 2Normal  ScalingReplicaSet  22s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 2Normal  ScalingReplicaSet  19s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 1Normal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0

从上面的（创建和更新）示例中，可以看出通过 Deployment 对象创建的 Pod，要更新升级 Pod，只需再次更新 Deployment Pod 模板即可。

Deployment 操作 Pod 的更新原理

仔细看 Deployment（ kubectl describe deployments ）的详细信息：

25% max unavailable, 25% max surge

Deployment 可确保在更新时仅关闭一定数量的 Pod。默认情况下，它确保至少所需 Pod 的 75% 处于运行状态（25% max unavailable，最大不可用比例为 25%）。

Deployment 还确保仅所创建 Pod 数量只可能比期望 Pod 副本数量高一点点。默认情况下，它可确保启动的 Pod 个数比期望个数最多多出 125%（25% max surge，最大峰值 25%）。

Deployment 控制器调整（ReplicaSet）replicas 数量时，严格通过以下公式来控制发布节奏。

(目标副本数-maxUnavailable) <= 线上 Pod 实际 Ready 副本数 <= (目标副本数+maxSurge)

在这个升级过程中，Deployment 就能够保证服务不间断的情况下，并且副本数量始终维持在用户期望的数量。生产环境中，大规模化的应用更新即可平滑地升级，不影响业务服务的正常提供。

Deployment 是如何完成 Pod 更新的呢？

仔细观察上面 Deployment 对象创建 & 更新的过程，Pod 的滚动更新如下所示：

在初始创建 Deployment 时，系统创建了一个 ReplicaSet (nginx-deployment-75675f5897)，并按照用户需求（Pod 副本期望数）创建了 3 个 Pod 副本。当更新 Deployment 时，系统创建了一个新的 ReplicaSet (nginx-deployment-1564180365)，并将其 Pod 副本数扩展到 1 ，然后将旧的 ReplicaSet 缩减为 2。然后系统继续按照相同的更新策略对新旧两个 RS 进行逐个调整。最后，新的 RS 运行 3 个新版本的 Pod 副本，旧的 RS 的 Pod 副本数量则缩减为 0。

Deployment 更新策略

在 Deployment 的定义中，可以通过 spec.strategy 指定 Pod 的更新策略，目前支持两种更新策略：

• • Recreate（重建）：设置 spec.strategy.type=Recreate，表示 Deployment 在更新 Pod 时，会先杀掉所有正在运行的 Pod，然后创建新的 Pod。

• • RollingUpdate（滚动更新）：设置 spec.strategy.type=RollingUpdate，表示 Deployment 会以滚动更新的方式来逐个更新 Pod。同时，可以通过设置 spec.strategy.rollingUpdate 下的两个参数（maxUnavailable 和 maxSurge）来控制滚动更新的过程。

下面对 RollingUpdate（滚动更新） 时的两个主要参数的说明如下：

• • spec.strategy.rollingUpdate.maxUnavailable：用于指定 DepIoyment 在更新过程中不可用状态的 Pod 数量的上限。该 maxUnavailable 的数值可以是整数绝对值（例如5）或 Pod 期望的副本数的百分比（例如10%），如果被设置为百分比，那么系统会先以 向下取整的方式计算出绝对值（整数）。而当另一个参数 maxSurge 被设置为 0 时，maxUnavailable 则必须被设置为绝对数值大于 0 的整数（从 Kubernetes v1.6 开始，maxUnavailable 的默认值从 1 改为 25%）。举例来说，当 maxUnavailable 被设置为 30% 时，旧的 ReplicaSet 可以在滚动更新开始时立即将副本数缩小到所需副本总数的70%。一旦新的 Pod 创建并准备好，旧的 ReplicaSet 会进一步缩容，新的 ReplicaSet 又继续扩容，整个过程中系统在任意时刻都可以确保可用状态的 Pod 总数至少占 Pod 期望副本总数的 70%。

• • spec.strategy.rollingUpdate.maxSurge：用于指定在 Deployment 更新 Pod 的过程中 Pod 总数超过 Pod期望副本数部分的最大值。该 maxSurge 的数值可以是绝对值（例如5）或 Pod 期望副本数的百分比（例如10%）。如果设置为百分比，那么系统会先按照 向上取整的方式计算出绝对数值（整数）（从 Kubernetes v1.6 开始，maxSurge 的默认值从 1 改为 25%）。举例来说，当 maxSurge 的值被设置为 30% 时，新的 ReplicaSet 可以在滚动更新开始时立即进行副本数扩容，只需要保证新旧ReplicaSet 的 Pod 副本数之和不超过期望副本数的 130% 即可。一旦旧的 Pod 被杀掉，新的 ReplicaSet 就会进一步扩容。在整个过程中系统在任意时刻都能确保新旧 ReplicaSet 的 Pod 副本总数之和不超过所需副本数的 130%。

Deployment 更新注意事项

1. 1. 需要注意 多重更新（Rollover） 的情况。如果 Deployment 的上一次更新正在进行，此时用户再次发起 Deployment 的更新操作，那么 Deployment 会为每一次更新都创建一个 ReplicaSet，而每次在新的 ReplicaSet 创建成功后，会逐个增加 Pod 副本数，同时将之前正在扩容的 ReolicaSet 停止扩容（更新），并将其加入旧版本 ReplicaSet 列表中，然后开始缩容至 0 的操作。

【举例说明】

假设我们创建一个 Deployment，这个 Deployment 开始创建 5 个 nginx:1.14.2 的 Pod 副本，在这个创建 Pod 动作尚未完成时，我们又将 Deployment 进行更新，在副本数不变的情况下将Pod 模板中的镜像修改为 nginx:1.23.1，又假设此时 Deployment 已经创建了 3 个 nginx:1.14.2 的Pod 副本，则 Deployment 会立即杀掉已创建的 3 个 nginx:1.14.2 的 Pod，并开始创建 nginx:1.23.1 的 Pod，Denlovment 不会在等待 nginx:1.14.2 的 Pod 创建到 5 个之后再进行更新操作。

1. 1. 还需要注意更新 Doployment 的 标签选择器（Label Selector） 的情况。通常来说，不鼓励更新 Doployment 的标签选择器，因为这样会导致 Deployment 选择的 Pod 列表发生变化，也可能与其他控制器产生冲突。如果一定要更新标签选择器，那么请务必谨慎，确保不会出现其他问题。

Doployment 的标签选择器（Label Selector）更新注意事项

当 Doployment 标签选择器（Label Selector）更新时，需要注意以下几种情况：

1. 1. 添加选择器标签时。

2. 2. 更新标签选择器时。

3. 3. 删除标签选择器时。

• • 1》添加选择器标签时，必须同步修改 Deployment 配置的 Pod 的标签，为 Pod 添加新的标签，否则 Deployment 的更新会报验证错误而失败：

deployments "nainx-deplovment" was not valid:
* spec.template.metadata.labels:Invalid value: {"app":"nginx"} : 'Selector' does not match template 'labels'

添加标签选择器是无法向后兼容的，这意味着新的标签选择器不会匹配和使用旧选择器创建的ReplicaSets 和 Pod，因此添加选择器将会导致所有旧版本的 ReplicaSets 和由旧 ReplicaSets 创建的 Pod 处于孤立状态（不会被系统自动删除，也不受新的 ReplicaSet 控制）。

通过命令操作，为标签选择器和 Pod 模板添加新的标签：

kubectl edit deployment

查看修改后的 ReplicaSet 信息：

kubectl get rs

输出如下信息：

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-75675f5897   3         3         3       3s
nginx-deployment-70656f5973   3         3         3       1m
nginx-deployment-73675f8579   0         0         0       53s

查看新 RS（nginx-deployment-75675f5897） 创建的 3 个 Pod：

kubectl get pods

• • 2》更新标签选择器，即更改选择器中标签的键或者值，也会产生与添加选择器标签类似的效果。

• • 3》删除标签选择器，即从 Deployment 的标签选择器中删除一个或者多个标签，该 Deployment 的 RS 和 Pod 不会受到任何影响。但需要注意，被删除的标签仍然会存在现有的 Pod 和 RS 上，此时现有的 RS 和 Pod 就会处于孤立状态（不会被系统自动删除，也不受新的 ReplicaSet 控制）。

Deployment 回滚

有时候我们可能需要将 Deployment 回滚到旧版本，比如：新的 Deployment 不稳定时。

在默认情况下，所有 Deployment 的发布记录都被保留在系统中，以便于我们随时进行回滚（可配置历史记录数据）。

Deployment 回滚示例

举例，比如在更新 Deployment 镜像时，将镜像名称或版本设置错误（一个不存在的镜像）。

此处我们依然以 Nginx 为例，假设 Nginx 的镜像设置成 nginx:1.231（正确写法，nginx:1.23.1）

kubectl set image deployment/nginx-deployment nginx=nginx:1.231
deployment "nginx-deployment" image updated

则这时 Deployment 的部署过程会卡（qia）住，查看 Deployment 的上线状态（更新过程）：

kubectl rollout staus deployment/nginx-deployment

输出如下信息：

Waiting for rollout to finish: 1 out of 3 new replicas have been updated...

卡住的原因是设置的 nginx 镜像根本不存在，因此需要执行 Ctrl+C 命令来终止查看更新过程的命令。

还可以进一步查看 RS 的状态：

kubectl get rs

在依据上面 RS 的信息，具体查看 RS 创建的 Pod：

kubectl get pods

输出的信息中，会有 STATUS 值为 ImagePullBackOff 的记录，此时说明由 RS 创建的该 Pod 被卡在镜像拉取的过程中。

为了解决上面描述的问题，这时我们就需要回滚到之前稳定版本的 Deployment，回滚操作如下：

1. 1. 查看这个 Deployment 部署的历史记录：

kubectl rollout history deployment/nginx-deployment

输出如下信息：

deployments "nginx-deployment"
REVISION     CHANGE-CAUSE
1            kubectl create --filename=nginx-deployment.yaml --record=true
2            kubectl set image deployment/nginx-deployment nginx=nginx:1.23.1
3            kubectl set image deployment/nginx-deployment nginx=nginx:1.231

说明：在创建 Deployment 时使用 --record 参数，就可以在 CHANGE-CAUSE 列看到每个版本使用的命令了。另外，Deployment 的更新操作是在 Deployment 进行部署（Rollout）时被触发的，这意味着当且仅当 Deployment 的 Pod模板（即 spec.template）被更改时才会创建新的修订版本，例如更新模板标签或容器镜像。其他更新操作（如扩展副本数）将不会触发 Deployment 的更新操作，这也意味着我们将 Deployment 回滚到之前的版本时，只有 Deployment 的 Pod 模板部分会被修改。

指定版本号 --version=<N> 参数，查看特定版本信息：

kubectl rollout history deployment/nginx-deployment --version=3

输出如下信息：

deployments "nginx-deployment" with revision #3
Pod Template:Labels: app=nginxpod-template-hash=3660254250Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.231Containers:nginx: Image: nginx:1.231Port: 80/TCPEnvironment:  <none>Mounts:  <none>Volumes:  <none>

通过上面的详细信息，我们可以看到 Image 镜像版本为 nginx:1.231，但真实情况是该镜像不存在，因此我们撤销本次发布并回滚到上一个部署的版本，命令操作如下：

kubecti rollout undo deployment/nginx-deployment
deployment "nginx-deployment" rolled back

还可以使用 --to-revision 参数指定要回滚的部署版本号：

kubeetl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back

通过上面的操作，此时 Deployment 就回滚到之前稳定的版本了，我们可以从 Deployment 的事件信息中查看回滚版本 2 的操作过程：

kubectl describe deployment/nginx-deployment

这里详细信息就不在展示，可自行实践查看 Deployment 的事件回滚信息。

Deployment 操作 Pod 的回滚原理

通过 Deployment 对象创建的 Pod，回滚版本其实和滚动更新是类似的，刚好是滚动更新（升级）的反向过程，如下图所示：

暂停和恢复 Deployment 的部署操作，以完成复杂的修改

对于复杂的 Deployment 配置修改，为了避免频繁触发 Deployment 的更新操作，可以先暂停 Deployment 的更新操作，然后进行配置修改，在恢复 Deployment ，一次性触发完整的更新操作，就可以避免不必要的 Deployment 更新操作了。

暂停 Deployment 的部署操作

通过执行如下命令，暂停 Deployment 的更新操作：

kubectl rollout pause deployment/nginx-deployment nginx=nginx:1.231
deployment "nginx-deployment" paused

为了验证上面的操作是否有触发新的 Deployment 部署操作，我们查看 Deployment 的历史记录：

kubectl rollout history deployment/nginx-deployment

输出如下信息：

deployments "nginx-deployment"
REVISION     CHANGE-CAUSE
1            kubectl create --filename=nginx-deployment.yaml --record=true

通过查看历史记录信息，并没有发现有触发新的 Deployment 部署操作。

在暂停 Deployment 部署之后，可以根据需要进行任意次数的配置更新。例如，再次配置更新容器的资源限制：

kubectl set resources deployment nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
deployment "nginx-deployment" resource requirements updated

除了上面命令行的方式配置更新容器的资源限制，也可以通过编辑 Deployment 的 yaml 文件配置，k8s 系统中没有刻意强调只能使用其中一种方式，依据个人喜好，选择对应的操作方式，最终达到目的即可。生产环境中，我个人更喜欢修改 yaml 配置文件方式操作部署。

恢复 Deployment 的部署操作

执行如下命令，恢复 Deployment 的部署操作：

kubectl rollout resume deploy nginx-deployment
deployment "nginx-deployment" resumed

再次查看 ReplicaSet 创建信息：

kubectl get rs

输出如下信息：

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-75675f6987   3         3         3       6s
nginx-deployment-57675f9876   0         0         0       42s

查看 Deployment 更多信息：

kubectl describe deployment/nginx-deployment

注意：在恢复暂停的 Deployment 之前，无法回滚该 Deployment。

对于 ReplicationController（简称，RC） 的滚动更新，k8s 提供了一个 kubectl rolling-update 命令进行实现。RC 与 RS/Deployment 相比，RC 不具有 Deployment 在应用版本升级过程中的历史记录、新旧版本数量的精细控制等功能，在 k8s 版本迭代的演进过程中，RC 逐渐被 RS 和 Deployment 所取代（目前新版本的 k8s 中，RC 已经淘汰，替代者是 RS），k8s 官方推荐优先使用 Deployment 完成 Pod 的部署和升级操作。

Pod 其他管理对象的更新策略

Kubernetes 从1.6版本开始,对 DaemonSet和 StatefulSet的更新策略也引入类似于Deployment的滚动升级,通过不同的策略自动完成应用的版本升级。

DaemonSet 更新策略

目前DaemonSet的升级策略包括两种：OnDelete 和 RollingUpdate。

1. 1. OnDelete：DaemonSet 的默认升级策略，与 1.6 及以前版本的 Kubernetes 保持一致。当使用OnDelete 作为升级策略时，在创建好新的 DaemonSet 配置之后，新的 Pod 并不会被自动创建，直到用户手动删除旧版本的 Pod，才触发新建操作。

2. 2. RollingUndate：从 Kubernetes v1.6 版本开始引入。当使用 RollingUpdate 作为升级策略对 DaemonSet 进行更新时，旧版本的 Pod 将被自动杀掉，然后自动创建新版本的 DaemonSet Pod，整个过程与普通 Deployment 的滚动升级一样是可控的。不过有两点不同于普通 Pod 的滚动升级：

• • 一是目前的 Kubernetes 还不支持查看和管理 DaemonSet 的更新历史记录；

• • 二是 DaemonSet 的回滚（Rollback）并不能如同 Deployment 一样直接通过 kubectl rollback 命令来实现，必须通过再次提交就版本配置的方式实现。

推荐参考文章：

• • 《对 DaemonSet 执行滚动更新》，https://kubernetes.io/zh-cn/docs/tasks/manage-daemon/update-daemon-set/

• • 《对 DaemonSet 执行回滚》，https://kubernetes.io/zh-cn/docs/tasks/manage-daemon/rollback-daemon-set/

StatefulSet 更新策略

Kubernetes v1.6 版本开始，针对 StatefulSet 的更新策略逐渐向 Deployment 和 DaemonSet 的更新策略看齐，也将实现 RollingUpdate，Paritioned 和 OnDelete 这几种策略，以保证 StatefulSet 中各 Pod 有序地、逐个更新，并且能够保留更新历史，也能回滚到某个历史版本。

推荐参考文章：

• • 《StatefulSet 更新策略》，https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/#update-strategies