企业官网建设流程全解析

做 Kubernetes 平台运维这些年，我最怕听到的一句话就是“这服务有点状态，直接用 Deployment 跑一下不就行了”。说这话的人通常还没经历过 Pod 重启后 IP 地址变了、集群成员互相找不到的窘境，也没经历过容器重建后数据目录被连锅端掉的“至暗时刻”。StatefulSet 就是专门解决这类问题的控制器——它管的是那些“有身份、有记忆”的应用，比如数据库、消息队列、分布式协调服务，以及任何需要稳定网络标识和持久化存储的业务组件。

StatefulSet 的核心价值可以浓缩成三件事：稳定的网络标识、稳定的持久化存储、有序的部署与销毁。不管 Pod 怎么重建、怎么在节点间迁移，它都会保留一个不变的网络身份和一份绑定的存储卷，就像给每个实例发了一张“永久身份证”。这篇文章我会从原理讲到 YAML 实操，再讲到排查经验，覆盖 StatefulSet 的核心机制、关键参数和真实踩坑记录。如果你正在用 Deployment 跑数据库实例，或者准备把中间件集群迁到 Kubernetes 上，又或者只是想把有状态应用编排彻底搞明白，这篇文章都值得你读完。

1. 为什么需要 StatefulSet：从一次故障说起

1.1 无状态和有状态应用的本质差别

要理解 StatefulSet，先得搞清楚“有状态”到底意味着什么。无状态应用是最理想化的部署形态：每个副本都是同一个模子里刻出来的，谁都能替代谁。比如一组 Web 前端，Pod A 挂了，控制器立刻拉起一个新的 Pod，流量照打，没有任何人会注意到刚才那个实例的“身份”变了。因为前端不关心自己是谁，它也没有任何必须保留的东西。

有状态应用就完全不一样了。以某个分布式数据库集群为例，三个节点组成一个复制组，每个节点有明确的角色：一个主节点、两个从节点。主节点负责写入，从节点同步主节点数据并对外提供读服务。这时候问题就来了：

• 如果 Pod 随机命名，重启后名字变了，集群里的其他成员怎么知道谁是原来的主节点？
• 如果 Pod 每次启动都用新的存储卷，原来那份数据去哪找？
• 如果要扩容到五个节点，新节点应该排在什么位置？主从关系怎么重新协商？

这些问题在传统物理机或虚拟机上都不是事儿，因为服务器有固定的 IP 和固定的磁盘。但 Kubernetes 默认的 Pod 模型是“临时、可替换、无身份”的，Deployment 创建的每个 Pod 名字后面跟着随机后缀，每次重建都会变。这套模型对无状态应用来说非常完美，但对有状态应用就是灾难。

我当年第一次用 Deployment 跑一个三节点的分布式存储系统，看起来一切正常：三个副本全都 Running，数据读写也没问题。结果某天一台宿主机维护，节点被驱逐，Kubernetes 自动拉起了一个新 Pod。新 Pod 确实起来了，但它是个“陌生人”——没有数据目录、没有原来的集群身份，其他两个节点根本不认它。最后整个存储集群状态异常，只能人工介入恢复。那次事故之后我才明白，Deployment 的副本模型和有状态应用的需求之间存在根本性冲突。

1.2 Deployment 面对有状态应用的三个盲区

Deployment 处理不了有状态应用，核心体现在三个维度上。

第一个维度是网络标识。Deployment 创建的 Pod 名称是“deployment名-随机串”，这个随机串每次重建都会变。很多分布式系统是靠主机名或固定 IP 来做成员发现和通信的，Pod 名称一变，集群元数据就乱了。哪怕你用 Service 做了一层抽象，Pod 之间的直连通信、数据同步通道仍然需要稳定的端点。

