VMware

VCF9 – Überblick über den vSphere Kubernetes Service

Veröffentlicht am

Dieser Beitrag ist der letzte in der VCF-9-Serie. Nachdem wir uns mit NSX als Netzwerk- und vSAN als Storage-Basis beschäftigt haben, geht es nun um die integrierte Komponente, die in der IT-Welt eine immer wichtigere Rolle spielt: vSphere Kubernetes Service, kurz VKS. VKS ist heute der zentrale Begriff für Kubernetes-Cluster auf vSphere bzw. VCF.

Es handelt sich dabei um einen Managed Kubernetes Service auf der VMware-Infrastruktur, welcher in vorherigen Versionen als „Tanzu Kubernetes Grid Service / vSphere with Tanzu“ bekannt war. Das Konzept und die Architektur haben sich in den Grundzügen nicht verändert, Kubernetes wird nicht neben der VMware-Plattform betrieben, sondern als nativer Workload in die VCF-Architektur integriert. Die meisten Änderungen betreffen die Tiefe der Integration und den Funktionsumfang.

Dieser Beitrag beschreibt den klassischen Architektur-Überblick: die drei Ebenen Supervisor, VKS Cluster und Namespaces, die Verbindung zur darunterliegenden VCF-Infrastruktur und die wichtigsten 9.1-Erweiterungen. Das Grundwissen über Kubernetes-Konzepte wie Pods, Cluster und Namespaces wird vorausgesetzt. Der Fokus liegt hier auf der Frage, wie Kubernetes in VCF integriert wird, nicht auf Kubernetes als solchem.

Drei Ebenen von VKS

VKS besteht aus Architektursicht aus drei aufeinander aufbauenden Schichten. Das Verständnis dieser Schichtung erklärt fast alle weitere Architekturkomponenten.

Die vSphere Workload Domain bildet das Fundament für den Aufbau der oberen VKS. Sie stellt die darunterliegende Infrastruktur bereit: ESXi-Hosts, vCenter, vSAN und NSX. Genau die Konstruktion, die in den vorherigen Beiträgen dieser Serie bereits behandelt wurde.

Auf diesem Fundament wird innerhalb einer Workload Domain ein vSphere Cluster als Supervisor aktiviert. Es handelt sich um ein in ESXi eingebettetes Kubernetes-Steuerwerk, das aus drei Control Plane VMs im HA-Verbund besteht.

Der Supervisor stellt eine Kubernetes-API bereit und bildet gleichzeitig die Plattform für die nächste Schicht, die sogenannten Supervisor Namespaces. Die Supervisor Namespaces dienen im Grobem als Mandanten- und Konsum-Grenze.

Innerhalb des einen Supervisor-Namespaces werden die einzelnen VKS Cluster erstellt. Diese sind vollwertige, CNCF-konforme Kubernetes-Cluster, deren Control Plane und Worker Nodes als VMs auf den ESXi-Hosts laufen.

Diese Aufteilung illustriert deutlich, die oft gestellte Frage: Warum braucht VKS zwei Kubernetes-Ebenen? Der Grund dafür liegt in der Aufgabentrennung. Der Supervisor ist aus der Perspektive Infrastruktur/Workload die Infrastruktur-Sicht. Er verwaltet, wo VKS Cluster laufen, wie sie skaliert werden, welche Storage-Klassen und Netzwerke ihnen zur Verfügung stehen.

Die VKS Cluster sind wiederum die Workload-Sicht. Sie tragen die eigentlichen Anwendungen und werden von Entwicklungsteams als klassische K8S-Cluster bereitgestellt, ohne dass diese mit der vSphere-Infrastruktur in Berührung kommen müssen. Diese Zweiteilung erlaubt es Plattform-Engineering-Teams, eine Self-Service-Schnittstelle bereitzustellen.

In VCF 9.1 wurde die Skalierung deutlich erhöht: Ein einzelner Supervisor kann bis zu 500 VKS Cluster mit insgesamt bis zu 4000 Cluster Nodes unterstützen. Damit lassen sich auch große Plattformen mit einem einzigen Supervisor betreiben, ohne mehrere Supervisor horizontal aufstellen zu müssen.

Supervisor im Detail

Wie bereits erwähnt, wird der Supervisor pro Workload Domain aktiviert. Das bedeutet konkret, dass drei dedizierte Control Plane VMs auf den ESXi-Hosts der Workload-Domain bereitgestellt werden und untereinander einen hochverfügbaren Cluster bilden. Diese VMs bilden gemeinsam die Kubernetes-basierte Steuerungsebene des Supervisors. Dazu gehören die bekannten Kubernetes-Komponenten wie API-Server, etcd, Scheduler und Controller-Manager.

