做过几年容器平台的人多半都经历过类似的场景明明在 Kubernetes 里跑得好好的无状态服务一换到数据库、消息队列、注册中心这类有状态应用就各种水土不服。Pod 重建后 IP 变了数据丢了集群节点互相找不到对方……这时候你再回头看 Deployment就会发现它天生只适合打死重来的活。而 StatefulSet就是 Kubernetes 为这一类身份不能丢、数据不能丢、启动顺序不能乱的工作负载专门设计出来的控制器。这篇东西不会给你抄一份 YAML 就完事。我会从 StatefulSet 为什么存在讲起把它的三大核心机制拆开揉碎再带你把一个三节点的有状态服务完整跑起来最后列出我在实际维护中踩过的坑和面试里最容易被追问的考点。不管你是刚接触 Kubernetes还是准备面试或者正在生产环境里被有状态应用折腾这篇都值得你花十分钟读完。1. StatefulSet 存在的意义为什么 Deployment 管不了有状态应用1.1 Deployment 的无状态假设到底假设了什么很多人学 Kubernetes 的第一课就是 Deployment知道它保证 Pod 的副本数、支持滚动更新、支持回滚。但很少有人去细想Deployment 对 Pod 的基本假设是什么答案很简单——所有副本是完全等价的。这句话听起来平淡实际影响非常大。因为副本等价所以 Deployment 创建的 Pod 名字是随机后缀比如web-7d9b5c8b6d-abcde因为等价所以任何一个 Pod 挂了Deployment 可以立刻用一个新的 Pod 顶上名字不一样也无所谓因为等价所以所有副本共享同一个 Service 入口流量打到哪个副本都一样。这套逻辑对无状态服务比如 Nginx 前端、API 网关、计算 worker完美适用。但对数据库、ZooKeeper、Kafka、Redis Cluster 这类应用问题就来了这些应用需要我是谁这个概念。主从架构里主节点要知道自己是主节点从节点要能通过固定的名字找到主节点集群模式下每个节点都要有唯一的、稳定的标识供其他节点发现。Deployment 可以帮你把 Pod 拉起来但它保证不了这个 Pod 还是原来那个 Pod。1.2 有状态应用对基础设施提出的三个硬性要求我把有状态应用对 Kubernetes 的核心诉求总结成三点你拿这三把尺子去量任何有状态应用都能判断它适不适合用 StatefulSet稳定的网络标识Pod 无论怎么重建它的主机名、DNS 名称必须不变。这样集群里的其他成员才能靠配置好的名字找到它而不是每次都要重新发现 IP。稳定的持久化存储Pod 可以死但数据不能死。Pod 重建后要能自动挂载回原来那块存储而不是拿到一块空盘。有序的部署和销毁很多分布式系统对启动顺序有硬性要求。比如 ZooKeeper 要求节点按序号依次启动Kubernetes 需要先启动 etcd 才能启动 control plane。Pod 的创建、更新、删除要有一个可预期的顺序。Deployment 一个都满足不了。StatefulSet 就是为了同时满足这三点而存在的。你可以把 StatefulSet 理解为给 Pod 发身份证 绑定私人保险柜 安排排队入场的控制器。1.3 StatefulSet 不适用的场景别把万能钥匙当锤子反过来也要说清楚StatefulSet 不是银弹。它解决的是身份 存储 顺序问题但如果你只是需要一个能跑多个副本、挂个共享存储的应用它反而是过度设计。举几个反例如果你的应用不需要固定网络标识不需要每个实例独立存储不需要按顺序启停那就老老实实用 Deployment。比如 Redis 的纯缓存模式挂了重启数据丢了也无所谓Deployment 反而更合适。再比如用 NFS 做共享读写的应用这类应用因为所有副本共用一块盘、不需要身份用 Deployment 挂一个 PVC 就够了用 StatefulSet 反而会给你创建出一堆无意义的独立卷。一句话有状态不等于必须用 StatefulSet关键看你这个状态是绑定在 Pod 实例上的还是绑定在外部共享资源上的。2. 三大核心机制拆解稳定标识、稳定存储、有序调度2.1 稳定网络标识Pod 名称和 Headless Service 如何协同工作StatefulSet 的第一个核心机制是它管理的每个 Pod 都有一个有序且永久的名字。命名规则是${StatefulSet名称}-${序号}序号从 0 开始。比如一个名为zk的 StatefulSet 有 3 个副本那么 Pod 名字一定是zk-0、zk-1、zk-2。这个名字在 Pod 的生命周期内不会变即使 Pod 被删除重建新 Pod 还是会叫zk-0。光有稳定的名字还不够其他服务怎么通过这个名字找到它这就轮到 Headless Service 登场了。普通的 Service 会分配一个 ClusterIP作为负载均衡入口而 Headless Service 的定义里写了clusterIP: None它不提供 ClusterIP而是把 DNS 查询直接解析到后端的每个 Pod IP 上。两者的配合是这样工作的StatefulSet 通过serviceName字段关联一个 Headless ServiceKubernetes 会为每个 Pod 生成一条 DNS 记录格式是pod名称.service名称.命名空间.svc.cluster.local举例来说zk-0这条记录就会是zk-0.zk-hs.default.svc.cluster.local。同一个集群里的其他 Pod直接访问这个名字就能连到对应的实例而且无论zk-0被重建多少次、IP 变成什么这条记录始终指向当前存活的zk-0的 IP。我在最初接触这个设计时总觉得绕后来想通了一个类比Pod 的名字相当于人的身份证号IP 相当于人的临时住址。住址可以换来换去但身份证号是唯一的。ClusterIP 是公司总机Headless Service 是通讯录——你自己翻通讯录找到对应的人而不是让总机转接。2.2 稳定存储volumeClaimTemplates 与 PVC 的绑约关系稳定网络标识解决了找到我稳定存储解决的是别忘了我的数据。StatefulSet 里有一个volumeClaimTemplates字段它就像一个PVC 模板工厂——每创建一个 Pod就自动按模板生成一个 PVC并且 PVC 的名字会带上 Pod 的名字。还是用zk这个例子。假如我在volumeClaimTemplates里定义了一个名为data的 PVC 模板那么zk-0会得到名为>apiVersion: v1 kind: Service metadata: name: zk-hs labels: app: zk spec: clusterIP: None selector: app: zk ports: - port: 2888 name: server - port: 3888 name: leader-election这里clusterIP: None就是把它变成 Headless Service 的关键。2888 是 ZooKeeper 节点间同步数据的端口3888 是 leader 选举端口这两个端口只需要集群内部互相访问不需要 ClusterIP。然后是 StatefulSet 本体apiVersion: apps/v1 kind: StatefulSet metadata: name: zk spec: serviceName: zk-hs replicas: 3 podManagementPolicy: OrderedReady selector: matchLabels: app: zk template: metadata: labels: app: zk spec: containers: - name: zk image: zookeeper:3.8 ports: - containerPort: 2181 name: client - containerPort: 2888 name: server - containerPort: 3888 name: leader-election env: - name: ZOO_MY_ID valueFrom: fieldRef: fieldPath: metadata.name command: - sh - -c - | echo ZK_ID$(echo $ZOO_MY_ID | awk -F- {print $NF}) # 这里把 Pod 名字的最后一个数字作为 myid 写入数据目录 # 具体启动脚本按需调整核心思路是把序号的最后一位传给 ZooKeeper 的 myid exec zkServer.sh start-foreground volumeMounts: - name: data mountPath: /data updateStrategy: type: RollingUpdate volumeClaimTemplates: - metadata: name: data spec: accessModes: [ReadWriteOnce] storageClassName: local-path resources: requests: storage: 2Gi这段配置有几个值得注意的点serviceName字段必须填上面创建的 Headless Service 名字这是 StatefulSet 生成稳定 DNS 记录的依据。ZOO_MY_ID从metadata.name也就是 Pod 名字里取再用 shell 提取最后的数字。ZooKeeper 要求每个节点的myid文件内容必须是一个唯一的整数且这个整数要和节点在集群配置里的序号对应。我们利用 StatefulSet 的命名规则把zk-0、zk-1、zk-2的尾部数字提取出来作为myid这样每个节点天然就是唯一且有序的妥妥的身份即配置。volumeClaimTemplates里的data这个名字很关键因为生成的 PVC 名字是>kubectl apply -f zk.yaml service/zk-hs created statefulset.apps/zk created观察 Pod 的创建顺序你能看到它是严格的串行zk-0先启动Ready 之后zk-1才开始然后是zk-2kubectl get pods -l appzk -w NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 0 10s zk-1 0/1 Pending 0 1s zk-1 1/1 Running 0 8s zk-2 0/1 Pending 0 1s等三个 Pod 都 Running 之后我们验证一下稳定网络标识是否生效。进入任意一个 Pod尝试解析另外两个节点的 DNS 名称kubectl exec -it zk-0 -- nslookup zk-1.zk-hs.default.svc.cluster.local返回的应该直接是zk-1的 Pod IP而不是某个 Service 的 ClusterIP。这就是 Headless Service 的解析行为。同一时刻如果zk-1被删掉重建IP 会变但你再次解析zk-1.zk-hs.default.svc.cluster.local拿到的一定是新 Pod 的 IP名字始终不变。然后验证稳定存储。先往zk-0的数据目录里写一个标记文件kubectl exec zk-0 -- sh -c echo hello-stable-storage /data/my-marker.txt然后删掉zk-0kubectl delete pod zk-0等 StatefulSet 自动重建zk-0后再去看那个文件kubectl exec zk-0 -- cat /data/my-marker.txt hello-stable-storage文件还在。Pod 已经被重建了一次但它重新绑定了原来的>kubectl exec zk-0 -- zkServer.sh status正常情况下会输出Mode: leader或Mode: follower并且三个节点能互相发现对方。4. 保住数据的代价维护阶段踩过的坑和完整排查过程到这里StatefulSet 的基本用法你已经会了。但生产环境真正考验人的从来不是能用而是挂了怎么办。这一节我把实际维护 StatefulSet 时踩过的几个坑完整记录下来包括一次 Pending 问题的完整排查链路希望能帮你省下几个小时的排查时间。4.1 Pod 一直 Pendingdescribe 之后才发现是 PVC 绑定失败有一次我部署一个三节点的 etcd StatefulSetkubectl get pods看到三个 Pod 全部 Pending卡了十几分钟。我第一反应是资源不足但kubectl describe node看了下 CPU 内存都够。再kubectl describe pod etcd-0看到了关键信息Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 8s default-scheduler 0/5 nodes are available: 5 node(s) didnt match Pods node affinity/selector. Warning FailedMount 3s kubelet MountVolume.SetUpPod failed: pvc-xxxx has not been bound yet注意看FailedMount这行——PVC 还没绑定。这说明问题不在调度而在存储。接下来我的排查链路是kubectl get pvc看 PVC 状态如果显示Pending说明 PVC 没有成功绑定到 PV。kubectl describe pvc># 查看 Service 是否 Headless kubectl get svc zk-hs -o yaml | grep clusterIP # 进入 Pod 测试解析 kubectl exec zk-0 -- nslookup zk-1.zk-hs.default.svc.cluster.local如果clusterIP那里不是None说明 Service 定义错了。如果解析出来的是 ClusterIP 而不是具体 Pod IP那也说明它其实不是真正的 Headless。修复方式很简单——把 Service 改成clusterIP: None再 apply 一遍。但要注意StatefulSet 的serviceName一旦确定部分场景下需要重建 StatefulSet 才能让 DNS 彻底生效所以最好在第一次部署时就确认 Service 和 StatefulSet 是配套的。4.3 缩容之后 PVC 不删是特性不是 BugStatefulSet 的另一个坑是缩容时数据卷会留着。假设我为了测试把副本数从 3 缩到 1kubectl scale statefulset zk --replicas1然后kubectl get pvc你会看到>kubectl delete statefulset zk kubectl delete pvc>kubectl patch statefulset kafka -p {spec:{updateStrategy:{rollingUpdate:{partition:2}}}}第二个情况应用本身支持乱序启动想加速更新。把podManagementPolicy改成Parallel可以并行重建 Pod更新速度快很多。但在改之前一定确认应用没有隐性的启动顺序依赖否则你会收获一个看起来全绿、实际集群起不来的诡异故障。4.5 别乱动 StatefulSet 的名字最后提醒一个低级但致命的点StatefulSet 的名字就是 Pod 身份的一部分。如果某天你因为重构把 StatefulSet 从zk改名为zookeeper那么新 StatefulSet 管理的 Pod 会叫zookeeper-0、zookeeper-1……它们对应绑定的 PVC 是>