Netzwerkarchitektur mit CNI & Service Mesh

In diesem Artikel behandeln wir die Wichtigkeit von Netzwerkmechanismen in Kubernetes für moderne Microservices und Cloud-native Architekturen, insbesondere in Bezug auf Optimierung und Sicherheit. Wir untersuchen CNI-Plugins und Service Meshes und bietet technisch versierten Lesern eine Analyse von Netzwerkoptionen sowie Best Practices zur optimalen Netzwerkarchitektur.

Für den Betrieb moderner und oft komplexer Microservices und Cloud-nativen Architekturen, wird das Verständnis von Netzwerkmechanismen in Kubernetes zunehmend wichtiger - nicht nur für die Optimierung, sondern auch für die Sicherheit.

In diesem Artikel tauchen wir in Kubernetes-Netzwerke ein und betrachten die verschiedenen Mechanismen, die für die Kommunikation in Kubernetes-Clustern verwendet werden. Wir werden dabei auf CNI-Plugins und ihre Rolle im Netzwerkmanagement eingehen, sowie auf Service Meshes, die erweiterten Funktionen wie Traffic Management, Fehlerbehandlung und Sicherheit bieten. Dabei richten wir uns an technisch versierte Leser, die bereits ein Grundverständnis für Kubernetes haben und nun ihre Kenntnisse im Bereich der Netzwerkinfrastruktur vertiefen möchten. 

Wir werden die verschiedenen Netzwerkoptionen und -lösungen detailliert untersuchen, Vor- und Nachteile abwägen und Best Practices sowie Entscheidungshilfen bieten, um die optimale Netzwerkarchitektur für unterschiedliche Anwendungsfälle zu wählen.

Für die interne Kommunikation zwischen Pods setzt Kubernetes standardmäßig auf den Service Type “ClusterIP”. Dabei wird jedem Service eine virtuelle IP-Adresse zugewiesen, über die Anfragen entgegengenommen werden und an die Host-Pods weitergeleitet werden.

1. PodA sendet eine Anfrage an die ClusterIP des Services
2. Die Anfrage wird von ClusterIP an den zugehörigen PodB weitergeleitet
3. PodA und PodB verbinden sich ohne NAT

ClusterIP sorgt für eine reduzierte Latenz, da keine zusätzlichen NAT-Adressenauflösungen erforderlich sind. Dies bedeutet, dass der Datenverkehr schnell und direkt innerhalb des Clusters ohne zusätzliche Adressauflösung weitergeleitet wird, was insbesondere bei häufigen Interaktionen zwischen den Pods von Vorteil ist.

Während ClusterIP eine einfache Möglichkeit bietet, die Kommunikation innerhalb des Clusters zu ermöglichen, kann diese Flexibilität potenziell Sicherheitsrisiken mit sich bringen, wenn keine geeigneten Network Policies definiert sind. Network Policies sorgen dafür, dass nur autorisierte Pods miteinander kommunizieren können und verhindern so unberechtigte Zugriffe, durch Autorisierung des Datenverkehrs auf Netzwerkebene.

Für die Verbindung externer Clients auf Services innerhalb des Clusters gibt es 3 genannte Hauptmethoden. NodePort ist nativ vertreten, Loadbalancer werden von Managed Kubernetes Services bereitgestellt und Ingress wird durch einen Ingress Controller realisiert.

Bei dem Aufbau von Kubernetes-Netzwerken gibt es Aspekte die es zu berücksichtigen gilt. Mit der zunehmenden Anzahl von Pods und Nodes steigt auch der Netzwerkverkehr, was die Komplexität des Routings erhöht. Das dynamische Hinzufügen und Entfernen von Pods, sowie die Zuweisung von IP-Adressen können dazu führen, dass Routing-Tabellen schnell wachsen und die Performance des Netzwerks beeinträchtigen. In einer großen Kubernetes-Umgebung könnte es zu Engpässen kommen, wenn die Nodes nicht ausreichend skalieren oder die Ressourcen knapp werden, was das effiziente Management von Netzwerkverbindungen erschwert. 

Dadurch kann die Verwaltung eines großen Kubernetes-Clusters zu einer Herausforderung werden, insbesondere wenn Ressourcen wie CPU, Arbeitsspeicher und Netzwerkbandbreite dynamisch angepasst werden müssen. Horizontal Pod Autoscaling stellt sicher, dass Pods bei Bedarf automatisch skaliert werden. Dennoch wird die Verwaltung der zugrunde liegenden Infrastruktur immer komplexer, je größer der Cluster wird. Hier kommen Managed Kubernetes Services wie Azure Kubernetes Service (AKS) ins Spiel. 

