Auf einen Blick: Kubernetes-Netzwerke sind entscheidend für die Kommunikation innerhalb eines Clusters und verwalten die Interaktionen zwischen Containern. Es umfasst verschiedene Netzwerktypen und die Rolle von Diensten bei der Weiterleitung des Verkehrs.
- Netzwerktypen gewährleisten eine nahtlose Kommunikation ohne NAT.
- Dienste abstrahieren die Verkehrsleitung zu Pods und erhöhen so die Flexibilität.
- Tools wie Cilium und Flannel optimieren Kubernetes-Netzwerke.
Kubernetes-Netzwerke sind ein integraler Bestandteil der Verwaltung und Erleichterung der Kommunikation innerhalb eines Kubernetes-Clusters. Es verwaltet eine breite Palette von Abläufen, wie zum Beispiel:
- Umgang mit interner Containerkommunikation
- Die Container dem Internet zugänglich machen
Dieser Artikel führt Sie in die wichtigsten Kubernetes-Netzwerkkonzepte ein.
Netzwerke in Kubernetes
Zuerst schauen wir uns die grundlegenden Netzwerktypen in einem Kubernetes-Cluster an:
- Container-zu-Container-Netzwerk
- Pod-zu-Pod-Netzwerk
- Pod-to-Service-Netzwerk
- Internet-zu-Service-Netzwerke
Schauen wir uns nun an, wie jeder Typ funktioniert, um Konnektivität innerhalb des Clusters bereitzustellen.
Container-zu-Container-Netzwerk
In den grundlegendsten Konfigurationen erfolgt die Container-zu-Container-Kommunikation innerhalb eines einzelnen Pods über die Localhost- und Portnummern. Dies ist möglich, weil die Container im Pod im selben Netzwerknamensraum liegen. Ein Netzwerknamensraum ist ein logischer Netzwerkstack, der Routen, Firewall-Regeln und Netzwerkgeräte umfasst und einen vollständigen Netzwerkstack für Prozesse innerhalb des Namensraums bereitstellt. Es kann mehrere Namensräume auf derselben virtuellen Maschine geben. In Kubernetes gibt es einen versteckten Container namens Pause-Container, der auf allen Pods in Kubernetes läuft. Dieser Container hält den Namensraum offen, auch wenn alle anderen Container im Pod nicht funktionieren. Jedem erstellten Pod wird ein neuer Netzwerknamensraum zugewiesen. Container innerhalb des Pods können diesen Netzwerknamensraum über localhost verwenden. Ein Benutzer muss jedoch über die Portkonflikte informiert sein: Wenn die Container denselben Port verwenden, treten Netzwerkprobleme innerhalb der Container auf.
Pod-zu-Pod-Netzwerk
Jeder Pod in einem Kubernetes-Knoten erhält eine dedizierte IP-Adresse mit einem eigenen Namensraum. Durch eine automatische Zuweisung müssen Nutzer keine expliziten Verbindungen zwischen den Pods anlegen. Dies ermöglicht es uns, Pod-Netzwerkoperationen wie Portzuweisung, Lastverteilung und Benennung ähnlich wie bei einer virtuellen Maschine oder einem physischen Host zu steuern. Kubernetes stellt jedem Netzwerk drei grundlegende Anforderungen.
- Pods auf einem Knoten können mit allen Pods auf allen Knoten ohne NAT kommunizieren.
- Agenten auf einem Knoten (Systemdämonen, Kubelet) können mit allen Kapseln auf diesem speziellen Knoten kommunizieren.
- Pods in einem Hostnetzwerk eines Knotens können mit allen Pods auf allen Knoten ohne NAT kommunizieren (nur für Plattformen wie Linux, das Pods im Host-Netzwerk unterstützt)
Kommunikation zwischen Kapseln im selben Knoten
Kubernetes erstellt für jeden Pod einen virtuellen Ethernet-Adapter, der mit dem Netzwerkadapter des Knotens verbunden ist. Wenn eine Netzwerkanfrage gestellt wird, verbindet sich der Pod über das virtuelle Ethernet-Gerät, das mit dem Pod verbunden ist, und tunnelt den Datenverkehr zum Ethernet-Gerät des Knotens. In einem Kubernetes-Knoten gibt es eine Netzwerkbrücke namens cbr0, die die Kommunikation zwischen den Pods in einem Knoten erleichtert. Alle Kapseln sind Teil dieser Netzwerkbrücke. Wenn eine Netzwerkanfrage gestellt wird, prüft die Brücke das richtige Ziel (Pod) und leitet den Datenverkehr weiter.
Kommunikation zwischen Pods in verschiedenen Knoten
Wenn die angeforderte IP-Adresse im Pod nicht gefunden werden kann, leitet die Network Bridge den Datenverkehr zum Standard-Gateway weiter. Dies würde dann nach der IP innerhalb der Clusterebene suchen. Kubernetes führt eine Aufzeichnung aller IP-Bereiche, die jedem Knoten zugeordnet sind. Dann wird den Pods innerhalb der Knoten eine IP-Adresse aus dem dem dem Knoten zugewiesenen Bereich zugewiesen. Wenn eine Anfrage an eine IP-Adresse im Cluster gestellt wird, wird dies:
- Suchen Sie nach dem IP-Bereich der gewünschten IP.
- Dann leiten Sie es an den spezifischen Knoten und dann an den richtigen Pod.
Pod-to-Service-Netzwerk
Ein Service ist eine Abstraktion, die den Datenverkehr an eine Reihe von Pods leitet. Mit anderen Worten: Ein Service weist eine einzelne IP-Adresse auf eine Reihe von Pods zu. Wenn eine Netzwerkanfrage gestellt wird, leitet der Service die Anfrage an den erforderlichen Pod weiter. Dieser Proxy-Service erfolgt über einen Prozess namens Kube-Proxy, der innerhalb jedes Knotens läuft. Der Dienst erhält seine IP im Cluster, wenn eine Anfrage die Service-IP erreicht, bevor sie an die tatsächliche IP des Pods weitergeleitet wird. Dies ist eine wichtige Funktion in Kubernetes – es entkoppelt die Netzwerkabhängigkeit direkt zu jedem Pod. Die Pods können erstellt und zerstört werden, ohne sich um die Netzwerkverbindung zu kümmern. Das liegt daran, dass der Dienst seine Endpunkte automatisch aktualisiert, wenn die Pods mit der IP des Pods wechseln. Der Dienst erhält seine IP innerhalb des Clusters. Jede Anfrage erreicht zuerst die Service-IP, bevor sie an die tatsächliche IP des Pods weitergeleitet wird. Dies ist eine wichtige Funktion in Kubernetes, da sie die Abhängigkeit des Netzwerks direkt zu jedem Pod entkoppelt. So können Pods erstellt und zerstört werden, ohne sich um die Netzwerkverbindung sorgen zu müssen, da der Dienst seine Endpunkte automatisch mit der IP des Pods aktualisiert, den er anvisiert, sobald sich der Pod ändert. Ein Service weiß, welche Pods er mit dem Label-Selektor anvisieren soll. Der Label-Selector ist das Kern-Gruppierungsprimitiv in Kubernetes; über einen Label-Selector kann der Client oder Benutzer eine Menge von Objekten identifizieren.
- Der Label-Selector sucht nach den angegebenen Labels in jedem Pod und ordnet sie entsprechend dem Service zu.
- Ohne den Selektor können richtig konfigurierte Dienste die Pods nicht verfolgen und führen zu Kommunikationsproblemen innerhalb des Clusters.
DNS für internes Routing in einem Kubernetes-Cluster
Jeder Cluster ist mit einem eingebauten Dienst für DNS-Auflösung ausgestattet.
- Jedem Dienst im Cluster wird ein Domainname zugewiesen
- Den Pods wird ein DNS-Name zugewiesen.
(Diese können manuell über die YAML-Datei unter Verwendung der Felder Hostname und Subdomain konfiguriert werden.) Wenn eine Anfrage über den Domainnamen gestellt wird, löst der Kubernetes-DNS-Service die Anfrage auf und weist sie auf den notwendigen internen Service des Dienstes weiter. Der Kube-Proxy-Prozess weist sie auf den Endpunkt-Pod.
Internet-zu-Service-Netzwerke
In den obigen Abschnitten haben wir die internen Netzwerkgrundlagen eines Kubernetes-Clusters behandelt. Der nächste Schritt ist, die containerisierte Anwendung dem Internet zugänglich zu machen. Im Gegensatz zu den vorherigen Netzwerktypen hängt die Bereitstellung des Kubernetes-Clusters für das Internet von beiden:
- Zugrunde liegende Cluster-Infrastruktur
- Netzwerkkonfigurationen
Die gebräuchlichste Methode zur Verkehrsbewältigung ist die Verwendung eines Load Balancers. In Kubernetes können wir Load Balancer konfigurieren. Wenn ein Dienst erstellt wird, können Nutzer:
- Spezifizieren Sie einen Load Balancer, der die IP-Adresse des Load Balancers offenlegt.
- Leiten Sie den Datenverkehr an den Load Balancer und kommunizieren Sie über diesen mit dem Service.
Werkzeuge für Kubernetes-Netzwerke
Es gibt viele Tools, mit denen wir Netzwerke innerhalb von Kubernetes konfigurieren können, während wir alle Richtlinien und Anforderungen des Clusters einhalten.
- Cilium ist eine Open-Source-Software zur Bereitstellung und Sicherung der Netzwerkverbindung zwischen Anwendungscontainern. Cilium ist L7/HTTP-Kenntnis und kann Netzwerkrichtlinien von L3-L7 mittels identitätsbasierten Sicherheitsmodellen durchsetzen.
- Flannel ist ein einfaches Netzwerk-Overlay, das die Anforderungen von Kubernetes erfüllt.
- Kube-router ist eine schlüsselfertige Lösung für Kubernetes-Netzwerke. Kube-router bietet eine schlanke und leistungsstarke Alternative zu den Standard-Kubernetes-Netzwerkkomponenten aus einem einzigen DaemonSet/Binär.
- Antrea ist eine Kubernetes-native Open-Source-Netzwerklösung, die Open vSwitch als Netzwerkdatenebene nutzt.
Und hier sind cloud-spezifische Container-Netzwerkschnittstellen:
- AWS VPC CNI für Kubernetes ist das Amazon Web Services-spezifische CNI.
- Azure CNI for Kubernetes ist das Microsoft Azure-spezifische CNI.
Bitte siehe die offizielle Kubernetes-Dokumentation für die vollständige Liste der verfügbaren Netzwerkwerkzeuge.
K8s-Netzwerke optimieren die Leistung
Kubernetes-Cluster-Netzwerke können so konfiguriert werden, dass sie alle Benutzeranforderungen erfüllen, um die Leistung der containerisierten Anwendung und des Clusters zu optimieren.
Verwandte Literatur
Kubernetes-Leitfaden
- Was ist Kubernetes (K8s)? Ein Tutorial zu den Grundlagen von Kubernetes
- Kubernetes Best Practices für verbesserte Cluster-Effizienz
- Best Practices: Wie man Anwendungen für Kubernetes architekt
- Kubernetes Pods: Eine Einführung
- Kubernetes ReplicaSets: Eine kurze Einführung
- Kubernetes-Deployments vollständig erklärt
- Wie man Kubernetes DaemonSets verwendet und verwaltet
- Wie Kubernetes-Dienste funktionieren
- Verwendung von Kubernetes Port, TargetPort und NodePort
- Erstellen und verwenden von ConfigMaps in Kubernetes
- Einführung in Kubernetes-Geheimnisse
- Kubernetes-Netzwerkgrundlagen
- Kubernetes-Ingress erklärt
- Einführung in Kubernetes Helm Charts
- Was ist das Kubernetes-Operator-Muster?
- Bereitstellung von PostgreSQL als StatefulSet in Kubernetes
- Kubernetes Custom Resource Definition (CRDs) erklärt
- 3 Kubernetes-Muster für Cloud-native Anwendungen
- Kubernetes Compute-Ressourcen erklärt
- Kubernetes-Sicherheit für DevOps-Pipelines
- Verwendung von Spinnaker mit Kubernetes für Continuous Delivery
- Kubernetes-Multi-Cluster: Wie und warum man sie verwendet.
- Kubernetes-Überwachung: Ein umfassender Leitfaden
- Kubernetes vs. Docker: Ein kurzer Vergleich
- Kubernetes vs. Docker Swarm: Vergleich von Container-Orchestrierungstools
- Kubernetes vs. OpenShift: Was ist der Unterschied?
- Kubernetes-Zertifizierungen: Wie und warum man zertifiziert wird
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.