ake1150 - stock.adobe.com
So stellen Sie Kubernetes auf VMware mit vSphere Tanzu bereit
Wenn Sie im Unternehmen schon mit VMware und Kubernetes arbeiten, bietet es sich an, beides zusammenzulegen und VMware Tanzu zu nutzen. Wir erklären, wie der Einstieg gelingt.
VMware vSphere mit Tanzu ist eine gute Option für Unternehmen, die bereits mit VMware arbeiten und das Kubernetes-Clustermanagement zentralisieren möchten. IT-Teams nutzen mit Tanzu eine alternative – aber dennoch vertraute – Methode für die Arbeit mit Clustern.
vSphere ist hauptsächlich als Hypervisor für virtuelle Maschinen bekannt, es eignet sich aber auch für Kubernetes-Cluster mit Container-Workloads. Schauen wir uns an, was vSphere mit Tanzu bietet und wie man es zum Laufen bringt.
Wie vSphere mit Tanzu als Kubernetes-Cluster funktioniert
VMware vSphere mit Tanzu besteht aus zwei Hauptfunktionen: Es ermöglicht IT-Administratoren den Betrieb von Container-Workloads auf einem Hypervisor und das Bereitstellen von Kubernetes-Clustern in VMs. Damit funktioniert es wie ein Kubernetes-Cluster, das Cluster bereitstellt.
Wer sich mit Kubernetes auskennt, weiß, dass ein Deployment aus Control-Plane-Knoten besteht, die für die Verwaltung zuständig sind, und Worker-Knoten, auf denen die Container laufen. Um vSphere mit Tanzu einzurichten, benötigen Sie drei virtuelle Appliances in einem regulären vSphere-Cluster, dem sogenannten Supervisor-Cluster.
Abbildung 1 zeigt einen vSphere-Cluster namens SA-Compute-01 mit seinen drei Supervisor-Kontrollebenen-VMs. Diese drei VMs bilden die Master-Knoten des Clusters.
Die ESXi-Hosts im Cluster bilden die Worker-Nodes, sodass keine weiteren physischen Nodes oder VMs erforderlich sind. Die ESXi-Hosts werden direkt auf dem Hypervisor ausgeführt – oder technisch gesehen in einer kleinen dedizierten VM mit einer abgespeckten Photon OS Linux-Distribution, in der sich die Container-Engine befindet. Wie bei Kubernetes üblich, laufen Container in Pods, und bei vSphere mit Tanzu laufen sie folglich in vSphere Pods.
Manch einer mag sagen, dass vSphere Pods zusätzlichen Overhead verursachen und im Grunde dasselbe erreichen, wie das Installieren von Kubernetes in virtuellen Maschinen. Doch es gibt einen Unterschied: vSphere verwendet einen kleineren Linux-Kernel und lädt direkt in den ausführbaren Prozess der virtuellen Maschine (VMX), ohne den gleichen Boot-Zyklus wie eine normale VM zu durchlaufen. Daher lassen sich Container mit vSphere Pods genauso schnell starten wie auf jedem anderen Kubernetes-Arbeitsknoten.
In einem Kubernetes-Cluster führt jeder Worker-Knoten einen Prozess namens kubelet aus, der mit dem Scheduler auf dem Control-Pane-Knoten verbunden ist. In vSphere mit Tanzu führt jeder ESXi-Host einen Prozess namens spherelet aus, der dasselbe tut: Wenn die Kontroll-VMs des Supervisor-Clusters einen Container auf einem Host einplanen, lädt spherelet das Container-Image herunter und startet es in einem vSphere-Pod.
So richten Sie vSphere mit Tanzu ein
Beginnen Sie mit dem Bereitstellen der drei Steuerebenen-Appliances. Als Nächstes erstellen Sie einen Container im vCenter-Inventar des Namespace-Typs. Er erfüllt die gleiche Funktion wie ein Kubernetes-Namensraum, der die Grenzen dafür festlegt, wo Workloads ausgeführt werden. Abbildung 3 zeigt ein Namespace-Konfigurationspanel mit einer Speicherrichtlinie, die festlegt, wo Container-Speicher liegen darf und wer die Berechtigung hat, den Namespace zu nutzen.
Mit dieser Konfiguration führen Sie containerisierte Workloads auf die gleiche Weise aus, wie sie es normalerweise mit VMs tun. Sie sehen Ihre vSphere Pods im vCenter-Server-Inventar. Der einzige wirkliche Unterschied besteht darin, dass sie nicht über den vSphere-Client gesteuert werden, sondern über kubectl-Befehle wie jeder andere Kubernetes-Cluster. Entwickler nutzen Kubernetes also wie gewohnt.
Für die Netzwerkvirtualisierung benötigen vSphere Pods VMware NSX, da die virtuellen Netzwerkschnittstellenkarten mit Overlay-Segmenten verbunden sind, die für die Kommunikation innerhalb und zwischen physisch getrennten Pods auf vSphere-Hosts sorgen. Sie funktionieren genauso wie in regulären Kubernetes-Clustern, wo Administratoren beispielsweise Calico oder Antrea für diesen Zweck verwenden.
NSX bietet zudem die Möglichkeit, Load Balancer automatisch als Service bereitzustellen, wie in Abbildung 4 zu sehen ist. Das Bild zeigt einen automatisch bereitgestellten virtuellen Load-Balancer-Server in der NSX-Benutzeroberfläche. Sie nehmen hier jedoch keine Änderungen vor. YAML-Dateien steuern den Zugriff auf diese Seite.
VMware vSphere mit Tanzu kann Kubernetes-Cluster auch ohne vSphere Pods in VMs bereitstellen. Sie benötigen immernoch drei Supervisor-Control-Plane-VMs. Über diese Maschinen stellen die ESXi-Hosts die VMs bereit, auf denen Linux läuft. Diese VMs führen dann die Kubernetes-Kontrollebene und die Worker-Knoten aus. Man nennt diese Konstellation Tanzu Kubernetes Grid (TKG).
Abbildung 5 zeigt einen TKG-Cluster namens techtarget-tkg-02 mit drei VMs für die Steuerebene und fünf Worker-VMs. Diese Maschinen führen einen nativen Kubernetes-Cluster aus, ganz ohne VMware-Spezialitäten. Das ermöglicht einen vollständigen Root-Zugriff auf das Cluster und das Bereitstellen beliebiger Diensttypen in Kubernetes.
Für TKG-Cluster ist NSX nicht erforderlich; Sie benötigen jedoch einen Load Balancer, bevor vSphere mit Tanzu die Kubernetes-Cluster in VMs ausführen kann. Zum Zeitpunkt der Veröffentlichung sind die beiden unterstützten Load Balancer HAProxy und VMware NSX Advanced Load Balancer. Die letztgenannte Option bedeutet nicht, dass eine vollständige NSX-Bereitstellung erforderlich ist; dieser Load Balancer ist eine Weiterentwicklung des Avi Networks Load Balancers, den VMware vor einigen Jahren übernommen hat, und ein eigenständiges Produkt. Kunden, die den HAProxy Load Balancer einsetzen möchten, laden die virtuelle Appliance von GitHub herunter und setzen sie auf einem ESXi-Host ein.
Vorteile von vSphere mit Tanzu
Mit vSphere und Tanzu verwaltet der VMware-Software-Stack Kubernetes-Cluster-Bereitstellungen und der vSphere-Client stellt Updates zur Verfügung. Dies ermöglicht ein zentrales Kubernetes-Cluster-Management.
Es ist auch einfacher, Cluster nach Bedarf zu starten und herunterzufahren, was das Nutzen von Clustern für Tests und Entwicklung weniger zeitintensiv macht. Darüber hinaus arbeiten Entwickler mit Clustern über die kubectl-Befehle und YAML-Dateien, wie sie es von anderen Kubernetes-Umgebungen gewohnt sind.
