Terraform中Kubernetes Provider依赖Azure AKS集群的正确配置方案

一、核心修复：延迟kubeconfig获取时机 #

Terraform Provider配置在plan阶段求值，直接引用azurerm_kubernetes_cluster的kubeconfig会导致集群重建时，plan阶段无法获取新集群的有效配置。通过以下步骤确保Provider在集群完全就绪后初始化：

1. 强制等待AKS集群就绪
   在azurerm_kubernetes_cluster资源中显式声明wait_for_cluster_ready = true（azurerm v3.106.0+建议显式设置，避免默认行为变更）：

resource "azurerm_kubernetes_cluster" "aks" {
  name                = "my-aks-cluster"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  node_resource_group = "my-aks-nodes"

  default_node_pool {
    name       = "default"
    node_count = 3
    vm_size    = "Standard_D2s_v3"
  }

  identity {
    type = "SystemAssigned"
  }

  # 确保Terraform等待集群所有组件就绪
  wait_for_cluster_ready = true
}

2. 用数据源延迟获取kubeconfig
   使用data "azurerm_kubernetes_cluster"数据源替代直接引用资源属性，数据源会在apply阶段执行，确保集群创建/重建完成后再拉取kubeconfig：

data "azurerm_kubernetes_cluster" "aks" {
  name                = azurerm_kubernetes_cluster.aks.name
  resource_group_name = azurerm_kubernetes_cluster.aks.resource_group_name

  depends_on = [azurerm_kubernetes_cluster.aks]
}

3. 配置Kubernetes Provider使用数据源内容
   通过config_raw直接传入数据源的原始kubeconfig，简化配置同时确保有效性：

provider "kubernetes" {
  config_raw = data.azurerm_kubernetes_cluster.aks.kube_config_raw
}

或者分字段配置（适合需要自定义认证的场景）：

provider "kubernetes" {
  host                   = data.azurerm_kubernetes_cluster.aks.kube_config.0.host
  client_certificate     = base64decode(data.azurerm_kubernetes_cluster.aks.kube_config.0.client_certificate)
  client_key             = base64decode(data.azurerm_kubernetes_cluster.aks.kube_config.0.client_key)
  cluster_ca_certificate = base64decode(data.azurerm_kubernetes_cluster.aks.kube_config.0.cluster_ca_certificate)
}

二、替代kubeconfig获取方式 #

如果上述方案仍有问题，可尝试以下两种替代路径：

1. Azure CLI生成kubeconfig文件 #

通过null_resource调用Azure CLI生成kubeconfig文件，再让Kubernetes Provider读取该文件：

resource "null_resource" "fetch_aks_credentials" {
  provisioner "local-exec" {
    command = "az aks get-credentials --name ${azurerm_kubernetes_cluster.aks.name} --resource-group ${azurerm_kubernetes_cluster.aks.resource_group_name} --file ${path.module}/aks-kubeconfig.yaml --overwrite-existing"
  }

  triggers = {
    # 集群重建时触发重新获取
    cluster_id = azurerm_kubernetes_cluster.aks.id
  }

  depends_on = [azurerm_kubernetes_cluster.aks]
}

provider "kubernetes" {
  config_path = "${path.module}/aks-kubeconfig.yaml"
}

注意：运行环境需已安装Azure CLI并完成身份验证（如本地已登录、CI环境配置了服务主体）。

2. 基于Azure CLI的exec认证 #

跳过kubeconfig文件，直接通过Azure CLI的exec流程完成K8s认证，无需管理kubeconfig内容：

provider "kubernetes" {
  host                   = azurerm_kubernetes_cluster.aks.kube_config.0.host
  cluster_ca_certificate = base64decode(azurerm_kubernetes_cluster.aks.kube_config.0.cluster_ca_certificate)

  exec {
    api_version = "client.authentication.k8s.io/v1beta1"
    command     = "az"
    args = [
      "aks", "get-credentials",
      "--name", azurerm_kubernetes_cluster.aks.name,
      "--resource-group", azurerm_kubernetes_cluster.aks.resource_group_name,
      "--file", "-",
    ]
  }
}

这种方式依赖Azure CLI自动处理令牌刷新，适合长期运行的自动化场景。

三、关键注意事项 #

• 资源依赖声明：所有Kubernetes资源（如kubernetes_deployment、kubernetes_service）必须添加depends_on = [azurerm_kubernetes_cluster.aks]，确保集群就绪后再执行K8s资源的创建/更新。
• 避免plan阶段冲突：不要在plan阶段提前引用K8s资源的属性，否则会因kubeconfig未就绪导致报错。
• 版本兼容性：确保使用azurerm v3.106.0+的最新版本，该版本对AKS就绪逻辑有优化，显式设置wait_for_cluster_ready = true可避免隐性问题。

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