Das manuelle Aufbauen einer Kubernetes-Infrastruktur auf physischer Hardware ist relativ aufwändig. VMwares Tanzu Kubernetes Grid erleichtert diesen Vorgang und stellt die Knoten eines Clusters auf VMs bereit. Der Admin sieht Kubernetes-Objekte als Elemente der vSphere-Bestandsliste.
Um vSphere mit Tanzu zu verstehen, ist es nützlich, erst die wichtigsten Kubernetes-Grundlagen zu rekapitulieren.
Kubertenes unter der Haube
Eine Besonderheit von Kubernetes und maßgeblich für dessen Erfolg ist die präzise Definition von Schnittstellen für Dinge, welche die Kubernetes-Entwickler nicht selber lösen, bzw. vorgeben wollten, etwa wie Storage- und Netzwerk-Infrastruktur „hinter“ Kubernetes aussehen. Die Spezifikation überlässt es also den Betreibern eines Kubernetes-Clusters, wie etwa Netzwerk- und Storage-Ressourcen bereitgestellt werden. Maßgeblich unter den zahlreichen Kubernetes-APIs seinen hier CRI, CNI, CSI genannt.
CRI, CNI und CSI
Da es Kubernetes relativ egal ist, wie ein Computer-Knoten beschaffen ist (VM oder Bare-Metal), entscheidet das Container Runtime-Interface (CRI) darüber, über welche Container-Engine elementare Operationen wie Run, Start, Stop usw. umgesetzt werden. Das muss nicht zwingend Docker sein. Kubernetes favorisiert hier seit einiger Zeit CRI-IO der Open Container Initiative (OCI).
Für alle Cluster-spezifischen Vorgänge kommt das Kubernetes-API in Form eines API-Servers zu Einsatz, der Anfragen vom kubelet auf dem Container-Host entgegennimmt oder an diesen weiterleitet.
Bei vSphere mit Tanzu ersetzt ESXi den Container-Host und ein Kernel-Modul namens Spherelet das kubelet eines Kubernetes-Knotens. Innerhalb eines so genannten nativen vSphere-Pods kommt mit der Container Runtime Executive (CRX) eine mit ESXi integrierte Container-Engine zum Einsatz. Sie ähnelt aus Sicht von hostd und vCenter Server einer VM, bzw. ist quasi eine VM in der VM.
Konkret enthält CRX einen stark paravirtualisierten Linux-Kernel (Photon), der mit dem ESXi-Hypervisor zusammenarbeitet. CRX verwendet dazu die gleichen Hardware-Virtualisierungstechniken wie VMs, ist aber von einer weiteren VM-Grenze umgeben.
Die Engine verwendet zudem eine Technik zum Direktstart, mit welcher der Linux-Gast von CRX den Hauptinitialisierungsprozess starten kann, ohne die Kernel-Initialisierung zu durchlaufen. Auf diese Weise können native vSphere-Pods fast so schnell wie Container starten.
Container Networking Interface (CNI)
Damit Nutzer von außerhalb des Kubernetes-Clusters Zugriff auf ihre Applikationen erhalten oder Anwendungskomponenten untereinander kommunizieren können, stellt Kubernetes eine weitere Abstraktionsschicht für virtuelle Netzwerke namens Container Networking Interface (CNI) bereit.
Kubernetes-Knoten sind dabei mit einem virtuellen Netzwerk verbunden und können eingehende und ausgehende Konnektivität für Pods bereitstellen. Die auf jedem Knoten ausgeführte Komponente kube-proxy stellt diese Netzwerkfunktionen bereit.
Dabei werden in Kubernetes Pods von so genannten Diensten logisch gruppiert, um den direkten Zugriff über eine IP-Adresse, einen DNS-Namen oder an einem bestimmten Port zu erlauben. Man kann den Datenverkehr aber auch über einen Load-Balancer verteilen.
Für die Sicherheit und das Filtern des Datenverkehrs von Pods sind Netzwerkrichtlinien zuständig, die bei vSphere intern zum Beispiel auf NSX-Policies abgebildet werden.
Bei den Diensten zur Gruppierung von Pods handelt es sich um:
- Cluster-IP: erstellt eine interne IP-Adresse zur Verwendung innerhalb des AKS-Clusters
- NodePort: erstellt eine Port-Zuordnung auf dem zugrunde liegenden Knoten, über die mithilfe von Knoten-IP-Adresse und Port der direkte Zugriff auf die Anwendung erfolgen kann
- LoadBalancer: erstellt eine Load Balancer-Ressource, konfiguriert eine externe IP-Adresse und verbindet die angeforderten Pods mit dem Load Balancer.
Ähnlich elegant bindet die CSI-Abstraktionsebene in Kubernetes mit so genannten Speicherklassen persistenten Speicher an.