如何让多个Pod将独立卷映射至同一Azure Disk？

Great question—you’re absolutely right that the default one-disk-per-Pod model with the Azure Disk provisioner creates an artificial limit based on VM disk attach counts, and you don’t need to reach for something like Ceph to get shared persistent storage. Here are practical, low-overhead solutions to share an Azure Disk across multiple Pods:

1. Use Azure Disk’s Native ReadWriteMany (RWX) Mode #

Certain Azure Disk types natively support RWX access, letting multiple Pods mount the same disk simultaneously without extra components. This is the cleanest option if your workload can use supported disk types:

• Supported disks: Premium SSD v2, Ultra Disk
• How to configure:
  Define a StorageClass with accessModes: ["ReadWriteMany"] and the appropriate disk parameters. For example, an Ultra Disk StorageClass:

  kind: StorageClass
  apiVersion: storage.k8s.io/v1
  metadata:
    name: azure-ultra-disk-rwx
  provisioner: disk.csi.azure.com
  parameters:
    skuname: UltraSSD_LRS
    diskIOPSReadWrite: "4000"  # Adjust based on your needs
    diskMBpsReadWrite: "200"    # Adjust based on your needs
    cachingmode: None
  allowVolumeExpansion: true
  accessModes:
    - ReadWriteMany
  

  Then create a PVC using this StorageClass, and mount it in multiple Pods—Kubernetes will handle the rest.

2. Share an Azure Disk via an NFS Server (for non-RWX disk types) #

If you’re using disk types that don’t support native RWX (like standard SSDs), you can turn a single Azure Disk into a shared NFS volume with minimal overhead:

1. Deploy an NFS server Pod: Mount your Azure Disk to a dedicated Pod that acts as the NFS server. Use a Deployment to ensure it stays running, and a Service to expose it to other Pods.
   Example NFS server Deployment:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nfs-server
   spec:
     replicas: 1
     selector:
       matchLabels:
         role: nfs-server
     template:
       metadata:
         labels:
           role: nfs-server
       spec:
         containers:
         - name: nfs-server
           image: registry.k8s.io/volume-nfs:0.8
           ports:
             - name: nfs
               containerPort: 2049
             - name: mountd
               containerPort: 20048
             - name: rpcbind
               containerPort: 111
           securityContext:
             privileged: true
           volumeMounts:
             - name: azure-disk-volume
               mountPath: /exports
         volumes:
         - name: azure-disk-volume
           persistentVolumeClaim:
             claimName: azure-disk-pvc  # Your existing Azure Disk PVC
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: nfs-server
   spec:
     ports:
       - name: nfs
         port: 2049
       - name: mountd
         port: 20048
       - name: rpcbind
         port: 111
     selector:
       role: nfs-server
   

2. Mount the NFS share in other Pods: Create a PVC that points to the NFS server, then mount it in your application Pods. Example NFS PVC:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: nfs-pv
   spec:
     capacity:
       storage: 100Gi
     accessModes:
       - ReadWriteMany
     nfs:
       server: nfs-server.default.svc.cluster.local  # NFS service DNS
       path: "/exports"
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: nfs-pvc
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: ""
     resources:
       requests:
         storage: 100Gi
   

   Note: For high availability, you can run multiple NFS server replicas with a shared disk (using RWX if supported) or use a StatefulSet, but this adds minor complexity.

3. Switch to Azure Files (If Workload Allows) #

While you asked about Azure Disk, Azure Files is a fully managed, low-overhead alternative that natively supports RWX. It’s ideal for workloads that don’t require block storage performance, like shared configs, static content, or log storage:

• Configuration example:

  kind: StorageClass
  apiVersion: storage.k8s.io/v1
  metadata:
    name: azurefile-rwx
  provisioner: file.csi.azure.com
  parameters:
    skuname: Standard_LRS
  accessModes:
    - ReadWriteMany
  allowVolumeExpansion: true
  

  Create a PVC with this StorageClass, and mount it in as many Pods as needed—no extra servers or components required.

Key Considerations #

• Performance: Native RWX Azure Disks (Ultra/Premium v2) offer block storage performance, while NFS shares add minor latency, and Azure Files is optimized for file access.
• Region Support: Ensure your Azure region supports the RWX disk types you want to use.
• Overhead: Native RWX and Azure Files have zero extra management overhead, while the NFS server approach requires maintaining a small Pod.

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