第二个维度是存储。Deployment 当然可以挂载 PVC，但如果你给多个副本挂同一个 PVC，那就是所有实例抢一块盘，根本跑不起来；如果每个副本各挂一块 PVC，Pod 重建后到底挂哪块？Deployment 本身不负责为每个副本维护独立的、可复用的存储卷。控制器只会无脑地“新建 Pod”，不会去关心这个新 Pod 是不是应该复用原来那个实例的数据盘。

第三个维度是顺序。有些应用对启停顺序有严格要求。典型例子是分布式数据库的初始化流程：第一个节点必须最先启动，完成集群初始化，然后第二个、第三个节点才能陆续加入。传统的集群部署脚本通常会写“等第一个节点就绪后再启动下一个”，但 Deployment 的滚动策略是“先建新的、再删旧的”，完全不理会这种依赖。

StatefulSet 就是照着这三个盲区设计出来的控制器。它给每个 Pod 一个固定的序号和名字，为每个副本动态创建独立的存储卷，并且严格控制创建和销毁的顺序。可以说，StatefulSet 是 Kubernetes 对有状态应用世界的一次系统性妥协和补课。

2. 核心机制拆解：稳定标识才是 StatefulSet 的灵魂

2.1 稳定网络标识背后的 Headless Service

StatefulSet 的 Pod 命名规则是“statefulset名-序号”，序号从 0 开始递增。比如一个叫db的 StatefulSet 有三个副本，Pod 名字就是db-0、db-1、db-2。这个名字不是随机生成的，只要 StatefulSet 不删除，序号不改变，Pod 无论重建多少次，名字都保持不变。这是 StatefulSet 最基础也最重要的特性。

但光有固定名字还不够，Pod 之间要能通过网络找到对方。Kubernetes 内部的服务发现机制有两种：普通 Service 会提供一个 VIP，流量经过负载均衡转发；而 StatefulSet 必须配合一种特殊的 Service —— Headless Service 来使用，也就是clusterIP: None的 Service。

Headless Service 不提供 VIP，它只负责生成 DNS 记录。Kubernetes 内部 DNS 系统会为每个 Pod 生成一条 A 记录，格式是pod名称.服务名.命名空间.svc.cluster.local。举个例子，StatefulSet 在default命名空间里，配套的 Headless Service 叫db-headless，那么db-0这个 Pod 的完整域名就是db-0.db-headless.default.svc.cluster.local，并且这个域名指向该 Pod 当前的 IP 地址。Pod 重建后 IP 可能会变，但域名不变，DNS 会自动把域名解析到新的 IP 上。

这套机制解决了一个很实际的问题：分布式系统的节点之间需要互相知道对方的地址。它们可以用“约定好的域名规则”来对号入座，比如节点 0 永远访问db-0.db-headless，节点 1 永远访问db-1.db-headless。不管底层 Pod 怎么漂移，这个地址都对。

我在实际项目里见过不少人犯一个错误：只创建了 StatefulSet，忘了创建 Headless Service，或者创建了普通 Service。结果 Pod 之间通过固定域名访问时经常失败。记住一条铁律：StatefulSet 的serviceName字段必须指向一个真实存在的 Headless Service，否则稳定的网络身份就是空谈。

2.2 持久化存储：volumeClaimTemplates 的魔法

有状态应用和数据是深度绑定的，StatefulSet 解决这个问题的方案是volumeClaimTemplates——把 PVC 的模板直接写进 StatefulSet 定义里。每个副本都会被分配一个从这个模板复制出来的 PVC，名字的格式是“卷名-statefulset名-序号”。

举个例子，模板里定义的卷名叫data，StatefulSet 叫db，那么db-0对应的 PVC 就叫>apiVersion: v1 kind: Service metadata: name: db-headless namespace: default spec: clusterIP: None selector: app: db ports: - port: 3306 name: mysql

关键在于clusterIP: None。加上这一行，Kubernetes 就不会分配 VIP，而是直接创建无头服务；去掉这一行，它就是一个普通 Service。StatefulSet 的 Pod 同样会被普通 Service 选中并接收流量，但 Pod 之间的“点对点”域名访问就会失效。

