StatefulSets
在深入讨论技术细节前，需要明确有状态（Stateful）与无状态（Stateless）应用在实际业务场景中的本质区别。无状态应用如大多数 Web 服务，其每个服务实例（Pod）均为同质、可互换的，适用于通过 Kubernetes Deployment 进行标准化部署与自动伸缩。
例如，处理用户请求的 stateless 服务无需持久化存储前后状态，系统可在任意节点随意调度及重建实例。
然而，某些场景如数据库（MySQL、PostgreSQL）或分布式协调系统（ZooKeeper、etcd），由于其需保障业务连续性及数据一致性，天然具有“有状态”属性。
此类应用的每个 Pod 都具备唯一的身份标识和专属的持久化数据。在这类场景下，Deployment 无法满足对稳定网络标识、持久存储及有序伸缩的需求。
这时，Kubernetes 提供的 StatefulSet 控制器，针对有状态服务的生命周期管理、持久数据存储及有序部署，提供了标准化和更为严谨的解决方案。
StatefulSet 的核心
StatefulSet 与 Deployment 同样是 Kubernetes 的控制器，负责应用的部署、扩缩容和自愈。但它之所以特别，是因为它为 Pod 提供了一份独一无二且持之以恒的“身份证明”。这份身份证明包含三个关键部分。
稳定的网络标识
StatefulSet 为每个 Pod 都分配了一个稳定且可预测的名字和网络地址（DNS 主机名）。
这个名字遵循一个简单的格式：<StatefulSet名称>-<序号>。例如，一个名为 mysql 的 StatefulSet，它创建的 Pod 会被依次命名为 mysql-0、mysql-1、mysql-2……这个序号是固定的，即使 Pod 发生故障被重建，新的 Pod 依然会继承同样的名字和序号。
稳定的持久化存储
有状态应用最核心的就是数据。StatefulSet 确保每个 Pod 都能绑定到一个专属的持久化存储卷（Persistent Volume）。
更神奇的是，这个绑定关系是“一生一世”的。mysql-0 这个 Pod 永远使用它自己的那个存储卷，mysql-1 也永远用它自己的。就算 mysql-0 所在的服务器节点宕机了，Kubernetes 会在另一个节点上重新创建 mysql-0，并且把之前属于它的那个存储卷重新挂载给它。数据完好无损，就像给咪咪们分配了刻有名字的专属饭碗，无论它跑到哪里，它的饭碗永远跟着它。
有序的部署与扩缩容
与 Deployment 一上来就“群起而攻之”（并行创建所有 Pod）不同，StatefulSet 充满了仪式感，它严格按照 Pod 的序号进行操作，一个一个来。
- 创建：它会先创建
mysql-0，并耐心等待它完全启动并进入“就绪”（Ready）状态后，才会开始创建mysql-1。这个过程就像建造一座高塔，必须先建好第一层，才能往上盖第二层，保证了集群的稳定初始化。 - 扩容：当你需要增加实例时，它会按照
mysql-3、mysql-4的顺序依次创建。 - 缩容：当你需要减少实例时，它会从序号最大的那个开始，比如先优雅地终止
mysql-4，等它完全关闭后，再处理mysql-3。这种可预见的逆序销毁对于需要数据同步的集群应用至关重要，避免了“雪崩”式的灾难。
StatefulSet 这种有序的操作行为，是防止分布式数据应用（如数据库主从集群）在启动或关闭时发生数据不一致或脑裂问题的关键。它用可预测性换来了系统的稳定性。
部署一个有状态的 Web 应用
理论说完了，让我们亲手部署一个 StatefulSet，来感受它的“魔法”。我们将部署一个简单的 Nginx 应用，但为它配上持久化存储，模拟一个需要保存用户上传内容的网站。 在开始之前，你需要一个正在运行的 Kubernetes 集群。
第一步：创建 StorageClass
首先，我们需要告诉 Kubernetes，我们的应用需要什么样的存储。StorageClass 就是用来定义存储类型的对象。比如，我们可以定义一种名为 fast 的、使用 SSD 的高性能存储。
这里我们使用一个适用于 Google Kubernetes Engine (GKE) 的例子。如果你使用其他云平台或自建集群，请参考对应存储插件的文档。
|# gcp-sc.yml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: flash provisioner: pd.csi.storage.gke.io volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true parameters:
请注意，对于整个物理节点（Node）失联的复杂故障，StatefulSet 出于数据安全考虑，不会自动将 Pod 漂移到新节点。因为它无法判断节点是永久宕机还是暂时网络分区。在这种情况下，通常需要管理员手动介入，确认节点无法恢复后，再强制删除旧 Pod，触发重建。
小结
StatefulSet 是 Kubernetes 中管理有状态应用的核心武器。它通过提供三大法宝：稳定的网络标识、稳定的持久化存储和有序的操作，为那些需要“记忆”和“身份”的应用提供了运行基础。
虽然它比 Deployment 更复杂，但当你需要部署数据库、消息队列或任何需要可靠数据存储和可预测性的分布式系统时，StatefulSet 都是你最值得信赖的伙伴。