AKS中ML训练Pod挂载Azure Files间歇性报[Errno 11]故障排查

问题背景 #

• AKS集群上的ML训练Pod使用Azure Files官方CSI驱动挂载共享，启动阶段挂载正常，但在密集读操作期间间歇性出现[Errno 11] Resource temporarily unavailable错误，任务成功率约50%
• 已排除基础连接问题：使用官方CSI驱动、挂载初始化无异常、存储与集群处于同一区域
• 集群节点版本：Kubernetes 1.26.6

相关配置 #

StorageClass配置 #

allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  creationTimestamp: "2023-11-09T17:26:35Z"
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: azurefile-premium
  resourceVersion: "4868935"
  uid: 9f564575-d36c-40fc-acc0-7ce94de80da9
mountOptions:
- async
- mfsymlinks
- actimeo=30
- nosharesock
parameters:
  skuName: Premium_LRS
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate

Persistent Volume配置 #

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: file.csi.azure.com
    volume.kubernetes.io/provisioner-deletion-secret-name: ""
    volume.kubernetes.io/provisioner-deletion-secret-namespace: ""
  creationTimestamp: "2023-11-09T23:44:00Z"
  finalizers:
  - kubernetes.io/pv-protection
  name: pvc-331bb244-14c2-4510-a5b5-2535bc022ee2
  resourceVersion: "6443272"
  uid: c8ab511f-4876-413b-86e2-57e30e20244a
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 30Ti
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: machine-learning-team-data
    namespace: clearml
    resourceVersion: "6443270"
    uid: 98e13a9e-ce8f-479e-b88d-acae5d1d684b
  csi:
    driver: file.csi.azure.com
    volumeAttributes:
      csi.storage.k8s.io/pv/name: pvc-331bb244-14c2-4510-a5b5-2535bc022ee2
      csi.storage.k8s.io/pvc/name: machine-learning-team-data
      csi.storage.k8s.io/pvc/namespace: clearml
      secretnamespace: clearml
      skuName: Premium_LRS
      storage.kubernetes.io/csiProvisionerIdentity: 1699550739022-5062-file.csi.azure.com
    volumeHandle: mlops-nodes#f25531b5495a8486281d07a#pvc-331bb244-14c2-4510-a5b5-2535bc022ee2###clearml
  mountOptions:
  - mfsymlinks
  - actimeo=30
  - nosharesock
  persistentVolumeReclaimPolicy: Retain
  storageClassName: azurefile-premium
  volumeMode: Filesystem
status:
  phase: Bound

排查思路与解决方案建议 #

排查方向 #

1. 挂载参数验证

   • 当前使用async挂载选项，异步IO在高负载下可能因队列溢出触发资源不可用错误，可临时切换为sync测试是否缓解
   • actimeo=30的缓存过期时间较短，密集读场景下可尝试增大至60或120，减少元数据刷新频率与存储交互压力
   • 检查是否缺少hard挂载选项：默认soft挂载遇到错误会直接返回失败，添加hard可让系统自动重试IO操作

2. CSI驱动版本与日志分析

   • 确认Azure Files CSI驱动版本与Kubernetes 1.26.x兼容，旧版本可能存在高负载IO处理BUG
   • 收集CSI节点驱动日志定位底层错误：

     kubectl logs -n kube-system -l app=csi-azurefile-node
     

     搜索Resource temporarily unavailable相关条目，排查是否存在连接重置、元数据锁冲突等问题

3. Azure Files性能阈值检查

   • Premium_LRS文件共享有IOPS和吞吐量限制：30Ti容量的最大IOPS为10000，吞吐量为1000MiB/s。使用iostat在Pod内监控实际负载：

     iostat -x 1 60
     

     若负载接近阈值，需考虑性能扩容或负载拆分

4. 节点资源与调度检查

   • 确认错误Pod是否集中在特定节点，排查节点的网络带宽、磁盘IO是否存在瓶颈
   • 验证节点对同一文件共享的并发连接数：单节点连接数有限制，过多Pod共享挂载可能触发资源限制

解决方案建议 #

1. 调整挂载选项
   修改StorageClass的mountOptions，替换异步挂载并添加重试机制：

   mountOptions:
   - hard
   - mfsymlinks
   - actimeo=60
   - nosharesock
   - sync
   

   更新StorageClass后，重新创建PVC和Pod应用新配置

2. 升级CSI驱动
   按照AKS标准流程，将Azure Files CSI驱动升级至对应Kubernetes版本的最新兼容稳定版

3. 优化负载分布

   • 将ML训练任务分散到更多节点，降低单节点对Azure Files的并发连接压力
   • 把常用训练数据缓存到Pod本地临时存储（如emptyDir使用节点SSD），减少远程存储依赖

4. 性能扩容
   若负载超出当前SKU阈值，可将StorageClass的skuName调整为Premium_ZRS等更高性能选项，或拆分大存储共享为多个小共享分配给不同任务组

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