Amazon EKS StatefulSet副本与PVC绑定异常致文件存储错乱排查

核心原因 #

StatefulSet的特性是为每个Pod创建独立的PVC（命名格式为<PVC模板名>-<StatefulSet名>-<Pod序号>），你的3个副本各自拥有独立的gp2存储卷。当用户请求被负载均衡转发到不同Pod时，上传的文件会存在当前Pod绑定的PVC中，其他Pod无法访问该存储卷，自然会出现下载找不到文件的读写错误。

配置修正方案 #

1. 改用共享存储卷 #

如果需要所有Pod共享同一存储，放弃StatefulSet的独立PVC机制，改用以下方式：

• 使用单PVC+ReadWriteMany(RWX)类型存储：AWS EKS中可选择EFS（弹性文件系统），它支持多Pod同时读写。将原PVC的存储类改为EFS对应的存储类，访问模式设为ReadWriteMany，然后在StatefulSet的volumeMounts中挂载这个共享PVC。
• 示例配置片段：

  # PVC配置（EFS）
  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: shared-demo-data
  spec:
    accessModes:
      - ReadWriteMany
    storageClassName: efs-sc # 替换为你的EFS存储类名
    resources:
      requests:
        storage: 10Gi
  
  # StatefulSet中挂载共享PVC
  spec:
    template:
      spec:
        volumes:
          - name: demo-data
            persistentVolumeClaim:
              claimName: shared-demo-data
        containers:
          - name: your-web-app
            volumeMounts:
              - name: demo-data
                mountPath: /demo-data
  

2. 保持StatefulSet独立存储但实现文件同步 #

如果必须保留每个Pod的独立PVC（比如需要隔离存储），需在应用层或存储层实现文件同步：

• 应用层：在Web应用中添加文件同步逻辑，比如上传后将文件同步到所有Pod的PVC，或者使用中心化的文件存储服务（如S3）替代本地PVC存储，Pod仅作为计算节点，文件统一存到S3。
• 存储层：使用支持跨卷同步的工具，比如基于rsync的定时同步脚本，或使用Kubernetes Operator（如Portworx）实现存储卷的数据复制。

3. 调整请求路由策略 #

如果不需要文件共享，只是要让用户的上传和下载请求落到同一个Pod：

• 配置负载均衡（如AWS ALB或Nginx Ingress）的会话保持（Sticky Session），将同一用户的请求始终转发到同一个Pod。但这种方案存在单点风险，Pod故障时用户文件会暂时无法访问，需配合Pod的优雅下线和数据备份机制。

关键注意事项 #

• 存储访问模式匹配：gp2是EBS卷，仅支持ReadWriteOnce(RWO)（单节点读写），无法多Pod共享，这是导致问题的根本原因之一。如果要共享存储必须选择支持RWX的存储类型（EFS、FSx for Lustre等）。
• StatefulSet存储设计：StatefulSet的独立PVC适合需要持久化Pod身份、数据隔离的场景（如数据库集群），不适合需要共享文件的Web应用场景，选型时需匹配业务需求。
• Init容器作用范围：Init容器仅在Pod启动时执行，创建的目录只存在于当前Pod的PVC中，不会同步到其他Pod的存储卷。
• 数据备份：无论使用共享存储还是独立存储，都需配置定期备份（如EBS快照、EFS备份、S3版本控制），避免数据丢失。

内容的提问来源于stack exchange，提问作者jq09