Terraform部署AKS时service_principal相关技术问题咨询

1. 修改Service Principal Client Secret导致Pod重建的原因 #

AKS集群的Service Principal（SP）是节点kubelet组件访问Azure云资源的核心凭据，用于拉取ACR镜像、挂载Azure存储卷、管理虚拟网络等操作。当修改SP的client_secret时，AKS需要将新凭据同步到所有节点的kubelet配置中。

为保障集群可用性，AKS会对节点池执行滚动更新：逐个删除旧节点、创建配置了新凭据的节点。节点被删除时，其上的Pod会被驱逐并调度到新节点，最终表现为所有Pod逐个删除重建。

2. 忽略Service Principal变更对AKS集群的影响 #

添加以下配置后，Terraform会忽略SP配置的变更，不会将本地代码中的SP信息同步到云端AKS集群：

lifecycle {
  ignore_changes = [
    service_principal,
  ]
}

• 若云端SP的client_secret过期或失效，而Terraform未同步更新，节点kubelet将无法访问Azure资源，引发Pod镜像拉取失败、存储卷挂载异常等问题，直接影响集群正常运行。
• 该配置仅适合临时规避SP变更触发的滚动更新，操作后需手动通过Azure控制台或CLI更新AKS的SP凭据，之后务必移除该配置，保证Terraform状态与云端一致。
• 长期使用会导致Terraform状态与实际集群配置脱节，增加运维风险，不建议长期保留。

3. AKS集群部署是否必须使用Service Principal #

不是必须的，AKS支持两种身份验证方案：

• Service Principal（SP）：传统方式，需手动创建并配置权限，适合需要精细权限管控的场景。
• Managed Identity（托管身份）：Azure提供的托管凭据，无需手动管理secret，Azure自动轮换凭据，安全性更高、运维更简单，是当前官方推荐的方式。

专业建议 #

• 优先选择系统托管身份部署AKS，避免手动管理SP的secret过期、轮换等问题，降低运维复杂度和安全风险。
• 若必须使用SP，建议将secret存储在Azure Key Vault中并配置自动轮换，Terraform中直接引用Key Vault的secret，避免硬编码敏感信息。
• 更新SP的client_secret时，建议在业务低峰期操作，利用AKS滚动更新特性保障业务连续性，同时避免长期使用ignore_changes忽略配置差异。

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