#Alauda Service Mesh v2.2 known issues

This section documents known issues and limitations that affect Alauda Service Mesh.

#Kiali reports a stale KIA1313 validation for waypoint-enabled workloads

In ambient mode, the workload detail page can keep reporting the validation KIA1313 - This workload has annotated waypoint but it does not exist or is misconfigured after the waypoint is deployed and running. The workload list page does not report the warning for the same workload, so the two views disagree.

This occurs when the Kiali server starts before the waypoint exists, for example when you install Kiali, deploy an application, and then enroll it in ambient mode. Kiali caches waypoint lookups for four minutes, so the validation is computed while the cache is still empty. Its change detection tracks namespace and workload labels, but not the result of the waypoint lookup, so the stored validation is never recomputed and the detail page keeps serving the outdated result.

Workaround: Restart the Kiali server to rebuild the cache and the stored validations:

kubectl -n istio-system rollout restart deployment/kiali

Changing any tracked value, such as adding a label to a namespace or a workload, also triggers a full revalidation.

Confirm that the waypoint is healthy before you dismiss the warning, because the same validation is raised when a waypoint is genuinely missing or misconfigured.

#Ambient mode does not work on a kube-ovn underlay network

Ambient mode supports kube-ovn overlay networking only. On a kube-ovn underlay network, where nodes and pods are on different subnets, every kubelet HTTP or TCP probe against an enrolled pod times out. Pods that keep a liveness or readiness probe running are then killed and enter CrashLoopBackOff, while pods without a probe are unaffected.

The istio-cni node agent SNATs kubelet probes to a deliberately non-routable address (169.254.7.127 for IPv4, fd16:9254:7127:1337:ffff:ffff:ffff:ffff for IPv6) so that a pod can tell them apart from other host traffic. This assumes the probe never leaves the node, which holds for overlay networking. On an underlay network the probe is routed through the physical gateway, which has no route back to the SNAT address, so the pod response is dropped. The behavior is the same for IPv4 and IPv6 and does not depend on the CPU architecture.

Workaround: Use sidecar mode on a kube-ovn underlay network. Sidecar mode rewrites the probes in the pod specification and does not rely on host SNAT, so it is not affected.