默认情况下，在创建AKS集群时正在为该集群创建服务主体。
然后服务主体可以在其他Azure资源(VM?)的级别上设置，以便它们能够建立网络连接并能够通信(当然一般网络设置除外)
我真的不确定，不能理解什么时候需要，什么时候不需要。例如，如果我在VM级别上有db，我是否需要授予AKS服务主体对VM的访问权限，以便能够通过网络与之通信?
谁能给我提供一些指导，而不是一般的文档。什么时候需要在其他Azure资源的级别上使用/设置它，什么时候不需要?对此我找不到适当的解释。谢谢你
关于您关于DB的问题，则不需要为服务主体提供对该VM的任何访问权限。假设数据库运行在Kubernetes之外，不需要以任何方式访问该VM。数据库甚至可以在不同的数据中心或完全托管在另一个云提供商上，只要防火墙等允许流量，在kubernetes中运行的应用程序仍然能够与它通信。
我知道你没有要求通用文档，但是Kubernetes Service Principals的文档很好地说明了这一点:
要与Azure api交互，AKS集群需要AzureActive Directory (AD)服务主体或受管身份。一个需要动态创建服务主体或托管标识并管理其他Azure资源，如Azure负载平衡器或容器注册(ACR).
换句话说，服务主体是Kubernetes集群在与其他Azure资源交互时进行身份验证的标识，例如:
- Azure容器注册表:创建容器的映像必须来自某个地方。如果将自定义映像存储在私有注册中心，则必须授权集群从注册中心提取映像。如果私有注册中心是Azure容器注册中心，则必须授权服务主体进行这些操作
- 网络:Kubernetes必须能够动态配置路由，并为负载均衡器中的服务注册外部IP。同样，服务主体被用作标识，因此它必须被授权
- Storage:访问磁盘资源并将它们挂载到pod
- Azure容器实例:如果您正在使用虚拟kubelet动态地向您的集群添加计算资源，Kubernetes必须允许在ACI上管理容器。
要委派对其他Azure资源的访问权限，您可以使用Azure cli在特定范围内将角色分配给一个受让人:
az role assignment create --assignee <appId> --scope <resourceScope> --role Contributor
下面是使用
的所有集群身份权限的详细列表