Kubernetes StatefulSet 介绍 – wiki基地

作者： /

深入理解 Kubernetes StatefulSet：管理有状态应用的基石

在云原生时代，Kubernetes 已成为容器编排的事实标准。它极大地简化了无状态应用的部署、扩展和管理。无状态应用（Stateless Application）的每个实例都是相同的、可互换的，不依赖于特定的实例状态，例如典型的 Web 服务器、API 网关等。它们可以随时被创建、删除或替换，而不会影响整个应用的正常运行。然而，在企业应用中，大量的核心业务系统都是有状态的（Stateful Application），例如数据库（MySQL, PostgreSQL, MongoDB）、消息队列（Kafka, RabbitMQ）、分布式键值存储（etcd, ZooKeeper）等。这些应用具有以下特点：

  1. 需要持久化存储： 数据需要在Pod生命周期结束后依然存在，并且特定实例的数据通常是固定的。
  2. 需要稳定的网络标识： 每个 Pod 实例需要一个稳定、可预测的名称或网络地址，以便其他服务或客户端能够可靠地连接到特定实例（例如，数据库的主副本、特定的分片）。
  3. 需要有序的部署、扩展或删除： 对于一些分布式系统，启动顺序、关闭顺序或扩缩容顺序可能非常重要（例如，先启动主节点，再启动从节点）。

标准的 Kubernetes Deployment 对象非常适合管理无状态应用，但它无法满足有状态应用的这些独特需求。Deployment 管理的 Pods 是随机命名的，它们是可丢弃的，并且 Pod 的重启或替换会导致其网络身份改变。此外，Deployment 默认以并行方式创建、删除或更新 Pods，并且不保证 Pod 与特定持久化存储之间的关联。

为了解决这一问题，Kubernetes 引入了 StatefulSet API 对象。StatefulSet 是 Kubernetes 专门用于管理有状态应用负载的控制器。它提供了一组独特的保证，使得在 Kubernetes 上运行有状态应用成为可能且相对稳定。

本文将深入探讨 Kubernetes StatefulSet 的方方面面，包括其核心概念、工作原理、关键特性、与 Deployment 的区别、使用场景以及相关的最佳实践。

一、什么是 StatefulSet？

StatefulSet 是 Kubernetes 的一种工作负载 API 对象，用于管理有状态应用。与 Deployment 类似，StatefulSet 管理基于相同容器规范的一组 Pods。但与 Deployment 不同的是，StatefulSet 为这些 Pods 提供以下保证：

  1. 稳定的、唯一的网络标识符： StatefulSet 中的每个 Pod 都被分配一个稳定的主机名，格式为 <statefulset-name>-<ordinal> (例如: web-0, web-1)，其中 <ordinal> 是一个从零开始的整数，表示 Pod 在 StatefulSet 中的序号。这个主机名在 Pod 被重新调度或替换后会保持不变。结合 Headless Service，这个主机名可以解析到一个稳定的网络地址。
  2. 稳定的、持久化的存储： StatefulSet 可以使用 volumeClaimTemplates 为每个 Pod 实例自动创建 PersistentVolumeClaim (PVC)。这些 PVC 会绑定到可用的 PersistentVolume (PV)，为 Pod 提供稳定的持久化存储。即使 Pod 被删除或重新调度，其对应的 PVC 和数据依然保留，当新的 Pod 以相同的序号启动时，它将重新绑定到原来的 PVC 和数据，确保数据的连续性。
  3. 有序的、优雅的部署、扩展、删除和滚动更新： StatefulSet 对其管理的 Pods 强制执行特定的顺序。默认情况下，Pods 的创建、启动、更新和缩容都是按其序号（从 0 开始）顺序进行的。例如，当创建 StatefulSet 时，Pod statefulset-name-0 会先被创建、初始化并运行就绪后，Pod statefulset-name-1 才会开始创建，依此类推。缩容时则按序号逆序进行（从最大序号开始）。这种有序性对于许多分布式系统来说是必需的。

