当前位置：首页 > news >正文

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

news 2026/4/25 1:15:16

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 保持原版本