AKS übernimmt viele dieser komplexen Aufgaben wie die Verwaltung des Control Plane, Auto-Scaling, Load-Balancing und die Integration von Sicherheitsfunktionen. Dies erleichtert die Skalierung von Kubernetes-Clustern und reduziert den manuellen Verwaltungsaufwand erheblich. Weitere Beispiele dafür wären:

• Monitoring: Die Integration von Azure Monitoring for Containers ermöglicht eine umfassende Überwachung der Performance und Netzwerkaktivitäten.
• Auto-Scaling: AKS verwendet sogenannte Scale Sets, was das automatische Skalieren der Nodes basierend auf der Auslastung und Ressourcenbedarf vereinfacht.
• Security: Integration mit dem Azure Entra ID und Managed Identities verbessert Authentifzierungs- und Autorisierungsprozesse.
• Administration: Operationelle Aufgaben wie Updates vom Control Plane, Patching oder des zugrundeliegenden Infrastrukturmanagement wird von Microsoft übernommen.

Die Funktionen können insbesondere den Betrieb großer, komplexer Cluster vereinfachen, bei denen manuelle Konfiguration und Wartung einen erheblichen Mehraufwand bedeuten würden.

Neben AKS bieten auch andere Cloud-Anbieter Managed Kubernetes Services an, wie etwa Amazon Elastic Kubernetes Service (EKS) und Google Kubernetes Engine (GKE). Diese Dienste bieten ähnliche Funktionen wie AKS, jedoch mit unterschiedlichen Stärken: EKS bietet eine tiefe Integration mit anderen AWS-Diensten und eignet sich besonders für Unternehmen, die bereits intensiv AWS-basierte Infrastruktur nutzen.

GKE von Google hebt sich durch fortschrittliche Funktionen zur Automatisierung von Updates und ein integriertes Monitoring mit Google Cloud Operations hervor. Jeder dieser Anbieter hat eigene Merkmale, die ihn für bestimmte Anforderungen besonders geeignet machen, aber alle vereinfachen die Verwaltung von Kubernetes-Umgebungen und bieten skalierbare Lösungen für große Cluster.

Das Container Networking Interface (CNI) ist eine Schlüsselkomponente der Kubernetes-Netzwerkinfrastruktur. Es definiert ein standardisiertes Framework, das die Verwendung von API-Plugins ermöglicht, die den Pods eine Netzwerkkonnektivität bereitstellen. Ohne ein CNI-Plugin könnten Pods keine IP-Adressen zugewiesen bekommen und somit nicht miteinander kommunizieren. CNI-Plugins fungieren als Vermittler zwischen den Kubernetes-Komponenten und sorgen dafür, dass Pods miteinander kommunizieren können.

Beim Start eines Pods wird vom kubelet das konfigurierte CNI-Plugin aufgerufen. Dieses Plugin weist dem Pod eine IP-Adresse zu, konfiguriert die zugehörige Netzwerkschnittstelle und passt gegebenenfalls Routing-Tabellen (und NAT-Regeln) an, um eine konsistente Netzwerkinfrastruktur sicherzustellen. Wird der Pod beendet, übernimmt das CNI-Plugin auch das Aufräumen und die Freigabe der zugehörigen Netzwerkressourcen.

CNI-Plugins stellen Konnektivität über zwei unterschiedliche Wege bereit - das Overlay oder Flat Modell:

Flat-Modell:

• Die Pods erhalten ihre IP-Adressen direkt aus dem zugrunde liegenden Adressraum (z. B. eines virtuellen Netzwerks).
• Alle Nodes und Pods nutzen einen gemeinsamen, global verfügbaren Adresspool.
• In Multi-Cloud- oder Multi-Tenant-Umgebungen kann dies problematisch sein, wenn der Adressraum nicht groß genug dimensioniert ist.

Overlay-Modell:

• Hier wird eine zusätzliche, virtuelle Netzwerkschicht (Overlay) über das physische Netzwerk (Underlay) gelegt.
• Pakete werden mit zusätzlichen Headern (z. B. mittels VxLAN) eingekapselt, um sie über die bestehende Infrastruktur zu transportieren.
• Dieses Modell eignet sich besonders für heterogene Umgebungen und sorgt für eine verbesserte Isolation der Workloads.