总而言之，StatefulSet 旨在解决在分布式环境中运行有状态应用的核心挑战，即在动态变化的集群中为应用的每个实例提供稳定的身份和持久化的状态。

二、为什么需要 StatefulSet？与 Deployment 有何不同？

理解 StatefulSet 的必要性最好是通过将其与 Deployment 进行对比。Deployment 适用于无状态应用，其设计理念是 Pods 是可互换的、无差别的副本。

特性 Deployment StatefulSet
管理的应用类型 无状态应用 (Stateless) 有状态应用 (Stateful)
Pod 命名 随机哈希值，每次重启或替换都会改变 (<deployment-name>-<random-string>) 稳定的、有序的命名 (<statefulset-name>-<ordinal>)，序号从 0 开始，不会改变。
网络标识 不稳定，依赖 Pod 的 IP，IP 会随 Pod 生命周期改变。通常通过 Service 负载均衡访问一组 Pods。 稳定，结合 Headless Service，每个 Pod 有一个稳定的 DNS 主机名。
存储管理 通常使用临时存储或共享 PV (所有 Pod 共享一个 PV 或多个 PV)，不保证特定 Pod 绑定特定 PV。 使用 volumeClaimTemplates 为每个 Pod 自动创建独立的 PVC，保证特定序号的 Pod 绑定到特定的存储。
部署/扩缩容顺序 并行进行，不保证顺序。 默认按序号顺序进行（创建/扩容：0, 1, 2…；删除/缩容：N, N-1,…0）。可配置为并行。
Pod 删除 Pod 被删除后即消失。 Pod 被删除后，其对应的 PVC 默认不会被删除（防止数据丢失），需要手动删除。
Pod 更新策略 支持 RollingUpdate, Recreate。RollingUpdate 是并行或批处理。 支持 RollingUpdate (可分区), OnDelete。RollingUpdate 默认是按序号顺序更新。

核心区别在于对待 Pod 的态度：

  • Deployment 将 Pods 视为可丢弃的、无差别的副本。 你不关心是哪个 Pod 实例处理请求，只要有一组健康的 Pods 可用即可。
  • StatefulSet 将 Pods 视为具有稳定身份的独立个体。 每个 Pod 都有其独特的序号、名称和可能绑定的存储。它们的顺序和身份是重要的。

因此，对于需要稳定身份、持久化存储和/或严格操作顺序的应用，StatefulSet 是唯一的选择。试图用 Deployment 来管理复杂的有状态应用通常会导致数据丢失、服务不稳定或难以管理。

三、StatefulSet 的核心工作原理与组件

