Kubernetes Service Mesh — Multi-Cluster mit Istio

In diesem 165-Minuten-Modul verlasst ihr den einzelnen Cluster, auf dem der Vorgängerkurs euer Mesh aufgebaut hat, und baut es über zwei Cluster hinweg neu auf. Ihr startet mit der Entscheidung, die vor jedem Kommando steht: Multi-Primary – jeder Cluster betreibt seine eigene, vollständige Control-Plane (istiod), was Hochverfügbarkeit und kürzere Latenz zur nächsten Control-Plane bringt – oder Primary-Remote – nur ein Cluster betreibt istiod, der zweite liefert ausschließlich Workloads und spart dafür die komplette Control-Plane-Ressourcen ein. Für das Hands-on baut ihr zwei eigenständige kind-Cluster auf – bewusst ohne die Pod-Netze der beiden Cluster routingfähig zu machen, wie es das GitOps-Aufbaumodul zum Cluster-Generator noch vermieden hat: Hier ist die fehlende direkte Pod-zu-Pod-Erreichbarkeit über Cluster-Grenzen hinweg der eigentliche Ausgangspunkt, denn genau das macht Istios East-West-Gateway zum zentralen Baustein statt zu einem optionalen Detail: Ein pro Cluster installiertes, öffentlich erreichbares Gateway auf Port 15443 mit AUTO_PASSTHROUGH-TLS leitet jeden Cross-Cluster-Request an den richtigen Sidecar weiter, ohne dass ein einziges Anwendungs-Byte unverschlüsselt das eigene Netzwerk verlässt. Bevor die beiden Cluster sich gegenseitig vertrauen, baut ihr eine gemeinsame Root-CA mit je einer Intermediate-CA pro Cluster auf – per OpenSSL und dem offiziellen Istio-Makefile, real ausführbar ohne jeden Cluster-Zugriff – und spielt sie als cacerts-Secret in beide Cluster ein: Erst danach vertrauen sich die Envoy-Sidecars beider Cluster gegenseitig für mTLS, statt zwei isolierte, sich fremde Zertifikatsketten zu betreiben. Mit beiden Clustern im Multi-Primary-Modus und aktivem East-West-Gateway verifiziert ihr Cross-Cluster-Service-Discovery an einer über beide Cluster verteilten Demo-Anwendung, und baut zum Abschluss die eigentliche Pointe des Moduls: ein gewichtetes Cross-Cluster-Traffic-Splitting mit denselben VirtualService-/ DestinationRule-Objekten, die ihr aus dem Istio-Vorgängerkurs bereits kennt – nur dass die Subsets, zwischen denen gesplittet wird, diesmal auf zwei verschiedenen Clustern laufen, ohne dass sich an der Objekt-Syntax irgendetwas ändert. Ein kurzer Ausblick ohne eigenes Hands-on rundet ab: die Primary-Remote-Topologie als ressourcensparende Alternative, wenn nicht jeder Cluster seine eigene Control-Plane rechtfertigt. Voraussetzung ist das Modul “Kubernetes Service Mesh — Traffic-Management mit Istio” (Pflicht) – Sidecar-Modell, VirtualService/DestinationRule und mTLS gelten als bekannt und werden hier nicht wiederholt, nur über die Cluster-Grenze hinweg angewendet. Empfohlen zusätzlich “Kubernetes Service Mesh Observability — Kiali & der Service-Graph”, weil ihr den Cross-Cluster-Traffic aus Hands-on 4 damit visuell statt nur per curl-Auszählung nachvollziehen könnt. Die Session läuft komplett lokal über zwei kind-Cluster (Kubernetes-in-Docker) mit MetalLB für LoadBalancer-Support, ohne Cloud-Account und ohne Kostenwirkung.