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

Kubernetes Deployment 基础：ReplicaSet、Pod 模板、更新策略

Deployment 是 Kubernetes 中用于声明式管理 Pod 和 ReplicaSet 的核心资源对象。理解其底层组件与更新策略，是掌握滚动更新与证书轮换协同方案的前提。本节将深入剖析 Deployment 的三层结构：ReplicaSet、Pod 模板与更新策略。

1. Deployment 的三层架构

Deployment 并不直接管理 Pod，而是通过 ReplicaSet 间接控制 Pod 的副本数量与版本。这种分层设计实现了版本控制与回滚能力。

2. ReplicaSet：版本控制的基石

ReplicaSet 负责确保指定数量的 Pod 副本始终运行。每次 Deployment 更新（如镜像版本变更）都会创建一个新的 ReplicaSet，旧的 ReplicaSet 则被保留（默认保留 10 个版本）。

属性	说明	典型值
replicas	期望运行的 Pod 副本数	3、5、10
selector	标签选择器，用于匹配所管理的 Pod	matchLabels: { app: nginx, version: v1 }
template	Pod 模板，定义 Pod 的容器、卷、环境变量等	包含 image、ports、env 等字段
revisionHistoryLimit	保留的历史 ReplicaSet 数量	10（默认）

关键认知：ReplicaSet 的 selector 一旦创建不可修改。因此 Deployment 每次更新都会生成新的 ReplicaSet，而不是修改旧的。这是实现版本隔离和回滚的基础。

3. Pod 模板：定义运行时的蓝图

Pod 模板是 Deployment 中定义 Pod 规格的核心部分，位于 .spec.template 字段下。模板中的任何变更（如镜像标签、环境变量、挂载卷）都会触发 Deployment 的更新流程。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:                    # <-- Pod 模板开始
    metadata:
      labels:
        app: webapp
        version: "1.0.0"
    spec:
      containers:
      - name: app
        image: myapp:1.0.0
        ports:
        - containerPort: 8080
        env:
        - name: CERT_PATH
          value: "/etc/certs"
        volumeMounts:
        - name: tls-certs
          mountPath: "/etc/certs"
          readOnly: true
      volumes:
      - name: tls-certs
        secret:
          secretName: app-tls-20240101

  证书轮换场景提示：当证书 Secret 更新时，Pod 模板中的 secretName 或 mountPath 通常不变。但若证书格式或路径发生变化，则必须通过修改 Pod 模板来触发滚动更新，使新 Pod 挂载新证书。

4. 更新策略：Recreate vs RollingUpdate

Deployment 支持两种更新策略，通过 .spec.strategy.type 指定。选择哪种策略直接影响服务的可用性和证书轮换的平滑度。

策略	行为描述	适用场景	对证书轮换的影响
Recreate	先删除所有旧 Pod，再创建新 Pod	开发环境、允许短暂停服的应用	证书切换期间服务完全不可用，适合非关键证书更新
RollingUpdate	逐步替换旧 Pod，保持一定数量的 Pod 可用	生产环境、要求零停机的高可用服务	证书逐步生效，新旧 Pod 可能同时存在，需确保新旧证书均有效

4.1 RollingUpdate 参数详解

RollingUpdate 策略通过两个关键参数控制更新速率与可用性边界：

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

4.2 策略对比与选择建议

对比维度	Recreate	RollingUpdate
服务中断时间	全部中断，直到新 Pod 就绪	无中断（若 maxUnavailable=0）
资源消耗峰值	低（仅运行新副本）	较高（新旧副本共存，受 maxSurge 控制）
更新速度	快（一次性替换）	慢（逐步替换，受 readinessProbe 影响）
证书轮换兼容性	新旧证书不共存，需确保新证书立即生效	新旧证书可能同时存在，需设计双证书信任链
回滚复杂度	低（直接切换 ReplicaSet）	低（kubectl rollout undo）

证书轮换关键约束：若使用 RollingUpdate 策略进行证书轮换，必须确保旧 Pod 持有的旧证书与新 Pod 持有的新证书在过渡期内均能被客户端信任。建议采用“双证书签发”或“信任锚点合并”策略，避免新旧 Pod 之间的 TLS 握手失败。

5. 更新策略与版本协同的实践要点

版本标签规范化：Pod 模板中的 version 标签应与镜像标签、证书版本号保持一致，便于 ReplicaSet 的 selector 精确匹配。
readinessProbe 配置：滚动更新依赖 Pod 的就绪探针判断新 Pod 是否可用。证书轮换场景下，探针应验证证书加载是否成功。
revisionHistoryLimit 调整：证书轮换频繁时，建议增大历史版本保留数（如 20），确保有足够的回滚点。
更新暂停与恢复：使用 kubectl rollout pause 暂停更新，验证新 Pod 的证书状态后再恢复，降低风险。

  生产建议：对于证书轮换作业，推荐使用 RollingUpdate 策略，并设置 maxUnavailable: 0、maxSurge: 1，确保每次只替换一个 Pod，最小化影响面。同时配合 preStop 钩子优雅关闭旧连接。