Deployment 、DaemonSet、StatefulSet更新策略

Deployment

如果Pod是使用Deployment创建的，那么用户可以实时的修改Deployment 内容并应用，K8S 会自动完成Deployment的更新，如果更新过过程中发生了错误，还可以用Rollback 操作恢复Pod的版本

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

• Recreate : 重建，spec.strategy.type=Recreate 表示Deployment会在更新Pod时先杀掉所有正在运行的Pod然后创建新Pod
• Rolling Update：滚动更新 spec.strategy.type=RollingUpdate, 通过滚动更新的方式逐个更新Pod。

Rolling Update

滚动更新示意图

Rolling Update的两个重要参数

• maxUnavailable ：spec.strategy.type.RollingUpdate.MaxUnavailable 用于指定更新过程中不可用状态Pod数量的上限，此值可以是绝对值 例如1，或者不可用pod数占Pod期望数的百分比。如果设置为百分比，k8s会优先向下取整数。如果设置为 70%，整个系统中会确保可用状态的Pod总数最少占期望总数的 70%
• maxSurge： spec.strategy.type.RollingUpdate.MaxSurge 用于指定更新过程中Pod总数超过Pod期望副本数量部分的最大值。此值可以是绝对值 例如1，或者是百分比。如果是百分比，k8s会优先向上取整数。如果设置为30%，整个系统中会确保新旧的RS的Pod总数不会超过期望副本总数的130%。
  注意事项

1. 从1.6版本开始，两个参数都由默认的1 改为 25%。
2. 如果maxSurge 设置为0，那么maxUnavailable 必须设置为绝对值大于0.
3. 多重更新（RollOver）的情况，如果在Deployment的上一次更新还未完成，但是又发起了新的更新操作。那么K8S 会为每一次更新都创建相应的RS，而新的RS在创建成功后会逐个增加副本数，同事将之前正在扩容的RS停止更新，并加入旧版本历史列表中，并开始缩容至副本数为0的操作
4. 注意Deployment 的标签选择器（Label Selector ）的改动情况。

官方解释
.spec.selector is a required field that specifies a label selector for the Pods targeted by this Deployment.
选择器是必填字段
.spec.selector must match .spec.template.metadata.labels, or it will be rejected by the API.
必须匹配
In API version apps/v1, .spec.selector and .metadata.labels do not default to .spec.template.metadata.labels if not set. So they must be set explicitly. Also note that .spec.selector is immutable after creation of the Deployment in apps/v1.
在API apps/v1版本中，如果没有设置，两个值并不会默认相同，因此需要明确值。在此版本API中便签选择器在Deploy创建后就无法修改。
A Deployment may terminate Pods whose labels match the selector if their template is different from .spec.template or if the total number of such Pods exceeds .spec.replicas. It brings up new Pods with .spec.template if the number of Pods is less than the desired number.

Note: You should not create other Pods whose labels match this selector, either directly, by creating another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you do so, the first Deployment thinks that it created these other Pods. Kubernetes does not stop you from doing this.
If you have multiple controllers that have overlapping selectors, the controllers will fight with each other and won't behave correctly.

版本回滚

使用 rollout history 检查 deploy的历史记录 --revision 制定版本
使用 rollout undo 回滚到上个部署版本， 加 参数-to-revision 指定回滚版本

DaemonSet

1.6版本开始支持滚动更新。如如下两种策略

• OnDelete ： 默认升级策略，在创建好新的DaemonSet配置之后，新的Pod不会被自动创建，用户需要手动删除旧版本的Pod，才出发新建操作。
• RollingUpdate： 旧版本的POD 将被自动杀掉，然后自动创建新版的DaemonSet Pod。与Deployment 不同为不支持查看和管理DaemonSet的更新记录；回滚操作是通过再次提交旧版本配置而不是 rollback命令实现

StatefulSet

• OnDelete ： 默认升级策略，在创建好新的StatefulSetSet配置之后，新的Pod不会被自动创建，用户需要手动删除旧版本的Pod，才出发新建操作。
• RollingUpdate： StatefulSet 控制器将删除并重新创建 StatefulSet 中的每个 Pod。它将按照与 Pod 终止相同的顺序进行（从最大的序数到最小的），依次更新每个 Pod。Kubernetes 控制平面会等到更新的 Pod 运行并准备好，然后再更新其前任。如果您已设置.spec.minReadySeconds（请参阅“最小就绪秒数”），则控制平面会在 Pod 准备就绪后额外等待该时间，然后再继续。
• partitioned：分区滚动更新。如果指定了分区，则在更新 StatefulSet 时，将更新序数大于或等于该分区的所有 Pod .spec.template。所有序号小于分区的 Pod 都不会更新，即使删除了，也会在之前的版本中重新创建。如果 StatefulSet 的.spec.updateStrategy.rollingUpdate.partition大于其.spec.replicas，则对其的更新.spec.template将不会传播到其 Pod。在大多数情况下，您不需要使用分区，但如果您想要暂存更新、roll out Canary 或执行分阶段roll out，它们会很有用

回滚更新： 一旦更新配置有误，即使修改了配置，k8s也不会继续更新，而是等待异常POD恢复至正常。这时我们需要手动删除异常POD