为何已注册file.csi.azure.com驱动的AKS节点仍提示驱动未找到？

针对你遇到的AKS中GitLab Runner容器启动报错driver name file.csi.azure.com not found，但CSI驱动Pod正常运行的问题，可按以下步骤排查：

1. 确认Runner Pod与CSI驱动是否在同一节点 #

GitLab Runner的Pod可能被调度到了没有部署Azure File CSI驱动的Windows节点：

• 先获取Runner Pod所在节点：

  kubectl get pod runner-xxxx-project-821-concurrent-0-5cwua3fq -o jsonpath='{.spec.nodeName}'
  

• 检查该节点是否存在Azure File CSI驱动Pod：

  kubectl get pods -n kube-system -o wide | grep <获取到的节点名> | grep azurefile
  

如果没有匹配结果，说明Runner Pod调度到了无CSI驱动的节点。解决方法：

• 调整GitLab Runner的nodeSelector，指定只调度到部署了Azure File CSI驱动的Windows节点；
• 确保AKS集群中所有Windows节点都部署了csi-azurefile-node-win驱动。

2. 检查CSI驱动Pod的运行状态与日志 #

驱动Pod运行不代表驱动成功注册到kubelet，需查看驱动日志：

kubectl logs <csi-azurefile-node-win-xxx> -n kube-system -c csi-driver

重点排查是否有Failed to register driver、socket连接失败等异常信息。常见原因包括：

• 驱动Pod未正确挂载kubelet的CSI插件目录（Windows节点路径通常为C:\var\lib\kubelet\plugins）；
• 驱动版本与AKS集群版本不兼容，导致注册失败。

3. 验证存储类与卷配置正确性 #

• 检查所用StorageClass的Provisioner是否为file.csi.azure.com：

  kubectl describe sc <你的存储类名称>
  

  如果Provisioner不符，需修改StorageClass或调整GitLab Runner的PVC配置。
• 检查GitLab Runner的卷配置：确保在config.toml中定义的卷（如release-area-volume、sdk-volume）使用了正确的StorageClass，且挂载路径符合Windows容器格式（如C:\release-area而非/release-area）。

4. 排查Windows容器初始化错误 #

报错hcs::CreateComputeSystem init-permissions: The parameter is incorrect.通常与Windows容器的权限配置或命令兼容性有关：

• 检查init-permissions容器的命令是否适配Windows环境：比如避免使用Linux风格的bash命令，改用PowerShell语法；
• 确认卷的挂载路径在Windows容器中是合法路径，不存在特殊字符或权限冲突。

内容的提问来源于stack exchange，提问作者Mitten.O