基于CSI为Kubernetes配置Azure Blob存储的实操困惑

你的理解完全正确——创建Storage Class后，结合PVC（或StatefulSet的volumeClaimTemplates）就能完成Azure Blob存储的动态配置，两种文档的差异只是场景不同，没必要纠结。

实际实操的标准流程 #

1. 确认CSI驱动已部署
   先检查Azure Blob CSI插件是否在集群正常运行：

   kubectl get pods -n kube-system | grep blob
   

   确保有csi-blob-controller和csi-blob-node类型的Pod处于Running状态。

2. 创建Storage Class
   这是动态配置的核心，定义存储的规格（比如SKU、区域），示例配置：

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: azureblob-csi-sc
   provisioner: blob.csi.azure.com
   parameters:
     skuName: Standard_LRS
     location: eastus
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   

   执行kubectl apply -f sc.yaml完成创建。

3. 用StatefulSet自动生成PVC
   不需要提前手动创建PVC，直接在StatefulSet里通过volumeClaimTemplates定义存储需求，Kubernetes会自动为每个Pod副本创建对应的PVC和Azure Blob容器：

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: blob-demo
   spec:
     serviceName: "blob-demo"
     replicas: 2
     template:
       spec:
         containers:
         - name: demo-container
           image: nginx
           volumeMounts:
           - name: blob-storage
             mountPath: /data
     volumeClaimTemplates:
     - metadata:
         name: blob-storage
       spec:
         accessModes: ["ReadWriteMany"]
         storageClassName: azureblob-csi-sc
         resources:
           requests:
             storage: 10Gi
   

   应用后，用kubectl get pvc就能看到自动创建的PVC，状态会变成Bound，对应Azure端也会生成存储容器。

为什么文档步骤不一样？ #

• GitHub文档的流程是Kubernetes动态存储的标准用法，直接用StatefulSet的volumeClaimTemplates自动管理PVC，适合生产部署，步骤简洁高效。
• 微软文档提到的“先创建PVC和Pod”，本质是分步验证CSI驱动的可用性——先手动创建PVC确认能正常绑定，再用单Pod挂载测试存储读写，没问题再部署StatefulSet，属于调试排查的流程，不是必须的生产步骤。

额外注意点 #

• Azure Blob是对象存储，CSI驱动仅支持ReadWriteMany访问模式，配置PVC时别写错。
• 如果非要手动创建PVC再给StatefulSet用，也是可行的，但生产环境更推荐用volumeClaimTemplates，因为StatefulSet会为每个副本生成独立的PVC，方便管理和扩容。

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