解读

在国内金融、运营商、政务云等落地场景中，CouchDB 常被用作“离线优先”业务的核心存储，同一套业务往往拆成多命名空间（Namespace）部署：例如“离线-生产”ns、“在线-灾备”ns、“测试”ns。跨命名空间复制（x-ns-replication）既涉及 CouchDB 自身的多主复制协议，又依赖 Kubernetes 的ServiceEntry、Sidecar、NetworkPolicy等流量治理对象。
Kiali 作为 Istio 官方的可观测控制台，默认只呈现 HTTP/gRPC 的“服务-到-服务”拓扑，不会把 CouchDB 的_replicate 端点自动识别成“复制流量”。因此候选人必须回答“如何让 Kiali 看见这条流”，而不是“如何在 CouchDB 里看复制”。面试官想确认两点：

1. 你是否理解 Istio 指标缺什么；
2. 你是否能把 CouchDB 的特殊语义映射成 Istio 可识别的信号，并落地到国内常见的“命名空间隔离+ sidecar 注入”环境。

知识点

1. CouchDB 复制本质：对目标库发起 POST /{db}/_replicate，请求体带 source、target、continuous 等字段，返回 202 即建立长连接，后续流量走普通 5984 端口。
2. Istio 指标维度：istio_request_total、istio_tcp_sent_bytes_total 等，缺“复制”语义；需要利用 Prometheus 的 recording rule 或 Kiali 的“自定义边标签”能力，把_replicate 端点打上 replication=true 标签。
3. 跨命名空间流量在 Kiali 的呈现条件：
   a. 两个 ns 的 Pod 都被注入 sidecar；
   b. 有ServiceEntry显式声明外部 CouchDB 服务，或跨 ns Service被 Federation 方案暴露；
   c. 有Telemetry V2的 EnvoyFilter 把路径或请求头映射成 Kiali 可识别的“操作名”。
4. 国内安全合规：金融客户要求 mTLS 必须开启，且复制流量需走国密双证书通道；Kiali 的边颜色需按“安全—非安全”区分，候选人应知道在 Kiali 的 Graph 设置里勾选“Security”层。
5. 实战套路：
   • 在源 CouchDB 端注入 sidecar，给 outbound 5984 流量打上“replication”标签；
   • 在目标端同样注入，确保 inbound 流量能被统计；
   • 用 Prometheus 录制规则：
     couchdb_replication_bytes = sum(rate(istio_tcp_sent_bytes_total{replication="true"}[5m])) by (source_workload_namespace, destination_workload_namespace)
   • 在 Kiali 的“Edge Labels”里勾选“tcp sent”，并自定义“replication”标签，即可在拓扑图上看到跨命名空间的紫色箭头，旁边显示实时字节速率。
6. 排障经验：若 Kiali 无箭头，优先检查PeerAuthentication是否强制 mTLS 导致 5984 被 Envoy 拒绝，再检查NetworkPolicy是否未放行 5984。

答案

第一步：确保两个命名空间下的 CouchDB 实例均已注入 Istio sidecar，并在 PeerAuthentication 中设置 STRICT 模式以满足国内合规。
第二步：在源命名空间创建ServiceEntry，把目标命名空间的 CouchDB 服务以 FQDN 形式声明出来，例如
couchdb-dr.apps.svc.cluster.local，端口 5984，协议 TCP；同时给该 ServiceEntry 打上 app=couchdb-replication 标签。
第三步：在源端部署的 CouchDB 复制任务中，把 target URL 写成上述 FQDN，并在 HTTP 头里加入自定义头 X-Replication: true。
第四步：编写 EnvoyFilter，匹配 X-Replication: true，把 Envoy 的 request_operation 动态设为 “_replicate”，这样 Kiali 会把该流识别为独立操作。
第五步：在 Prometheus 侧增加 recording rule：
couchdb_replication_bytes = sum(rate(istio_tcp_sent_bytes_total{request_operation="_replicate"}[5m])) by (source_workload_namespace, destination_workload_namespace)
第六步：打开 Kiali Graph，选择“Namespaces”为 All，勾选“Edge Labels”→“tcp sent”与“Security”，并在“Display”里启用“Operation Nodes”。此时即可看到从源 ns 到目标 ns 的紫色箭头，边上实时显示复制流量字节速率；若 mTLS 开启，箭头带锁图标，符合国内安全审计要求。
第七步：若需告警，可在 Alertmanager 中针对 couchdb_replication_bytes 设置阈值，例如 5 分钟速率归零即触发“CouchDB 跨命名空间复制中断”告警，并对接企业微信或飞书。

拓展思考

1. 如果客户要求零信任，不允许 TCP 直联，必须走 Istio 的 HTTP 代理，如何把 CouchDB 的连续 _changes feed 转成 gRPC stream？
2. 当复制流量超过 1 Gbps 时，Envoy sidecar 的 CPU 增幅明显，国内大厂通常采用eBPF 旁路加速或Ambient Mesh模式，你如何改造以上方案以保证 Kiali 仍能看见流量？
3. 在多集群联邦场景（如北京主集群+上海灾备集群），跨集群复制需通过Istio East-West Gateway，Kiali 默认不显示跨集群边，你是否知道用 kiali.io/api-spec 注解把远程集群的 Prometheus 聚合到同一 Kiali 实例，从而画出真正的“跨命名空间+跨集群”复制拓扑？