Allerdings verursacht die Kapselung und Entkapselung der Pakete einen Performance-Overhead, was zu einer höheren Latenz und einem erhöhten Ressourcenverbrauch führen kann.

Einige CNI-Plugins, wie beispielsweise Calico, unterstützen zusätzlich zum Overlay-Modus auch einen direkten Routing-Modus. In produktiven Umgebungen kann dieser Ansatz von Vorteil sein, da die direkte Zuweisung von IP-Adressen ohne zusätzliche Kapselung zu einer Reduzierung der Latenzzeiten führt.

Das nachfolgende Diagramm zeigt eine beispielhafte Kommunikation zwischen zwei Pods.

Network Policies spielen eine entscheidende Rolle in der Sicherheit und Steuerung des Netzwerkverkehrs zwischen Pods in einem Kubernetes-Cluster. Sie ermöglichen es, fein granulare Regeln festzulegen, die bestimmen, welcher Pod mit welchem anderen Pod oder Service kommunizieren darf. 

Diese Policies operieren auf der Netzwerkschicht und schützen den Cluster vor unautorisiertem Zugriff. Sie können sowohl Ingress- als auch Egress-Regeln enthalten, um den eingehenden und ausgehenden Traffic zu steuern. Zum Beispiel könnte eine Network Policy so konzipiert werden, dass Pods aus einem bestimmten Namespace nur mit Pods im selben Namespace kommunizieren dürfen.

Genauer gesagt, werden sogenannte Namespaces definiert, zwischen denen Informationen ausgetauscht werden dürfen. Dadurch qualifizieren sie sich als Sicherheitsmaßnahme auf Netzwerkebene, um potenziell unberechtigte Zugriffe abzuwehren. Eine solche Netzwerkpolicy kann beispielsweise folgendermaßen ausgestaltet werden:

Ein Service Mesh ist eine speziell entwickelte Infrastruktur, die die Kommunikation zwischen Microservices in verteilten Anwendungen verwaltet. Es fungiert als ein Abstraktionslayer, der Aufgaben wie Load Balancing, Überwachung, Authentifizierung und Verschlüsselung der Kommunikation übernimmt. Ein Service Mesh ermöglicht es, diese Funktionen zentral zu steuern, ohne Änderungen an der Anwendungslogik selbst vorzunehmen. 

Dies ist besonders wichtig in Microservices-Architekturen, in denen viele kleine, unabhängige Dienste miteinander kommunizieren müssen. Durch die Einführung eines Service Mesh können komplexe Kommunikationsmuster und -anforderungen leichter verwaltet und überwacht werden.

Ein Service Mesh ergänzt die Funktionalität von CNI-Plugins, indem es zusätzliche Features wie Traffic Management, Fehlerbehandlung und Sicherheit bietet. Während CNI für die grundlegende Netzwerkkonnektivität und IP-Adressierung der Pods sorgt, übernimmt das Service Mesh eine tiefere Kontrolle über die Kommunikation zwischen den Microservices. In einer Kubernetes-Umgebung könnten CNI und Service Mesh zusammenarbeiten, um sicherzustellen, dass der Datenverkehr sowohl auf der Netzwerkschicht als auch auf der Anwendungsebene optimiert und abgesichert.

Features

In einem Kubernetes-Cluster kann ein Service Mesh den Datenverkehr zwischen den Microservices gezielt steuern und optimieren. Durch die zusätzliche Abstraktionsschicht lassen sich Regeln und Richtlinien zentral definieren, ohne Änderungen am Quellcode der Microservices vorzunehmen.

Dies ermöglicht:

• Detaillierte Steuerung des Datenverkehrs
• Automatische Fehlerbehandlung (z. B. Retries, Circuit Breaking)
• Dynamische Service-Erkennung (Service Discovery)
• Zentrale Sicherheitsrichtlinien ohne Änderungen an der Applikation

