Netzwerk im Cluster sauber planen: WZ-IT plant und betreibt Kubernetes-Netzwerke mit CNI, Network Policies, Gateway API, DNS und TLS. Netzwerk und Secure Access ansehen
Ein Service Mesh verlegt Verschlüsselung, Zugriffsregeln, Traffic-Steuerung und Metriken zwischen Services aus dem Anwendungscode in die Infrastruktur. Das lohnt nur, wenn eine dieser Aufgaben im Cluster tatsächlich offen ist, denn jedes Mesh bringt eine zusätzliche Datenebene, eigene Releases und eigene Fehlerbilder mit. Dieser Artikel klärt zuerst, wann ein Mesh entfällt, und vergleicht danach Istio (Sidecar und Ambient), Linkerd und Cilium Service Mesh anhand der Projektdokumentation. Stand: 28. Oktober 2026.
Inhaltsverzeichnis
- Brauchen Sie überhaupt ein Service Mesh?
- Die drei Kandidaten
- Vergleich auf einen Blick
- Ressourcenbedarf laut Projekt
- Betriebsrisiken mit Quelle
- Gateway API und Mesh
- Entscheidungstabelle
- Ohne Mesh anfangen
- Stand und Methodik
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Brauchen Sie überhaupt ein Service Mesh?
Die Cilium-Dokumentation fasst die Aufgaben eines Mesh so zusammen: resiliente Verbindungen über Cluster-Grenzen, L7-aware Traffic-Steuerung, identitätsbasierte Sicherheit sowie Observability, alles transparent für die Anwendung (Cilium: Service Mesh). In der Praxis laufen sie auf fünf Aufgaben hinaus, die sich teilweise ohne Mesh lösen lassen:
| Aufgabe | Ohne Mesh | Mesh nötig, wenn |
|---|---|---|
| Verschlüsselung und Authentisierung zwischen Pods | Cilium verschlüsselt den Verkehr zwischen Cilium-verwalteten Endpunkten transparent mit IPsec oder WireGuard, als Beta auch mit ztunnel (Doku) | der Nachweis gegenseitiger Authentisierung je Workload gefordert ist |
| Zugriff begrenzen | NetworkPolicy auf Pod-Ebene | Regeln nach Identität, HTTP-Methode oder Pfad nötig sind |
| Routing und Canary | Gateway API am Cluster-Rand (Gateway API vs. Ingress) | auch der Verkehr zwischen Services gesteuert werden muss |
| Metriken | Hubble bei Cilium-CNI, Instrumentierung in der Anwendung | einheitliche Request-Metriken für viele Services ohne Codeänderung fehlen |
| Retries und Timeouts | Client-Bibliothek der Anwendung | Resilienz für alle Services und Sprachen zentral gelten soll |
Unsere Einordnung: Ein Mesh ist begründet, wenn mindestens eine Zeile der rechten Spalte zutrifft und die Alternative mehr kostet. Eine Mindestzahl an Services nennen wir nicht, weil der Bedarf von Anforderungen abhängt, nicht von der Zahl der Deployments. Trifft keine Zeile zu, entfällt das Mesh; Ohne Mesh anfangen beschreibt den Weg.
Die drei Kandidaten
Istio: Sidecar und Ambient
Istio besteht aus der Control Plane istiod und einer Datenebene in zwei Modi (Sidecar oder Ambient). Im Sidecar-Modus läuft seit 2017 ein Envoy-Proxy in jedem Pod. Im Ambient-Modus übernimmt ein in Rust geschriebener ztunnel pro Node (DaemonSet) mTLS, L4-Autorisierung und L4-Telemetrie. L7-Funktionen liefern optionale Waypoint-Proxies auf Envoy-Basis, die getrennt von den Anwendungen installiert, aktualisiert und skaliert werden (Ambient-Überblick). Eine mit Ambient-Unterstützung installierte Istio-Umgebung heißt in der Dokumentation "Ambient Mesh". Der Modus ist seit Istio 1.24 (November 2024) General Availability (Istio-Blog). Aktuell ist Istio 1.31.3 vom 22. Oktober 2026 (Release); eine Minor-Version erhält Support bis sechs Wochen nach Erscheinen der übernächsten (Support-Policy).
Grenzen von Ambient laut Migrationsleitfaden: VM-Workloads können nicht beitreten, SPIRE als Zertifikatsquelle ist nicht unterstützt, EnvoyFilter gilt nicht auf Waypoints, und VirtualService ist dort Alpha, vorgesehen ist HTTPRoute.
Linkerd: Lizenz- und Release-Modell
Linkerd nutzt einen Rust-Micro-Proxy als Sidecar in jedem Pod (Architektur), seit Version 2.20 standardmäßig als Native Sidecar Container (Ankündigung 2.20). mTLS ist für TCP-Verkehr zwischen gemeshten Pods standardmäßig aktiv (Automatic mTLS).
Beim Release-Modell gilt: Seit Linkerd 2.15 (Februar 2024) stellt das Open-Source-Projekt keine Stable-Release-Artefakte mehr bereit, das übernimmt die Anbieterlandschaft (Ankündigung 2.15). Als Distribution führt die Release-Seite nur Buoyant Enterprise for Linkerd (BEL). Das Projekt veröffentlicht weiter Edge-Releases (aktuell edge-26.10.1) und nennt sie in der Regel produktionsreif. Im Open-Source-Plan fehlen laut Buoyant-Preisseite Stable-Releases mit Semantic Versioning und CVE-Remediation-SLAs. BEL ist zum Testen frei, Unternehmen mit weniger als 50 Mitarbeitenden dürfen es produktiv nutzen; darüber hinaus bietet Buoyant die Pläne Premium und Strategic an. Beträge nennt die Seite nicht (Abruf 28.10.2026).
Cilium Service Mesh
Cilium ist zuerst ein CNI mit eBPF-Datenpfad. Die Mesh-Funktionen kommen dazu: Gateway API, GAMMA, L7-Policy über einen Envoy pro Node (Gateway API), Sichtbarkeit über Hubble und transparente Verschlüsselung. Die gegenseitige Authentisierung über SPIFFE und SPIRE ist in der Dokumentation für 1.20 als Beta gekennzeichnet; die Punkte "Per-connection handshake" und "Integrate with WireGuard" stehen auf TODO, und Cluster in einem Cluster Mesh sind nicht kompatibel (Mutual Authentication). Cilium zeigt standardmäßig L3/L4-Ereignisse; L7-Sichtbarkeit entsteht über L7-Regeln in einer CiliumNetworkPolicy, die den Verkehr zugleich einschränken (Visibility). Aktuell ist Cilium 1.20.4 vom 23. Oktober 2026 (Release).
Istio, Linkerd und Cilium im Vergleich
| Istio 1.31 | Linkerd 2.20 | Cilium 1.20 | |
|---|---|---|---|
| Datenebene | Envoy-Sidecar je Pod oder ztunnel je Node plus optionale Waypoints | Rust-Sidecar je Pod | eBPF im Kernel plus Envoy je Node |
| mTLS | Stable; im Ambient-Modus zwischen Mesh-Workloads immer erzwungen | Standard für TCP zwischen gemeshten Pods | Mutual Authentication Beta; transparente Verschlüsselung getrennt per WireGuard oder IPsec; die ztunnel-Variante mit L4-mTLS ist ebenfalls Beta |
| L7-Steuerung | voller Umfang, im Ambient-Modus nur mit Waypoint | Routing, Retries, Timeouts, Circuit Breaking, Rate Limiting | GAMMA und L7-Policy über Envoy |
| Metriken | L7 per Sidecar oder Waypoint, L4 per ztunnel | HTTP- und TCP-Metriken per Proxy (Prometheus) | Hubble, L7 nur mit L7-Regeln |
| Mehrere Cluster | Beta laut Feature-Status; Ambient nur Multi-Primary | Multicluster mit gemeinsamem Trust Anchor | Cluster Mesh, nicht kompatibel mit Mutual Authentication |
| Gateway API und GAMMA | konform als Ingress und Mesh | HTTPRoute und GRPCRoute als Konfiguration, nicht in der Konformitätsliste | konform als Ingress und Mesh, nur Producer Routes |
| Code-Lizenz | Apache-2.0 | Apache-2.0 | Apache-2.0 (BPF-Code GPL-2.0 oder BSD-2-Clause) |
| CNCF-Status | Graduated seit 12.07.2023 (CNCF) | Graduated seit 28.07.2021 (CNCF) | Graduated seit 11.10.2023 (CNCF) |
| Voraussetzung | Kubernetes 1.32 bis 1.37; Ambient braucht den Istio-CNI-Node-Agent | Kubernetes bis 1.35 | Kernel ab 5.10, auf RHEL 8.10 ab 4.18 (Systemvoraussetzungen) |
Die Einstufung zu Gateway API stammt aus der Implementierungsliste: Dort stehen unter "Service Mesh Implementation Status" als konform Cilium und Istio, Linkerd ist nicht aufgeführt.
Zum Reifegrad von Istio Multicluster widersprechen sich zwei Istio-Seiten: Der Feature-Status führt "Multicluster Mesh" und für Ambient "Multi-network multicluster" als Beta, die Seite zu den Datenebenenmodi nennt den Sidecar-Modus "Stable, including multi-cluster". Die Tabelle folgt dem Feature-Status, weil er den Reifegrad je Funktion ausweist. Für Ambient gilt laut Installationsanleitung: Beta, nur Multi-Primary und nur Multi-Network.
Ressourcenbedarf laut Projekt
Aktuelle CPU- und Speicherzahlen mit offengelegter Messmethode haben wir nur bei Istio gefunden. Für Version 1.24 nennt die Performance-Seite bei 1.000 HTTP-Requests pro Sekunde mit 1 KB Payload:
| Komponente | CPU | Speicher | Skaliert mit |
|---|---|---|---|
| Sidecar (2 Worker-Threads) | etwa 0,20 vCPU | etwa 60 MB | Zahl der Pods |
| Waypoint (2 Worker-Threads) | etwa 0,25 vCPU | etwa 60 MB | Zahl der Waypoint-Deployments |
| ztunnel | etwa 0,06 vCPU | etwa 12 MB | Zahl der Nodes |
Die Latenz (p90/p99) beziffert Istio in der Gegenüberstellung der Modi mit 0,63 bis 0,88 ms für Sidecars, 0,16 bis 0,20 ms für Ambient und 0,40 bis 0,50 ms mit Waypoint. Die Latenzdiagramme der Performance-Seite entstanden auf einem Bare-Metal-Cluster mit Flannel bei 500 bis 1.500 Requests pro Sekunde und aktivem mTLS; andere Hardware liefert andere Werte. Für Linkerd führt das Projekt-Blog zwei Gegenüberstellungen mit Istio: eine von 2021 mit CPU-, Speicher- und Latenzwerten, vor Istios Ambient Mode (Benchmark 2021), und eine vom 24. April 2025 mit Istio Ambient, die nur Latenzen bei 20, 200 und 2.000 Requests pro Sekunde auf GKE ausweist (Benchmark 2025). Beide stammen von Linkerd-Seite und sind nicht herstellerneutral. In der Cilium-Dokumentation zu Service Mesh, Gateway API, GAMMA und Verschlüsselung (1.20) haben wir keine Ressourcenzahlen für die Mesh-Funktionen gefunden. Ein Vergleich der drei braucht deshalb einen Test mit dem eigenen Workload.
Betriebsrisiken mit Quelle
Istio
- Ambient mit L7-Funktionen braucht Waypoint-Proxies, also zusätzliche Envoy-Deployments, die getrennt installiert, aktualisiert und skaliert werden (Überblick).
- Auf Cilium als CNI braucht Ambient
cni.exclusive=false; BPF-Masquerading wird nicht unterstützt, und eine Default-Deny-Policy blockiert die Kubelet-Health-Probes, bis eine CiliumClusterwideNetworkPolicy sie freigibt (Plattform-Voraussetzungen). Bei k3s mit mitgeliefertem CNI ist das Plattform-Flagglobal.platform=k3snötig, bei einem eigenen CNI wie Cilium stattdessen die CNI-Pfade. - Ambient-Migration mit L7-Policies hat ein Fenster ohne Durchsetzung dieser Regeln, bis die Waypoint-Policies greifen (Migration).
Linkerd
- Der von
linkerd installerzeugte Trust Anchor läuft nach 365 Tagen ab und muss manuell erneuert werden, oder er wird selbst mit längerer Laufzeit erzeugt. Das Issuer-Zertifikat läuft ebenfalls nach einem Jahr ab, seine Rotation lässt sich mit cert-manager automatisieren. Multicluster verlangt einen gemeinsamen Trust Anchor (Automatic mTLS). - Linkerd 2.20 nennt Gateway API 1.2.1 bis 1.5.1 als kompatibel und warnt vor schwer zu debuggenden Fehlern bei anderen Versionen (Gateway API). Cilium 1.20 nennt Gateway API 1.6.3. Wer beide betreibt, prüft die CRD-Version gegen beide Tabellen.
Cilium
- Gateway API und GAMMA verlangen den Kube-Proxy-Ersatz (
kubeProxyReplacement=true); GAMMA unterstützt nur Producer Routes, keine Consumer Routes (GAMMA). - Cilium und Istio gemeinsam: L7-Policy nur in einem von beiden Systemen einsetzen, sonst drohen laut Cilium-Dokumentation Split-Brain-Effekte (Integration mit Istio).
Gateway API und Mesh
Die GAMMA-Initiative konfiguriert Mesh-Routing mit denselben Routen wie den Ingress, indem eine HTTPRoute an einen Service statt an ein Gateway gebunden wird. Istio führt "Gateway APIs for mesh" im Feature-Status als Stable, Cilium unterstützt nur Producer Routes, Linkerd nutzt HTTPRoute und GRPCRoute für Policies, Timeouts und Routing. Wer die Gateway API am Rand einführt, arbeitet im selben Routing-Format, das Istio-Waypoints und Linkerd für Mesh-Routing verwenden. Den Hintergrund liefert Gateway API vs. Ingress.
Entscheidungstabelle
| Ausgangslage | Naheliegende Wahl | Grenze |
|---|---|---|
| Keine der fünf Aufgaben ist offen | kein Mesh: Gateway API, NetworkPolicy, bei Bedarf transparente Verschlüsselung | Anforderungen regelmäßig neu prüfen |
| Cilium ist CNI; gebraucht werden L7-Routing am Rand und Sichtbarkeit | Cilium Gateway API und Hubble, kein zweites Mesh | mTLS-Identitätsnachweis nur mit Beta-Funktion |
| mTLS mit Identität, kleines Team, nur Kubernetes | Linkerd | Release-Modell klären: BEL-Lizenz oder Edge-Releases |
| Breiter Funktionsumfang, Multi-Cluster, VirtualService-Konfigurationen im Bestand | Istio im Sidecar-Modus | größter Konfigurationsumfang (VirtualService, Gateway API, Waypoints); Multicluster laut Feature-Status Beta |
| Neues Mesh, zunächst nur mTLS und L4-Policy, keine VMs | Istio Ambient mit ztunnel, Waypoints erst bei L7-Bedarf | Multicluster Beta |
| Istio-Sidecars im Betrieb, Ressourcen- oder Neustartlast | Migration auf Ambient je Namespace | L7-Policy-Fenster einplanen |
Istio oder Linkerd? Beide liefern mTLS, L7-Routing und Metriken und binden auch Nicht-Kubernetes-Workloads an (Istio im Sidecar-Modus, Linkerd über Mesh Expansion seit 2.15). Linkerd nennt operative Einfachheit als Ziel (Ankündigung 2.20); seine Datenebene besteht laut Architekturdokumentation aus Sidecar-Proxies. Istio bietet zusätzlich den Ambient-Modus mit ztunnel und Waypoints. Dafür steht bei Linkerd die Frage nach dem Bezug von Stable-Releases und bei Istio die Konfigurationsbreite. Die Tabelle ist unsere Einordnung aus den genannten Quellen, kein Benchmark.
Ohne Mesh anfangen
- Gateway API am Rand: HTTPRoutes mit Gewichten für Canary-Releases, TLS am Gateway.
- Default-Deny je Namespace mit NetworkPolicy; der CNI-Vergleich steht in Cilium vs. Calico.
- Verschlüsselung per WireGuard bei Cilium als CNI, wenn Transportverschlüsselung gefordert ist.
- Sichtbarkeit über Hubble und Metriken aus den Anwendungen.
- Entscheidungspunkt: Trifft eine der Anforderungen aus dem ersten Abschnitt zu, startet ein Pilot in einem Namespace. Bei Istio Ambient genügt das Label
istio.io/dataplane-mode=ambientohne Neustart der Pods, bei Linkerd die Annotationlinkerd.io/injectmit anschließendem Rollout.
Im Sidecar-Modus akzeptiert ein Istio-Workload standardmäßig Klartext und mTLS (PERMISSIVE), ohne den Klartextverkehr zu authentisieren (mTLS-Migration); die Umstellung auf STRICT folgt, wenn alle Aufrufer im Mesh sind. Ambient erzwingt mTLS zwischen Mesh-Workloads immer (Migrationsleitfaden).
Stand und Methodik
Stand: 28.10.2026. Grundlage sind ausschließlich Primärquellen: die verlinkten Projektseiten (Istio, Linkerd, Buoyant, Cilium, Gateway API, CNCF) und die Kubernetes-Dokumentation, abgerufen am 28.10.2026. Versionen: Istio 1.31.3, Linkerd 2.20 (neuester Edge-Release edge-26.10.1), Cilium 1.20.4, Gateway API 1.6.3 laut GitHub-Releases. Die Ressourcenzahlen stammen von Istio für Version 1.24; die Latenzwerte der Istio-Seite zu den Datenebenenmodi nennen keine Version. Wir haben keine eigenen Messungen durchgeführt. Buoyant veröffentlicht keine Preise. Die Entscheidungstabelle und die Einordnung zu Beginn sind unsere Bewertung. Die beschriebenen Grenzen können sich mit neuen Releases ändern; die verlinkten Seiten gelten als maßgeblich.
Unser Vorgehen bei WZ-IT
Netzwerkplanung mit CNI, NetworkPolicies, Gateway API, DNS und TLS gehört zum Aufbau eines Kubernetes-Clusters bei WZ-IT (Netzwerk und Secure Access). Die ersten beiden Schritte aus Ohne Mesh anfangen, Gateway API am Rand und Default-Deny mit NetworkPolicies, liegen in diesem Rahmen. Den Betrieb des Clusters selbst beschreibt Managed Kubernetes.
Weiterführende Guides
- Gateway API vs. Ingress
- Cilium vs. Calico
- Von ingress-nginx zu Gateway API migrieren
- Kubernetes privat über NetBird erreichen
- Kubernetes-Lexikon: die wichtigsten Begriffe erklärt
Kubernetes-Netzwerk planen: Kubernetes Netzwerk und Secure Access umfasst CNI, Network Policies, Gateway API, DNS, TLS und privaten Zugriff.
Angebot zum Thema: Cilium und Network Policies
