Kubernetes StatefulSet 详解：有状态服务的部署与管理实战

一、开篇：有状态服务的部署痛点与 StatefulSet 定位

在 Kubernetes 生态中，无状态服务 （如 Nginx、API 网关）可通过 Deployment/ReplicaSet 轻松部署，但有状态服务（如数据库、缓存集群、分布式存储）面临三大核心痛点：

需固定网络标识（如数据库主从节点的域名）；
需持久化存储（数据不随 Pod 重建丢失）；
需有序部署 / 扩展 / 更新（如主节点先启动，从节点再同步数据）。

StatefulSet 正是为解决这些痛点而生 ------ 它是 Kubernetes 中专门用于管理有状态应用的控制器，前身为 Kubernetes 1.4 版本的 PetSet，在 1.5 版本更名为 StatefulSet，1.7 版本仍处于 Beta 阶段（需注意集群兼容性）。

本文将通过 核心特性解析 + 实操案例 + 对比 Deployment，帮你掌握：

StatefulSet 与 Deployment 的核心差异；
如何用 StatefulSet 部署有状态服务；
生产环境中的关键配置与最佳实践。

二、StatefulSet 核心特性与原理可视化

2.1 核心特性（有状态服务的四大保障）

稳定的网络标识 ：每个 Pod 拥有固定的 DNS 名称（格式：Pod名称.服务名称.命名空间.svc.cluster.local），即使 Pod 重建，标识也不变；
稳定的持久化存储 ：通过 volumeClaimTemplates 自动创建 PersistentVolume（PV），每个 Pod 绑定独立 PV，数据永久保存；
有序的部署 / 扩展 ：按 0→1→2...N-1 顺序创建 Pod，前一个 Pod 就绪后才启动下一个；扩展时遵循同样顺序；
有序的删除 / 更新 ：删除时按 N-1→2→1→0 反向顺序；更新时支持滚动更新（默认反向顺序）、金丝雀发布等策略。

2.2 架构依赖图

略

2.3 StatefulSet vs Deployment 核心差异表

对比维度	StatefulSet（有状态）	Deployment（无状态）	适用场景
网络标识	固定 DNS 名称 + 序号，持久化	随机名称 + IP，Pod 重建后变化	数据库、缓存集群
存储方案	每个 Pod 独立 PV（通过 volumeClaimTemplates）	共享存储或无持久化需求	分布式存储、数据服务
部署顺序	有序部署（0→N-1），依赖前驱 Pod 就绪	并行部署，无顺序依赖	主从架构、集群化应用
更新策略	支持滚动更新（反向顺序）、金丝雀发布（partition）	滚动更新、重建更新，无序号依赖	版本敏感的有状态服务
删除行为	反向顺序删除，PV 保留（数据安全）	随机删除，Pod 数据随 Pod 销毁	需数据持久化的场景
核心目标	保障数据与标识的稳定性	保障副本数与服务可用性	无状态 API、静态服务

三、实操案例：用 StatefulSet 部署 Nginx 有状态服务

案例需求

部署 3 个 Nginx 副本，要求：

每个副本拥有独立持久化存储（1Gi）；
固定网络标识（如 web-0.nginx.default.svc）；
有序部署、反向顺序删除；
支持滚动更新与金丝雀发布。

步骤 1：创建 Headless Service

复制代码

# headless-service.yaml

apiVersion: v1

kind: Service

metadata:

 name: nginx

 labels:

   app: nginx

spec:

 ports:

 - port: 80

   name: web

 clusterIP: None  # 关键：Headless Service 无集群 IP

 selector:

   app: nginx

kubectl apply -f headless-service.yaml

步骤 2：创建 StatefulSet 配置

复制代码

# statefulset-nginx.yaml

apiVersion: apps/v1beta1

kind: StatefulSet

metadata:

 name: web

spec:

 serviceName: "nginx"  # 关联上面创建的 Headless Service

 replicas: 3  # 3 个副本

 template:

   metadata:

     labels:

       app: nginx

   spec:

     terminationGracePeriodSeconds: 10  # 优雅终止时间（不建议设为 0）

     containers:

     - name: nginx

       image: gcr.io/google_containers/nginx-slim:0.8

       ports:

       - containerPort: 80

         name: web

       volumeMounts:

       - name: www  # 与 volumeClaimTemplates 名称一致

         mountPath: /usr/share/nginx/html

 # 持久化存储模板：自动为每个 Pod 创建 PVC

 volumeClaimTemplates:

 - metadata:

     name: www

   spec:

     accessModes: [ "ReadWriteOnce" ]  # 读写权限（仅单个节点挂载）

     storageClassName: "my-storage-class"  # 需提前创建 StorageClass

     resources:

       requests:

         storage: 1Gi

