vSphere mit Tanzu Wie sich Kubernetes in die VMware-Umgebung einfügt

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-Bestands­liste.

Um vSphere mit Tanzu zu verstehen, ist es nützlich, erst die wichtigsten Kubernetes-Grundlagen zu rekapitulieren.

Kubertenes unter der Haube

Kubernetes kümmert sich in erster Linie um das Cluster-Management und weiß bei jedem neuen Workload, auf welchen Knoten es genügend Kapazität für die Platzierung eines Pods gibt. Es stellt zudem entsprechend viele Replikate bereit, sofern dies der Entwickler in seiner Deployment-Definition wünscht, startet Pods neu, wenn Knoten ausfallen, plant Pods neu ein, wenn Knoten die Kapazität ausgeht oder bildet Storage- und Netzwerk-Anforderungen der (statuslosen) Container-Anwendung auf externe Gegebenheiten ab.

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.

Aufbau eines Kubernetes-Clusters
Aufbau eines Kubernetes-Clusters.

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 zusammen­arbeitet. CRX verwendet dazu die gleichen Hardware-Virtualisierungs­techniken wie VMs, ist aber von einer weiteren VM-Grenze umgeben.

Abbildung von Kubernetes-Komponenten auf die VMware-Plattform
Abbildung von Kubernetes-Komponenten auf die VMware-Plattform.

Die Engine verwendet zudem eine Technik zum Direktstart, mit welcher der Linux-Gast von CRX den Haupt­initialisierungs­prozess 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 Anwendungs­komponenten untereinander kommunizieren können, stellt Kubernetes eine weitere Abstraktions­schicht 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 Netzwerk­funktionen 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 Netzwerk­richtlinien 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-Abstraktions­ebene in Kubernetes mit so genannten Speicherklassen persistenten Speicher an.

Hier weiterlesen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.