Flux Terraform控制器无法识别正确Terraform状态求助

问题概述 #

使用Flux Terraform控制器（搭配GitHub Provider）时，控制器无法识别已存在的Terraform S3后端状态，持续尝试重新创建已存在的资源，最终执行失败。尝试使用configPath指向本地状态配置文件时，触发Kubernetes配置加载错误。

配置信息 #

Flux Terraform CR配置 #

apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
metadata:
  name: saas-github
  namespace: flux-system
spec:
  interval: 2h
  approvePlan: "auto"
  workspace: "prod"
  backendConfig:
    customConfiguration: |
      backend "s3" {
        bucket                      = "my-bucket"
        key                         = "my-key"
        region                      = "eu-west-1"
        dynamodb_table              = "state-lock"
        role_arn                    = "arn:aws:iam::11111:role/my-role"
        encrypt                     = true
      }
  path: ./terraform/saas/github
  runnerPodTemplate:
    metadata:
      annotations:
        iam.amazonaws.com/role: pod-role
  sourceRef:
    kind: GitRepository
    name: infrastructure
    namespace: flux-system

本地可正常工作的状态配置（state.config） #

bucket         = "my-bucket"
key            = "infrastructure-github"
region         = "eu-west-1"
dynamodb_table = "state-lock"
role_arn       = "arn:aws:iam::111111:role/my-role"
encrypt        = true

错误信息（使用configPath时） #

Failed to initialize kubernetes configuration: error loading config file couldn't get version/kind; json parse error

已排查点 #

• 本地与runner pod均运行Terraform 1.3.1版本
• runner pod内生成的generated_backend_config.tf与本地配置一致，.terraform/terraform.tfstate指向正确S3存储桶
• 日志中出现的hashicorp/github与integrations/github双重Provider安装警告，本地执行时也存在，排除该因素影响

解决方案建议 #

1. 修正后端配置的Key值
   注意到本地状态配置的key是infrastructure-github，但CR配置中的key是my-key，两者不匹配会导致控制器加载的状态为空，进而认为资源未创建。将CR中backendConfig.customConfiguration内的key修改为infrastructure-github，与本地一致。

2. 正确使用configPath字段
   configPath字段用于指定Kubernetes ConfigMap/Secret的路径，而非本地Terraform配置文件。控制器会尝试加载带有apiVersion和kind字段的Kubernetes资源格式文件，因此直接指向本地state.config会触发解析错误。
   若需通过配置文件管理后端参数，应将HCL格式的后端配置存储在Kubernetes Secret/ConfigMap中，然后通过backendConfig.secretRef或backendConfig.configMapRef引用。

3. 验证Runner Pod权限
   确认runner pod绑定的IAM角色pod-role具备S3桶的读取权限（获取状态文件）以及DynamoDB锁表的读写权限，避免因权限不足导致状态加载失败。

4. 手动验证状态加载
   进入runner pod，手动执行以下命令确认状态是否能正常读取：

   terraform init
   terraform state list
   

   对比控制器执行日志，确认状态加载流程是否一致。

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