AKS配置Azure File StorageClass后PVC Pending，提示无法获取存储账户密钥

核心报错现象 #

创建PVC后资源始终处于Pending状态，卷 provision 流程返回如下失败日志：

Failed to provision volume with StorageClass "xxxxxxxxxxx": could not get storage key for storage account yyyyyyyyyyy: could not get storage key for storage account yyyyyyyyyyy: Retriable: false, RetryAfter: 0s, HTTPStatusCode: 400, RawError: Retriable: false, RetryAfter: 0s, HTTPStatusCode: 400, RawError: azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to http://localhost:7788/subscriptions/zzzzzzzzzzz-aaaaaa-bbbbbb/resourceGroups/MC_kkkkkkkkkkkkkkkkkkkk/providers/Microsoft.Storage/storageAccounts/yyyyyyyyyyyyyyy/listKeys?api-version=2019-06-01: StatusCode=400 -- Original Error: adal: Refresh request failed. Status Code = '400'. Response body: {"error":"unauthorized_client","error_description":"AADSTS700016: Application with identifier 'aaaaaa-bbbbbbbb-cccccccccccccccc' was not found in the directory 'ppppppppppp-aaaaaaaaaaaa-tttttttttttt'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.

已完成的基础校验项 #

以下基础配置均已人工核对确认无误：

• 使用的Azure登录账户、关联订阅与目标AKS集群匹配
• 报错中提及的存储账户在Azure资源列表中实际存在
• 存储账户与AKS集群处于同一区域，所属资源组与集群托管节点组完全匹配

现有资源配置 #

自定义StorageClass清单 #

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: xxxxxxxx
provisioner: kubernetes.io/azure-file
parameters:
  skuName: Standard_LRS
  storageAccount: yyyyyyyyyyyy
  resourceGroup: MC_zzzzzzzzzzzzzzzzz

待绑定PVC清单 #

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: xxxxxxxx
  resources:
    requests:
      storage: 5Gi 

根因定位与修复步骤 #

报错核心为kube-controller-manager组件的Azure认证身份配置异常，并非StorageClass/PVC本身的参数配置错误。日志中出现的AADSTS700016错误，本质是集群用来调用Azure API拉取存储账户密钥的服务主体/托管标识，配置的所属租户与实际租户不匹配，或是对应的身份已被从租户中删除、权限被回收。
排查修复按以下顺序执行：

• 核对云认证配置的一致性
  提取日志中报错的应用ID（即字符串aaaaaa-bbbbbbbb-cccccccccccccccc），在当前关联的Azure AD租户的应用注册列表中全局检索：如果完全检索不到该应用，说明对应身份已被删除；如果检索到但和配置的租户ID不匹配，说明身份配置存在跨租户错误。
• 分场景调整认证配置
  1. 若集群为旧版使用服务主体认证的模式：检查controller-manager启动参数中写入的租户ID，确认是否在集群升级、资源迁移过程中被误修改；如果服务主体已被删除，重新创建具备对应存储组读取权限的服务主体，更新到集群的云凭证配置中即可。
  2. 若集群为新版使用托管标识认证的模式：检查MC托管资源组下的系统分配托管标识是否被意外删除；如果集群开启了Workload Identity能力，同步核对身份映射规则配置，确认不会出现身份注入错误。
• 修复后验证流程
  无需重新创建PVC或StorageClass，等待controller-manager自动重新触发卷 provision 流程即可。通过集群事件列表查看PVC的关联事件流，确认能够正常拉取存储账户密钥、完成Azure文件共享的创建流程。

操作提示 #

• 日常使用Lens类工具管理集群时，可直接在事件面板查看PVC的关联事件，重点关注provision控制器返回的原始调用日志，不要仅依赖PVC本身的状态字段判断问题原因。
• 日志中请求地址为本地代理地址http://localhost:7788，说明认证失败发生在集群内的云配置代理层，与存储账户的公网连通性、防火墙规则无关。

内容的提问来源于stack exchange，提问作者Diego Rafael Souza