2. Kubernetes Deployment 基础：资源定义、ReplicaSet、滚动更新与回滚机制

Deployment 是 Kubernetes 中用于声明式管理 Pod 和 ReplicaSet 的核心工作负载资源。它提供了无状态应用的完整生命周期管理能力，包括期望状态维持、滚动更新、版本回滚以及扩缩容。理解 Deployment 的底层机制是进行故障注入与 IDP 隔离验证设计的前提。

2.1 Deployment 资源定义结构

一个标准的 Deployment YAML 清单包含四个主要部分：apiVersion、kind、metadata 和 spec。其中 spec 内部又细分为 replicas、selector、template 和 strategy。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

2.2 ReplicaSet：Deployment 的编排引擎

Deployment 并不直接管理 Pod，而是通过管理 ReplicaSet 来实现对 Pod 的编排。每个 Deployment 版本对应一个 ReplicaSet，ReplicaSet 负责维持指定数量的 Pod 副本。

2.3 滚动更新机制

滚动更新是 Deployment 的默认更新策略，它通过逐步替换旧版本 Pod 为新版本 Pod 来实现零停机发布。更新过程由两个关键参数控制：maxUnavailable 和 maxSurge。

2.3.1 滚动更新参数

2.3.2 滚动更新流程

1. 创建新 ReplicaSet：Deployment 控制器检测到 Pod 模板变更，创建新版本的 ReplicaSet。
2. 扩容新 RS：根据 maxSurge 参数，新 RS 开始创建新版本 Pod。
3. 缩容旧 RS：新 Pod 进入 Ready 状态后，旧 RS 开始销毁旧版本 Pod。
4. 迭代直至完成：重复步骤 2-3，直到所有旧 Pod 被替换，新 RS 达到期望副本数。

2.4 回滚机制

Deployment 的版本管理基于 ReplicaSet 的历史快照。每次更新都会创建一个新的 ReplicaSet，旧的 ReplicaSet 会被保留（默认保留 10 个版本）。回滚操作本质上是将 Deployment 的 Pod 模板恢复到某个历史版本，触发一次新的滚动更新。

2.4.1 回滚触发条件

• 手动回滚：使用 kubectl rollout undo deployment/<name> 命令。
• 自动回滚：结合 progressDeadlineSeconds 参数，当更新在指定时间内未完成时，可触发自动回滚（需配合 CI/CD 策略）。
• 故障注入触发：在混沌工程实验中，通过注入 Pod 故障导致更新失败，验证回滚机制的可靠性。

2.4.2 回滚流程

2.5 故障注入视角的关键配置

在混沌工程和 IDP 隔离验证设计中，以下 Deployment 配置直接影响故障注入实验的设计和结果分析：