在向Azure Kubernetes服务集群部署新作业和服务时，pod无法请求具有所有可用权限的有效AAD访问令牌。如果在部署之前或之后的同一天添加了新权限，则令牌仍然不会获取这些权限。到目前为止，在授予Active Directory组对密钥保管库、存储帐户和SQL数据库作用域的权限时，已发现此问题。
示例：我有一个.NET 5.0 C#API在3个pods上运行，每个pods的反关联规则位于一个单独的节点上。应用程序从SQL数据库中读取信息。我发布了一个版本，然后添加了数据库权限。到目前为止，我已经尝试过让应用程序重置访问令牌：
基本上创建了3个新pod的CCD_ 1由于权限不足而再次失败。
kubectl apply -f deployment.yaml部署在容器中运行的映像的新版本，再次所有3个pod都失败了。
CCD_ 3，然后是CCD_ 4以擦除旧的kubernetes对象并创建新的对象。这解决了2/3 pod上的问题，然而，第三个pod由于权限不足而不断失败。
kubectl delete namespace <namespace>以擦除具有所有可用配置的整个命名空间，并再次重新创建它。令人惊讶的是，又有2/3的pod在正确的权限下运行，而最后一个没有。
将权限添加到组后，命令运行了一个多小时。数据库令牌在24小时内处于活动状态，当我看到cronjobs出现此问题时，我不得不等待1天才能正确执行任务(上述步骤在cronjob场景中都不起作用(。令牌的有效性不断变化，这意味着pod正在请求新的访问令牌，再次排除最近添加的权限。我发现的唯一一个100%有效的解决方案是销毁集群并重新创建它，这在任何生产场景中都是不可行的。
在我的例子中，失败的pod总是在节点00上运行，这让我认为集群的第一个初始节点上可能有一个额外的缓存层。然而，我仍然不明白为什么其他2个pod运行时没有问题，也不明白如何重新启动我的pod或刷新访问令牌，以最大限度地缩短解决问题的等待时间。
Kubernetes版本：1.21.7。集群没有启用AKS管理的AAD或pod标识。所有RBAC都通过AD组授予群集MSI。
请检查以下内容是否可以在您的情况下解决。
要访问Kubernetes资源，您必须访问AKS集群、Kubernetesneneneba API和Kubernete对象。确保您是集群管理员或具有访问AKS集群的适当权限的用户你需要做的事情，如果你还没有：
-
在您现有的AKS集群上启用Azure RBAC，使用：
az-aks更新-g myResourceGroup-n myAKSCluster--启用azure rbac
创建允许读取访问所有其他播客和服务的角色：向用户添加必要的角色(Azure Kubernetes Service Cluster User Role、Azure Kuberneses Service RBAC Reader/Writer/Admin/Cluster Admin(。请参阅(Microsoft文档(。
另请检查故障排除
- 还要检查您是否需要；虚拟机贡献者"；以及包含pod的资源组的存储帐户贡献者，如果您错过了，请查看该pod中是否提到了命名空间。堆栈溢出引用。还要检查防火墙是否限制了对该吊舱中网络的访问
使用az-aks-get-credentials命令重置kubeconfig上下文可能会清除某些xyz用户以前缓存的身份验证令牌：
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing>参考
请检查以下其他参考：
- kubernetes-权限错误-堆栈溢出
- 为用户创建访问集群的角色分配|microsoft文档
- 用户无法访问启用了RBAC的AKS集群(github.com(
- kubernetes-堆栈溢出