Was ist Kubernetes-Networking?

Das Netzwerk ist komplex und umfasst die Kommunikation zwischen allen wichtigen Komponenten, die innerhalb existieren, wie Pods, Knoten, Container und Services, und außerhalb, wie der externe Verkehr eines Kubernetes-Clusters.

Diese Komponenten verwenden vier unterschiedliche Netzwerkmethoden zur Kommunikation:

1. Container-to-Container-Networking

2. Pod-to-Pod-Networking

3. Pod-to-Service-Networking

4. External-to-Service-Networking

Der Name Kubernetes stammt aus Griechenland und bedeutet Steuermann oder Pilot. Kubernetes basiert auf Borg, der internen Container-Orchestrierungsplattform von Google, und wurde 2014 als Open-Source-Tool der Öffentlichkeit vorgestellt.

Im selben Jahr spendete Google Kubernetes an die Cloud Native Computing Foundation, das anbieterneutrale Open-Source-Zentrum für cloudnatives Computing. Seitdem hat sich Kubernetes zum weltweit am weitesten verbreiteten Container-Orchestrierungstool für die Ausführung von containerbasierten Workloads entwickelt.

Kubernetes ist auch als „k8s“ oder „kube“ bekannt und wurde speziell dafür entwickelt, das Management von Containern zu automatisieren. Container sind die Standardeinheit der Software, die Code und alle seine Abhängigkeiten paketiert. Das Orchestrierungstool wird sehr geschätzt, da es schnell und zuverlässig in jeder Infrastrukturumgebung ausgeführt werden kann, egal ob On-Premises, Private Cloud, Public Cloud oder Hybrid Cloud.

Im Gegensatz zu virtuellen Maschinen (VMs), die physische Hardware virtualisieren , virtualisieren Container das Betriebssystem, wie Linux® oder Windows. Jeder Container enthält nur die Bibliotheken und Abhängigkeiten der Anwendung. Da Container sich den Betriebssystemkernel mit dem Host teilen, gelten sie als schlank, schnell und tragbar.

Kubernetes und sein Ökosystem aus Diensten, Support und Tools sind zur Grundlage für eine moderne Cloud-Infrastruktur und Anwendungsmodernisierung geworden. Alle großen Cloud-Anbieter, darunter Amazon Web Services (AWS), Google, Microsoft, IBM® und Red Hat®, integrieren Kubernetes in ihre Cloud-Plattformen, um Platform-as-a-Service (PaaS)- und Infrastructure-as-a-Service (IaaS)-Funktionen zu verbessern.

Die folgenden grundlegenden Komponenten bilden die Kubernetes-Architektur:

Zu den weiteren Komponenten von Kubernetes gehören:

Bereitstellung: Die Bereitstellung in Kubernetes verwaltet eine Reihe von Pods für die Ausführung eines Anwendungs-Workloads. Eine Bereitstellung identifiziert, wie viele Replikate eines Pods auf dem Cluster ausgeführt werden sollen. Wenn ein Pod ausfällt, erstellt die Bereitstellung einen neuen.

Diese wichtige Funktion hilft dabei, die Anzahl der Replikat-Pods zu skalieren, Code-Updates durchzuführen und die Verfügbarkeit aufrechtzuerhalten. Bereitstellungen werden mit kubectl, dem Kubernetes-spezifischen Befehlszeilentool, durchgeführt.

Service: Ein Kubernetes Service ist eine Abstraktionsschicht, die eine logische Menge von Pods definiert und wie man darauf zugreift. Ein Kubernetes Service stellt eine Netzwerkanwendung frei, die auf einem oder mehreren Pods in einem Cluster läuft. Es bietet eine abstrakte Möglichkeit, Load-Balance-Pods zu verteilen.

Programmierschnittstelle (API)-Server: Der API-Server in Kubernetes stellt die Kubernetes-API (die Schnittstelle zur Verwaltung, Erstellung und Konfiguration von Kubernetes-Clustern) bereit und dient als Einstiegspunkt für alle Befehle und Abfragen.

Grundlegendes Computer-Networking beinhaltet das Verbinden von zwei oder mehr Rechengeräten, um Daten zu teilen und Ressourcen auszutauschen, entweder über Kabel (kabelgebunden) oder WLAN.

Bei physischen Netzwerken werden physische Server an physische Netzwerkgeräte wie Switches, Router und Ethernet-Kabel angeschlossen, um eine Verbindung zum Internet herzustellen.

