Kubernetes应用编排与管理 —— Deployment升级策略

1、Deployment概述

　　Deployment 是 Kubernetes 控制器的一种高级别实现，它构建于 ReplicaSet 控制器之上，它可用于为 Pod 和 ReplicaSet 资源提供声明式更新，并能够以自动方式实现跨多个 ReplicaSet 对象的滚动更新功能。相比较来说，Pod 和 ReplicaSet 是较低级别的资源，以至于很少被直接使用。

　　Deployment 控制器资源的主要职责同样是为了保证 Pod 资源健康运行，其大部分功能通过调用 ReplicaSet 控制器实现，并增添了部分特性。

• 版本记录：将 Deployment 对象的更新操作予以保存，以便后续可能执行的回滚操作使用。
• 回滚：更新操作启动后的任一时刻（包括完成后）发现问题，都可以通过回滚机制将应用返回到前一个或由用户指定的历史记录中的版本。
• 暂停和启动：更新过程中能够随时暂停和继续完成后面的步骤。
• 事件和状态查看：必要时可以查看 Deployment 对象的更新进度和状态。
• 多种升级策略：一是 Recreate，即重建更新机制，单批次更新所有 Pod 对象；另一个是 RollingUpdate，即滚动更新机制，多批次逐步替换旧有的 Pod 至新的版本。

　　通过以上内容可以知道Deployment提供了很多核心功能，在本文主要关注Deployment多种升级策略功能。通过深入研究Deployment升级策略，我们将获得更好的理解和掌握如何在Kubernetes环境中进行应用程序的升级。我们将学习如何选择合适的升级策略，并了解如何正确配置和管理升级过程中的各种参数。最终，我们将能够实现无缝、可控的应用程序升级，提高应用的稳定性和可用性。

      在接下来的篇章中，让我们一起深入探索Deployment升级策略的精髓，并学习如何在实际应用中应用这些策略，为应用程序的持续演进提供支持。

注意 1：Deployment只负责管理不同版本的ReplicaSet， 由ReplicaSet管理Pod副本数。每个ReplicaSet对应了Deployment template的一个版本，一个ReplicaSet下的Pod都是相同的版本。

 2、Deployment升级策略 

　　Deployment控制器支持两种更新策略: 滚动更新(RollingUpdate)和删除式更新(Recreate)也称为单批次更新，默认使用滚动更新策略。 

• 滚动更新(Rolling Update)，滚动更新是默认的更新策略，一次仅更新一批Pod，当更新的Pod就绪后再更新另一批，直到全部更新完成为止；该策略实现了不间断服务的目标，但是在更新过程中，不同客户端得到的响应内容可能会来自不同版本的应用，会出现新老版本共存状态。
• 删除式更新(Recreate)，当更新策略设定为Recreate，在更新镜像时，它会先删除现在正在运行的Pod，等彻底杀死后，重新创建新的RS(ReplicaSet)，然后启动对应的Pod，在整个更新过程中，会造成服务一段时间无法提供服务。也称之为单批次更新。

　　Deployment 控制器的滚动更新操作并非在同一个 ReplicaSet 控制器对象下删除并创建 Pod 资源，而是将它们分置于两个不同的控制器之下，当前 ReplicaSet 对象的 Pod 副本数量不断减少的同时，新 ReplicaSet 对象的 Pod 对象数量不断增加，直到现有 ReplicaSet 对象的 Pod 副本数为 0，而新控制器的副本数量变得完全符合期望值，新旧版本之间区别彼此 Pod 对象的关键标签为 pod-template-hash。

2.1  滚动更新(Rolling Update)策略实战

2.1.1 滚动更新(Rolling Update)策略升级步骤

　　滚动更新(RollingUpdate)一次仅更新一批Pod，当更新的Pod就绪（可用）后，再更新另一批，直到全部更新完成为止，该策略实现了不间断服务的目标，在更新过程中可能会出现不同的应用版本且并存，同时提供服务的情况，Rolling Update升级策略分为三个步骤:

• 创建新的RS，然后根据新的镜像运行新的Pod。
• 删除旧的Pod，启动新的Pod，当新Pod就绪后，继续删除旧Pod，启动新Pod。
• 持续第二步过程，直到所有Pod都被更新成功。

注意 1：注意滚动升级步骤第2步，存在先增新后减旧、先减旧后增新、同时增减（少减多增）多种情况，具体与滚动升级策略属性spec.strategy.rollingUpdate.maxSurge和spec.strategy.rollingUpdate.maxUnavailable配置相关，此部分会在下文进行详细解释。

注意 2：在Deployment的滚动升级期间，可以通过以下方式判断Pod是否处于可用状态：Pod配置就绪探针（Readiness Probe）的情况下：如果就绪探针的探测结果为成功，则表示容器已经准备好接收流量，该Pod被认为是就绪状态。Pod没有就绪探针的情况下：判断Pod是否就绪的依据主要是基于Pod的运行状态，一般Pod的状态为Running则认为Pod是就绪状态。

注意 3：修改 Deployment 控制器的 minReadySeconds、replicas 和 strategy 等字段的值并不会触发 Pod 资源的更新操作，因为它们不属于 template 的内嵌字段，对现存的 Pod 对象不产生任何影响。

2.1.2 滚动更新(Rolling Update)策略实战

（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

#  type字段须配置为RollingUpdate #  spec: #     strategy: #        type: RollingUpdate # 应用配置文件,现版本Nginx是1.16版本，要滚动到1.21.5； root@kubernetes-master01:~# cat nginx-deployment-test.yaml apiVersion: apps/v1 kind: Deployment metadata:   name: deployment-nginx-test   namespace: deployment-test spec:   strategy:     type: RollingUpdate   replicas: 2   selector:     matchLabels:       app: nginx-deployment   template:     metadata:       labels:         app: nginx-deployment     spec:       containers:       - name: nginx         image: nginx:1.16         imagePullPolicy: IfNotPresent         ports:         - name: http           containerPort: 80

在集群创建Deployment工作负载对象deployment-nginx-test。

1 2 3 4

[root@node1 deploy]# kubectl create ns deployment-test namespace/deployment-test created [root@node1 deploy]# kubectl apply -f nginx-deployment-test.yaml deployment.apps/deployment-nginx-test created

查看Deployment工作负载对象deployment-nginx-test状态，可以看到其滚动升级策略类型为RollingUpdate，这里提前注意