Deployment Controller

Deployment Controller 是 Kubernetes 中最常用、最强大的控制器之一。它的核心作用是：在 ReplicaSet 的基础上，提供 声明式更新、滚动升级和版本回滚，让应用的生命周期管理更加稳定和可控。

🧩 Deployment Controller 的职责

  • 声明式更新
    👉 用户只需声明“我想要 5 个 Pod，运行 v2 版本镜像”，Deployment 会自动完成更新过程。
  • 滚动升级
    👉 在更新 Pod 时，Deployment 会逐步替换旧 Pod，保证服务不中断。
    类比：项目经理安排工人分批换班，而不是一次性全部替换。
  • 版本回滚
    👉 如果新版本出现问题，可以快速回滚到旧版本。
    类比：发现新工人不合格，立即召回老工人继续工作。
  • 副本管理
    👉 Deployment 内部通过 ReplicaSet 来维持 Pod 数量。每次更新都会创建新的 ReplicaSet。

📌 类比理解

  • Deployment = 高级项目经理
    • 它不仅监督工人数量（ReplicaSet 的工作），还负责安排工人换班（滚动升级）、保存历史版本（回滚）。
    • 让整个生产过程更平滑、更安全。

📝 示例配置

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

👉 这个 Deployment 会确保始终有 3 个 nginx Pod 在运行，并且在更新镜像时会逐步替换旧 Pod。

💡 总结

  • Deployment = ReplicaSet 的升级版，提供更高级的应用管理能力。
  • 它支持 声明式更新、滚动升级、版本回滚。
  • 在生产环境中，几乎所有应用都通过 Deployment 来管理。

Deployment 的滚动升级机制

Deployment 的滚动升级机制是 Kubernetes 中最重要的特性之一，它保证应用在升级过程中不会中断服务。

🧩 滚动升级的核心流程

  1. 创建新 ReplicaSet
    • 当你更新 Deployment（比如镜像版本），Deployment Controller 会创建一个新的 ReplicaSet。
    • 新 ReplicaSet 使用新的 Pod 模板。
  2. 逐步替换 Pod
    • Deployment 会按照配置的策略（如 maxUnavailable 和 maxSurge）逐步终止旧 Pod，并启动新 Pod。
    • 默认策略：一次替换少量 Pod，保证服务始终可用。
  3. 健康检查
    • 新 Pod 启动后，必须通过 Readiness Probe 才会被加入负载均衡。
    • 如果新 Pod 不健康，Deployment 会暂停升级，避免影响服务。
  4. 完成升级
    • 当所有旧 Pod 被替换为新 Pod，并且新 Pod 都处于 Ready 状态时，升级完成。

📌 类比理解

  • Deployment = 高级项目经理
    • 它安排工人（Pod）分批换班，而不是一次性全部替换。
    • 每批新工人上岗前，必须通过考核（健康检查）。
    • 如果新工人不合格，换班会暂停，避免生产线停工。

⚙️ 配置参数

  • maxUnavailable：升级过程中最多允许多少 Pod 不可用。
  • maxSurge：升级过程中最多允许额外启动多少 Pod。

👉 例如：

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

表示升级时最多有 1 个 Pod不可用，同时最多额外启动 1 个 Pod。

💡 总结

  • 滚动升级通过 新旧 ReplicaSet 的交替 来实现。
  • 关键是 逐步替换 + 健康检查，保证服务不中断。
  • 可通过 maxUnavailable 和 maxSurge 调整升级速度与可用性。

Deployment 的回滚机制

Deployment 的回滚机制是 Kubernetes 提供的另一项关键能力，它保证在升级失败或出现问题时，可以快速恢复到之前的稳定版本。

🧩 回滚机制的核心流程

  1. 版本记录

    • 每次 Deployment 更新时，都会创建一个新的 ReplicaSet。
    • 旧的 ReplicaSet 不会被删除，而是保留作为历史版本。

  2. 触发回滚

    • 如果新版本 Pod 出现问题（例如健康检查失败、应用崩溃），用户可以执行：

      kubectl rollout undo deployment <deployment-name>

    • 这会让 Deployment Controller 停止使用当前 ReplicaSet，重新启用之前的 ReplicaSet。

  3. 恢复旧版本

    • Deployment 会逐步替换新 Pod，重新启动旧版本 Pod。
    • 回滚过程和滚动升级类似，也是分批替换，保证服务不中断。

  4. 版本历史管理

    • Deployment 默认会保留多个历史版本（可通过 revisionHistoryLimit 配置）。
    • 用户可以选择回滚到最近一次更新，或指定某个历史版本。

📌 类比理解

  • Deployment = 高级项目经理
    • 每次换班（升级）都会保存一份记录。
    • 如果新工人（新版本 Pod）不合格，可以立刻召回老工人（旧 ReplicaSet）。
    • 项目经理不仅能安排换班，还能快速恢复到之前的稳定状态。

⚙️ 配置示例

spec:
  revisionHistoryLimit: 5

👉 表示最多保留 5 个历史版本，可以在需要时回滚。

💡 总结

  • 回滚机制依赖 ReplicaSet 的版本记录。
  • 用户可以快速恢复到旧版本，避免服务长时间不可用。
  • 与滚动升级结合，Deployment 提供了完整的 升级 + 回滚 生命周期管理。
posted @ 2026-05-28 11:14  Donaver  阅读(28)  评论(0)    收藏  举报