StatefulSet 通过几个关键机制来提供其独特的保证：

  1. Pod 命名与序号 (Ordinals):
    当 StatefulSet 控制器创建 Pods 时，它会按照从 0 开始的递增整数为每个 Pod 命名，格式为 <statefulset-name>-<ordinal>。例如，一个名为 database 的 StatefulSet 启动 3 个副本，会创建 database-0, database-1, database-2 三个 Pod。这个序号是 Pod 身份的一部分，并且在 Pod 的整个生命周期中保持稳定。即使 Pod 被删除后重新创建（例如，由于节点故障），新的 Pod 仍然会尝试使用相同的名称和序号。

  2. Headless Service (无头服务):
    StatefulSet 通常与一个 Headless Service (.spec.clusterIP: None) 结合使用。普通 Service 会为一组 Pods 提供一个稳定的集群 IP 和负载均衡能力。而 Headless Service 没有集群 IP，它只提供 DNS 查询服务。
    当使用 Headless Service 并将其名称指定给 StatefulSet 的 .spec.serviceName 字段时，Kubernetes 会为 StatefulSet 中的每个 Pod 创建一个 DNS 条目。这个 DNS 条目的格式通常是 <pod-name>.<service-name>.<namespace>.svc.cluster.local。
    例如，一个名为 database 的 StatefulSet 关联了一个名为 database-svc 的 Headless Service，在 default 命名空间中，Pod database-0 的 DNS 名称将是 database-0.database-svc.default.svc.cluster.local。其他 Pods 或外部客户端可以通过这个稳定的 DNS 名称直接查询和访问特定的 StatefulSet Pod 实例，而不需要知道其动态变化的 IP 地址。这是实现稳定网络身份的关键。

  3. VolumeClaimTemplates (存储卷申请模板):
    .spec.volumeClaimTemplates 是 StatefulSet 中用于管理持久化存储的核心机制。它是一个 PVC 定义的模板列表。StatefulSet 控制器会为 StatefulSet 管理的每个 Pod（基于其序号）创建一个对应的 PVC。
    PVC 的命名格式是 <volume-template-name>-<pod-name>。例如，如果有一个名为 data 的 VolumeClaimTemplate，StatefulSet 名为 database，Pod 名为 database-0，那么创建的 PVC 名称将是 data-database-0。
    当 Pod 启动时，它会尝试挂载其对应的 PVC。Kubernetes 的存储系统会确保这个 PVC 绑定到合适的 PersistentVolume (PV)，并将 PV 提供的存储挂载到 Pod 中。
    重要一点是： 当 StatefulSet Pod 被删除（例如，缩容或节点故障导致 Pod 驱逐后未自动重建）时，其对应的 PVC 默认不会被删除。这是一种数据保护机制，防止误删 StatefulSet 导致数据丢失。这意味着即使 Pod 被删除，其状态数据仍然保留在对应的 PersistentVolume 中。当你重新创建一个具有相同序号的 Pod 时，它会重新使用这个现有的 PVC，从而访问到之前的数据。

  4. Pod 管理策略 (Pod Management Policy):
    .spec.podManagementPolicy 控制 StatefulSet 创建和删除 Pods 的顺序和并行性。有两个主要选项：

    • OrderedReady (默认): 这是最常用的策略，它强制执行严格的顺序。当 StatefulSet 扩容时，Pod <statefulset-name>-0 会先被创建并等待其进入 Ready 状态后，才会创建 <statefulset-name>-1，依此类推。当缩容时，Pod <statefulset-name>-N (序号最大的那个) 会先被终止并完全删除后，才会终止 <statefulset-name>-N-1，依此类推。更新操作也遵循类似的有序、逐个进行的原则。这种策略适用于许多分布式数据库和消息队列，它们对节点的启动和关闭顺序有严格要求。
    • Parallel: 这个策略允许 StatefulSet 控制器并行地创建或删除 Pods。它仍然会按照序号创建 Pods，但不会等待前一个 Pod 变为 Ready 状态。这种策略适用于那些即使并行启动或关闭也能正常工作的应用，可以加快扩缩容速度，但失去了有序性保证。

  5. 更新策略 (Update Strategy):
    .spec.updateStrategy 控制如何更新 StatefulSet 中的容器、标签、资源请求/限制等配置。有两个主要选项：

    • RollingUpdate (默认): 类似于 Deployment 的滚动更新，StatefulSet 会按照其序号逆序（从最大序号的 Pod 开始）逐个替换 Pod。在替换每个 Pod 之前，它会等待前一个 Pod 完成更新并进入 Running 和 Ready 状态。RollingUpdate 还支持 partition 字段，可以指定一个分区号。只有序号大于或等于分区号的 Pods 才会被更新，小于分区号的 Pods 会保留旧版本。这对于灰度发布或手动控制更新节奏非常有用。
    • OnDelete: 当设置为 OnDelete 时，StatefulSet 控制器不会自动更新 Pods。只有当用户手动删除一个 Pod 后，控制器才会创建一个新版本（使用更新后的模板）的 Pod 来替换它。这提供了完全手动的更新控制。

四、StatefulSet YAML 定义详解

下面是一个 StatefulSet 定义的示例，用于部署一个简单的 Web 应用（为了演示存储和身份，即使 Web 应用通常是无状态的，这里我们模拟需要独立存储的情况）：