Der Supervisor ist mehr weit mehr als eine reine Management-Ebene für Kubernetes-Cluster. Er fungiert als universelle Control Plane, die es ermöglicht, auch klassische virtuelle Infrastruktur-Ressourcen wie Code zu verwalten. Das beste Beispiel hierfür ist der VM Service. Über diese Schnittstelle können Entwickler traditionelle VMs deklarativ über die gewohnte Kubernetes-API (mittels YAML-Dateien) selbst provisionieren und verwalten.

In VCF 9.1 wird der VM Service durch Fast Deploy mit Linked Clones beschleunigt. Die neuen VMs lassen somit sich in Sekunden statt Minuten provisionieren.

Die Hauptaufgabe des Supervisors im VKS-Kontext bleibt jedoch die Bereitstellung der Supervisor Namespace und VKS Clusters. Wenn ein Plattform-Administrator die Erstellung eines neuen Clusters initiiert, ist es der Supervisor, der die Cluster-VMs erstellen lässt, das Netzwerk konfiguriert, die Storage Classes aus den vSAN-Policies ableitet und den Lebenszyklus übernimmt.

Namespaces als Konsum-Grenze

Normalerweise verwaltet ein einzelner Supervisor mehrere Cluster von mehreren Teams, die wiederum mehrere Anwendungen hosten. Der Supervisor Namespace bildet die Konsum- und Mandantengrenze zwischen diesen.

Ein Supervisor Namespace ist dabei wesentlich mehr als nur eine logische Trennung. Er definiert die Rahmenbedingungen, unter denen ein Team Ressourcen konsumieren darf. Dazu gehören:

  • Ressourcenquoten (CPU, Memory, Storage),
  • Vergabe von Berechtigungen über Rollen und Zugriffsrechte,
  • Verwaltung verfügbarer Storage Policies,
  • Festlegung erlaubter Image Registries,
  • Zulassung bestimmter VM Klassen,
  • Netzwerkzuordnungen.

Damit fungiert ein Supervisor Namespace ist klare Verwaltungsgrenze bzw. Übergabepunkt zwischen dem Plattform-Engineering-Team und den Entwicklerteams. Der Plattform Admin erstellt einen Namespace nach den gewünschten Anforderungen, während das Entwicklungsteam ihn eigenverantwortlich nutzt. Dies kann durch die Erstellung von VKS-Clustern innerhalb eines Namespaces oder durch das direkte Deployment von vSphere-Pods und -VMs erfolgen.

VKS Clusters und Cluster-Lifecycle

Ein VKS Cluster ist ein „normaler“ Kubernetes-Cluster im klassischen Sinne mit eigener Control Plane, eigenen Worker Nodes und eigenem API-Endpoint. Die Nodes laufen als virtuelle Maschinen auf den ESXi-Hosts der Workload Domain und dass der Cluster-Lifecycle vollständig durch den Supervisor verwaltet wird. Auch Supervisor selbst läuft als drei Control Plane VMs ebenfalls auf denselben ESXi-Hosts.

In VKS wird die Bereitstellung von Kubernetes-Clustern über das Cluster-API-Modell (CAPI) standardisiert. Die zentrale, besser gesagt globale „Bauvorlage“ (Blueprint) dafür ist die ClusterClass. Sie definiert die grundlegende Konfiguration jedes VKS-Clusters und legt fest, wie ein Cluster aufgebaut wird und welche Konfigurationsoptionen beim Erstellen oder Ändern eines Clusters verfügbar sind.

Mit VCF 9.1 wurde dieser Erstellungsvorgang an zwei Stellen spürbar optimiert.

Zum einen wird die CNI-Auswahl ab Kubernetes 1.35 zu einem deklarativen Schritt: Der Cluster-Ersteller wählt das CNI über die bootstrapAddons-Variable der ClusterClass aus. Antrea bleibt der Default, Cilium ist als Add-on Service verfügbar. Dies kann für Teams relevant sein, die Ciliums erweitertes Load-Balancing oder transparente Verschlüsselung nutzen möchten, ohne dabei den Lifecycle-Vorteil der VKS-Add-ons zu verlieren.

Zweitens beschleunigt Fast Deploy die Cluster- und VM-Provisionierung wesentlich. Dabei werden neue Cluster nicht mehr aus Vollkopien der Node-Templates, sondern aus Linked Clones erzeugt. Dadurch wird auch der Speicherverbrauch deutlich reduziert.

Die zugrunde liegende Kubernetes-Version wird in vSphere Kubernetes Releases (VKr) ausgeliefert. Der Release-Stream erhält regelmäßige Updates, auch für ältere Kubernetes-Versionen, innerhalb von 24 Monaten ab dem Datum der Veröffentlichung.

 

Quellen

, , , , , , , ,