---
tags: [k8s, deployment, replicaset, devops]
create time: 2026-07-07 15:48
---

# Deployment 与 ReplicaSet

## 概述

Deployment 是 Kubernetes 中最常用的无状态工作负载控制器，它在 ReplicaSet 之上提供了声明式更新、滚动发布、版本回滚等高级能力。日常开发中，绝大多数无状态服务（Web API、微服务后端、定时任务 Worker）都通过 Deployment 来管理 Pod 的生命周期。理解 Deployment 与 ReplicaSet 的协作关系，是掌握 Kubernetes 应用交付模型的基础。

## ReplicaSet 详解

### 什么是 ReplicaSet

ReplicaSet（简称 RS）的核心职责只有一件事：**确保指定数量的 Pod 副本始终处于运行状态**。如果某个 Pod 意外退出或被删除，RS 会立即创建新的 Pod 来弥补差额；如果 Pod 数量超过期望值，RS 会删除多余的 Pod。

```yaml
# 一个独立的 ReplicaSet 示例（通常不直接创建，由 Deployment 自动管理）
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-rs
  namespace: default
spec:
  replicas: 3                    # 期望副本数
  selector:
    matchLabels:
      app: nginx                 # Label Selector：通过标签匹配 Pod
  template:
    metadata:
      labels:
        app: nginx               # Pod 必须携带此标签才能被 RS 管理
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
```

### Label Selector 机制

RS 通过 **Label Selector** 来发现和管理 Pod，而非维护一个固定的 Pod 列表。这意味着：

- 手动创建的 Pod 只要标签匹配，也会被 RS 纳入管理（数量超出则删除，不足则新建）
- 修改某个 Pod 的标签可以将其从 RS 管理中"摘除"，这在调试时非常有用

```bash
# 将一个 Pod 从 RS 中移除（不删除 Pod，仅修改标签使其脱离管理）
kubectl label pod nginx-rs-xxxx app=detached --overwrite

# 此时 RS 会发现少了一个副本，自动新建一个 Pod 来补足
```

> [!tip] 调试技巧
> 需要排查某个 Pod 问题时，先把它从 RS 中"摘出来"（修改标签），这样 RS 不会因为 Pod 异常而自动重建，你可以从容排查。

### ReplicaSet vs ReplicationController

ReplicationController（RC）是 RS 的前身，两者核心区别在于 Selector 语义：

| 对比维度 | ReplicationController | ReplicaSet |
|----------|----------------------|------------|
| Selector 类型 | 仅支持等式（`env=prod`） | 支持等式 + 集合（`env in (prod, staging)`） |
| 标签匹配灵活性 | 低 | 高 |
| 推荐程度 | 已废弃，不建议使用 | 推荐使用 |
| 滚动更新 | 需要 `kubectl rolling-update`（客户端执行） | 由 Deployment 在服务端协调 |

RC 已经是遗留概念，新资源应统一使用 ReplicaSet。不过实践中你几乎不会直接创建 RS，而是通过 Deployment 间接管理。

## Deployment 核心机制

### 声明式管理

Deployment 采用声明式模型：你只需描述"期望状态"（desired state），Kubernetes 控制面会持续将其与"实际状态"（actual state）做对比，自动执行必要的操作来弥合差距。这个循环叫做 **Reconcile Loop**（调谐循环）。

```mermaid
graph LR
    A["用户提交 Deployment<br/>(desired state)"] --> B["Deployment Controller"]
    B --> C{"desired == actual ?"}
    C -->|No| D["创建/删除/更新<br/>ReplicaSet / Pod"]
    D --> B
    C -->|Yes| E["状态稳定<br/>不做任何操作"]
```

工作流程：