“`yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
namespace: default
spec:
serviceName: “web-service” # 关联一个 Headless Service 的名称
replicas: 3 # 期望的 Pod 副本数量
selector:
matchLabels:
app: web # 用于查找关联 Pods 的标签选择器
template:
metadata:
labels:
app: web # Pod 模板的标签
spec:
containers:
– name: nginx
image: k8s.gcr.io/nginx-slim:0.8 # 容器镜像
ports:
– containerPort: 80
name: web
volumeMounts:
– name: www # 卷挂载名称，对应 volumeClaimTemplates 中的名称
mountPath: /usr/share/nginx/html # 容器内挂载路径
volumeClaimTemplates: # 定义 PVC 模板列表
– metadata:
name: www # PVC 模板名称，会被 Pod 引用
spec:
accessModes: [ “ReadWriteOnce” ] # 访问模式
storageClassName: “standard” # 存储类名称 (需要你的集群有对应的 StorageClass)
resources:
requests:
storage: 1Gi # 请求 1Gi 的存储空间

“`

字段解释：

  • apiVersion, kind, metadata: 标准的 Kubernetes 对象元数据。
  • spec.serviceName: 必需字段！ 指定与该 StatefulSet 关联的 Headless Service 的名称。StatefulSet 利用此 Headless Service 创建稳定的网络标识。请确保您已经创建了一个同名的 Headless Service。
  • spec.replicas: 期望运行的 Pod 副本数量。
  • spec.selector: 用于匹配 Pod 模板标签的选择器，StatefulSet 控制器使用它来查找和管理 Pods。
  • spec.template: 定义了 StatefulSet 创建的 Pod 的模板，与 Deployment 的 Pod 模板类似。
    • spec.template.metadata.labels: Pod 的标签，必须与 spec.selector.matchLabels 匹配。
    • spec.template.spec.containers: 定义 Pod 中的容器。
    • spec.template.spec.containers.volumeMounts: 定义容器内的卷挂载点。name 字段必须与 volumeClaimTemplates 中的 metadata.name 匹配。
  • spec.volumeClaimTemplates: StatefulSet 独有的关键字段！ 这是一个 PVC 定义的模板列表。StatefulSet 控制器会为每个 Pod 实例（根据序号）自动创建一个 PVC，命名格式为 <volume-template-name>-<pod-name>。
    • metadata.name: PVC 模板的名称，用于在 Pod 模板的 volumeMounts 中引用。
    • spec.accessModes: PVC 的访问模式，如 ReadWriteOnce, ReadOnlyMany, ReadWriteMany。对于 StatefulSet，通常使用 ReadWriteOnce，因为每个 Pod 需要独占自己的存储。
    • spec.storageClassName: 指定用于动态创建 PV 的 StorageClass。如果省略，则使用默认的 StorageClass。如果不想使用动态创建，可以设置为 ""，然后需要手动创建匹配标签和访问模式的 PV 供 PVC 绑定。
    • spec.resources.requests.storage: 请求的存储空间大小。

要使上述 StatefulSet 工作，您还需要创建一个对应的 Headless Service：

yaml
apiVersion: v1
kind: Service
metadata:
name: web-service # 必须与 StatefulSet 中的 serviceName 字段匹配
namespace: default
spec:
ports:
- port: 80
name: web
clusterIP: None # **关键：设置为 None 使其成为 Headless Service**
selector:
app: web # 必须与 StatefulSet 的 selector 匹配

应用这两个 YAML 文件：

bash
kubectl apply -f headless-service.yaml
kubectl apply -f statefulset.yaml

查看创建的资源：

bash
kubectl get sts web
kubectl get pods -l app=web
kubectl get pvc -l app=web # 查看自动创建的 PVCs

您会看到类似如下的输出：

“`

kubectl get sts web

NAME READY AGE
web 3/3 5m

kubectl get pods -l app=web

NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 5m
web-1 1/1 Running 0 4m
web-2 1/1 Running 0 3m

kubectl get pvc -l app=web

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
www-web-0 Bound pvc-abcde… 1Gi RWO standard 5m
www-web-1 Bound pvc-fghij… 1Gi RWO standard 4m
www-web-2 Bound pvc-klmno… 1Gi RWO standard 3m
“`