In virtuellen Netzwerken werden softwaredefinierte Netzwerke (SDN), Komponenten wie virtuelle Ethernet-Geräte und virtuelle Schnittstellen auf Bare Metal Servers oder virtuellen Maschinen installiert, um eine Verbindung mit dem Internet herzustellen. Die Kubernetes-Bereitstellung nutzt SDN, um die Netzwerkkommunikation zwischen Clustern zu konfigurieren und zu verwalten.

Bevor wir uns eingehender mit Kubernetes-Netzwerken befassen, lohnt es sich, grundlegende Netzwerkbegriffe zu wiederholen:

Netzwerk-Host: Ein Netzwerk-Host ist jeder Computer, der mit einem Netzwerk verbunden ist und anderen Hosts oder Knoten im Netzwerk Informationen, Anwendungen oder Dienste bereitstellt.

Internet Protocol (IP) Adresse: Eine IP-Adresse ist eine eindeutige Nummer, die jedem Gerät zugewiesen wird, das mit einem Netzwerk verbunden ist, das die IP-Adresse zur Kommunikation verwendet. Er identifiziert das Hostnetzwerk des Geräts und den Standort des Geräts im Hostnetzwerk.

Localhost: Localhost ist ein Standard-Hostname, der als private IP-Adresse fungiert und direkt auf den von ihnen verwendeten Computer oder das Gerät verweist.

Port: Ein Port identifiziert eine bestimmte Verbindung zwischen Netzwerkgeräten. Jeder Port wird durch eine Nummer identifiziert. Computer verwenden Portnummern, um zu bestimmen, welche Anwendung, welcher Dienst oder welcher Prozess bestimmte Nachrichten empfangen soll.

Netzwerkadressübersetzung (NAT): NAT wandelt interne oder private Adressen in öffentliche oder global routingfähige IP-Adressen um und ermöglicht so einen sicheren Internetzugang. NAT ermöglicht es, dass eine einzige, eindeutige IP-Adresse eine ganze Gruppe von Computergeräten repräsentiert.

Knoten-Agenten: Knoten-Agenten sind administrative Agenten, die Anwendungsserver auf einem Hostsystem überwachen und administrative Anfragen an andere Server weiterleiten.

 Netzwerk-Namespace: Ein Netzwerk-Namespace ist eine Sammlung von Netzwerkschnittstellen und Routing-Tabellenanweisungen, die eine Isolation zwischen Netzwerkgeräten gewährleistet.

Proxy oder Proxy-Server: Ein Proxy stellt ein Tor zwischen Benutzern und dem Internet bereit.

Kubernetes wurde entwickelt, verteilte Systeme mit einer über ein Cluster von Maschinen verteilten Netzwerkebene auszuführen. Die Kubernetes-Cluster-Vernetzung bietet nicht nur Konnektivität zwischen den Komponenten, sondern schafft auch eine nahtlose Umgebung, in der sich Daten durch Software-defined Networking (SDN) frei und effizient bewegen können.

Ein weiteres besonderes Merkmal des Kubernetes-Networking ist seine flache Netzwerkstruktur, was bedeutet, dass alle Komponenten verbunden werden können, ohne auf andere Hardware angewiesen zu sein. In Kubernetes kann jeder Pod in einem Cluster mit jedem anderen Pod kommunizieren, unabhängig davon, auf welchem Node er ausgeführt wird. Das flache Netzwerk bietet eine effiziente Möglichkeit zur gemeinsamen Nutzung von Ressourcen und macht eine dynamische Portzuweisung überflüssig.

Insgesamt abstrahiert das Kubernetes-Netzwerk die Komplexität und ermöglicht es Entwicklungs- und Operations-Teams, sich auf die Erstellung und Wartung von Anwendungen zu konzentrieren, anstatt sich mit komplizierten Netzwerkkonfigurationen zu beschäftigen.

Kubernetes bietet ein Networking-Modell, mit dem die Herausforderungen der Orchestrierung von Containeranwendungen in einer verteilten Umgebung bewältigt werden können. Die Containerlaufzeit auf jedem Knoten implementiert das Netzwerkmodell und folgt den folgenden Regeln:

Jeder Pod hat seine eigene IP-Adresse, die innerhalb des Clusters geroutet werden kann. Durch diese Funktion entfällt die Notwendigkeit, Verbindungen zwischen Pods und Mapping-Ports zu erstellen.