1. 用户通过 `kubectl apply` 提交 Deployment YAML，声明 `replicas: 3`、`image: nginx:1.25` 等期望状态
2. Deployment Controller 观察到当前没有匹配的 RS，创建一个新的 RS
3. RS Controller 观察到 Pod 数量为 0，创建 3 个 Pod
4. 持续监控：如果某个 Pod 崩溃，RS Controller 检测到 actual < desired，立即补充新 Pod

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  namespace: default
spec:
  replicas: 3                  # 声明：我想要 3 个副本
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25       # 声明：我想用这个镜像
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi
```

### 滚动更新（Rolling Update）

滚动更新是 Deployment 最核心的价值。当你修改了 Pod 模板（比如升级镜像版本），Deployment 不会一次性杀掉所有旧 Pod，而是**逐批替换**，在更新过程中始终保持服务可用。

#### 关键参数

| 参数 | 默认值 | 含义 |
|------|--------|------|
| `maxSurge` | 25% | 更新过程中允许超出 `replicas` 的最大 Pod 数量 |
| `maxUnavailable` | 25% | 更新过程中允许不可用的最大 Pod 数量 |

> [!info] 参数计算
> 对于 `replicas: 4`、`maxSurge: 25%`、`maxUnavailable: 25%` 的配置：
> - maxSurge = ceil(4 * 0.25) = 1，最多可以有 5 个 Pod 同时存在
> - maxUnavailable = floor(4 * 0.25) = 1，至少保证 3 个 Pod 可用
>
> 这意味着每批替换 1 个 Pod，共需 4 批完成更新。

#### 滚动更新过程

```mermaid
sequenceDiagram
    participant U as 用户
    participant D as Deployment Controller
    participant RS1 as ReplicaSet v1
    participant RS2 as ReplicaSet v2

    U->>D: kubectl apply（image: nginx:1.26）
    D->>RS2: 创建新 RS（image: 1.26, replicas: 0）
    D->>RS2: scale up +1（新建 1 个新 Pod）
    Note over RS1,RS2: maxSurge=1, 新 Pod 启动
    D->>RS1: scale down -1（销毁 1 个旧 Pod）
    Note over RS1,RS2: maxUnavailable=1, 保证可用
    D->>RS2: scale up +1
    D->>RS1: scale down -1
    Note over RS1,RS2: 重复直到 RS1=0, RS2=4
    D->>RS1: 保留 RS1（revision=1, 可回滚）
```

逐批替换的过程（以 `replicas: 4` 为例）：

| 阶段 | RS v1 (旧) | RS v2 (新) | 总 Pod 数 | 可用 Pod |
|------|-----------|-----------|----------|---------|
| 初始 | 4 | 0 | 4 | 4 |
| 第 1 批 | 4 → 3 | 0 → 1 | 5 | 4 |
| 第 2 批 | 3 → 2 | 1 → 2 | 4 | 4 |
| 第 3 批 | 2 → 1 | 2 → 3 | 4 | 4 |
| 第 4 批 | 1 → 0 | 3 → 4 | 4 | 4 |

#### 滚动更新配置

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 4
  strategy:
    type: RollingUpdate           # 更新策略
    rollingUpdate:
      maxSurge: 1                 # 最多多 1 个 Pod
      maxUnavailable: 1           # 最多少 1 个 Pod
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        readinessProbe:            # 重要：就绪探针决定新 Pod 何时接收流量
          httpGet:
            path: /healthz
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
```

> [!warning] readinessProbe 的重要性
> 滚动更新依赖 `readinessProbe` 判断新 Pod 是否就绪。如果没有配置就绪探针，新 Pod 一创建就被视为 Ready，可能导致流量打到尚未初始化完成的 Pod 上，造成请求失败。

### 回滚策略

Kubernetes 为每次 Deployment 变更自动记录 revision（版本号），支持快速回滚到任意历史版本。

```bash
# 查看 rollout 历史
kubectl rollout history deployment nginx-deploy

# 输出示例：
# REVISION  CHANGE-CAUSE
# 1         <none>
# 2         <none>
# 3         <none>

# 查看某个 revision 的详细信息
kubectl rollout history deployment nginx-deploy --revision=2

# 回滚到上一个版本
kubectl rollout undo deployment nginx-deploy

# 回滚到指定版本
kubectl rollout undo deployment nginx-deploy --to-revision=1

# 查看 rollout 状态（是否完成、耗时等）
kubectl rollout status deployment nginx-deploy
```

#### revisionHistoryLimit 配置

默认保留 10 个历史 revision。过多的历史 RS 会占用 etcd 资源，过少则可能丢失回滚能力。

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  revisionHistoryLimit: 5        # 只保留最近 5 个 revision
  # 设为 0 则禁用回滚（不推荐）
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        kubernetes.io/change-cause: "升级到 nginx 1.26"  # 记录变更原因，显示在 rollout history 中
    spec:
      containers:
      - name: nginx
        image: nginx:1.26
```

> [!tip] 记录变更原因
> 在 Pod template 的 `annotations` 中添加 `kubernetes.io/change-cause`，这样 `kubectl rollout history` 会显示每次变更的原因，方便排查。

### 扩缩容

#### 手动扩缩容

```bash
# 命令行直接扩缩
kubectl scale deployment nginx-deploy --replicas=5

