Engineering · 2 min read
兩種通往遠端 DB 的通道：Cloud SQL Auth Proxy vs kubectl port-forward
連上遠端 DB 的兩種通道：Cloud SQL Auth Proxy（走 Admin API + IAM）與 kubectl port-forward（走 kubeconfig）。同樣落在 localhost，走的 auth 路徑不同。
同樣是本地 port → 遠端 DB的結果，但走兩條不同的 auth 路徑：
| Cloud SQL Auth Proxy | kubectl port-forward | |
|---|---|---|
| 適用 | managed Cloud SQL instance | 任何跑在 k8s pod／svc 裡的 DB |
| 定位方式 | project:region:instance | namespace + svc/pod |
| Auth 路徑 | Cloud SQL Admin API + IAM（ADC／service account） | 你的 kubeconfig（GKE 憑證） |
| 加密 | 到 instance 的臨時 TLS 通道 | 經 k8s API server 的通道 |
| Client 看到的 | 純 localhost TCP（原生 wire protocol） | 一樣 |
Client 永遠只對 127.0.0.1:PORT 講正常的 DB 協定；通道是透明的，client 不知道中間隔了一層。
這次的實例： Postgres／MySQL 走 cloud_sql_proxy（Admin API）；ClickHouse 跑在 GKE 裡，所以走容器化的 kubectl port-forward——這也是為什麼只有它需要先做一次性的 gcloud container clusters get-credentials。
兩條通道 auth 路徑不同，但 client 端看到的都是
127.0.0.1:PORT上的原生 DB 協定。
參考來源
- Cloud SQL Auth Proxy — https://cloud.google.com/sql/docs/postgres/sql-proxy
- Cloud SQL Auth Proxy demystified — https://engineering.sada.com/cloud-sql-auth-proxy-demystified-54dd803d1474
- cloud-sql-proxy (GitHub) — https://github.com/GoogleCloudPlatform/cloud-sql-proxy