EKS环境中EBS持久卷Multi-Attach错误问题及解决方案咨询

Hey there, let's break down what's happening and walk through both temporary workarounds and long-term solutions for your problem.

Why the Multi-Attach Error Happens #

First, let's clarify the root cause:

• EBS volumes are AZ-bound and only support the ReadWriteOnce (RWO) access mode, which means a single volume can only be mounted to one node at a time.
• Your Deployment is configured to run 2 Pods, which might get scheduled to different nodes (even in the same AZ). When you delete one Pod, the scheduler tries to spin up a new Pod on another node—but the EBS volume is still attached to the original node, triggering the Multi-Attach error.
• When you tried switching to ReadWriteMany (RWX), it failed because EBS simply doesn't support this mode—this is expected behavior, not a configuration mistake.

Temporary Workaround (WA) #

If you need a quick fix to keep your Deployment running with multiple Pods, you can force all Pods to schedule on the same node using pod affinity. Since RWO allows multiple Pods on the same node to access the volume, this will bypass the Multi-Attach error.

Add this affinity configuration to your Deployment's pod template:

spec:
  template:
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - your-app-label # Replace with your Deployment's actual app label
            topologyKey: kubernetes.io/hostname

This ensures all Pods from your Deployment land on the same node, letting them share the RWO EBS volume without conflicts.

⚠️ Note: This is a temporary fix—you lose high availability if the single node fails.

Long-Term Solutions #

Choose the right solution based on your application's storage needs:

1. Switch to Amazon EFS (Shared Storage) #

Amazon EFS is a managed network file system that natively supports ReadWriteMany (RWX), making it perfect for multi-Pod shared storage scenarios.

Steps to implement:

1. Install the EFS CSI Driver on your EKS cluster (using eksctl for simplicity):

   eksctl create iamserviceaccount \
     --cluster=<your-cluster-name> \
     --namespace=kube-system \
     --name=efs-csi-controller-sa \
     --attach-policy-arn=arn:aws:iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
     --approve \
     --override-existing-serviceaccounts
   

2. Create an EFS StorageClass:

   kind: StorageClass
   apiVersion: storage.k8s.io/v1
   metadata:
     name: efs-sc
   provisioner: efs.csi.aws.com
   parameters:
     provisioningMode: efs-ap
     fileSystemId: <your-efs-file-system-id> # Replace with your EFS ID
     directoryPerms: "700"
   

3. Create a RWX PVC:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: efs-claim
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: efs-sc
     resources:
       requests:
         storage: 4Gi # EFS is elastic, this value is just a placeholder
   

4. Update your Deployment to use this new PVC—now all Pods can mount the shared EFS volume without Multi-Attach issues.

2. Use StatefulSet for Independent Storage #

If your application doesn't need shared storage (e.g., each Pod needs its own dedicated volume), switch from Deployment to StatefulSet. StatefulSet automatically provisions a unique EBS volume for each Pod, eliminating conflicts entirely.

Example StatefulSet snippet (simplified):

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: your-app-statefulset
spec:
  serviceName: "your-app-service"
  replicas: 2
  selector:
    matchLabels:
      app: your-app
  template:
    spec:
      containers:
      - name: your-app-container
        image: your-app-image
        volumeMounts:
        - name: app-storage
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: app-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: ebs-sc # Use your existing EBS StorageClass
      resources:
        requests:
          storage: 4Gi

Each Pod in the StatefulSet will get its own PV/PVC, so no Multi-Attach errors when scaling or rolling restarts.

Quick Note on Your Existing Config #

I noticed your PVC uses storageClassName: gp2, but you created a custom StorageClass named ebs-sc. Make sure you're using the correct storage class name if you stick with EBS for single-node scenarios—this avoids unintended provisioning behavior.

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