Ein zentrales Konzept des Service Meshes sind Sidecar-Proxies, die innerhalb des gleichen Pods wie die Microservices bereitgestellt werden. Diese Proxies übernehmen die gesamte eingehende und ausgehende Kommunikation der jeweiligen Services. Sie agieren als Proxy für den Service und führen Aufgaben wie Traffic Routing, Fehlerbehandlung (z. B. Retries, Circuit Breaking), Load Balancing und Sicherheitsmaßnahmen wie die komplette Verschlüsselung des cluster-internen Datenverkehrs mittels mTLS aus. Durch diese Trennung der Kommunikationslogik vom eigentlichen Microservice wird der Code der Anwendung vereinfacht, während gleichzeitig die Flexibilität und Skalierbarkeit erhöht wird. 

Es gibt mehrere populäre Service Mesh-Lösungen, die in Kubernetes-Umgebungen verwendet werden, darunter:

1. Istio: Eine der beliebtesten und leistungsstärksten Service Mesh-Lösungen, die umfangreiche Funktionen für Traffic Management, Sicherheit, Überwachung und Fehlerbehandlung bietet. Istio ist sehr flexibel, aber auch komplex in der Einrichtung und Verwaltung.
2. Linkerd: Eine leichtgewichtigere und einfachere Service Mesh-Lösung, die besonders für Benutzer geeignet ist, die eine unkomplizierte Implementierung und geringere Latenzzeiten benötigen. Linkerd bietet grundlegende Funktionen für mTLS, Traffic Management und Überwachung.
3. Consul: Eine weitere populäre Lösung, die sich gut für Hybrid- und Multi-Cloud-Umgebungen eignet und eine zentrale Verwaltung von Services über verschiedene Clouds hinweg ermöglicht.

Jede dieser Lösungen hat ihre Stärken und eignet sich je nach Anforderungen für unterschiedliche Anwendungsfälle. Für den Betrieb kann ggf. auch auf professionellen Support zurückgegriffen werden, welcher sich allerdings erst ab einer gewissen Komplexität der Cluster-Lösung lohnt

Die Kommunikation zwischen Pods in einem Cluster unter der Verwendung eines Service Meshes kann folgendermaßen illustriert werden.

Hierbei versucht Pod 1 eine Kommunikation mit Pod 2 aufzubauen. Das Service Mesh nutzt IP Tables, um herauszufinden, welche IP-Adresse der anvisierte Pod besitzt. Über das Sidecar wird dann die Kommunikation geleitet und auf dem Node von Pod 2 gleichfalls über das Sidecar an den Pod weitergeleitet. Ein Beispiel für eine Authorization Policy könnte, wie im Folgenden aussehen:

Sowohl das CNI-Plugin als auch das Service Mesh bieten Mechanismen sicherzustellen, welche Kommunikation zwischen Pods erlaubt ist. Allerdings erfolgen diese Prüfungen auf verschiedenen Ebenen, die daher unterschiedlichen Angriffsvektoren entgegenwirken. 

Wie hier zu sehen, wird auf beiden Seiten der Grafik an jeweils 2 Stellen überprüft, ob die Verbindung legal ist oder geblockt werden sollte. Ein potenzieller Angriffsversuch gegen die Mittel eines CNIs könnte folgendermaßen aussehen:

In diesem Fall startet der Frontend Pod mit der IP-Adresse 10.1.1.5. Ihm ist es erlaubt eine Kommunikation mit dem Backend Namespace, dessen Pod aktuell die IP 10.1.1.6 besitzt aufzunehmen. In diesem Angriffsszenario hat ein Angreifer einen anderen Pod kompromittiert. In dem Moment, in dem beispielsweise der Frontend Pod erneuert wird (heruntergefahren und neu erstellt durch den Kubernetes Cluster), erhält dieser eine neue IP-Adresse. Dies ist in der IP-Tabelle rechts im Bild gezeigt. Bis diese Information jedoch in der IP-Tabelle aktualisiert ist, kann der Angreifer mit seinem Pod, der die alte IP-Adresse des Frontend Pods verwendet auf den Backend Pod zugreifen. Man spricht hierbei von IP-Spoofing.

Bei der Verwendung eines Service Meshes stellt sich die Lage wie in folgendem Schaubild gezeigt dar: 

Ein Service Mesh stellt üblicherweise eine Komponente zur Erstellung von Zertifikaten zur Verfügung. Jede Transaktion wird unter Verwendung dieser Zertifikate durchgeführt, wobei das Sidecar desjenigen Pods, der die Verbindung empfängt prüft, ob der im Zertifikat angegebene Namespace Berechtigung besitzt den Pod aufzurufen. Wenn es einem Angreifer gelingt mit einem kompromittierten Pod ein Service Account Token eines berechtigten Pods zu entwenden, ist er in der Lage bei der Service Mesh Controller Komponente ein Zertifikat für den berechtigten Pod zu erhalten. So kann er illegalerweise einen Pod aufrufen, auf den er normalerweise keine Berechtigungen besitzt. 