Da jeder Pod seine eigene IP-Adresse hat, ist NAT nicht erforderlich. Alle Pods können ohne NAT mit allen anderen Pods im Cluster kommunizieren.

Agenten auf einem Knoten, wie das Kubelet, der primäre Knoten-Agent, der auf jedem Knoten läuft, können mit allen Pods auf diesem bestimmten Knoten kommunizieren.

Das Kubernetes-Networking-Modell gilt für 4 grundlegende Arten der Kubernetes-Kommunikation:

Container sind die kleinste Einheit in einem Kubernetes-Netzwerk. In grundlegenden Netzwerkkonfigurationen kommunizieren Container innerhalb eines einzelnen Pods über localhost.

Diese Kommunikation ist möglich, weil Container im selben Pod denselben Netzwerk-Namensraum teilen, der Netzwerkressourcen wie Speicher, IP-Adresse und Port Space umfasst.

Pod-zu-Pod-Kommunikation umfasst die Kommunikation zwischen Pods am selben Knoten und die Kommunikation zwischen Pods auf verschiedenen Knoten. Jeder Pod in einem Kubernetes-Cluster hat seine eigene eindeutige IP-Adresse, die eine direkte Kommunikation zwischen Pods ermöglicht, unabhängig davon, auf welchem Knoten sie sich befinden.

Darüber hinaus stellt jeder Kubernetes-Cluster zusätzlich zur Pod-IP-Adresse automatisch einen Domain Name System Service (DNS-Dienst) bereit. Der DNS-Dienst, bei dem Pods und Diensten Namen zugewiesen werden, erstellt für Administratoren leicht lesbare Namen und bietet so einen einfachen Mechanismus zur Diensterkennung.

Ein Dienst in Kubernetes ist eine Abstraktion, die einen logischen Satz von Pods definiert und die Offenlegung des externen Datenverkehrs, den Lastausgleich und die Diensterkennung für diese Pods ermöglicht. Dienste erleichtern sowohl die Pod-to-Service- als auch die External-to-Service-Kommunikation.

Laut dem Kubernetes-Networking-Modell sind Pod-IP-Adressen kurzlebig. Wenn ein Pod abstürzt oder gelöscht wird und an seiner Stelle ein neuer Pod erstellt wird, erhält der neue Pod daher höchstwahrscheinlich eine neue IP-Adresse.

Bei der Pod-to-Service-Kommunikation ist ein ClusterIP ein Diensttyp, der einer Reihe von Pods eine stabile virtuelle IP-Adresse bereitstellt. Diese interne IP ist nur innerhalb des Clusters erreichbar und kann für die interne Kommunikation zwischen Pods und Services verwendet werden.

Der kube-Proxy, der auf jedem Node in einem Cluster installiert ist, unterhält Netzwerkregeln auf dem Host und überwacht Änderungen an Services und Pods. Wenn Pods erstellt oder zerstört werden, aktualisiert der kube-Proxy iptables (ein Hilfsprogramm zum Erstellen von Regeln in der Linux-Kernel-Firewall für die Weiterleitung des Datenverkehrs), um diese Änderung widerzuspiegeln, sodass der an die Dienst-IP gesendete Datenverkehr korrekt weitergeleitet wird.

External-to-Service-Networking bezieht sich auf die Bereitstellung von und den Zugriff auf Dienste, wie externe Dienste oder Datenbanken, von außerhalb des Kubernetes-Clusters.

Kubernetes bietet mehrere Dienste, um den externen Datenverkehr in einen Cluster zu erleichtern:

ClusterIP: Während ClusterIP der Standard-Kubernetes-Dienst für interne Kommunikation ist, kann externer Datenverkehr über den Kube-Proxy darauf zugreifen. ClusterIP kann hilfreich sein, wenn man auf einem Laptop auf einen Dienst zugreifen oder einen Dienst debuggt.

NodePort: Der NodePort stellt den Dienst auf einem statischen Port auf der IP jedes Knotens frei, sodass der Dienst außerhalb des Clusters zugänglich ist. Der NodePort ist die grundlegendste Möglichkeit zur externen Nutzung von Netzwerken und wird häufig zu Testzwecken verwendet, wie zum Beispiel beim Testen des öffentlichen Zugangs zu einer App.

LoadBalancer: Der Standard für externe Service-Netzwerke, der LoadBalancer stellt den Service extern frei, indem er den Load Balancer eines Cloud-Providers verwendet und dem Service eine öffentliche Adresse zuweist. Der Datenverkehr vom externen Load Balancer wird dann an die Backend-Pods weitergeleitet.

