AzureFiles存储PVC绑定Pod数量上限及挂载失败问题咨询

首先针对你第一个问题：Azure Files存储后端PVC绑定的Pod数量确实存在上限，这个上限主要来自两方面：

1. Azure Files本身的并发连接限制 #

Azure Files的SMB共享有明确的并发连接数限制：

• 标准存储账户（GPv2）下的文件共享：默认最大并发SMB连接数为1000个
• 高级存储账户（FileStorage）下的文件共享：最大并发SMB连接数可达16000个

每个挂载了Azure Files PVC的Pod，至少会占用一个SMB连接，实际场景中可能因为连接复用、会话保持等因素，有效可用连接数会略低于标称值。

2. Kubernetes节点的挂载限制 #

除了Azure端的限制，Kubernetes节点本身对挂载的Azure Files数量也有限制：

• Linux节点默认每个节点最多挂载100个Azure Files共享
• Windows节点的默认限制会更高，但同样存在上限

如果你的集群节点数量较少，大量Pod集中在少数节点上，可能先触发节点级的挂载限制，导致新Pod无法完成挂载。

接下来分析你遇到的800个Pod卡在ContainerCreating状态、仅60个运行的问题：
从你提供的错误日志timeout expired waiting for volumes to attach/mount来看，大概率是触发了Azure Files的并发连接上限。当共享的连接数接近或达到最大值时，新的Pod尝试挂载会因为无法获取新的SMB连接而超时，最终卡在ContainerCreating状态。

建议的解决方案和排查步骤： #

• 检查Azure Files共享类型与连接数指标
  登录Azure Portal，找到对应的存储账户和文件共享，查看SMB客户端连接数指标，确认是否已经接近或达到1000（标准共享）或16000（高级共享）的上限。
• 升级到高级文件共享
  如果当前使用的是标准GPv2共享，考虑升级到FileStorage类型的高级共享，大幅提升并发连接上限，这是最直接解决大规模Pod挂载的方案。
• 拆分文件共享
  创建多个Azure Files共享，将PVC分散绑定到不同的共享上，分摊每个共享的连接数压力。比如将1000个Pod的PVC分散到10个标准共享，每个共享只承载100个Pod的连接，远低于1000的上限。
• 调整节点挂载限制或增加节点数量
  如果是节点级挂载限制导致的问题，可以考虑：
  1. 增加集群节点数量，分散Pod的分布，减少单个节点的挂载数量
  2. 对于Linux节点，可以修改kubelet配置（--max-volume-mounts参数）提升挂载上限，但此操作需要重启kubelet，且需评估节点资源承载能力
• 排查Pod分布与PVC配置
  使用kubectl get pods -o wide查看运行中Pod的节点分布，确认是否集中在少数节点；同时检查所有PVC的配置，确认是否都指向同一个Azure Files共享。

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