Eine Lösung dieser beiden Angriffsszenarien besteht darin die beiden Ansätze zu kombinieren. Die CNI Policies sind in der Lage auf OSI-Level 4 Regeln durchzusetzen, wogegen das Service Mesh Policies einsetzen kann, um auf OSI-Level 7 die Kommunikation abzusichern.

Angewendet auf die beiden Angriffsszenarien würde ein Angreifer, der eine IP-Adresse eines berechtigten Pods übernimmt von den Policies des CNI zwar durchgelassen werden, jedoch besitzt er nicht das Zertifikat, um den anvisierten Pod aufzurufen. Das Service Mesh würde die Kommunikation in diesem Fall nicht zulassen. Umgekehrt wird ein Angreifer, der ein gestohlenes Zertifikat nutzt von den Policies des CNI abgelehnt, da er mit einer falschen IP-Adresse agiert.

Service Kommunikation

In Kubernetes sind Pods dynamisch und erhalten bei jeder Skalierung oder Neustart neue IP-Adressen, was die direkte Kommunikation erschwert. Services bieten jedoch eine Abstraktionsebene, die es ermöglicht, dass Anwendungen auf dem Cluster zuverlässig erreicht werden können, unabhängig davon, wie sich die IP-Adressen der Pods ändern. Services sorgen dafür, dass der Traffic von Clients zu den richtigen Pods weitergeleitet wird, ohne dass der Client sich um die IP-Adressen der Pods kümmern muss.

Auswahl eines CNI Plugins

Die Wahl des richtigen CNI-Plugins ist entscheidend für die Performance, Sicherheit und Flexibilität eines Kubernetes-Clusters. Verschiedene CNI-Plugins bieten unterschiedliche Stärken, die je nach Anwendungsfall und Infrastruktur berücksichtigt werden sollten. Zum Beispiel beeinflussen CNI-Plugins die Latenz, den Durchsatz und die Skalierbarkeit des Netzwerks, sowie die Fähigkeit, mit Cloud-spezifischen Sicherheitsfunktionen und Netzwerkdiensten (wie VNETs oder Security Groups) zu interagieren.

Ein CNI-Plugin, das gut in eine Cloud-Infrastruktur integriert ist, kann die Netzwerkmanagement-Kosten und den administrativen Aufwand erheblich reduzieren. Auf der anderen Seite bietet ein CNI-Plugin, das BGP oder eBPF unterstützt, Vorteile in Bezug auf Performance und Netzwerksteuerung.

Nachfolgend einige Beispiele, die potenziell zur Auswahl stehen:

Kubenet

• Pods erhalten interne IP-Adressen, NAT wird für die Kommunikation außerhalb des Nodes genutzt
  • Pods erhalten private IP-Adressen, die nur innerhalb des Nodes gültig sind. Daher erfordert die Kommunikation zwischen Pods Network Address Translation. Diese NAT-Regeln müssen manuell verwaltet werden.

Azure CNI

• Pods erhalten IP-Adressen aus dem VNET. Hierdurch können Features wie Network Security Groups, VNET-Peering und Private Link verwendet werden.
• Höherer IP-Adressen Bedarf bei Skalierung

Calico

• Unterstützt fein-granularere Einstellmöglichkeiten auf Pod Level
• Unterstützt BGP (Border Gateway Protocol) für optimierte Netzwerk Routing Performance
• Unterstützt eBPF (extended Berkeley Packet filter) für höhere Performance anstelle von IP-Tables-Regeln

Cilium 

• Durch die Verwendung von eBPF (extended Berkeley Packet filter) als Ersatz für IP-Tables-Regeln wird eine hohe Performance erreicht.
• Integrierte Netzwerk Policies und DNS-basierte Policies

Flannel

• keine Unterstützung für Network Policies
• einfaches Overlay Netzwerk

Für viele Szenarien ohne besondere Anforderungen lässt sich mit dem Azure CNI Plugin arbeiten, solange Netzwerke mit hinreichend IP-Adressen bereitgestellt werden können. Andere Plugins bieten für besondere Anforderungen an Sicherheit, Performance und Monitoring zum Teil auch kostenpflichtige Lösungen mit Support an. 

