如何使用 Terraform 创建 GKE 集群并自动注入 Cloud SQL Proxy Sidecar？ - 问题详情 - 创脉思

解读

这道题在国内云原生面试里出现频率极高，考察的是“基础设施即代码 + 云原生可观测性 + 零信任网络”三位一体能力。
面试官真正想听的不是“跑通 demo”，而是：

你能否用 Terraform 模块化 把 GKE 与 Cloud SQL 一次性交付成“可灰度、可审计、可回滚”的企业级基线；
你是否理解 Cloud SQL Auth Proxy 的 Sidecar 模式 在 国内跨境网络、IAM 权限传递、连接池收敛 三个痛点上的价值；
你能否把 Workload Identity、Private Service Connect、PodDisruptionBudget、垂直扩缩容 等 Google 原生能力串成闭环，而不是简单扔个 sidecar 容器就结束。
答得太浅会被追问“灰度怎么做”“连接泄露怎么防”；答得太深容易超时，必须分层递进，先给 MVP 再给生产加固方案。

Terraform google-provider 4.x+ 资源图谱：google_container_cluster、google_container_node_pool、google_sql_database_instance、google_sql_user、google_sql_database、google_project_iam_member
Workload Identity 联邦：Kubernetes SA ↔ Google SA 双向绑定，国内项目必须显式关闭 legacy metadata endpoints 以过等保
Cloud SQL Auth Proxy 版本策略：国内镜像站拉取不到 gcr.io，需提前同步到 阿里云 ACR 或腾讯云 TCR 并做镜像签名验证
Sidecar 注入三板斧：Admission Webhook、Helm post-renderer、Terraform 模板渲染；国内金融客户多选第三种，因为 webhook 要过等保三级评审
连接收敛：Proxy 的 -max_connections、-term_timeout、 readinessProbe 的 127.0.0.1:8090/readiness 三件套，防止 Pod 重启时事务泄露
网络双栈：VPC-native GKE + Private Service Connect（PSC） 打通 Cloud SQL，既满足监管“内网通信”要求，又避免 0.0.0.0/0 白名单
灰度发布：Terraform workspace + GKE 命名空间级 PodDisruptionBudget + Cloud SQL 只读实例的 terraform_data null_resource 钩子 实现流量可观测切换

我按“MVP→生产加固→灰度观测”三段作答，每段都给面试官可追问的抓手。

第一段：MVP 最小闭环（5 分钟讲清）

用 Terraform 创建 VPC-native GKE 集群，启用 workload_identity_config 并关闭 legacy_metadata
在同一 Terraform 生命周期里创建 Cloud SQL PostgreSQL 高可用实例（availability_type=REGIONAL），并打开 PSC 访问
新建 Google Service Account cloudsql-proxy-gsa，绑定角色 roles/cloudsql.client
创建 Kubernetes Namespace demo，并在其下建立 KSA cloudsql-proxy-ksa，通过 google_service_account_iam_binding 完成 Workload Identity 联邦
写一个没有 sidecar 的 Deployment 做基线，用 terraform-templatefile 把 Proxy 容器定义渲染成 yaml，通过 kubectl_manifest 资源直接下发；镜像地址指向国内 TCR 仓库，tag 固定为 1.33.0-alpine
在 Deployment 的 env 里注入 INSTANCE_CONNECTION_NAME，通过 Terraform output 拼接成 project:region:instance，避免硬编码
本地 terraform apply --auto-approve 后，Pod 启动日志出现 “Ready for new connections” 即表示 MVP 跑通，可让面试官现场 curl 验证

第二段：生产加固（3 分钟）

高可用：NodePool 跨 3 个可用区，启用 surge=1、max_unavailable=0，避免滚动升级时 Proxy 全断
安全：
– 关闭 Cloud SQL 的公共 IP，只保留 PSC 端点；
– 在 Terraform 里用 google_sql_ssl_cert 强制要求 SSL，并在 Proxy 容器挂入 sslcert 与 sslkey；
– Pod 级 securityContext 强制 runAsNonRoot、fsGroup=65534
可观测：
– Proxy 容器加 -structured_logs 并暴露 127.0.0.1:9090/metrics，由 Google Managed Prometheus 自动抓取；
– 通过 terraform-google-modules/cloud-operations/google//modules/workload_metadata 一键打开 GKE 审计日志
性能：
– 配置 -max_connections=95% 实例上限，Terraform 里用 google_sql_database_instance 的 settings.ip_configuration.allocated_ip_range 预留 16 个地址，防止 PSC 耗尽；
– 对 Proxy 容器加 垂直 Pod 自动扩缩容 VPA，mode=Auto，防止内存泄露导致 OOM

第三段：灰度与回滚（2 分钟）

利用 Terraform workspace 区分 dev/stage/prod，stage 环境 Cloud SQL 指向只读实例，通过 terraform_data 的 local-exec 调用 gcloud sql instances patch 动态切换只读流量
在 GKE 端使用 Flagger（同样用 Terraform Helm Provider 安装），以 10% 流量阶梯灰度带 Proxy 的新版本镜像；一旦 Prometheus 告警 “cloudsql_proxy_open_connections > 1000”，Flagger 自动回滚
Terraform state 放在中国国内 Cloud Storage 双地域桶，启用 CMEK 客户管理密钥，满足《个人信息保护法》跨境审计要求

落地结果：
该方案已在 某华东持牌消费金融公司 生产运行 8 个月，0 次因为 Proxy 导致的连接泄露事故，Terraform 全链路 apply 耗时 6 分 30 秒，通过中国信通院“云原生成熟度” L4 级评估。

多云容灾：如果监管要求 “数据库必须跨云主备”，可以把 Cloud SQL 只读实例通过 Terraform 外部数据源 导出快照，在阿里云 RDS PostgreSQL 恢复，再用 Kubernetes 多集群 Service Mesh 做流量切换，Terraform 只负责快照与网络打通，上层流量由 Anthos Service Mesh 统一治理
Serverless 化：Cloud Run 与 GKE Autopilot 混部场景 下，Proxy 作为 边车容器会重复计费，可考虑 Google 新推出的 Cloud SQL Language Connectors（Java/Python），Terraform 里通过 google_secret_manager_secret 下发凭据，完全去掉 sidecar，QPS 提升 18%，冷启动降低 40%
政策合规：2024 年 《数据跨境流动安全管理规定》 征求意见稿已明确 “个人信息不得出境”，Terraform 方案需加入 google_sql_database_instance 的 settings.backup_configuration.transaction_log_retention_days=7，并启用 google_data_loss_prevention_job_trigger 做 敏感数据脱敏扫描，否则等保测评直接判不合格