注意 Pod 的命名 (web-0, web-1, web-2) 和 PVC 的命名 (www-web-0, www-web-1, www-web-2)，它们都体现了 StatefulSet 的稳定身份和有序性。每个 Pod 都绑定到了一个专属的 PVC。

您可以通过 kubectl exec 进入 Pod 并检查其网络身份：

bash
kubectl exec web-0 -- hostname -f

输出将是 web-0.web-service.default.svc.cluster.local，这是 Pod 的稳定 FQDN。

五、StatefulSet 的高级特性与操作

1. 扩缩容 (Scaling):

StatefulSet 的扩缩容是有序的。

  • 扩容： 如果将 replicas 从 3 增加到 5，StatefulSet 会先创建 web-3，等待其 Ready 后再创建 web-4。
  • 缩容： 如果将 replicas 从 3 减少到 1，StatefulSet 会先终止并删除 web-2，完成后再终止并删除 web-1。web-0 会被保留。

使用 kubectl scale statefulset web --replicas=5 进行扩容，使用 kubectl scale statefulset web --replicas=1 进行缩容。

2. 更新策略 (Update Strategy):

  • RollingUpdate:
    默认的 RollingUpdate 策略按序号逆序更新 Pods。例如，更新 web StatefulSet 的镜像，它会先更新 web-2 Pod，等待其新版本变为 Ready 后再更新 web-1，最后更新 web-0。
    可以使用 partition 字段控制更新：
    yaml
    spec:
    updateStrategy:
    type: RollingUpdate
    rollingUpdate:
    partition: 1 # 只更新序号 >= 1 的 Pods (web-1, web-2)。web-0 保持旧版本。
    这常用于金丝雀发布或分阶段部署。

  • OnDelete:
    当 updateStrategy 为 OnDelete 时，StatefulSet 不会自动进行更新。你需要手动删除旧版本的 Pod (kubectl delete pod web-2)，StatefulSet 控制器才会使用新的模板创建 web-2 Pod。

3. 删除 StatefulSet 和其 Pods:

删除 StatefulSet 本身是一个需要谨慎的操作，因为它默认不会删除相关的 PVCs。

  • kubectl delete statefulset web: 这个命令会删除 StatefulSet 对象，并按照序号逆序删除其 Pods (web-2, web-1, web-0)。但是，与这些 Pod 关联的 PVCs (www-web-0, www-web-1, www-web-2) 会保留。这是为了防止数据丢失。你需要手动删除这些 PVCs (kubectl delete pvc www-web-0 www-web-1 www-web-2)。
  • kubectl delete statefulset web --cascade=orphan: 这个命令会删除 StatefulSet 对象，但不会删除其管理的任何 Pods 或 PVCs。这在某些高级场景下用于分离 StatefulSet 控制器和 Pods 的生命周期。
  • kubectl delete statefulset web --cascade=foreground: (Kubernetes 1.10+): StatefulSet 对象会先变为 “deletion in progress” 状态，然后控制器会按照逆序删除 Pods。所有 Pod 删除完成后，StatefulSet 对象本身才会被删除。相关的 PVCs 默认仍会保留。

删除 StatefulSet 时的数据保留行为是一个重要的安全特性，但也意味着清理资源时需要额外的步骤。

六、StatefulSet 的适用场景

StatefulSet 主要用于管理需要稳定身份和持久化存储的有状态应用，典型的使用场景包括：

  1. 数据库系统： MySQL 主从复制集群、PostgreSQL、MongoDB 副本集或分片集群、Cassandra 集群等。这些系统通常需要稳定的网络地址和每个副本独有的数据存储。
  2. 消息队列： Kafka 集群、RabbitMQ 集群等。这些系统需要持久化存储消息数据，并且集群成员可能需要稳定的标识进行内部通信。
  3. 分布式键值存储： etcd 集群、ZooKeeper 集群等。这些是构建许多分布式系统的基础组件，对成员身份和数据一致性要求极高。
  4. 分布式文件系统： GlusterFS、Cephfs 等客户端/服务器模式。
  5. 监控与日志存储后端： Prometheus、Elasticsearch 集群等，需要持久化存储大量的时序数据或日志数据。
  6. 其他需要稳定身份、持久化存储和/或有序操作的分布式系统。

