Kiali项目中Ambient与Sidecar模式间mTLS连接显示问题分析

问题背景

在Istio服务网格环境中，Kiali作为可视化工具能够展示服务间的通信情况，包括安全连接状态。近期发现一个特殊场景下的显示异常：当使用Ambient模式的命名空间中的Pod访问启用Sidecar注入的命名空间中的服务时，虽然Ztunnel日志确认连接确实使用了mTLS加密，但Kiali的流量图中却未能正确显示为mTLS连接。

问题复现条件

该问题在以下配置环境下可稳定复现：

1. 两个全新的命名空间，未配置PeerAuthentication和NetworkPolicy
2. 命名空间A标记为istio.io/dataplane-mode=ambient（Ambient模式）
3. 命名空间B标记为istio-injection=enabled（Sidecar注入模式）
4. 在命名空间A中部署带有curl工具的Sleep Pod
5. 在命名空间B中部署Ratings服务
6. 从Sleep Pod向Ratings服务发起curl请求

现象分析

实际测试中观察到以下关键现象：

• 请求能够成功完成并返回响应
• Ztunnel日志明确显示连接使用了mTLS加密
• Kiali流量图中该连接未标记为mTLS
• 其他组合模式（Sidecar→Ambient、Ambient→Ambient、Sidecar→Sidecar）均能正确显示mTLS状态

技术影响

这个问题虽然不影响实际的通信安全（mTLS确实已建立），但会给运维人员带来以下困扰：

1. 监控可视化不准确，可能导致误判安全状态
2. 混合部署环境下的安全审计困难
3. 故障排查时增加额外确认步骤

解决方案进展

Kiali开发团队已确认该问题并计划在2.0版本中增强对Ambient模式的支持。建议用户：

1. 等待即将发布的Kiali 2.0正式版
2. 或提前使用最新的nightly构建版本进行验证

技术原理推测

从现象分析，这可能与Kiali的指标采集逻辑有关：

• Ambient模式下流量由Ztunnel处理，而Sidecar模式下由Envoy处理
• 两种模式可能生成不同类型的指标数据
• Kiali的指标聚合算法可能未完全适配这种混合场景

最佳实践建议

在问题修复前，运维人员可以：

1. 结合Ztunnel日志和Kiali图表进行综合判断
2. 在关键路径上配置明确的PeerAuthentication策略
3. 考虑暂时统一数据平面模式（全Sidecar或全Ambient）