# 条件扩缩（只有当前副本数为 3 时才执行）
kubectl scale deployment nginx-deploy --replicas=5 --current-replicas=3
```

也可以直接修改 YAML 中的 `replicas` 字段后 `kubectl apply`。

#### HPA 自动扩缩

Horizontal Pod Autoscaler（HPA）根据 CPU、内存或自定义指标自动调整 Deployment 的副本数。

```yaml
# 前置条件：集群中需要安装 Metrics Server
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deploy               # 目标 Deployment
  minReplicas: 2                      # 最小副本数
  maxReplicas: 10                     # 最大副本数
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60        # CPU 使用率超过 60% 时扩容
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80        # 内存使用率超过 80% 时扩容
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60  # 扩容稳定窗口：60s 内取最大值
      policies:
      - type: Pods
        value: 4                      # 每次最多扩 4 个 Pod
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300 # 缩容稳定窗口：300s，防止抖动
      policies:
      - type: Percent
        value: 10                     # 每次最多缩 10%
        periodSeconds: 60
```

```bash
# 创建 HPA
kubectl apply -f hpa.yaml

# 或用命令行快速创建
kubectl autoscale deployment nginx-deploy --cpu-percent=60 --min=2 --max=10

# 查看 HPA 状态
kubectl get hpa nginx-hpa
```

> [!warning] HPA 与手动 scale 冲突
> 如果同时使用 HPA 和手动 `kubectl scale`，HPA 会在下一次指标采集时覆盖手动设置。两者不应混用。

## Deployment 更新策略

Deployment 支持两种更新策略，通过 `spec.strategy.type` 指定：

| 对比维度 | RollingUpdate | Recreate |
|----------|--------------|----------|
| 更新方式 | 逐批替换 Pod | 先杀全部旧 Pod，再创建全部新 Pod |
| 更新期间可用性 | 始终可用（前提：正确配置探针） | 有短暂不可用窗口 |
| 资源占用 | 可能临时需要更多资源（maxSurge > 0 时） | 只需要新版本的资源 |
| 适用场景 | 大多数无状态服务 | 不能有两个版本同时运行的场景 |
| 典型用例 | Web 服务、API 后端 | 涉及全局独占资源（如本地文件锁、全局数据库迁移） |

```yaml
# Recreate 策略示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: legacy-app
spec:
  replicas: 3
  strategy:
    type: Recreate                # 全量替换，更新期间服务不可用
  selector:
    matchLabels:
      app: legacy
  template:
    metadata:
      labels:
        app: legacy
    spec:
      containers:
      - name: app
        image: legacy-app:2.0
```

> [!info] 什么时候用 Recreate？
> 当新旧版本不能共存时使用 Recreate，比如：应用使用了本地文件锁、需要执行不可逆的数据库 Schema 迁移、或者旧版本会干扰新版本的初始化。大多数情况下 RollingUpdate 是更好的选择。

## 金丝雀发布与蓝绿部署

Deployment 本身不直接支持金丝雀发布和蓝绿部署，但可以通过组合多个 Deployment + Service 来实现。

### 金丝雀发布（Canary Release）

核心思路：同时运行两个版本的 Deployment，通过控制副本比例来控制流量分配。

```yaml
# 主 Deployment：稳定版本，占 90% 流量
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-stable
spec:
  replicas: 9                      # 9 个副本
  selector:
    matchLabels:
      app: myapp
      track: stable
  template:
    metadata:
      labels:
        app: myapp
        track: stable              # 核心标签 app: myapp 相同，Service 可以选中
    spec:
      containers:
      - name: app
        image: myapp:v1.0
---
# 金丝雀 Deployment：新版本，占 10% 流量
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-canary
spec:
  replicas: 1                      # 1 个副本
  selector:
    matchLabels:
      app: myapp
      track: canary
  template:
    metadata:
      labels:
        app: myapp
        track: canary
    spec:
      containers:
      - name: app
        image: myapp:v2.0
```

```yaml
# Service 通过 app: myapp 同时选中两个 Deployment 的 Pod
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  selector:
    app: myapp                     # 不指定 track，两个版本都会被选中
  ports:
  - port: 80
    targetPort: 8080
```

流量分配：9 个旧版本 Pod + 1 个新版本 Pod = 约 10% 流量到达新版本。验证无误后，逐步调整副本比例（如 `canary: 5, stable: 5`），最终全部切换到新版本。

```mermaid
graph LR
    Client --> Service
    Service -->|~90%| Pod1["Pod v1.0 x9"]
    Service -->|~10%| Pod2["Pod v2.0 x1"]
```

### 蓝绿部署（Blue-Green Deployment）

核心思路：同时运行蓝（当前版本）和绿（新版本）两套完整的 Deployment，通过切换 Service 的 selector 来瞬间完成流量切换。

```yaml
# 蓝色 Deployment（当前生产版本）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: app
        image: myapp:v1.0
