解读

在国内混合云或金融云场景下，企业常把 Istio 作为统一服务网格，但 Cloud SQL 的公网域名（如 *.googleapis.com）会被默认拦截。面试官想确认两点：

1. 你是否理解 Cloud SQL 在中国大陆的接入方式（公网 IP、Private Service Connect、Cloud SQL Auth Proxy）；
2. 能否用 Istio Egress Gateway 把出口流量统一收口，满足审计、限速、证书透明等合规要求，同时避免 Sidecar 直接访问公网带来的“逃逸”风险。
   回答时要体现“先收口、再分流、最后容灾”的三段式思路，并给出落地时与国内专线、备案、日志审计的衔接细节。

知识点

• Cloud SQL 在中国只有公网 endpoint（无国内 VPC 内网 IP），需通过 Cloud SQL Auth Proxy 或 Private Service Connect 回包。
• Istio Egress Gateway 本质是一个独立 Deployment，运行在 istio-system 命名空间，通过 Gateway + VirtualService + DestinationRule 三元组把出口流量先劫持到 Gateway，再转发到外部。
• SNI 路由：Cloud SQL 的 TLS 握手会携带 *.googleapis.com 的 SNI，Gateway 必须透传，否则 Google 前端会返回 421 Misdirected Request。
• 国内合规要求：所有出公网流量需经过企业级防火墙，并留存 6 个月日志；Egress Gateway 需开启 Envoy ALS 或 SkyWalking 对接国内审计系统。
• 证书信任：Google 证书根 CA “GTS Root R1” 必须加入 Gateway 的 cacerts Secret，否则 TLS 握手失败。
• 高可用：Gateway 至少 2 副本跨可用区，配合 PodDisruptionBudget 与 HorizontalPodAutoscaler，防止单点导致全集群数据库不可用。

答案

1. 创建专用命名空间
   kubectl create namespace cloudsql-egress

2. 准备 Google 根证书
   下载 GTS Root R1，命名为 google-ca.crt，并创建 Secret：
   kubectl -n istio-system create secret generic google-sql-ca
   --from-file=google-ca.crt

3. 定义 Egress Gateway
   在 istio-system 下部署 Gateway：
   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
   name: cloudsql-egress-gw
   namespace: istio-system
   spec:
   selector:
   istio: egressgateway
   servers:

   • port:
     number: 443
     protocol: HTTPS
     hosts:
     • "*.googleapis.com"
       tls:
       mode: ISTIO_MUTUAL

4. 配置 Sidecar 劫持
   apiVersion: networking.istio.io/v1beta1
   kind: Sidecar
   metadata:
   name: default
   namespace: cloudsql-egress
   spec:
   egress:

   • hosts:
     • "istio-system/*"
     • "*.googleapis.com"

5. 定义 VirtualService 把流量先送到 Gateway
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
   name: direct-cloudsql-through-egress-gw
   namespace: cloudsql-egress
   spec:
   hosts:

   • "*.googleapis.com"
     gateways:
   • mesh
   • istio-system/cloudsql-egress-gw
     http:
   • match:
     • gateways:
       • mesh
         route:
     • destination:
       host: istio-egressgateway.istio-system.svc.cluster.local
       port:
       number: 443
   • match:
     • gateways:
       • istio-system/cloudsql-egress-gw
         route:
     • destination:
       host: "*.googleapis.com"
       port:
       number: 443
       timeout: 30s

6. 配置 DestinationRule 做 TLS origination
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
   name: originate-tls-for-cloudsql
   namespace: istio-system
   spec:
   host: "*.googleapis.com"
   trafficPolicy:
   portLevelSettings:
   - port:
   number: 443
   tls:
   mode: SIMPLE
   caCertificates: /etc/istio/google-ca.crt

7. 国内合规加固

   • 在 Gateway Deployment 注入 istio-proxy 环境变量 ISTIO_META_DNS_CAPTURE=false，防止 DNS 污染。
   • 开启 Envoy ALS，把 access log 送到 Kafka + Elasticsearch，保留 180 天。
   • 通过 NetworkPolicy 仅允许 Gateway Pod 出公网，其余 Pod 全部拒绝。

8. 灰度验证
   在业务 Pod 内执行：
   curl -v https://<PROJECT_ID>:<REGION>:<INSTANCE_ID>-sql.googleapis.com
   返回 200 且日志中出现 egressgateway 侧 IP，即收口成功。

拓展思考

• 如果企业已拉 Google Cloud 中国专线（Partner Interconnect），可把 Gateway 的 externalTrafficPolicy 改为 Local，让流量直接走专线 VIP，减少 30 ms 延迟。
• 当 Cloud SQL 实例开启 Private IP（通过 PSC 穿透到国内 VPC）时，可再建一套 Internal Egress Gateway，用 istio-io/internal-gateway 标签区分，实现“公网/私网”双栈出口，满足金融级分区容灾。
• 未来若 Google 在中国大陆上线 Cloud SQL 专有域名（如 *.cloudsql.cn），只需在 VirtualService 里新增一条 host 匹配，无需重启 Gateway，即可实现 0 中断切换。