📚 课程目录第2章 Kubernetes Deployment基础回顾

Kubernetes Deployment 基础回顾：Deployment 的定义、ReplicaSet 与 Pod 的关系、滚动更新与回滚机制

在深入日志平台版本漂移自动校准设计之前，必须牢固掌握 Deployment 的核心工作原理。Deployment 是 Kubernetes 中用于声明式管理 Pod 和 ReplicaSet 的顶层资源对象，它定义了应用的期望状态，并由控制器循环（Control Loop）持续驱动实际状态向期望状态收敛。

2.1 Deployment 的定义与声明式 API

Deployment 通过 YAML 或 JSON 清单文件描述应用的运行期望，包括容器镜像版本、副本数量、更新策略、资源限制等。以下是一个典型的 Deployment 定义示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: log-collector
  labels:
    app: log-collector
    version: v2.1.0
spec:
  replicas: 3
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
        version: v2.1.0
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd:v1.16-debian-1
        ports:
        - containerPort: 24224
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

  关键字段说明：
  spec.replicas：期望运行的 Pod 副本数量。
spec.selector：标签选择器，用于关联 Deployment 管理的 Pod。
spec.template：Pod 模板，定义了 Pod 的容器、挂载卷、标签等。
spec.strategy：更新策略，决定如何替换旧版本 Pod。

2.2 ReplicaSet 与 Pod 的关系

Deployment 并不直接管理 Pod，而是通过 ReplicaSet 实现间接控制。ReplicaSet 负责确保指定数量的 Pod 副本始终运行，并在 Pod 因故障、节点宕机或资源抢占而终止时自动重建。

三者之间的层级关系如下：

版本漂移的关键点：当 Deployment 的 spec.template 发生变化（例如镜像标签被外部修改），Kubernetes 会创建一个新的 ReplicaSet，并逐步将流量从旧 ReplicaSet 迁移到新 ReplicaSet。如果外部工具绕过 Deployment 直接修改 Pod 或 ReplicaSet，就会产生版本漂移。

2.3 滚动更新与回滚机制

滚动更新（RollingUpdate）是 Deployment 默认的更新策略，它通过逐步替换旧版本 Pod 来实现零停机发布。回滚机制则允许在更新出现问题时快速恢复到上一个稳定版本。

滚动更新流程

步骤	操作	状态变化
1	修改 Deployment 镜像版本	创建新 ReplicaSet，副本数从 0 开始
2	启动新 Pod	新 Pod 通过 Readiness Probe 检查后进入就绪状态
3	缩容旧 ReplicaSet	旧 Pod 被优雅终止，流量切换到新 Pod
4	重复步骤 2-3	直到所有旧 Pod 被替换，旧 ReplicaSet 副本数归零

滚动更新过程中，maxUnavailable 和 maxSurge 两个参数控制更新速率：

maxUnavailable：更新过程中允许不可用的最大 Pod 数量（值或百分比），默认 25%。
maxSurge：更新过程中允许超出期望副本数的最大 Pod 数量（值或百分比），默认 25%。

回滚机制

Deployment 会保留历史版本的 ReplicaSet 记录，默认保留 10 个版本。当更新导致应用异常时，可以通过 kubectl rollout undo 命令快速回滚到上一个版本或指定版本。

# 回滚到上一个版本
kubectl rollout undo deployment/log-collector

# 回滚到指定版本
kubectl rollout undo deployment/log-collector --to-revision=3

# 查看版本历史
kubectl rollout history deployment/log-collector

版本漂移风险：回滚操作依赖 ReplicaSet 的历史记录。如果外部工具或手动操作删除了历史 ReplicaSet，或者直接修改了当前 ReplicaSet 的 Pod 模板，回滚机制将无法正常工作，导致版本状态不可控。这正是本课程需要解决的核心问题。

滚动更新与回滚状态机

  核心结论：Deployment 的声明式特性、ReplicaSet 的版本隔离能力以及滚动更新/回滚机制，共同构成了 Kubernetes 应用生命周期管理的基础。然而，这些机制依赖控制器循环的正常运行和 ReplicaSet 历史记录的完整性。日志平台版本漂移自动校准方案正是要弥补这些机制在复杂生产环境中的不足，确保日志采集组件的版本始终与预期一致。