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

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 hält 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. Die Spezifikation überlässt es aber 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.

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 zusammen­arbeitet. CRX verwendet dazu die gleichen Hardware-Virtualisierungs­techniken 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 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.

Kubernetes on-prem mit vSphere mit Tanzu

Da Software-definierte virtuelle Netzwerke und Software-definierter virtuelles Storage in der Public Cloud sehr einfach bereitzustellen sind, gehen viele Unternehmen heute dazu über, die Kubernetes-Angebote der großen Public-Cloud-Provider Google Kubernetes Engine (GKE), AWS Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) als Entwicklung- und Bereitstellungs­plattform für moderne Anwendungen zu nutzen.

Hier hat man zwar den Vorteil, mit dem Kubernetes Master den Cluster für die Kubernetes-Steuer­ebene mehr oder weniger automatisch hingestellt zu bekommen, allerdings bleiben dann Prozesse wie die Anbindung von virtuellen Netzwerken und Storage Provider-spezifisch und sind zudem erstmal vor dem Admin verborgen.

Allerdings wollen viele Unternehmen ihre Apps nicht in der Cloud entwickeln und betreiben, auch wenn der jeweilige Kubernetes-Service und die Cluster nicht zwingend öffentlich sein müssen. Außerdem liefert man sich dann einem Mietpreismodell ("Pay as you go") für die Compute-Ebene aus.

Mit vSphere mit Tanzu hingegen bilden vSphere-Nutzer Kubernetes-Dienste in ihrer vertrauten Umgebung ab, wobei VMware die Schnittstellen so nutzt, dass mit NSX-T automatisiert virtuelle Netzwerke und mit vSAN virtueller Speicher bereitgestellt werden kann.

Namespaces

Auch das Kubernetes-Konzept der Namespaces, welche ausgewählte Pods logisch gruppieren und mit Namespace-spezifischen Ressource-Limits ausstatten, findet sich in vSphere wieder. Auch hier legt ein Namespace die Ressourcen­grenzen fest, an denen native vSphere-Pods und Kubernetes-Cluster ausgeführt werden können.

Bei der erstmaligen Erstellung verfügt der Namespace über unbegrenzte Ressourcen im Supervisor-Cluster. Admins können aber Grenzwerte für CPU, Speicher, Speicher und die Anzahl der Kubernetes-Objekte festlegen, die im Namespace ausgeführt werden dürfen. Intern richtet vSphere für jeden Namespace einen Ressourcenpool ein.

Um DevOps-Entwicklern Zugriff auf Namespaces zu gewähren, weist der vSphere-Admin Berechtigungen an Benutzer oder Gruppen aus einer Identitätsquelle zu, die mit vCenter Single Sign On verknüpft ist.

Nachdem der vSphere-Admin einen Namespace mit Ressourcen- und Objekt­beschränkungen sowie Berechtigungen und Speicherrichtlinien konfiguriert hat, können Entwickler mithilfe der Kubernetes-Toolsets auf darauf zugreifen, um Kubernetes-Cluster zu erstellen und Workloads auszuführen.

Das Tolle an der Kubernetes-Interpretation von VMware ist, dass sie Entwicklern eine Sicht auf Kubernetes-Ressourcen im gewohnten Kontext der kubectl-Toolsets gewährt, die Kubernetes-Objekte aber für den vSphere-Admin als Bestandsobjekte sichtbar sind.

Namespaces sind also Bestandsobjekte, die Anwendungen als TKG-Cluster- oder vSphere-Pods-Deployments enthalten können.

vSphere-Administratoren profitieren also auch davon, dass sie die Kubernetes-Infrastruktur mit denselben Tools verwalten können, die sie für vSphere entwickelt haben, wobei der Namespace genau dasjenige Konstrukt ist, das diese beiden Welten zu verbindet.

Zusammenfassung

Ein Cluster, der mit vSphere mit Tanzu aktiviert ist, wird als Supervisor-Cluster bezeichnet. VMware bietet mit dem eingebetteten Tanzu Kubernetes Grid Service vollständig kompatible und konforme Kubernetes-Funktionen für containerisierte Anwendungen.

Dieser Ansatz stellt Entwicklern Kubernetes-APIs zur Verfügung und ermöglicht Continuous Integration sowie Continuous Delivery in einer globalen Infrastruktur, einschließlich lokaler Rechenzentren, Hyperskalierer und MSP-Infrastrukturen (Managed Service Providers).

Es vereint dann das Rechenzentrum und die Cloud mit einem integrierten Cloud-Betriebsmodell. Dort können DevOps Workloads ausführen, die aus Containern bestehen und in Tanzu-Clustern oder vSphere Pods laufen. Wer native vSphere Pods nutzen will, braucht indes NSX-T.