解读

面试官真正想考察的是：

1. 你是否理解 Cloud SQL 跨区域复制 的底层链路（跨区域只读实例、外部只读副本、专用网络路径）。
2. 你是否能把 Chaos Mesh 的网络混沌能力 映射到这条链路上，而不是“随便打延迟”。
3. 你是否能在 国内云环境合规 的前提下落地（IaaS 层网络不可控、VPC 对等/专线带宽有限、出口 IP 收敛）。
4. 你是否具备 可观测 + 可回滚 的意识，敢做“可灰度、可观测、可应急”的混沌实验。

一句话：不是“怎么打延迟”，而是“怎么精准、安全、合规地打延迟，还能量化对 Cloud SQL 业务的影响”。

知识点

1. Cloud SQL 跨区域架构

   • 跨区域只读实例：主实例在 Region A，只读实例在 Region B，Google 托管 VPC 对等 + 内部高带宽通道。
   • 外部只读副本：通过公网 SSL 隧道拉取，延迟受出口带宽、Google Front End 调度影响。
   • Private Service Connect / VPC 对等：国内用户常用“专线 + Cloud Router”收敛出口，延迟瓶颈在最后一公里专线。

2. Chaos Mesh 网络混沌模型

   • NetworkChaos：delay、loss、duplicate、corrupt、bandwidth。
   • target selector：支持 pod、label、namespace、ip、port 五元组。
   • externalTargets：可填 GCP 出口网段，但需先收敛到国内可路由的 CIDR（否则把全集群打挂）。

3. 国内合规限制

   • IaaS 层网络不可控：无法直接在宿主机 tc/iptables 注入，必须走 Kubernetes CNI。
   • 出口 IP 收敛：Cloud SQL 看到的源 IP 是 NAT 网关或专线网关，Chaos Mesh 只能打到网关后 Pod 的源 IP 段。
   • 灰度审计：金融、政企客户要求实验记录可审计，Chaos Mesh 需对接 Argo + Workflow + S3 兼容日志存储（如 OSS）。

4. 可观测闭环

   • 延迟指标：Cloud SQL 自带 replication lag（seconds_behind_master / pg_stat_replication）。
   • 业务指标：应用层 QPS、P99 响应、订单超时率。
   • 混沌指标：Chaos Mesh 的 event 审计日志 与 Grafana 插件（开源版需自己写 exporter）。

答案

分五步落地，每一步都给出可落地的 YAML 片段与国内踩坑提示，面试时可直接口述关键字段。

1. 收敛目标网段
   在 GCP 侧把 Cloud SQL 跨区域通道的对端 IP 段收敛到一条 /28（如 172.25.16.0/28），并在国内云侧通过 Cloud Router 自定义路由 宣告。
   目的：让 Chaos Mesh 的 externalTargets 只填 8 个 IP，避免误伤。

2. 建立专用混沌命名空间

   apiVersion: v1
   kind: Namespace
   metadata:
     name: cloud-sql-chaos
     labels:
       chaos-mesh.tencent.com/allowed: "true"
   

   国内腾讯云 TKE、阿里云 ACK 均强制开启 PodSecurityPolicy，必须给 chaos-daemon 加 SYS_ADMIN、NET_ADMIN 的 PSP。

3. 编写延迟实验

   apiVersion: chaos-mesh.org/v1alpha1
   kind: NetworkChaos
   metadata:
     name: cloud-sql-cross-region-delay
     namespace: cloud-sql-chaos
   spec:
     action: delay
     mode: all
     selector:
       namespaces:
         - prod-app
       labelSelectors:
         app: order-service   # 只打访问 Cloud SQL 的 Pod
     delay:
       latency: "120ms"
       jitter: "30ms"
       correlation: "100"
     duration: "10m"
     scheduler:
       cron: "@every 2h"
     direction: to
     externalTargets:
       - "172.25.16.0/28"
   

   关键解释：

   • latency=120ms 模拟北京→香港专线抖动均值。
   • correlation=100 保证每次包都延迟，方便压测。
   • direction=to 只影响出站，避免把回包也加倍，导致 RTT 翻倍到 240 ms。

4. 观测与熔断
   在实验 YAML 里加 workflow 与 prometheusProbe：

   - name: check-replication-lag
     type: prometheusProbe
     probe:
       endpoint: http://monitoring.alibaba-cloud.com:9090
       query: mysql_slave_lag_seconds{instance="cloud-sql-ro"}
       comparator:
         operator: ">"
         value: "5"
       timeout: 60s
       stopOnFailure: true
   

   一旦只读实例延迟 >5 s，Workflow 自动 kubectl delete NetworkChaos，实现熔断。

5. 审计与回滚
   实验结束自动上传 event 日志到 OSS bucket，文件名带 chaos-id+timestamp，方便等保审计。
   回滚时只需 删除 NetworkChaos 对象，tc 规则由 chaos-daemon 自动清理，无需重启 Pod。

面试收尾金句：
“整套方案把 Cloud SQL 跨区域复制链路 抽象成可路由的 /28 网段，用 Chaos Mesh 的 externalTargets + prometheusProbe 做精准延迟注入与熔断，既满足国内专线收敛的合规要求，又能在10 分钟内可灰度、可观测、可回滚。”

拓展思考

1. 如果客户用的是 Cloud SQL SQL Server 外部副本（依赖 Windows 库），Chaos Mesh 只能打到 Linux Pod，如何间接模拟？
   思路：在 NAT 网关前加一台 Linux 透明代理（Envoy + TPROXY），把 Chaos Mesh 打到代理 Pod，再把延迟透传到 Windows 副本，实现跨 OS 混沌。

2. 国内双栈（IPv6）专线逐步普及，Chaos Mesh 1.x 只支持 IPv4，如何升级？
   可贡献社区 PR，在 tc qdisc 层加 skb->protocol 判断，支持 inet6_skb，面试时可展示开源贡献意识。

3. 混沌实验通过等保 3 级测评，需要 4A 平台对接，如何把 Chaos Mesh 的 RBAC 事件同步到 客户堡垒机？
   方案：用 Kubernetes audit webhook → Kafka → Flink → 客户 4A API，实现实时审计链。面试时提到“已落地 POC”可大幅加分。