在K8S中，Deployment 升级过程有哪些?

在Kubernetes（K8s）中，Deployment的升级过程是一个受控且平滑的过程，用于将应用的新版本无缝地替换旧版本。以下是Deployment升级过程的详细步骤：

1. 更新Deployment配置

1. 准备新版本镜像或配置：
   • 确定新版本的应用程序镜像或需要更改的配置。
   • 更新Deployment的YAML配置文件，例如更改镜像标签到新版本的应用程序镜像，或修改应用配置（如环境变量、命令参数等）。
2. 应用更改：
   • 通过kubectl apply命令或API调用将新的配置应用到集群中。例如，kubectl apply -f my-deployment.yaml。

2. Deployment控制器检测到配置变化

1. 开始执行滚动更新策略：
   • Kubernetes Deployment控制器检测到配置变化后，会开始执行滚动更新（Rolling Update）策略。这是Deployment的默认升级策略。

3. 滚动更新过程

1. 创建新的ReplicaSet：
   • Deployment控制器根据新的Pod模板创建一个新的ReplicaSet。
   • 新的ReplicaSet开始创建并启动指定数量的新Pod，同时确保任何时候集群中至少有一部分旧Pod仍在提供服务。
2. 逐步替换旧Pod：
   • 滚动更新策略会按照ReplicaSet中的Pod副本数量和指定的.spec.strategy.rollingUpdate.maxUnavailable和.spec.strategy.rollingUpdate.maxSurge参数来逐步创建新版本Pod，并同时删除旧版本Pod。
   • maxUnavailable定义了可以有多少个Pod不可用（未就绪）而不会影响服务的整体可用性。
   • maxSurge则指定了可以比期望副本数多创建多少个Pod，以加速升级过程。
3. 健康检查：
   • 在每个新Pod被创建之后，Kubernetes会根据定义的livenessProbe（存活探针）和readinessProbe（就绪探针）来检查新Pod是否已经启动并准备好接收流量。
   • 当新Pod通过健康检查并标记为“就绪”时，Service会逐渐将流量从旧Pod转移到新Pod。
4. 完成替换：
   • 一旦所有旧Pod都被新Pod替换并且新版本的所有Pod都已准备就绪，则升级过程结束。

4. 监控与回滚

1. 监控状态：
   • 在升级过程中，可以通过kubectl或Kubernetes Dashboard监控Deployment的状态以及Pod的健康状况。
2. 回滚操作：
   • 如果在升级过程中发现问题，可以立即执行回滚操作回到上一个已知稳定版本。
   • Kubernetes自动维护着每个Deployment的历史记录，允许用户轻松地基于修订历史（revision history）回滚到之前任何一个版本。

5. 清理与验证

1. 清理旧资源：
   • 一旦验证新版本的应用程序正常工作，可以考虑清理旧的ReplicaSet和Pod副本，以释放资源。不过通常这些旧的ReplicaSet会被保留一段时间，以备回滚之需。
2. 验证新版本：
   • 测试新版本应用程序的功能，确保一切正常。

6. 其他操作

1. 暂停与恢复更新：
   • 在滚动更新过程中，如果需要暂停更新过程，可以使用kubectl rollout pause deployment命令。这会阻止新的Pod创建，但不会影响现有Pod的运行。
   • 当准备好继续时，可以使用kubectl rollout resume deployment命令继续滚动更新。
2. 检查更新状态：
   • 使用kubectl rollout status deployment命令来检查滚动更新的状态。

综上所述，Kubernetes中的Deployment升级过程旨在实现最小的服务中断和最大程度的可恢复性。通过滚动更新策略、健康检查、监控与回滚机制等，可以确保应用程序在升级过程中的稳定性和可靠性。