七、使用 StatefulSet 的注意事项和最佳实践

  1. 提前规划存储： StatefulSet 依赖于 PersistentVolume 机制。确保你的 Kubernetes 集群有可用的存储解决方案（如 StorageClass 配置动态 PV Provisioner，或预先创建好 PVs）来满足 StatefulSet 的 volumeClaimTemplates 需求。如果底层存储不可用或配置不当，StatefulSet 将无法创建 Pods。
  2. Headless Service 是关键： 总是为 StatefulSet 创建一个关联的 Headless Service，并通过 spec.serviceName 字段引用它。这是实现稳定网络身份的基础。
  3. 理解 Pod 命名和序号： 记住 Pod 的命名规则 (<statefulset-name>-<ordinal>) 和序号的意义。许多有状态应用（特别是分布式系统）的配置需要依赖这些序号来区分不同的实例（例如，区分主副本和从副本，或者配置分片）。应用程序自身可能需要读取 Pod 主机名或通过 Downward API 获取序号。
  4. 理解 Pod 管理策略： 默认的 OrderedReady 策略是安全的，但可能会导致扩缩容和更新过程较慢。如果你的应用允许并行操作，并且你想加快这些过程，可以考虑使用 Parallel 策略，但要确保你的应用能够正确处理并行启动/关闭带来的潜在问题。
  5. 谨慎删除 StatefulSet： 再次强调，删除 StatefulSet 默认不会删除其 PVCs。在删除 StatefulSet 后，你需要手动清理不再需要的 PVCs，否则它们会一直占用存储资源。在生产环境中操作前务必三思，并确保了解数据备份和恢复策略。
  6. 合理配置 Readiness Probe： 由于 StatefulSet 的有序操作依赖于前一个 Pod 进入 Ready 状态，因此正确配置 Readiness Probe 至关重要。确保 Readiness Probe 准确反映了 Pod 内部应用是否真正可用（例如，数据库是否启动并接受连接）。不准确的 Readiness Probe 可能导致后续 Pod 无法启动，从而阻塞整个部署或扩缩容过程。
  7. 应用程序设计考虑： 理想情况下，用于 StatefulSet 的应用程序应该能够优雅地处理有序启动和关闭。例如，在关闭前完成未尽的任务、释放资源等。StatefulSet 支持生命周期 Hook (preStop、postStart)，可以在 Pod 终止前或启动后执行一些清理或初始化脚本。
  8. 分区更新的使用： RollingUpdate 策略的 partition 字段是实现灰度发布或手动控制更新节奏的强大工具。熟练掌握它的用法可以让你更安全地进行应用升级。
  9. 监控： 监控 StatefulSet 中 Pods 的状态、PVCs 的状态、以及底层存储的使用情况非常重要。

八、总结

StatefulSet 是 Kubernetes 提供的一个强大且复杂的控制器，专门用于解决在动态环境中运行有状态应用所面临的挑战。通过提供稳定的网络身份、持久化的存储和有序的操作保证，StatefulSet 使得在 Kubernetes 上部署和管理数据库、消息队列等核心有状态服务成为可能。

理解 StatefulSet 的核心工作原理，特别是其如何通过 Pod 命名、Headless Service 和 VolumeClaimTemplates 提供稳定身份和存储，以及如何通过 Pod 管理策略和更新策略控制操作顺序，是成功使用 StatefulSet 的关键。虽然相比 Deployment 引入了更多的复杂性，但 StatefulSet 为有状态应用在 Kubernetes 中提供了必要的可靠性和可管理性，是构建强大、弹性的云原生数据基础设施不可或缺的一部分。

在使用 StatefulSet 时，务必仔细规划存储、正确配置 Headless Service 和 Readiness Probe，并充分理解其生命周期和删除行为，这样才能充分发挥其优势，确保有状态应用的稳定运行。

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部