---
# 绿色 Deployment（新版本，先部署但不接收流量）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: app
        image: myapp:v2.0
```

```yaml
# Service：切换 selector.version 即可瞬间切换流量
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  selector:
    app: myapp
    version: blue               # 当前指向蓝色，切换为 green 即完成上线
  ports:
  - port: 80
    targetPort: 8080
```

```bash
# 切换流量到绿色版本
kubectl patch service myapp-svc -p '{"spec":{"selector":{"version":"green"}}}'

# 回滚：切换回蓝色版本
kubectl patch service myapp-svc -p '{"spec":{"selector":{"version":"blue"}}}'
```

蓝绿部署的优点是切换瞬间完成（无中间状态），缺点是需要双倍资源。适合对上线/回滚速度要求极高的场景。

## Pod 模板字段详解

`spec.template.spec` 是 Pod 模板的核心，以下是常用字段的逐一说明：

```yaml
spec:
  template:
    metadata:
      labels:                    # Pod 标签，用于 Service Selector 和 ReplicaSet 匹配
        app: myapp
        version: v1
      annotations:               # 非标识性元数据，供工具或控制器使用
        kubernetes.io/change-cause: "初始部署"
    spec:
      # ---- 容器定义 ----
      containers:
      - name: app                # 容器名称，Pod 内唯一
        image: myapp:v1.0        # 镜像地址
        imagePullPolicy: IfNotPresent  # Always / IfNotPresent / Never
        ports:
        - containerPort: 8080    # 容器监听端口（声明性质，不强制）
        env:                     # 环境变量
        - name: APP_ENV
          value: "production"
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:        # 从 Secret 读取敏感信息
              name: db-secret
              key: password
        resources:               # 资源请求与限制
          requests:              # 调度依据：节点至少需要这么多资源
            cpu: 100m
            memory: 128Mi
          limits:                # 上限：超出会被 OOM Kill 或 CPU 限流
            cpu: 500m
            memory: 256Mi
        readinessProbe:          # 就绪探针：决定 Pod 是否接收流量
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:           # 存活探针：失败则重启容器
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20
        startupProbe:            # 启动探针：慢启动应用专用，通过前忽略 liveness
          httpGet:
            path: /healthz
            port: 8080
          failureThreshold: 30
          periodSeconds: 10

      # ---- 初始化容器 ----
      initContainers:            # 在主容器启动前顺序执行
      - name: init-db-migration
        image: myapp:v1.0
        command: ["./migrate.sh"]

      # ---- 卷挂载 ----
      volumes:
      - name: config-vol
        configMap:
          name: app-config       # 挂载 ConfigMap 作为文件
      - name: data-vol
        emptyDir: {}             # 临时卷，Pod 删除后数据丢失

      # ---- 调度相关 ----
      nodeSelector:              # 简单节点选择
        disk: ssd
      affinity:                  # 高级亲和性规则
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/os
                operator: In
                values: ["linux"]
      tolerations:               # 容忍污点
      - key: "dedicated"
        operator: "Equal"
        value: "gpu"
        effect: "NoSchedule"

      # ---- 其他 ----
      terminationGracePeriodSeconds: 30   # 优雅终止等待时间
      serviceAccountName: myapp-sa        # 使用的 ServiceAccount
```

> [!tip] imagePullPolicy 最佳实践
> - 使用 `:latest` 标签时，必须设置 `imagePullPolicy: Always`，否则可能使用本地缓存的旧镜像
> - 使用固定版本标签（如 `:v1.2.3`）时，`IfNotPresent` 更高效，避免重复拉取
> - `Never` 仅用于本地开发环境（如 minikube 中直接使用本地构建的镜像）

## 常见陷阱与最佳实践

### 更新卡住排查

滚动更新卡住是常见问题，通常由以下原因导致：

```bash
# 1. 查看 Deployment 状态
kubectl rollout status deployment nginx-deploy
# 可能输出：Waiting for rollout to finish: 2 out of 4 new replicas have been updated...

# 2. 查看 Deployment 的 Conditions
kubectl get deployment nginx-deploy -o yaml | grep -A 20 conditions:
# 常见条件：
# - Progressing: False（更新未推进）
# - Available: True/False（是否有足够可用 Pod）

# 3. 查看新 ReplicaSet 的事件
kubectl describe rs nginx-deploy-xxxxxx   # 查看新 RS 的 Events
# 常见原因：
# - FailedScheduling：资源不足，没有节点能满足 requests
# - ImagePullBackOff：镜像拉取失败（镜像名错、私有仓库无凭证）
# - CrashLoopBackOff：新容器启动后立即崩溃

