Kubernetes StatefulSet 与有状态服务运维：从无状态到有状态，数据库与中间件的容器化挑战

一、有状态服务的容器化困境：StatefulSet 为何必要

Kubernetes 的 Deployment 控制器专为无状态服务设计：Pod 是可互换的，任意 Pod 可被销毁重建，不影响服务可用性。但数据库、消息队列、分布式存储等有状态服务打破了这一假设——每个 Pod 拥有独特的身份（主机名、序号）、稳定的网络标识、持久化的数据卷。用 Deployment 部署 MySQL 主从集群，Pod 重建后可能丢失数据、角色错乱、集群分裂。

StatefulSet 是 Kubernetes 为有状态服务提供的控制器：为每个 Pod 提供有序的部署与终止、稳定的网络标识（<statefulset-name>-<ordinal>）、持久的存储卷（即使 Pod 重建，PVC 保留）。理解 StatefulSet 的行为特征，是数据库与中间件容器化的前提。

二、StatefulSet 的核心机制与有状态保障

flowchart TD
    A[StatefulSet 创建] --> B[Pod 0 创建并就绪]
    B --> C[Pod 1 创建并就绪]
    C --> D[Pod 2 创建并就绪]

    E[StatefulSet 缩容] --> F[Pod 2 终止]
    F --> G[Pod 1 终止]

    subgraph 稳定标识
        H[mysql-0.mysql: 3306]
        I[mysql-1.mysql: 3306]
        J[mysql-2.mysql: 3306]
    end

    subgraph 持久存储
        K[data-mysql-0: PVC 保留]
        L[data-mysql-1: PVC 保留]
        M[data-mysql-2: PVC 保留]
    end

    B --> H
    C --> I
    D --> J
    B --> K
    C --> L
    D --> M

    subgraph 有序性保障
        N[创建: 0→1→2 顺序]
        O[终止: 2→1→0 逆序]
        P[更新: 0→1→2 滚动]
    end

StatefulSet 的三个核心保障：有序性（创建从 0 到 N-1，终止从 N-1 到 0）、稳定网络标识（Pod 重建后主机名不变）、持久存储（PVC 不随 Pod 删除而销毁）。这些保障使得 MySQL 主从复制、ZooKeeper 集群、Kafka Broker 等有状态服务可以在 Kubernetes 上稳定运行。

三、工程实现：MySQL 主从集群的 StatefulSet 部署

# mysql-statefulset.yaml — MySQL 主从集群
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql  # Headless Service，提供稳定网络标识
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      initContainers:
      # 初始化容器：配置主从复制
      - name: clone-mysql
        image: gcr.io/google-samples/xtrabackup:1.0
        command:
        - bash
        - "-c"
        - |
          # Pod 0 为主节点，无需克隆
          if [[ $(hostname) == mysql-0 ]]; then
            echo "主节点，跳过克隆"
            exit 0
          fi
          # 从节点：从上一个节点克隆数据
          n=$(echo $hostname | sed 's/mysql-//')
          clone_src="mysql-$(($n-1)).mysql"
          echo "从 $clone_src 克隆数据..."
          # 执行 xtrabackup 克隆（实际实现需配置 SSH 密钥）
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
      containers:
      - name: mysql
        image: mysql:8.0
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: root-password
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
        resources:
          requests:
            cpu: "1"
            memory: "2Gi"
          limits:
            cpu: "2"
            memory: "4Gi"
        livenessProbe:
          exec:
            command: ["mysqladmin", "ping", "-h", "localhost"]
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          exec:
            command:
            - bash
            - "-c"
            - |
              # 主节点始终就绪，从节点检查复制状态
              if [[ $(hostname) == mysql-0 ]]; then
                mysql -h localhost -e "SELECT 1"
              else
                mysql -h localhost -e "SHOW SLAVE STATUS\G" | \
                  grep "Slave_SQL_Running: Yes"
              fi
          initialDelaySeconds: 10
          periodSeconds: 5
  # VolumeClaimTemplate：每个 Pod 独立的 PVC
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: ssd-storage
      resources:
        requests:
          storage: 50Gi
---
# Headless Service：提供稳定的 DNS 解析
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  clusterIP: None  # Headless 模式
  selector:
    app: mysql
  ports:
  - port: 3306

# mysql-configmap.yaml — MySQL 配置
apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-config
data:
  master.cnf: |
    [mysqld]
    log-bin=mysql-bin
    server-id=1
    binlog-format=ROW
    sync-binlog=1
    innodb-flush-log-at-trx-commit=1

  slave.cnf: |
    [mysqld]
    log-bin=mysql-bin
    server-id=2
    relay-log=relay-bin
    read-only=1
    relay-log-recovery=1

# 运维操作：手动主从切换
# 1. 在新主节点上停止复制并提升为主
kubectl exec mysql-1 -- mysql -e "STOP SLAVE; RESET MASTER;"

# 2. 在其他从节点上重新指向新主节点
kubectl exec mysql-2 -- mysql -e \
  "CHANGE MASTER TO MASTER_HOST='mysql-1.mysql', MASTER_USER='repl', MASTER_PASSWORD='xxx'; START SLAVE;"

# 3. 更新应用连接到新主节点
# 修改 Service 或 ProxySQL 配置指向 mysql-1.mysql

四、StatefulSet 运维的边界与权衡

滚动更新的风险：StatefulSet 默认的 RollingUpdate 策略从序号最大的 Pod 开始更新。对于 MySQL 主从集群，如果先更新从节点再更新主节点，需要确保从节点已追上复制进度。建议使用 OnDelete 策略手动控制更新顺序，或使用 Operator 自动化管理更新流程。

Pod 调度的亲和性：有状态服务通常需要稳定的网络与存储拓扑。建议为 StatefulSet 配置 Pod Anti-Affinity，确保同一集群的不同副本分布在不同节点上，避免单节点故障导致整个集群不可用。

PVC 的生命周期管理：StatefulSet 删除后 PVC 默认保留，这是正确的行为（防止数据丢失）。但这也意味着重新创建 StatefulSet 后，旧 PVC 会被重新挂载，如果新集群版本不兼容旧数据格式，可能导致启动失败。建议在升级前备份数据，并测试数据兼容性。

网络分区的脑裂风险：在网络分区场景下，多个 Pod 可能同时认为自己是主节点（脑裂）。建议引入外部仲裁（如 etcd）或使用 MySQL Group Replication 替代传统主从复制，从协议层面防止脑裂。

五、总结

StatefulSet 是 Kubernetes 部署有状态服务的核心控制器，通过有序部署、稳定网络标识与持久存储三个保障，使数据库与中间件可以在容器环境中稳定运行。工程落地的关键在于：Headless Service 提供稳定 DNS 解析、VolumeClaimTemplate 保障数据持久性、Pod Anti-Affinity 避免单点故障、手动控制滚动更新顺序。对于生产级数据库集群，建议使用专用 Operator（如 MySQL Operator、Strimzi Kafka Operator）替代手动 StatefulSet 配置，Operator 封装了主从切换、备份恢复、滚动升级等复杂运维逻辑。