在Atlantis中通过Terraform local-exec配置KUBECONFIG环境变量失败求助

Let's break down the core issue first: each local-exec provisioner runs in its own isolated subshell. When you run export KUBECONFIG=~/.kube/azurek8s in the second provisioner, that environment variable only exists within that specific subshell process. By the time the third provisioner runs env, it's a completely new shell session—so the variable you set earlier is gone entirely.

Worse, even if you could get the variable to show up in the env check, it wouldn't help with your Pod/Helm deployments because Terraform itself doesn't inherit these subshell variables. Let's fix this with a few practical, reliable approaches:

1. Combine All Commands in a Single local-exec #

If you just want to verify the variable is set, run all your commands in one shell session so the environment variable persists through the sequence:

resource "null_resource" "kubeconfig_setup" {
  provisioner "local-exec" {
    command = <<-EOT
      # Use -raw to get unquoted kubeconfig output (no need for sed!)
      terraform output -raw kube_config > ~/.kube/azurek8s
      export KUBECONFIG=~/.kube/azurek8s
      # Now env will show the variable since we're in the same shell
      env | grep KUBECONFIG
    EOT
  }
}

Note: I replaced the sed step with terraform output -raw—this flag outputs the raw, unquoted value of the kube_config output, so you don't need to delete the first/last lines anymore.

2. Specify KUBECONFIG Directly in Commands (For Kubectl/Helm) #

For actual deployments, the most reliable way is to skip setting the environment variable entirely and pass the kubeconfig path directly to your commands:

resource "null_resource" "deploy_resources" {
  provisioner "local-exec" {
    command = <<-EOT
      terraform output -raw kube_config > ~/.kube/azurek8s
      # Pass kubeconfig directly to kubectl
      kubectl get nodes --kubeconfig=~/.kube/azurek8s
      # Same for Helm
      helm install my-app ./my-chart --kubeconfig=~/.kube/azurek8s
    EOT
  }
}

This avoids any shell environment inconsistencies entirely.

3. Use Terraform's Kubernetes Provider (No Manual Kubeconfig Needed) #

If you're using Terraform to manage Kubernetes resources directly, you don't need to mess with local kubeconfig files at all. Instead, feed the AKS credentials directly into the Kubernetes provider:

# Fetch your AKS cluster outputs (adjust the backend/config to match your setup)
data "terraform_remote_state" "aks_cluster" {
  backend = "local"
  config = {
    path = "../aks-deployment/terraform.tfstate"
  }
}

provider "kubernetes" {
  host                   = data.terraform_remote_state.aks_cluster.outputs.kube_config.host
  client_certificate     = base64decode(data.terraform_remote_state.aks_cluster.outputs.kube_config.client_certificate)
  client_key             = base64decode(data.terraform_remote_state.aks_cluster.outputs.kube_config.client_key)
  cluster_ca_certificate = base64decode(data.terraform_remote_state.aks_cluster.outputs.kube_config.cluster_ca_certificate)
}

# Now you can define Kubernetes resources directly in Terraform
resource "kubernetes_pod" "example" {
  metadata {
    name = "example-pod"
  }
  spec {
    container {
      image = "nginx:latest"
      name  = "nginx"
    }
  }
}

This is the cleanest approach for Terraform-managed Kubernetes resources, as it eliminates manual credential handling entirely.

Key Takeaway #

Never rely on export in separate local-exec steps—each runs in its own shell. Instead, either combine commands, pass the kubeconfig path directly, or use Terraform's native provider integration for Kubernetes.

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