# 应用配置

kubectl apply -f statefulset-nginx.yaml

# 查看 StatefulSet 状态

kubectl get statefulset web

# 输出：NAME   READY   AGE

#       web    3/3     5m

# 查看 Pod（按序号命名）

kubectl get pods -l app=nginx

# 输出：web-0   Running   5m

#       web-1   Running   4m30s  （web-0 就绪后启动）

#       web-2   Running   4m     （web-1 就绪后启动）

# 查看自动创建的 PVC（每个 Pod 对应一个）

kubectl get pvc

# 输出：www-web-0   Bound   pvc-xxx   1Gi   RWO   my-storage-class   5m

#       www-web-1   Bound   pvc-yyy   1Gi   RWO   my-storage-class   4m30s

#       www-web-2   Bound   pvc-zzz   1Gi   RWO   my-storage-class   4m

步骤 3：验证核心特性

稳定网络标识：

进入 web-0 容器，解析 web-1 的 DNS

kubectl exec -it web-0 -- nslookup web-1.nginx

输出：Address 1: 10.244.1.10 web-1.nginx.default.svc.cluster.local

即使 web-1 重建，DNS 名称仍为 web-1.nginx，IP 自动更新。

有序删除：

缩容至 1 个副本（replicas=1）

kubectl scale statefulset web --replicas=1

观察删除顺序：先删除 web-2，再删除 web-1，保留 web-0

kubectl get pods -l app=nginx -w
滚动更新与金丝雀发布：

1. 配置滚动更新策略（默认反向顺序）

kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'

2. 更新镜像（触发滚动更新，从 web-2 开始，再 web-1，最后 web-0）

kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"nginx:1.21.6"}]'

3. 金丝雀发布（仅更新序号 >=2 的 Pod，即 web-2）

kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'

此时仅 web-2 升级为 1.21.6，web-0、web-1 保持原版本

四、StatefulSet 关键配置与生产实践

4.1 核心配置解析

Pod 管理策略（podManagementPolicy）：

OrderedReady（默认）：有序部署 / 更新，依赖前驱 Pod 就绪；
Parallel：并行部署 / 更新，无顺序依赖（适合无需主从同步的集群）。

更新策略（updateStrategy）：

OnDelete（默认）：手动删除 Pod 后才更新（兼容 1.6 及以前版本）；
RollingUpdate：自动滚动更新，按反向顺序（N-1→0）执行。

分区更新（partition）：

用于金丝雀发布或分阶段更新，仅更新序号 >= partition 的 Pod；
例：partition:2 时，仅 web-2 会被更新，web-0、web-1 保持不变。

4.2 生产环境限制与注意事项

存储依赖：必须提前创建 StorageClass 或预配置 PV，否则 PVC 会一直处于 Pending 状态；
数据安全：删除 / 缩容 StatefulSet 不会删除 PV，需手动清理无用 PV 避免存储浪费；
集群版本：1.5 版本以下不支持 StatefulSet，1.7 版本为 Beta 特性，生产环境建议使用 1.9+ 稳定版本；
终止时间 ：terminationGracePeriodSeconds 不建议设为 0，否则可能导致数据未同步完成就删除 Pod。

4.3 典型适用场景

数据库集群（MySQL 主从、PostgreSQL 集群）；
缓存服务（Redis 集群、Memcached 集群）；
分布式存储（GlusterFS、Ceph 集群）；
需固定标识的服务（如消息队列集群、服务注册中心）。

五、总结：有状态服务的部署核心原则

控制器选择：有状态服务优先用 StatefulSet，无状态服务用 Deployment，避免 "用无状态控制器部署有状态应用"；
核心依赖：StatefulSet 必须配合 Headless Service 和 PersistentVolume 使用，三者缺一不可；
更新策略 ：生产环境建议用 RollingUpdate + partition 实现灰度发布，降低版本更新风险；
数据安全：重视 PV 生命周期管理，删除 StatefulSet 后及时清理无用 PV，同时备份关键数据。

StatefulSet 作为 Kubernetes 有状态服务的核心解决方案，完美解决了网络标识、持久化存储、有序管理三大痛点。在实际工作中，需结合业务场景（如是否需要主从同步、数据是否持久化）选择合适的控制器，同时关注集群版本兼容性和存储配置的稳定性，才能确保有状态服务的高可用运行。

Kubernetes StatefulSet 详解：有状态服务的部署与管理实战