Ein weiterer wichtiger Aspekt bei der Wahl eines CNI-Plugins ist die Sicherheit. Einige CNI-Plugins wie Calico und Cilium bieten erweiterte Sicherheitsfunktionen, die Network Policies unterstützen und eine feinere Steuerung des Datenverkehrs auf Pod-Ebene ermöglichen. Diese Funktionalitäten erlauben es, den Zugriff zwischen den Microservices und Pods auf die gewünschten Services zu beschränken, wodurch potenzielle Angriffsflächen minimiert werden.

Um sicherzustellen, dass die Kommunikation zwischen den Pods und Diensten im Cluster sicher ist, sollten Network Policies implementiert werden, die den Zugriff basierend auf Sicherheitsanforderungen und Business-Logik steuern.

Oftmals ist die Entscheidung ein Service Mesh zu verwenden dadurch motiviert, dass eine Cluster-interne Verschlüsselung mittels mTLS erreicht werden soll, auch wenn ein Service Mesh natürlich noch eine Vielfalt weiterer Features umfasst. 

Wichtig bei der Entscheidung, ob ein Service Mesh eingesetzt werden soll, ist insbesondere das Bewusstsein, dass die Einführung eines solchen Systems mit einigem Wartungsaufwand einhergehen kann. Einige Service Meshes können in einer Premium Variante eingesetzt werden, bei dem der Betrieb des Meshes eingekauft werden kann. Dies lohnt sich allerdings nur für größere Anwendungsfälle.

Einfachere Service Meshes wie LinkerD können meistens mit geringem Aufwand selbst betrieben werden, bieten jedoch einen deutlich begrenzten Funktionsumfang und erlauben ggf. anders als bei aufwendigeren Systemen eingeschränkt die Einbindung von Ressourcen außerhalb des Clusters in das Netzwerkkonstrukt, wie beispielsweise Azure Functions.

Falls die Entscheidung für den Einsatz eines Service Meshes getroffen wurde, ist es wichtig umfassend abzuwägen, welches Mesh am besten zu den identifzierten Anforderungen passt. Das Wechseln im laufenden Betrieb auf ein anderes System kann sich sehr aufwendig gestalten. 

Service Types und Ingress

Grundsätzlich lässt sich sagen, dass für viele professionelle Anwendungen der Service Type “Cluster-IP” geeignet ist. Bei Verwendung dieses Modus sind die Dienste auf dem Cluster nicht direkt aus dem Internet erreichbar und können so den Anforderungen entsprechend durchzusätzliche Gateways und Firewalls abgesichert werden. 

Es gibt Situationen in denen andere Service Types geeigneter sind. Möchte man die externe Kommunikation vereinfachen können andere Service Types hier Abhilfe schaffen. Jedoch muss man hierbei darauf achten, dass Zugriffe auf die Pods dennoch nicht unkontrolliert abläuft. Es hängt also von der Gesamtarchitektur ab, welcher Service Type in Frage kommen kann. Zudem kommt es auch noch darauf an, welche zusätzlichen Tools im Cluster eingesetzt werden. Ein Service Mesh kann beispielsweise im Bereich Traffic Management aushelfen.

In diesem Artikel haben wir die Grundlagen der Kubernetes-Netzwerkarchitektur und deren Erweiterungen durch CNI-Plugins und Service Meshes behandelt. Wir haben gesehen, dass Kubernetes eine sehr flexible Netzwerkarchitektur bietet, die durch CNI-Plugins noch weiter optimiert werden kann. Dabei wurden die Unterschiede zwischen Flat- und Overlay-Modellen erklärt und gezeigt, wie die Wahl des richtigen CNI-Plugins sowohl die Performance als auch die Sicherheit eines Clusters beeinflussen kann.

Für die Kommunikation zwischen Microservices wurde der Nutzen eines Service Meshes hervorgehoben, das erweiterte Funktionen wie Traffic Management, Fehlerbehandlung und mTLS bietet. Wir haben auch beleuchtet, wie die Wahl eines Service Meshes oder eines CNI-Plugins von den spezifischen Anforderungen der Anwendung und der Infrastruktur abhängt und welche Faktoren dabei berücksichtigt werden sollten, wie Wartungsaufwand, Komplexität und Sicherheitsanforderungen.