ExternalName: Ein externer Name-Service ermöglicht den Zugriff auf einen externen Dienst über DNS-Name, ohne ihn im Cluster offenzulegen. Diese Art von Dienst trägt dazu bei, einen stabilen DNS-Namen für externe Dienste bereitzustellen, beispielsweise für Messaging-Dienste, die nicht innerhalb des Clusters gehostet werden.

Ingress: Kubernetes Ingress ist eine Sammlung von Routing-Regeln, die den externen Zugriff auf Dienste innerhalb des Clusters regeln. Der Ingress-Controller ist ein Lastverteiler, der als Netzwerkbrücke zwischen Kubernetes-Diensten und externen Diensten fungiert.

Kubernetes-Netzwerkrichtlinien sind ein Anwendungskonstrukt, das eine wichtige Rolle im Kubernetes-Networking spielt. Mit diesen Richtlinien können Administrations- und Entwicklungsteams Regeln definieren, die festlegen, wie Pods miteinander und mit anderen Netzwerkendpunkten kommunizieren können.

Netzwerkrichtlinien werden über die Kubernetes Network Policies API angewendet und bestehen aus den folgenden Grundkomponenten:

Pod-Selektor: Der Pod-Selektor gibt an, für welche Pods die Richtlinie anhand von Labels und Selektoren gilt.

Ingress: Ingress definiert Regeln für eingehenden Datenverkehr zu Pods

Egress: Egress definiert Regeln für den ausgehenden Verkehr von Pods.

Kubernetes-Netzwerkrichtlinien helfen bei der Definition und Verwaltung von Sicherheitsrichtlinien, indem sie Regeln festlegen, die kontrollieren, welche Pods miteinander kommunizieren können, und so unberechtigten Zugriff und bösartige Angriffe verhindern.

Netzwerkrichtlinien sorgen auch für die Isolation zwischen Pods und Diensten, sodass nur diese Pods oder Dienste mit einer zugelassenen Gruppe von Peers kommunizieren können. Zum Beispiel ist die Isolation für mehreren Mandanten Situationen entscheidend, wenn DevOps- oder andere Teams denselben Kubernetes-Cluster gemeinsam nutzen, aber an verschiedenen Projekten arbeiten.

Für Unternehmen mit spezifischen Compliance-Anforderungen helfen Netzwerkrichtlinien bei der Festlegung und Durchsetzung von Netzwerkzugangskontrollen. Dies hilft bei der Einhaltung gesetzlicher Vorschriften und gewährleistet, dass der Cluster die Unternehmensrichtlinien einhält.

Container Network Interface (CNI, deutsch: Container-Netzwerk-Schnittstelle) ist eine weitere wichtige Funktion im Zusammenhang mit Kubernetes-Networking. CNI wird von der Cloud Native Computing Foundation entwickelt und verwaltet und wird von Kubernetes und anderen Container-Runtimes, einschließlich Red Hat OpenShift und Apache Mesos, verwendet. Es ist eine standardisierte Spezifikation und eine Reihe von APIs, die definieren, wie Netzwerk-Plugins das Container-Networking ermöglichen sollen.

CNI-Plugins können IP-Adressen zuweisen, Network Namespaces erstellen, Netzwerkrouten einrichten usw., um die Pod-to-Pod-Kommunikation sowohl innerhalb desselben Nodes als auch nodeübergreifend zu ermöglichen.

Während Kubernetes eine Standard-CNI bereitstellt, gibt es zahlreiche CNI-Plugins von Drittanbietern, darunter Calico, Flannel und Weave, die für die Konfiguration und Sicherheit in containerbasierten Netzwerkumgebungen konzipiert sind.

Auch wenn sie unterschiedliche Funktionen und Netzwerkansätze haben, wie Overlay-Netzwerke oder direktes Routing, halten sie sich alle an die CNI-Spezifikationen, die mit Kubernetes kompatibel sind.

Wenn Sie mit der Arbeit mit Kubernetes beginnen oder Ihre vorhandenen Kenntnisse über Kubernetes und die Tools des Kubernetes-Ökosystems erweitern möchten, sollten Sie eines dieser Tutorials ausprobieren.

• Kubernetes-Tutorials: Praxisnahe Übungen mit Zertifizierung
• Kubernetes-Tutorials auf IBM Developer
• 8 Tipps und Tricks zu Kubernetes
• Mit Kubernetes eine Microservices-App in IBM Cloud bereitstellen