Deployment 与 ReplicaSet

Deployment 是你日常最常用的控制器，它会创建并管理 ReplicaSet，确保副本数和版本更新都可控。Deployment 提供声明式更新、回滚历史和可预测的扩缩容，适合无状态服务。

本节在基础概念上补充滚动更新策略、探针配置、扩缩容与排错思路。

关键点

ReplicaSet 负责“副本数量”。
Deployment 负责“版本更新”和回滚。
合理的滚动更新参数可以实现零停机。

示例 Deployment

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

标签与选择器

Deployment 的 selector 必须与 Pod 模板 label 一致，否则控制器无法接管 Pod。创建后不要随意修改 selector。

元信息与审计

建议在 Deployment 添加 owner、team、ticket 等注解，方便追踪变更来源与责任归属。在事故排查或回滚时，这些元信息能显著减少沟通成本。

声明式更新

Deployment 的核心是声明式：修改期望状态，控制器自动收敛。不要把手动删 Pod 当作发布方式，应更新 Deployment spec。

发布与回滚

kubectl rollout status deploy/api
kubectl rollout history deploy/api
kubectl rollout undo deploy/api

也可以暂停与恢复发布：

kubectl rollout pause deploy/api
kubectl rollout resume deploy/api

查看指定版本变更：

kubectl rollout history deploy/api --revision=2

触发更新

临时测试可用命令更新镜像：

kubectl set image deploy/api api=nginx:1.26
kubectl rollout status deploy/api

生产环境建议通过清单或 GitOps 变更，以便审计和回滚。

扩缩容

手动扩容：

kubectl scale deploy/api --replicas=5
kubectl get deploy api

自动扩缩容由 HPA 处理，但必须先设置 CPU requests。

HPA 基础

kubectl autoscale deploy/api --min=2 --max=6 --cpu-percent=60

确保已安装 metrics-server，否则 HPA 无法读取指标。

就绪与存活探针

探针可以避免错误实例接流量，并帮助自动恢复：

livenessProbe:
  httpGet:
    path: /healthz
    port: 80
  initialDelaySeconds: 10
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5

优雅关闭

需要平滑下线时，可设置 preStop 与 terminationGracePeriodSeconds：

terminationGracePeriodSeconds: 30
containers:
- name: api
  lifecycle:
    preStop:
      exec:
        command: ["sh", "-c", "sleep 10"]

滚动更新参数

maxSurge 控制更新过程中额外创建的 Pod 数量，maxUnavailable 控制允许不可用的副本数。对关键接口，建议设置 maxUnavailable: 0。

minReadySeconds 与进度超时

minReadySeconds: 10
progressDeadlineSeconds: 600

minReadySeconds 保证 Pod 稳定就绪一段时间；progressDeadlineSeconds 限制发布超时。

资源请求与限制

建议设置 requests/limits：

resources:
  requests:
    cpu: "200m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

否则调度与 HPA 难以准确评估。

PodDisruptionBudget

关键服务可以加 PDB：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api

查看 ReplicaSet

Deployment 每次更新都会创建新的 ReplicaSet：

kubectl get rs
kubectl describe rs <replicaset>

旧 ReplicaSet 会保留，除非设置 revisionHistoryLimit。

回滚历史数量

revisionHistoryLimit: 5

Pod 模板哈希

每个 ReplicaSet 都会带有 pod-template-hash 标签，用于区分不同版本。排查混合版本流量时，这个标签非常有用。

镜像标签与发布

生产环境避免 latest，用版本化 tag 保证可追溯。复用 tag 时要设置 imagePullPolicy: Always 或强制滚动。

灰度与蓝绿

灰度：新版本单独部署少量副本，并分流流量。
蓝绿：新旧版本并行，切换 Service selector 即可回退。

状态条件观察

发布卡住时可以查看 Deployment 条件：

kubectl get deploy api -o jsonpath='{.status.conditions}'

结合事件与探针日志通常能快速定位问题。

发布前检查清单

探针配置正确，避免误杀。
资源 requests 满足节点容量。
回滚路径明确且可操作。
日志与指标可见，便于定位问题。

常见问题

Pod 没更新：镜像标签未变或拉取策略不一致。
发布卡住：readiness 探针失败或更新参数过于严格。
频繁重启：liveness 探针过于激进。
镜像拉取失败：检查仓库权限与镜像名称。

Service 兼容性

Service selector 必须与 Deployment label 一致，否则 Pod 运行正常但没有流量。

排查流程

kubectl describe deploy api
kubectl describe pod <pod-name>
kubectl logs <pod-name>

实操要点

先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

资源定义与业务意图一致。
Namespace、权限、镜像与环境匹配。
上线前具备健康探针与可观测日志。
滚动更新策略符合业务流量特征。

实战补充

把快速入门应用到真实业务时，建议固定一套检查项：资源 requests、就绪探针、日志覆盖、告警阈值、回滚步骤。清单要短小、可重复，并随仓库一起维护，这样每次发布都能快速对齐标准。

排障路径

从现象入手，不要先猜原因。先看事件，再看日志，最后验证流量路径和配置版本是否一致。若访问异常，先确认 readiness 和 endpoints，再逐段排查入口到后端的链路。记录每一步改动，方便回滚和复盘。

小练习

在测试环境做几次常见操作：扩缩容、重启单个 Pod、调整一项配置并验证效果。通过这些小练习，你能更直观地感受到系统收敛速度和异常时的行为。

维护与责任

明确服务归属、值班人和升级窗口，准备常见故障的处理步骤。依赖服务也需要纳入监控和备份计划，确保问题出现时能快速定位和恢复。

交付提醒

发布后用用户视角快速验证一次：访问核心接口、观察延迟和错误率，确认新旧 Pod 的状态稳定。如果涉及存储或网络，顺手核对磁盘用量、DNS 和 endpoints 是否正常。

回滚预案

写下最小可行的回滚步骤，包括需要恢复的配置、镜像版本和校验方式。这样在出现异常时可以迅速还原，而不是现场临时拼步骤。