# 4. 查看 Pod 事件
kubectl get pods -l app=nginx --sort-by=.metadata.creationTimestamp
kubectl describe pod nginx-deploy-xxxxxx-yyyyy
```

常见原因和解决方案：

| 症状 | 原因 | 解决方案 |
|------|------|---------|
| ImagePullBackOff | 镜像不存在或无权限 | 检查镜像名称、imagePullSecrets |
| CrashLoopBackOff | 应用启动失败 | 查看 Pod 日志 `kubectl logs` |
| Pending | 资源不足或节点不满足约束 | 检查 `kubectl describe pod` 中的 Events |
| readinessProbe 一直失败 | 健康检查路径或端口错误 | 确认探针配置与应用实际端口一致 |

> [!warning] 超时回滚
> Deployment 有一个 `progressDeadlineSeconds` 参数（默认 600 秒），如果更新在该时间内未完成，Deployment 会标记为 `Progressing=False`。注意：这**不会自动回滚**，只是标记状态。需要手动执行 `kubectl rollout undo` 或编写自动化脚本。

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  progressDeadlineSeconds: 300   # 5 分钟内未完成更新则标记失败
  minReadySeconds: 10            # Pod Ready 后等待 10 秒才视为 Available
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.26
```

### imagePullPolicy 导致的镜像缓存问题

```bash
# 场景：修改了 YAML 中的 image 字段但没改 tag，apply 后 Pod 没有更新
# 原因：imagePullPolicy 默认为 IfNotPresent，本地已有旧镜像就不会重新拉取

# 解决方案 1：始终使用不同的 tag（推荐）
image: myapp:v1.0.1   # 而不是 myapp:latest

# 解决方案 2：强制设置 imagePullPolicy
imagePullPolicy: Always

# 解决方案 3：使用 SHA256 digest（最精确）
image: myapp@sha256:abc123...
```

### Deployment vs StatefulSet 选择

| 特性 | Deployment | StatefulSet |
|------|-----------|-------------|
| Pod 名称 | 随机（`nginx-5d6b8f7c9-abc12`） | 有序（`web-0`, `web-1`, `web-2`） |
| Pod 启动顺序 | 并行 | 有序（0 → 1 → 2） |
| Pod 终止顺序 | 并行（默认） | 逆序（2 → 1 → 0） |
| 网络标识 | 不稳定 | 稳定（`web-0.ng-svc`） |
| 持久存储 | 共享或无 | 每个 Pod 独立 PVC |
| 适用场景 | 无状态服务 | 有状态服务（数据库、MQ、ZooKeeper） |
| 滚动更新 | 替换 Pod | 逐个更新 |

> [!info] 选择原则
> 如果你的应用满足以下任意条件，应考虑 StatefulSet：
> - 需要稳定的网络标识（如 ZooKeeper 集群节点互相发现）
> - 需要持久化的、与 Pod 绑定的存储（如 MySQL 数据目录）
> - 需要有序的部署/扩缩/更新
>
> 其余场景一律使用 Deployment。

### 其他最佳实践

1. **始终配置资源请求和限制**：没有 requests 的 Pod 会被调度器视为零消耗，可能导致多个 Pod 被调度到同一节点，引发资源争抢。

2. **始终配置 readinessProbe**：没有就绪探针，新 Pod 创建后立即被标记为 Ready，流量可能打到未初始化完成的 Pod。

3. **不要直接管理 Deployment 创建的 ReplicaSet**：RS 的生命周期由 Deployment 控制器管理，手动修改 RS（如 scale）会被 Deployment 覆盖。

4. **使用 `kubectl apply` 而非 `kubectl create`**：apply 支持声明式管理，可以幂等执行，适合 GitOps 工作流。

5. **合理设置 minReadySeconds**：该参数让 Pod Ready 后再等待一段时间才被视为 Available，可以用来检测"启动后很快崩溃"的场景。

```yaml
# 推荐的最小 Deployment 模板
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  revisionHistoryLimit: 5
  progressDeadlineSeconds: 300
  minReadySeconds: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0            # 保证更新期间始终有足够的可用 Pod
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      terminationGracePeriodSeconds: 30
      containers:
      - name: myapp
        image: myapp:v1.0.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20
```

## 延伸阅读

- [[k8s-03-pod]] — Pod 的生命周期、调度机制、资源管理
- [[k8s-05-service-and-networking]] — Service 类型、Ingress、网络策略
- [Kubernetes 官方文档 - Deployments](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/)
- [Kubernetes 官方文档 - ReplicaSet](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicaset/)
- [Kubernetes 官方文档 - HPA](https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)