In diesem Blogbeitrag geht es um die Kubernetes Netzwerke. Hier werden folgende Komponenten erklärt: Node Network, Pod Network, Cluster Network, Kubernetes Ingress, Kubernetes Egress, Name-based Virtual Hosts, Path-based Routing, TLS Termination, Kubernetes DNS, Kubernetes CoreDNS.
Die ursprüngliche Visio-Datei können Sie unter folgendem Link herunterladen (Kubernetes_Network_Service_Types.vsdx)
Teil 2: Service Typen
Kubernetes Netzwerk
Das Kubernetes-Netzwerk ist ein virtuelles Netzwerk, welches in erster Linie dazu dient, die Kommunikation zwischen den Pods und anderen Diensten/Komponenten im Cluster zu ermöglichen.
Das Kubernetes-Netzwerk unterscheidet sich von anderen Netzwerktypen in mehreren Bereichen:
CNI-Plugin
Das CNI-Plugin (CNI steht für Container Networking Interface) ist in Grunde genommen eine Spezifikation für verschiedene Netzwerk-Plugins in Kubernetes. Das CNI-Plugin selbst dient zur Verwaltung der Netzwerkverbindungen zwischen Pods und Diensten innerhalb des Clusters. Es existiert bereits eine breite Palette von CNI-Plugins, die die Basis-Funktionalität wesentlich erweitern können. Mehr dazu auf dieser Seite www.github.com/cni
Service-Discovery
Service-Discovery wie der Name auch sagt, dient zur Erkennung der Services innerhalb eines Clusters, besonders wenn diese aus mehreren Containern bestehen und auch auf verschiedenen Knoten laufen. Außerdem ermöglicht Service-Discovery den Pods, andere Pods und Services im Cluster zu finden, ohne spezifische IP-Adressen kennen zu müssen.
Network-Policies
Die Network-Policies können den Netzwerkverkehr zwischen den Pods und Services im Kubernetes Cluster steuern. Die ermöglichen auch den Netzwerk-Traffic basierend auf IP-Adressen, Ports und anderen Merkmalen zu filtern.
Pod-to-Pod-Kommunikation
Die Pods, die auf verschiedenen Nodes aufgeführt werden, können miteinander ohne zusätzlichen speziellen Konfigurationen kommunizieren.
Netzwerk-Arten im Kubernetes Cluster
In einem Kubernetes-Cluster gibt es drei Arten von Netzwerken: das Node Network, das Pod Network / Cluster Network und das Service Network. Jedes Netzwerk erfüllt seine spezifische Rolle im Cluster.
- Node Network - Kommunikation zwischen den verschiedenen Worker- und Master-Knoten im Cluster.
- Pod Network - Kommunikation zwischen den einzelnen Pods im Cluster.
- Service Network - Abstrakte Schicht, die stabile Netzwerkzugriffspunkte für einen oder mehrere Pods bereitstellt.
Node Network
Das Node Network wird von Kubernetes verwendet, um die Kommunikation zwischen den Nodes im Cluster zu ermöglichen. Das Node Network wird für folgendes genutzt: den Clusterzustand zu synchronisieren, zur Lastverteilung zwischen den Nodes, für den Zugriff auf gemeinsam genutzte Ressourcen wie z.B. Storage.
Pod Network / Cluster Network
Das Pod Network dient verständlicherweise für die Kommunikation zwischen den Pods in einem Cluster, unabhängig davon auf welchen Cluster diese ausgeführt werden. Jeder Pod im Cluster hat seine eindeutige IP-Adresse, die innerhalb des gesamten Clusters nur einmal vorkommt. Das Pod-Netzwerk in Kubernetes wird durch CNI-Plugins bereitgestellt und verwaltet. Die Funktionsweise von CNI-Plugins wird weiter näher erläutert.
Die Begriffe "Cluster-Network" und "Pod-Network" werden oft als Synonyme gesehen. Da es in beiden Fällen um die Bereiche handelt, die für die Kommunikation zwischen Pods im Cluster verwendet werden.
Auf dem unteren Bild werden die IP-Adressen des Pod-Netzwerks angezeigt, die bei der Konfiguration von Calico-PlugIn eingegeben wurden.
Service Network
Dieser IP-Bereich wird für die Kubernetes-Services verwendet. Das Ziel des Service Networks ist, eine konstante IP-Adressen und DNS-Namen für einen oder mehreren Pods, die denselben Dienst repräsentieren, zuzuweisen.
Wenn die Konfiguration von Service Network nicht geändert wurde, werden die IP-Adresse aus dem Bereich 10.96.0.0/12 zugewiesen. So lässt sich die Konfiguration verifizieren:
kubectl get pods -n kube-system
kubectl describe pod <API_SERVER_POD_NAME> -n kube-system
Nach „--service-cluster-ip-range“ suchen.
Service Networks beinhaltet eine Reihe von Komponenten oder bessergesagt dazugehörigen Objekten:
Service-Objekt ist sozusagen ein Kern-Objekt des Service Networks und sorgt dafür, dass die zugrunde liegenden Pods über dauerhaften IP-Adressen oder DNS-Namen (abhängig vom Service-Typ) erreichbar sind. Dadurch wird erreicht, dass die IP-Adresse oder der DNS-Name des Services unverändert bleibt, auch dann, wenn die IP-Adressen der zugrundeliegenden Pods geändert werden.
Label-Selectors sorgen dafür, dass z.B. der Datenverkehr zu einer Gruppe von Pods geleitet wird, wenn diese Pods mit entsprechenden Labels versehen sind.
Load Balancing diese Option ist eigentlich selbsterklärend. LB sorgt für den gleichmäßigen Lastausgleich zwischen den verfügbaren Pods, die zum selben Service gehören.
Service-Typs es handelt sich dabei um die Methode, wie auf einen Service (z.B. ClusterIP, NodePort usw.) zugegriffen wird. Mehr dazu in Teil 2 des Beitrages.
EndpointSlice ist ein API-Objekt, welches von Control Nodes erstellt wird und Informationen über verfügbare Dienstinstanzen (Pods) und deren IP-Adressen/Ports speichert. Die Funktionsweise von EndpointSlice ist besonders dann sichtbar, wenn ein Service aus mehreren Pods besteht. EndpointSlice hilft dabei, den eingehenden Datenverkehr auf die Pods zu verteilen, indem es die Zuordnung von IP-Adressen und Ports zu den Pods organisiert und bereitstellt.
Kubernetes Ingress
Ingress ist eine Kubernetes-Ressource, die den Zugriff auf Services eines Clusters von außen ermöglicht. Ingress bietet mehrere Optionen zur Steuerung des eingehenden Netzwerkverkehrs. Der Traffic kann basierend auf Namen, Pfaden oder verschiedene Dienste innerhalb des Clusters verteilt werden. Ingress kann die Aufgaben eines Reverse Proxy übernehmen und somit den Zugriff auf einen oder mehrere interne Server von außen steuern. Außerdem kann zur SSL-Terminierung verwendet werden, um den SSL-Datenverkehr an einen Service weiterzuleiten.
Des Weiteren werden einige Ingress-Funktionsweisen erklärt:
Name-based Virtual Hosts
Ingress kann den eingehenden Datenverkehr basierend auf Hostnamen auf unterschiedliche Services innerhalb desselben Clusters verteilen. Diese Methode ist nützlich, wenn mehrere Anwendungen auf derselben Infrastruktur ausgeführt werden, z.B. wenn eine Anwendung unter "app1.example.com" und eine andere unter "app2.example.com" verfügbar sein sollte.
Path-based Routing
Ingress kann auch das Routing des eingehenden Datenverkehrs basierend auf bestimmten Pfaden bedienen. Das bedeutet, dass unterschiedliche Pfade auf verschiedene Services innerhalb des Clusters verweisen können, die aber auf denselben Cluster-IP-Adressen laufen. So lässt sich folgendes Szenario umsetzen, dass eine Anfrage an "/app1" auf einen Service und eine Anfrage an "/app2" auf einen anderen Service geroutet wird.
TLS Termination
Wie oben bereits erwähnt, kann auch Ingress als TLS-Terminierungspunkt dienen. Ingress kann die Entschlüsselung des eingehenden Datenverkehrs übernehmen und die Daten an den entsprechenden Service weiterleiten.
Service API vs. Ingress
Der Hauptunterschied zwischen der Kubernetes Service API und Ingress besteht darin, dass Kubernetes Service API auf OSI Layer 4 (Transport Layer) und Ingress auf OSI Layer 7 (Application Layer) arbeitet, und somit eine erweiterte Funktionalität für die Verarbeitung von HTTP-Verkehr bietet. Wenn es bei OSI Layer 4 hauptsächlich darum geht, die Datenpakete erfolgreich vom Sender zum Empfänger zu übertragen, beschäftigt sich Layer 7 mit den Anwendungen, die auf dieser Ebene tätig sind (z.B. E-Mail, Webbrowser usw.). Auch die Implementierung von Load Balancing Algorithmen oder TLS-Verschlüsselung findet auf der Anwendungsebene statt.
Open Source Ingress Controller
Es gibt verschiedene Open-Source-Ingress-Controller, die mit Kubernetes verwendet werden können. Die drei verbreitetste sind: Nginx, Traefik und Contour. Wobei Nginx Ingress Controller scheint der populärste von allen zu sein. Alle drei Controller haben ähnliche Funktionen (Reverse-Proxy, Load-Balancer, TLS-Terminierung) und unterscheiden sich in der Architektur und Implementierung. Die Wahl hängt von den spezifischen Anforderungen und Vorlieben ab.
Ingress Beispiel
apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: test-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /spec: rules: - host: example.com http: paths: - path: /app pathType: Prefix backend: service: name: test-service port: name: http
Im oberen Beispiel wird ein Ingress mit dem Namen test-ingress erstellt. Der Hostnamen example.com wird verwendet. Alle Anfragen, die auf den Pfad /app beginnen, werden an den Service mit namens test-service und dem Port http weitergeleitet. Die Annotation nginx.ingress.kubernetes.io/rewrite-target: / sorgt dafür, dass alle eingehende Anfragen an den Pfad / der Ziel-Service weitergeleitet werden.
Kubernetes Egress
Egress ist ein Antipode von Ingress. Egress beschäftigt sich verständlicherweise mit den ausgehenden Datenverkehr zu den externen Ressourcen oder APIs. Mit Egress lassen sich ebenfalls unterschiedliche Regeln definieren, um den Datenverkehr auf der Basis verschiedenen Attributen wie z.B. IP-Adressbereiche, Ports, Protokolle, Namespace-, Pod-, oder Service-Labels zu steuern. Die Egress-Regeln werden in den Network Policies konfiguriert. Hier ist ein Beispiel dafür:
Ergress Beispiel:
apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: allow-egressspec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.0/24 except: - 10.0.0.2/32
Im oberen Bespiel wird eine Network Policy namens "allow-egress". Die Policy wird auf alle Pods angewendet. Der Policy-Typ Egress zeigt, dass es sich um den ausgehenden Datenverkehr handelt. In diesem Beispiel darf der ausgehende Datenverkehr nur an einen bestimmten IP-Bereich (in diesem Fall 10.0.0.0/24) geleitet werden, außer einer Ausnahme (10.0.0.2).
Kubernetes DNS (kube-dns)
Kubernetes DNS (Domain Name System) ist eine integrierte Funktion von Kubernetes, die es Containern und Services im Cluster ermöglicht, über DNS-Namen anstatt über IP-Adressen zu kommunizieren. Dadurch kann die Kommunikation zwischen Containern und Services vereinfacht werden. (ab der Version 1.21 ist nicht mehr supportet)
Im Kubernetes Cluster wird der DNS-Service im diesem Format "service.namespace.svc.cluster.local" verwendet.
- service: der Name des Kubernetes-Services
- namespace: der Name des Namespaces, in dem sich der Service befindet
- svc: ein fester Teil des DNS-Namenschemas, zeigt, dass es sich um einen Service handelt
- local: der Standard-DNS-Name (ist anpassbar)
Kubernetes CoreDNS
Kubernetes CoreDNS ist ein spezielles DNS-Plugin, das als Standard-DNS-Server in Kubernetes-Clustern verwendet wird. CoreDNS erweitert die Basis-Funktionen und gibt z.B. die Möglichkeit, mehrere Domainnamen zu verwenden und DNS-Anfragen auf externe DNS weiterzuleiten. Ab der Version v1.26 ist CoreDNS die einzige unterstützte Cluster-DNS-Anwendung.
Hier sind die Vorteile aus der offiziellen Seite von CoreDNS: https://coredns.io
- Flexibilität: CoreDNS ist sehr flexibel und ermöglicht es Benutzern, benutzerdefinierte DNS-Server zu erstellen.
- Einfachheit: CoreDNS verwendet einfache und verständliche textbasierte Konfigurationsdateien Corefile).
- Performance: CoreDNS ist darauf ausgelegt eine hohe Leistung und geringe Latenzzeiten zu bieten.
- Erweiterbarkeit: Die CoreDNS Plugin-Architektur gibt es die Möglichkeit, neue Funktionen hinzuzufügen oder vorhandene Funktionen zu erweitern.
- DNS-Protokolle: CoreDNS unterstützt sowohl DNS-over-HTTP (DoH) als auch DNS-over-TLS (DoT)
So lassen sich DNS- oder CoreDNS-Pods anzeigen:
kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
Kubernetes Netzwerk-Plugins / Container Networking Interface (CNI)
Wenn man über Kubernetes Netzwerk-Plugins und CNI-Plugins spricht, ist meist dasselbe gemeint. CNI ist auch als eine Spezifikation zu verstehen, die von der Cloud Native Computing Foundation (CNCF) entwickelt wurde. Die Plugins erweitern die integrierte Netzwerkfunktionalität von Kubernetes wie z. B. Cluster-IP, NodePort oder LoadBalancer. Besonders in einem großen Cluster (mit vielen Pods und Nodes) kann die Nutzung von Plugins für bessere Skalierbarkeit und effizientere Lastverteilung sorgen sowie im Bereich Sicherheit viele Vorteile bieten. Die CNI-Plugins können verschiedene Arten von Netzwerken bereitstellen: Overlay-Netzwerke, Bridge-Netzwerke und Layer 3-Netzwerke.
Kubernetes unterstützt eine Vielzahl von CNI-Plugins, darunter Flannel, Cilium, Calico, Weave Net und andere. Die Wahl des CNI-Plugins hängt von den spezifischen Anforderungen und der Infrastruktur des Kubernetes-Clusters ab. Weitere Information zum Thema: www.cni.dev und github.com/containernetworking/plugins
Flannel
Flannel ist ein beliebtes CNI-Plugin, das ein Netzwerk von flachen Subnetzen über eine UDP-basierte Overlay-Netzwerktechnologie erstellt. Flannel ist einfach zu konfigurieren und verwendet dabei entweder die Kubernetes-API oder etcd direkt, um die Netzwerkkonfiguration, einschließlich zugewiesener Subnetze und aller Zusatzdaten, zu speichern. Im Vergleich zu anderen Plugins z. B. Calico oder Cilium, ist Flannel weniger funktionsreich. Mehr dazu: github.com/flannel-io/flannel
Cilium
Cilium ist ein leistungsstarkes CNI-Plugin, das auf eBPF (erweitertem Berkeley Packet Filter) aufbaut und umfangreiche Netzwerkrichtlinien sowie Sicherheitsfunktionen bereitstellt, wie z.B. das API-Sicherheit, dienstbasierten Schutz, sicheren Zugriff auf externe Dienste, einfaches Networking, Lastverteilung, Bandbreitenmanagement und Monitoring bietet. Die aktuelle Version ist v1.13.1.
Für weitere Informationen und Anleitungen zu Cilium, besuchen Sie die offiziellen Seiten des Projekts https://github.com/cilium/cilium oder https://cilium.io
Calico
Calico ist ein leistungsstarkes und funktionsreiches CNI-Plugin, welches von der Firma Tigera mitentwickelt wird. Calico ist skalierbar und kann sowohl in der Cloud als auch On-Premise eingesetzt werden, unabhängig von der Größe des Clusters. Werbetext 😉 „Calico ist eine flexible und sichere Netzwerklösung für verschiedene Workloads und Plattformen, die die Kommunikation und Sicherheit von Workloads in verschiedenen Umgebungen optimiert.“ Die Funktionalität von Calico ist nicht auf Kubernetes beschränkt. Es kann auch für virtuelle Maschinen und Bare-Metal-Workloads eingesetzt werden.
Mehr zu Calico: www.projectcalico.org und https://github.com/projectcalico/calico
Antrea
Antrea ist eine Kubernetes-native Netzwerklösung, die auf Open vSwitch basiert. Antrea ist nicht so funktionsreich wie z.B. Calico, hat aber auch eine breite Palette an Funktionen. Hier sind einige von denen: Kubernetes-native Abstraktionen und Erweiterung der Kubernetes-APIs, Hardware-Offloading-Unterstützung, erweiterte clusterweite Netzwerk-Policies, Tools zur Überwachung und Fehlersuche. Antrea ist das Standardprotokoll für "vSphere with Tanzu", alternativ kann aber auch Calico genutzt werden.
Mehr zu Antrea: https://antrea.io und https://github.com/antrea-io/antrea