我在多个项目里验证过这一点：当 Service 是普通类型时，你访问db-0.db-headless.default.svc.cluster.local，DNS 不会返回记录；改成 Headless 之后，同一域名立刻就能解析出 Pod 的 IP。所以排查“节点间通信失败”问题时，第一步永远是检查配套 Service 是不是 Headless。

3.2 podManagementPolicy：OrderedReady 和 Parallel 怎么选

如果你觉得一个接一个启动太慢，或者你的应用根本不依赖启动顺序，可以把podManagementPolicy改成Parallel。Parallel 模式下，控制器会同时创建或删除所有 Pod，不再等待前一个 Ready。这个策略适合那些启动顺序无关的应用，比如某些基于一致性算法的存储系统，它们对所有节点一视同仁，谁先启动都可以。

但改这个参数前要冷静评估。OrderedReady不只是控制启动顺序，它还承担着一个隐性职责：先启动的节点往往是集群中的“元老”，后启动的节点会主动找“元老”报到。如果你把数据库集群切到Parallel模式，几个 Pod 同时启动、彼此之间没有明确的“第一个”，有些数据库的初始化流程就会出问题——比如多个节点同时尝试创建集群元数据，导致冲突。

从我的经验来看：分布式协调服务、主从复制型数据库、共享集群状态的中间件，全都保持默认的OrderedReady；只有那些真正“节点之间不需要区分顺序”的应用才值得切到Parallel。不要为了省几分钟扩容时间给自己埋雷。

3.3 updateStrategy：滚动更新和 OnDelete 的取舍

StatefulSet 的更新策略默认是RollingUpdate，即滚动更新。滚动更新有两个重要参数需要掌握：partition和maxUnavailable。

partition的含义是“只更新序号大于等于 partition 的 Pod”。比如分区值是 2，那么序号 0 和 1 的 Pod 保持旧版本不动，从 2 开始逐个更新。这个参数非常适合灰度发布：先在副本数较多的集群里更新“低优先级”的从节点，观察一段时间没有异常，再把partition改成 0，让主节点和其他剩余节点完成升级。

OnDelete则是另一种更保守的策略：控制器不主动重建任何 Pod，只有在有人手动删掉某个 Pod 之后，控制器才会用新版本模板重建它。这适合那些希望完全掌控升级节奏的场景，比如数据库大版本升级，运维人员希望分批手动操作，每一步都确认无误。

我第一次用 StatefulSet 升级数据库集群时选的就是RollingUpdate，但没设partition，结果一上来就把所有的从节点更新了，幸好应用本身兼容滚动升级，否则就是一次大事故。升级数据库这类关键组件，推荐先把partition设为副本数减一，发布到只有一个节点，验证没问题再逐步推进。

3.4 persistentVolumeClaimRetentionPolicy：PVC 的去留问题

在较早版本的 Kubernetes 里，StatefulSet 删除后 PVC 会残留下来，这被很多人视为“坑”——集群里堆了一堆没人用的存储卷，还一直扣费。后来社区加入了persistentVolumeClaimRetentionPolicy，允许你控制 PVC 在 StatefulSet 删除或缩容时的行为。这个字段在spec下一层，有两个取值：WhenDeleted和WhenScaled，每个都可以设置Retain或Delete。

• WhenDeleted: Retain（默认）表示 StatefulSet 被删除时 PVC 保留，防止误删数据。
• WhenDeleted: Delete表示连同 PVC 一起删除。
• WhenScaled: Retain（默认）表示缩容时保留被缩掉副本的 PVC。
• WhenScaled: Delete表示缩容时自动删除多余的 PVC。

生产环境里我建议保持默认的 Retain 语义，尤其是WhenDeleted。你永远不知道哪一天想恢复一个删掉的 StatefulSet，如果 PVC 被自动清掉，数据就真的没了。PVC 的清理应该留给运维人员手动操作，而不是交给控制器自动处理。

