#Alauda Service Mesh v2.1 已知问题

本节记录影响 Alauda Service Mesh 的已知问题和限制。

#FIPS-enabled 集群不支持 Ambient 模式

配置为强制实施联邦信息处理标准（FIPS）的集群目前与 Istio Ambient 模式不兼容。如果您的环境需要符合 FIPS 要求，应继续使用 sidecar 模式部署服务网格。预计未来版本将解决 FIPS-enabled 集群对 Ambient 模式的支持问题。

#Ambient 模式下 Kiali tracing 集成无法正常工作

使用 Istio Ambient 模式时，Kiali 可能无法查询分布式 tracing，并且会生成指向 tracing 后端（例如 Jaeger）的错误链接。这是因为用于查询 tracing 的服务名称与 Ambient 模式部署中 tracing collector 记录的实际服务名称不匹配。

根本原因是 Istio Ambient 模式生成 tracing 的方式发生了变化。在 Ambient 模式下，waypoint proxy 生成的 tracing 使用的服务命名约定不同于 Kiali 的预期。因此，Kiali 无法找到对应的 tracing，tracing 链接会指向不存在的服务。

解决方法：直接使用 Jaeger UI 查询和查看分布式 tracing，或等待包含此修复的未来 Kiali 版本升级。

已在以下版本修复：Kiali v2.22.0。此修复在 external_services.tracing 下引入了 use_waypoint_name 配置选项，使 Kiali 能够在 Ambient 模式 tracing 中正确解析服务名称。

参考：kiali/kiali#9158

#多集群服务网格不支持 IPv6 负载均衡器 IP

在多集群（主集群/远程集群）部署中，Istio Helm Chart 仅识别 global.remotePilotAddress 配置参数中的 IPv4 地址。如果提供 IPv6 地址（例如 2001:db8::1），istio-discovery 中的 EndpointSlice 模板将无法正确渲染，导致 Istio 安装失败。

此限制源于 Helm Chart 模板中的正则表达式模式，该模式仅验证 IPv4 点分十进制表示法，未考虑 IPv6 十六进制冒号分隔格式。

解决方法：为 remotePilotAddress 使用 IPv4 地址或 DNS 主机名，而不是 IPv6 字面量。

已修复于：此修复已合并到上游 Istio master 分支，并将在未来的 Istio 版本中包含。

参考：istio/istio#58646

#Ambient 模式不支持 kube-ovn underlay 网络

Ambient 模式仅支持 kube-ovn overlay 网络。在 kube-ovn underlay 网络中，节点和 pod 位于不同的子网，针对已加入 Ambient 模式的 pod 执行的每个 kubelet HTTP 或 TCP 探针都会超时。随后，持续运行 liveness 或 readiness 探针的 pod 会被终止并进入 CrashLoopBackOff，而未配置探针的 pod 不受影响。

istio-cni 节点代理会将 kubelet 探针的源地址转换（SNAT）为一个特意设置的不可路由地址（IPv4 使用 169.254.7.127，IPv6 使用 fd16:9254:7127:1337:ffff:ffff:ffff:ffff），以便 pod 将这些探针与其他主机流量区分开来。此机制假设探针不会离开节点，而这在 overlay 网络中成立。在 underlay 网络中，探针会经过物理网关进行路由，而物理网关没有返回 SNAT 地址的路由，因此 pod 的响应会被丢弃。IPv4 和 IPv6 的行为相同，且与 CPU 架构无关。

解决方法：在 kube-ovn underlay 网络中使用 sidecar 模式。sidecar 模式会重写 pod 规范中的探针，不依赖主机 SNAT，因此不受此问题影响。