Kubernetes高可用架构：Deployment与StatefulSet实战指南

1. Kubernetes 高可用实战：Deployment 与 StatefulSet 深度解析

在云原生技术栈中，Kubernetes 已经成为容器编排的事实标准。经过前八篇系列文章的铺垫，我们已经掌握了 Pod 部署、Service 服务发现、Ingress 路由管理等基础能力。但在生产环境中，应用的高可用性才是真正考验技术深度的关键指标。本文将聚焦两个核心控制器：Deployment 和 StatefulSet，通过实战演示如何构建真正具备生产级可靠性的应用架构。

提示：本文所有 YAML 配置和命令都经过生产环境验证，可以直接复制使用。建议在测试集群中跟随操作，加深理解。

1.1 为什么需要高可用架构

现代互联网服务的 SLA（服务等级协议）通常要求达到 99.9% 甚至更高的可用性。这意味着全年不可用时间不能超过 8.76 小时（99.9% 可用性）。要实现这样的目标，单点部署显然无法满足需求。Kubernetes 通过控制器模式，为我们提供了构建高可用应用的基础设施：

• 自愈能力：当节点或 Pod 故障时自动重建
• 弹性伸缩：根据负载动态调整实例数量
• 滚动更新：实现零停机部署
• 状态保持：对有状态应用提供稳定的网络标识和存储

2. 无状态应用高可用：Deployment 进阶实战

2.1 Deployment 核心机制解析

Deployment 本质上是一个声明式的更新控制器，它通过 ReplicaSet 来管理 Pod 的生命周期。理解下图所示的控制循环对排查问题非常有帮助：

code复制用户更新 Deployment → 创建新 ReplicaSet → 逐步扩容新 RS → 逐步缩容旧 RS → 完成滚动更新

2.1.1 健康检查机制

生产环境中必须配置的两种探针：

1. 存活探针（Liveness Probe）

   • 检测容器是否"活着"
   • 失败时会重启容器
   • 适用于检测死锁等不可恢复状态

2. 就绪探针（Readiness Probe）

   • 检测容器是否"就绪"
   • 失败时会从 Service 的 Endpoints 中移除
   • 适用于启动依赖或临时过载场景

yaml复制livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15  # 容器启动后等待时间
  periodSeconds: 10       # 检查间隔
  timeoutSeconds: 1       # 超时时间
  failureThreshold: 3     # 连续失败次数

readinessProbe:
  exec:
    command:
    - sh
    - -c
    - "curl -s localhost:8080/ready | grep OK"
  initialDelaySeconds: 5
  periodSeconds: 5

2.2 滚动更新策略详解

Deployment 的更新策略（spec.strategy）有两种：

1. RollingUpdate（默认）

   • 渐进式更新，保证服务不中断
   • 可配置 maxSurge 和 maxUnavailable

2. Recreate

   • 先删除所有旧 Pod，再创建新 Pod
   • 会导致短暂服务中断
   • 适用于必须全量更新的场景

yaml复制strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%        # 可以超过期望副本数的比例
    maxUnavailable: 25%  # 更新期间允许不可用的比