4. 实操全过程：从 YAML 到生产可用

4.1 一个完整的 StatefulSet 示例

下面用一个典型的分布式数据库集群场景来演示。假设我们要部署一套三节点的数据库，每个节点需要独立的数据盘和稳定的网络标识。完整的 YAML 分两部分：先创建 Headless Service，再创建 StatefulSet。

# headless-service.yaml apiVersion: v1 kind: Service metadata: name: coredb-hs namespace: default spec: clusterIP: None selector: app: coredb ports: - name: db-port port: 5432 targetPort: 5432

# statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: coredb namespace: default spec: serviceName: coredb-hs replicas: 3 podManagementPolicy: OrderedReady updateStrategy: type: RollingUpdate selector: matchLabels: app: coredb template: metadata: labels: app: coredb spec: containers: - name: db image: myhub/coredb:3.2.1 ports: - containerPort: 5432 name: db-port env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: NODE_ID value: "$(POD_NAME)" volumeMounts: - name: data mountPath: /var/lib/coredb readinessProbe: exec: command: ["coredb-cli", "ping"] initialDelaySeconds: 10 periodSeconds: 10 livenessProbe: exec: command: ["coredb-cli", "status"] initialDelaySeconds: 60 periodSeconds: 20 volumeClaimTemplates: - metadata: name: data spec: accessModes: ["ReadWriteOnce"] storageClassName: fast-ssd resources: requests: storage: 100Gi

这段配置里容易被人忽略的两个细节，我展开讲一下。

第一个是环境变量POD_NAME和NODE_ID。很多分布式应用启动时需要一个“我是谁”的身份标识，我们通过 downward API 把 Pod 名称注入容器环境变量，应用启动时就知道自己是coredb-0还是coredb-1。这个看起来不起眼的小配置，实际上是把 Kubernetes 层面的稳定性“翻译”成应用层能理解的身份信息。

第二个是存储类fast-ssd。volumeClaimTemplates中声明的storageClassName必须提前在集群里创建好，并且对应的存储插件要能动态供给。如果你的集群没配置默认 StorageClass，这里就必须显式指定，否则 PVC 会一直停留在 Pending 状态。

部署命令也很简单，先建 Service 再建 StatefulSet，顺序不要反，否则 StatefulSet 启动时找不到 Service 会报错：

kubectl apply -f headless-service.yaml kubectl apply -f statefulset.yaml kubectl get pods -l app=coredb -w

观察 Pod 的创建顺序，你会看到coredb-0先进入 Running 和 Ready，然后coredb-1才开始创建，接着coredb-2。这就是OrderedReady策略最直观的表现。

4.2 扩缩容、存储扩容与数据安全边界

扩容和缩容是 StatefulSet 日常运维最频繁的操作。扩容很简单，修改replicas从 3 到 5：

kubectl scale statefulset coredb --replicas=5

控制器会自动创建coredb-3和coredb-4两个新 Pod，并为它们各自创建 PVC：>kubectl patch pvc>kubectl set image statefulset/coredb db=myhub/coredb:3.3.0

默认情况下，控制器会从最大序号开始逐个重建 Pod，coredb-2先更新，等它 Ready 之后再更新coredb-1，最后更新coredb-0。整个过程如果我们不加任何限制，有状态应用可能承受不必要的风险——主节点最后才升级没问题，但从节点全部升级完才发现兼容性问题，想回滚就得再来一轮。

所以在生产环境推荐用partition做灰度发布。把 StatefulSet 的更新策略配置成：

updateStrategy: type: RollingUpdate rollingUpdate: partition: 3

此时即使你修改了镜像，控制器也只更新序号大于等于 3 的 Pod。第一步可以先验证一个从节点，运行一段时间日志和指标都正常，再把partition改成 0 放量更新。掌握这个参数之后，数据库升级的胆子可以大很多。

