Kubernetes Deployment升级与回退实现过程

在生产环境中，应用持续交付要求能够在不中断服务的前提下平滑地升级，同时在出现问题时能迅速回退到稳定版本。Kubernetes 的 Deployment 机制正是为此而设计的。

本篇文章将介绍如何使用 kubectl set image --record 命令进行版本更新，以及如何利用 kubectl rollout undo 快速回退，帮助你掌握升级和回退 Deployment 的核心技巧。

Kubernetes Deployment 基础概念

Deployment 是 Kubernetes 中用于管理无状态应用的核心控制器。

它主要负责：

• 定义所需的 Pod 副本数
• 生成并维护 ReplicaSet 集合，确保当前运行状态符合预期
• 实现滚动更新，逐步替换旧版本 Pod 为新版本 Pod，保证服务连续性

通过声明式的方式，我们只需描述期望状态，Deployment 控制器便会自动完成版本更新、扩缩容以及故障回退等任务。

利用kubectl -n namespace set image --record 实现版本升级

在升级过程中，我们常常需要将容器镜像更新为新版本。使用以下命令可以完成这一操作：

kubectl -n test set image deployment/my-deployment my-container=myimage:newtag --record

• -n test：指定命名空间
• deployment/my-deployment：指定要更新的 Deployment 名称。
• my-container=myimage:newtag：将容器名称 my-container 对应的镜像更新为 myimage:newtag。
• –record：该参数会将此次操作记录在 Deployment 的 annotation 中（记录在 kubernetes.io/change-cause 字段中），方便后续查阅更新历史和在出现问题时进行回退。

更新命令执行后，Deployment 控制器会启动滚动更新流程，逐步创建新版本的 Pod 并删除旧版本的 Pod，从而实现零停机升级。

监控滚动更新进程

升级过程中可以使用以下命令来监控更新状态，确保新版本 Pod 已正常启动并达到预期副本数：

kubectl rollout status deployment/my-deployment

此外，还可以使用 kubectl get pods 和 kubectl get rs 分别查看 Pod 和 ReplicaSet 的状态，了解新旧版本 Pod 的数量变化情况。这样可以及时发现镜像拉取失败或健康检查不通过等问题。

Deployment 回退：快速恢复稳定版本

在升级后发现问题时，可以使用回退命令将 Deployment 恢复到之前的稳定版本。最简单的方式是执行：

kubectl rollout undo deployment/my-deployment

该命令会将 Deployment 回退到上一个版本。如果需要回退到特定版本，还可以加上 --to-revision 参数，例如：

kubectl rollout undo deployment/my-deployment --to-revision=2

回退命令同样会触发滚动更新，将现有的 Pod 替换为之前版本的 Pod，确保应用尽快恢复正常运行。

实战演示：升级与回退操作流程

假设我们有一个简单的 Deployment，其 YAML 文件如下：

apiVersion: apps/v1
kind: Deployment
namespace：test
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: my-container
        image: nginx:1.14
        ports:
        - containerPort: 80

升级步骤

执行升级命令

将镜像更新为新版本，例如 nginx:1.16：

kubectl -n test set image deployment/my-deployment my-container=nginx:1.16 --record

监控滚动更新

使用以下命令查看更新进度：

kubectl -n test rollout status deployment/my-deployment

同时，通过 kubectl -n test get pods 查看新旧 Pod 状态。

回退步骤

假设升级后出现异常，决定回退：

执行回退命令

将 Deployment 恢复到上一个版本：

kubectl -n test rollout undo deployment/my-deployment

验证回退结果

再次使用 kubectl -n test rollout status 和 kubectl -n test describe deployment my-deployment 检查当前镜像是否已恢复为 nginx:1.14。

补充：最佳实践与注意事项

记录变更历史

使用 --record 参数可以方便追踪每次更新的命令。不过需要注意，部分文档中提到该参数将来可能会被废弃，因此在自动化流水线中可以考虑在更新后手动添加注解记录变更信息：

kubectl annotate deployment/my-deployment kubernetes.io/change-cause="更新镜像至 nginx:1.16"

使用滚动更新策略

默认情况下，Deployment 采用滚动更新策略（RollingUpdate），可以通过设置 maxSurge 和 maxUnavailable 参数来调整更新时的并发度与可用性。

例如：

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

这样可以保证在更新过程中，始终保持所有副本可用，避免服务中断。

版本标记与镜像管理

在生产环境中，建议不要使用 latest 标签。每次构建后应生成唯一的镜像标签（如基于构建号或 Git commit SHA），这样可以确保每次更新都能明确标识版本，并便于回退操作。

自动化 CI/CD 流水线

在 CI/CD 系统中，将镜像构建与 Kubernetes 部署流程自动化，将更新命令（如 kubectl set image 或直接应用更新后的 Deployment YAML）集成到流水线中，能大幅提升更新效率和稳定性。

结语

通过本文，你应该已经了解了如何利用 Kubernetes 的 Deployment 机制进行无停机的滚动更新，以及在出现问题时如何使用回退命令快速恢复稳定版本。无论是在手动操作还是自动化流水线中，掌握这些命令和最佳实践都能帮助你更好地管理集群中的应用版本，确保服务的高可用性和持续交付。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。