Kubernetes容器编排实战：多副本滚动更新与就绪探针配置详解

Docker自动化部署到Kubernetes的编排演进

从Docker自动化部署迁移到Kubernetes容器编排，核心变化是从单机容器管理升级为多节点集群调度。Kubernetes通过Deployment、Service、Ingress等资源对象，实现了应用的声明式部署、弹性伸缩和滚动更新。SRE稳定性工程实践中，Kubernetes的滚动更新机制是保障零停机发布的基石。

一个标准的Deployment配置包含镜像定义、副本数、更新策略和健康探针四个核心部分。其中探针配置的正确性直接决定了滚动更新是否真正实现零停机——配置不当的探针会导致流量被路由到未就绪的Pod，引发502错误。

Deployment滚动更新配置详解

Kubernetes Deployment的滚动更新策略通过maxUnavailable和maxSurge两个参数控制更新节奏。maxUnavailable定义更新过程中允许不可用的Pod最大数量，maxSurge定义允许超出期望副本数的Pod最大数量。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 2
  minReadySeconds: 30
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: registry.internal/web-app:v2.1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 512Mi

minReadySeconds是一个容易被忽略但非常关键的参数。它定义了Pod通过就绪检查后，必须持续就绪多长时间才被计入可用副本。设置30秒意味着即使探针通过，Kubernetes也会等待30秒，如果期间Pod再次变为NotReady，则不计入成功更新，触发回滚保护。

就绪探针与存活探针的正确配置

Kubernetes定义了三种探针：livenessProbe（存活探针）、readinessProbe（就绪探针）和startupProbe（启动探针）。三者用途不同，混淆配置是DevOps实践中最常见的线上事故原因之一。

就绪探针（readinessProbe）：控制Pod是否接收流量。探针失败时，Pod从Service的Endpoints中移除，但不会被重启。滚动更新中，新Pod必须通过就绪探针后才会接收流量，旧Pod才会被终止。

存活探针（livenessProbe）：控制Pod是否需要重启。探针失败时，kubelet杀死容器并按restartPolicy重启。存活探针不应检查外部依赖，否则依赖抖动会导致Pod无限重启。

启动探针（startupProbe）：用于启动缓慢的应用（如Java Spring Boot应用），在启动探针成功之前，存活探针和就绪探针不会执行。

containers:
- name: web
  image: registry.internal/web-app:v2.1.0
  startupProbe:
    httpGet:
      path: /health/startup
      port: 8080
    failureThreshold: 30
    periodSeconds: 10
  livenessProbe:
    httpGet:
      path: /health/live
      port: 8080
    initialDelaySeconds: 0
    periodSeconds: 10
    failureThreshold: 3
  readinessProbe:
    httpGet:
      path: /health/ready
      port: 8080
    initialDelaySeconds: 0
    periodSeconds: 5
    failureThreshold: 2
    successThreshold: 1

健康检查端点的设计需要区分职责。/health/live只检查进程存活状态，/health/ready检查应用是否真正可以处理请求（包括数据库连接、缓存连接等依赖项状态），/health/startup检查应用初始化是否完成。

CI/CD流水线集成与回滚操作

CI/CD流水线中，Kubernetes部署通常通过kubectl或Helm实现。以下是基于kubectl的滚动更新发布流程：

# 直接更新镜像
kubectl set image deployment/web-app web=registry.internal/web-app:v2.1.0

# apply完整YAML
kubectl apply -f deployment.yaml

# 监控滚动更新状态
kubectl rollout status deployment/web-app

# 查看更新历史
kubectl rollout history deployment/web-app

# 回滚到上一版本
kubectl rollout undo deployment/web-app

# 回滚到指定版本
kubectl rollout undo deployment/web-app --to-revision=2

生产环境推荐配置maxSurge=2、maxUnavailable=0的纯增量更新策略：先创建新Pod，完全就绪后才删除旧Pod。这种策略需要集群有足够的冗余资源，但确保了更新过程中始终有完整副本数在服务。

监控告警体系与故障应急响应

监控告警体系中，Kubernetes集群需要关注以下指标：

• Deployment available replicas：可用副本数低于期望值时立即告警
• Pod restart count：单个Pod重启次数超过3次触发告警
• Rollout stuck：滚动更新超过10分钟未完成触发告警
• CrashLoopBackOff：Pod持续崩溃重启的实时告警

故障应急响应中，快速定位Pod异常的关键命令组合：

# 查看Pod事件
kubectl describe pod <pod-name>

# 查看Pod日志
kubectl logs <pod-name> --previous

# 进入Pod排查
kubectl exec -it <pod-name> -- /bin/sh

# 查看节点资源压力
kubectl top nodes
kubectl top pods --all-namespaces | sort -k3 --reverse

混沌工程可以通过Chaos Mesh注入Pod故障，验证滚动更新和探针配置是否正确。例如注入网络延迟，观察就绪探针是否及时将Pod移出Endpoints，以及流量是否正确切换到健康Pod。

Kubernetes容器编排的稳定性不仅取决于集群本身的配置，更取决于应用对探针的配合。就绪探针的端点实现必须真实反映应用处理请求的能力，滚动更新参数必须根据应用启动时间和资源余量合理设置。两者配合到位，才能实现真正意义上的零停机发布。