Service Mesh Migration und Co-Existence

Sidecar → Ambient (Istio)

Per Namespace, umkehrbar: bei L7-Bedarf Waypoint deployen und per istio.io/use-waypoint aktivieren, dann Label istio.io/dataplane-mode=ambient, Injection-Label entfernen, zuletzt kubectl rollout restart. Vorher VirtualService → HTTPRoute, L7-AuthorizationPolicy per targetRefs an den Waypoint. Mit L7-Policies kein Zero-Downtime: zwischen Löschen und Neuanlage greifen sie nicht. Sidecar-Clients umgehen den Waypoint, EnvoyFilter geht dort nicht.

mTLS-STRICT-Migration

Istio: PERMISSIVE, dann prüfen: reporter="destination", connection_security_policy!="mutual_tls" muss 0 sein, erst dann STRICT.

Linkerd: Default all-unauthenticated, Ziel all-authenticated per config.linkerd.io/default-inbound-policy; wirkt erst beim Pod-Neustart.

Cilium (ztunnel): kein Permissive-Modus, Verkehr zwischen enrollten und nicht enrollten Pods geht nicht. Kommunikationspartner gemeinsam enrollen.

Kuma: MeshTLS mit mode: Permissive, dann Strict.

Ohne Prüfschritt (Istio) brechen Jobs, externe Health-Checks, Legacy-Clients.

Tool-Wechsel

Co-Existence im selben Cluster ist möglich, schmerzhaft: unterschiedliche Pod-Labels, getrennte Namespaces, kein Mesh-zu-Mesh-mTLS. In der Praxis: das neue Mesh in neuen Namespaces einführen, Workloads namespace-weise migrieren, das alte Mesh am Ende entfernen.