回滚操作本质上就是再执行一次反向调整：

kubectl rollout undo statefulset/coredb

不过有状态应用的回滚比无状态应用复杂。镜像回滚了，但数据可能已经由新版本写入了新格式，旧版本未必能直接读取。所以“先备份、再升级、回滚前评估数据兼容性”是 StatefulSet 场景的黄金法则。别把无状态应用的回滚习惯直接搬到有状态应用上来。

5. 常见问题与排查实录

5.1 Pod 一直 Pending 起不来

这类问题在 StatefulSet 里最常见的原因就是 PVC 无法绑定。执行kubectl describe pod coredb-0会看到事件里反复出现FailedScheduling或者waiting for persistentvolumetoclaim to be bound。

排查路径一般是这样：先看 PVC 状态，执行kubectl get pvc，如果 PVC 停留在 Pending，再执行kubectl describe pvc>kubectl get svc coredb-hs -o yaml | grep clusterIP

如果输出是具体 IP 而不是None，那这个 Service 就不是 Headless，赶紧改成clusterIP: None然后重新创建。注意，普通 Service 不能原地改成 Headless——ClusterIP 一旦分配就不能清除，你需要先删除旧 Service 再创建新的。

另外别忘了，Pod 里面/etc/resolv.conf里的search域要包含 Service 所在的命名空间，否则短域名（不带namespace后缀的）解析会失败。Kubernetes 默认会自动配置，但如果你自定义了 dnsConfig，就要特别小心。

5.3 Pod 重建后数据丢失和数据目录异常

这是最让人紧张的一类问题。展开kubectl get pvc查看卷的对应关系：正常情况下>kubectl rollout status statefulset/coredb kubectl get pods -l app=coredb

看到某个 Pod 处于 CrashLoopBackOff 或 NotReady 时，重点看 readiness 探针。kubectl describe pod coredb-2会告诉你探针探测失败的次数和原因。数据库类的应用尤其容易栽在探针上——探针命令需要访问数据库，但数据库还没初始化完成，探针就失败了；探针超时时间太短，导致即使数据库起来了也无法在期限内返回。

我的经验是给 StatefulSet 的 readinessProbe 和 livenessProbe 设置足够宽容的initialDelaySeconds和failureThreshold。启动慢的数据库集群，initialDelaySeconds给到 60 秒以上不丢人，periodSeconds保持 10 到 15 秒，failureThreshold放宽到 3 到 5 次，可以有效避免假阳性误报导致更新停滞。

6. 最终实践心得：哪些场景该用，哪些不该用

我用 StatefulSet 管理有状态应用的时间已经不短，踩过的坑也足够多。个人最深的体会是，StatefulSet 不是“万能的有状态方案”，它解决的是“身份、存储、顺序”这三个核心问题，但它不解决应用自身的高可用逻辑、数据备份策略和跨区域容灾问题。你仍然需要自己在应用层面做好备份和恢复演练，不能因为上了 StatefulSet 就觉得数据万无一失。

再分享一个小技巧：在 StatefulSet 的 Pod 模板里，一定要把 Pod 名称注入到环境变量，同时让应用把它作为自己的节点标识。很多分布式中间件都支持“通过环境变量设置节点 ID”，这个设计能让你在排查问题时迅速把 Pod 和集群中的节点对应起来，省去大量猜来猜去的功夫。

如果你只是需要跑一个单节点的存储服务，别急着上 StatefulSet，普通的 Deployment 挂一块单独的 PVC、再用 Recreate 策略更新，完全够用且更简单。StatefulSet 的价值在于“一组有身份、有顺序的实例”，当你的应用需要三个、五个、几十个节点协同工作时，它才真正发挥威力。技术选型永远是适可而止，知道什么时候不用 StatefulSet，和知道怎么用 StatefulSet，同样重要。