Die prinzipielle Architektur von "Kubernetes auf vSphere" umfasst einen VM-basierten Supervisor-Cluster, ESXi-basierte Compute-Nodes samt Spherelet (die VMware-Variante eines Kubelet) und die Container-Engine CRX. Dieser Aufbau bietet zudem die Möglichkeit, je nach verwendeter Netzwerkvirtualisierung entweder native vSphere-PODs zusammen mit Tanzu-Kubernetes-Grid-Clustern (bei denen dann Kubernetes-Control-Plane sowie Compute-Knoten aus VMs bestehen) oder ausschließlich Letztere bereitzustellen. Dies kommt beim Verwenden von vSphere-Netzwerken mit Distributed Switches in Frage.

Wichtig für die Konnektivität der Kubernetes- Steuerungsebenen-VMs ist, dass sich Dienste und Arbeitslasten im Supervisor- Cluster seit vSphere 7 entweder mit vSphere-Netzwerk-Stack oder VMware NSX-T Data Center verwenden lassen. Dabei ist das für Tanzu-Kubernetes-Cluster verwendete Netzwerk, das vom Tanzu- Kubernetes-Grid-Dienst (TKG) bereitgestellt wird, einerseits das Fabric, das der "vSphere-mit-Tanzu"-Infrastruktur zugrunde liegt. Dazu gesellt sich eine Open- Source-Software, die Netzwerke für Cluster- Pods, Dienste und Ingress bereitstellt. Diese Flexibilität beim Netzwerkdesign rührt daher, dass Kubernetes mit der verteilten Konfigurationsdatenbank "etcd" im Zentrum und den drum herum gestrickten APIs (verwaltet durch den APIServer) sehr klug entwickelt wurde.

Vom Grundsatz her ist Kubernetes als eine Art Middleware konzipiert und weiß daher, dass es mit umgebenden Systemen kommunizieren muss, und zwar nach oben und nach unten. Dazu hat Kubernetes zahlreiche Schnittstellen geschaffen, sodass sich andere Projekte darum kümmern können, was dahinter passiert. Beim Netzwerk betrifft das beispielsweise das Container-Network-Interface CNI. Da die Kubernetes-APIs sehr flexibel konzipiert sind, fügt sich Kubenetes-Networking auf Wunsch in Azure Kubernetes Service, den Elastic Kubernetes Service von AWS, die Google Kubernetes Engine oder vSphere ein.

Natürlich ist hierbei trotzdem eine Menge Arbeit zu erledigen, wie etwa das Planen und Reservieren der benötigten Adressbereiche, aber Kubernetes lässt bewusst offen, wie sich das im Detail darstellt. Darüber können sich dann diejenigen Experten Gedanken machen, die jeweils zuständig sind, in diesem Fall also die Netzwerk-Profis und hier speziell im Kontext von VMware.

Im Fall des Container-Network-Interface sieht das ungefähr so aus: Kubernetes stellt zunächst sicher, dass jeder POD, der auf Kubernetes läuft, eine eigene IP-Adresse bekommt und dass mehrere PODs miteinander kommunizieren können. Dabei ist es unerheblich, ob diese auf demselben oder unterschiedlichen Knoten laufen. Dazu müssen Sie sich wie erwähnt bei der IP-Adressvergabe mit den eigenen Netzwerktechnikern außerhalb von Kubernetes abstimmen. Kubernetes verlangt lediglich, dass jeder POD eine IP-Adresse erhält und dass PODs miteinander reden können – oder eben auch nicht.

Kubernetes kennt nämlich auch Firewallähnliche Konstrukte, die sogenannten Network Policies. Auch dieses mächtige Konzept setzen die Kubernetes-APIs mithilfe einer unterstützten Open-Source- Software wie zum Beispiel Calico [1] um. Dabei kann der Firewall-Designer für mehrere PODs relativ einfach beschreiben, dass etwa App 1 auf App 2 zugreifen darf, aber nicht andersherum. Um dies mit mehreren Apps von Hand zu realisieren, müssten Sie sich mit einer großen Anzahl von Firewall-Regeln auseinandersetzen. In Calico/Kubernetes sehen solche Regeln (App 1 mit App 2, aber App 2 nicht mit App 1) hingegen sehr einfach aus.

Calico erzeugt automatisch die zahlreichen Einzelregeln, die bestimmen, welcher POD zum jeweiligen Zeitpunkt gerade in welcher Weise und mit welchem anderen POD kommunizieren darf. Auf diese Weise können Sie beispielsweise Ihre DMZ komplett auf Kubernetes verlagern. Und da letztendlich alles nur Software ist, sind Sie auch in der Lage, beliebig viele DMZs zu erzeugen (Mikrosegmentierung), was bei VMware vor allem das NSX-T-Fundament ermöglicht.

Ferner optimiert Kubernetes die Kommunikation zwischen den einzelnen PODs durch die automatische Bereitstellung von Loadbalancern (bei Kubernetes "Services" genannt). Damit lässt sich App 1 so konfigurieren, dass sie für den Zugriff auf App 2 den Loadbalancer kontaktiert, in diesem Fall eine virtuelle IPAdresse. Kubernetes regelt dann den Zugriff auf die virtuelle IP-Adresse so, dass App1 bei einem der Knoten von App2 landet. Das Loadbalancing ist direkt in Kubernetes eingebaut, kann aber über die entsprechenden APIs auch durch eine andere Software erledigt werden, wie zum Beispiel Azure Loadbalancer oder NSXEdges unter VMware. Kommt allerdings bei VMware nur der vSphere-Netzwerk- Stack zum Einsatz (Distributed Switch), müssen Sie den Lastausgleichsdienst durch eine externe virtuelle Appliance mit HAProxy bereitstellen. VMware stellt dazu ein per VAMI anpassbares HAProxy- OVA [2] auf Github zur Verfügung.

Um App1 nicht die virtuelle IP-Adresse des Lastausgleich-Services beibringen zu müssen, steht im Umfeld der Kubernetes- Kerndienste ein DNS-Service zur Verfügung. Der erlaubt es, dass Sie App1 dazu veranlassen, einen DNS-Lookup mit dem Namen "App2" durchzuführen. Der DNS-Dienst liefert die virtuelle IP-Adresse des Services als Antwort. Aber auch solche Kernkomponenten sind austauschbar. Populär ist es, beispielsweise die Standard- Konfigurationsdatenbank "etcd" durch Hashicorp Consul zu ersetzen, das dann auch gleich das Service-Discovery und den DNS-Dienst übernimmt. Kubernetes schreibt auch nur recht abstrakt vor, wie Netzwerkverkehr in den Cluster gelangt – etwa per Gateway oder Reverse- Proxy. Dabei laufen alle genannten Komponenten selbst als Kubernetes-PODs im Cluster. Der Reserve-Proxy verteilt dann die Aufrufe auf die verschiedenen Dienste im Cluster. Bei VMware kommt dazu wie erwähnt NSX-T oder wie im folgenden Light-Szenario erläutert HAProxy zum Einsatz.

Das Aktivieren von Kubernetes in vSphere geschieht im vSphere-Client im "Workload-Management". VMware hat der Funktion einen eigenen Hauptmenü- Eintrag "Arbeitslastverwaltung" spendiert. Hier fügen Sie im Reiter "Cluster" einen bestehenden Host-Cluster hinzu, nachdem Sie die netzwerktechnischen Voraussetzungen (NSX-T oder DVS/HAProxy) geschaffen haben. Soll vSphere-Networking (DVS) zum Einsatz kommen, müssen Sie zunächst die zu verwendenden Adressbereiche planen und entsprechenden DVS-Portgruppen zuweisen. Wird der Supervisor-Cluster durch einen vSphere Distributed Switch gestützt, kommen wie erwähnt verteilte Portgruppen als Arbeitslastnetzwerke für Namespaces zum Einsatz.

Natürlich können Sie auch mehrere Workload- Netzwerke betreiben. Die Workload- Netzwerke dienen der Verbindung zu den Knoten von Tanzu-Kubernetes-Clustern sowie zu den VMs der Supervisor-Cluster- Control-Plane. Dasjenige Workload- Netzwerk, das die Konnektivität zu den Kubernetes-Steuerungsebenen-VMs zur Verfügung stellt, heißt übrigens "primäres Arbeitslastnetzwerk". Jeder Supervisor- Cluster muss zwingend eines davon haben, und sie lassen sich zudem ausschließlich im Verlauf der Aktivierung des Supervisor- Clusters hinzufügen, nicht später.

Dabei nutzen die drei Kubernetes-Steuerungsebenen- VMs des Supervisor-Clusters drei IP-Adressen aus dem IP-Adressbereich, den Sie für das primäre Workload- Netzwerk eingeplant haben. Jeder Knoten jedes Tanzu-Kubernetes-Clusters hat dann eine eigene IP-Adresse, die aus dem Adressbereich des zugehörigen Workload- Netzwerks stammt. Dieses ist dann mit dem Namespace konfiguriert, in dem der Kubernetes-Cluster läuft. Summa summarum müssen Sie also die zu verwendenden Adressbereiche sorgfältig planen. Minimal brauchen Sie wie erwähnt zwei davon: Einen für die Knoten des Supervisor- Clusters sowie die Kubernetes-Cluster- Knoten und einen weiteren für die Zuteilung der virtuellen IP-Adressen von HAProxy. VMware schlägt in seiner Tanzu-Dokumentation folgende Bereiche für ein 24-er Netzwerk vor:

- Netzwerk: 192.168.120.0/24

- HAProxy-VIPs: 192.168.120.128/24

- Eine IP-Adresse für das HA-Proxy-Workload-Interface: 192.168.120.5

In Abhängigkeit der IP-Adressen, die innerhalb der ersten 128 Adressen frei sind, können Sie IPBereiche für Arbeitslastnetzwerke definieren, zum Beispiel 192.168. 120.31 bis 192.168.120.40 für das primäre Arbeitslastnetzwerk und 192.168.120.51 bis 192.168.120.60 für ein weiteres Arbeitslastnetzwerk. VMware schlägt in seiner Tanzu-Dokumentation verschiedene Workload-Netzwerk-Topologien vor:

- Ein Arbeitslastnetzwerk

- Ein isoliertes Arbeitslastnetzwerk

- Ein isoliertes Netzwerk für Workloads

- Mehrere isolierte Arbeitslastnetzwerke

- Mehrere isolierte Workload-Netzwerke

- Eine HAProxy-Konfiguration mit drei virtuellen Netzwerkkarten und isoliertem Frontend-Netzwerk

Für welche Variante Sie sich entscheiden, hängt von Ihren spezifischen Ansprüchen ab. Hier bewegen Sie sich irgendwo zwischen einfacher Verwaltbarkeit und höchstmöglicher Isolation. In der ersten Variante legen Sie eine Portgruppe als primäres Arbeitslastnetzwerk für den Supervisor-Cluster fest und nutzen diese gleichzeitig als Portgruppe für Supervisor- Namespaces. In diesem Fall stellen Supervisor-Cluster, Tanzu-Kubernetes- Cluster, HAProxy, DevOps-Benutzer und externe Dienste ihre Verbindung über die gleiche verteilte Portgruppe her.

Im zweiten Fall ist der Supervisor-Cluster mit der als primäres Arbeitslastnetzwerk bezeichneten Portgruppe verbunden und der Kubernetes-Cluster mit einer anderen verteilten Portgruppe. Beide müssen für ein Schicht-3-Routing geeignet sein, während Sie eine Schicht-2-Isolierung mit VLANs realisieren. Im dritten Fall mit mehreren isolierten Arbeitsplatznetzwerken können Sie wieder eine Portgruppe als primäres Arbeitslastnetzwerk konfigurieren und dann je eine dedizierte Portgruppe als Arbeitslastnetzwerk für jeden einzelnen Namespace. HAProxy kommt wie auch bei den vorherigen Szenarien mit zwei virtuellen Netzwerkkarten zum Einsatz und Sie können eine Verbindung entweder mit dem primären Arbeitslastnetzwerk oder den anderen Arbeitslastnetzwerken herstellen. In der HAProxy-Konfiguration mit drei virtuellen Netzwerkkarten können Sie HAProxy auch mit einem Frontend-Netzwerk verbinden.

Die Entscheidung für die jeweilige Topologie hängt letztendlich davon an, wie Benutzer oder externe Dienste auf Ihre vSphere-Umgebung zugreifen dürfen. Bei nur einem Arbeitslastnetzwerk für alles senden Benutzer oder externe Dienste den Datenverkehr an eine virtuelle IP-Adresse in einem Subnetz des Arbeitslastnetzwerks der verteilten Portgruppe. HAProxy sorgt dann für den Lastenausgleich des vir - tuellen IP-Datenverkehrs zur IP-Adresse des Tanzu-Ku - bernetes-Knotens oder zur IP-Adresse der Control-Pla ne- VM. Das heißt, HAProxy beansprucht die virtuelle IP-Adresse, um die Last des auf dieser IP-Adresse eingehenden Datenverkehrs auszugleichen. Die Control-Plane-VM oder der Kubernetes-Cluster-Knoten leitet den Datenverkehr dann an den Ziel-Pod weiter, der entweder im Supervisor- Cluster oder im Tanzu-Kubernetes- Cluster läuft.

Im Szenario mit isoliertem Arbeitslastnetzwerk ist das genauso. Der Datenverkehr wird hierbei aber nur an genau dasjenige Netzwerk weitergeleitet, das mit HAProxy verbunden ist. Sie müssen sich also nur die Frage stellen, ob Sie eine Schicht-2-Isolation zwischen dem Supervisor-Cluster und dem Tanzu-Kubernetes-Cluster benötigen. Falls ja, greifen Sie zur Workload-Netzwerk- Topologie mit getrennten primären und Arbeitslastnetzwerken. Nur wenn Sie eine weitere Schicht-2-Isolierung zwischen mehreren Tanzu-Kubernetes-Clustern benötigen, greifen Sie zur Topologie mit getrennten Arbeitslastnetzwerken für jeden Namespace.

Wollen Sie zusätzlich verhindern, dass Benutzer oder externe Dienste direkt zu VMs der Control-Plane von Kubernetes oder Kubernetes-Cluster-Knoten geroutet werden können, greifen Sie zur Topologie mit HAProxy mit drei virtuellen Netzwerkkarten und separatem Frontend-Netzwerk. Haben Sie sich für eine Netzwerktopologie und Adressbereiche entschieden, ist das Aufsetzen des Supervisor-Clusters mit HAProxy nicht mehr weiter schwierig. Allerdings müssen Sie zuvor noch weitere Vorbereitungen treffen.

Erstellen Sie zunächst in vSAN eine Speicherrichtlinie für die Verwendung mit dem Supervisor-Cluster. Sie können für erste Experimente durchaus die StandardvSAN- Policy kopieren und Sie beispielsweise "k8s-storage-policy" nennen. Außerdem müssen Sie zwei Inhaltsbibliotheken erstellen. Eine vom Typ "lokal" zur Aufnahme der HAProxy-OVAs.

Diese laden Sie von [3] herunter und importieren sie in die Content Library. Über die zweite Inhaltsbibliothek vom Typ "Abonniert" mit der Subscription-URL "https://wp-content.vmware.com/v2/latest/ lib.json" stellt VMware fortlaufend Updates für seine Tanzu-Kubernetes- Grid-Distribution zur Verfügung.

Dann stellen Sie die HAProxy-VM auf Basis der OVA aus der Inhaltsbibliothek bereit. Im OVA-Bereitstellungsassistent wird es dann im Abschnitt "Konfiguration" spannend. Hier stehen die Optionen "Default" mit zwei und "Frontend Network" mit drei Netzwerkkarten zur Auswahl. Im Punkt "Netzwerke auswählen" weisen Sie jedem Netzwerktyp (Management, Workload, Frontend) eine der vorbereiteten DVS-Portgruppen zu, wobei Sie die größte Aufmerksamkeit dem Abschnitt "Vorlage anpassen" widmen müssen. Legen Sie bei "Network Config" die von Ihnen zuvor identifizierten IP-Adressen und Netzwerkbereiche für HAProxy im Management- und im Workload- Netzwerk im CIDR-Format bei "Management- IP" und "Workload IP" fest. Die übrigen Einstellungen (Host-Name, DNS, Management-Gateway und Workload- Gateway) sind selbsterklärend.

Im Abschnitt "Load Balancing" hinterlegen Sie bei "Load-Balancer IP-Ranges" den vorab identifizierten Netzwerkbereich für die IP-Adressen des Loadbalancers in CIDR-Notation, zum Beispiel "172.20.10. 160/29". Außerdem müssen Sie den "Management- Port für die Dataplane-API" angeben, der Default-Wert ist 5556. Zudem definieren Sie hier den HAProxy- Admin-User und sein Passwort. Haben Sie im letzten Abschnitt "Bereit zum Abschließen" die Zusammenfassung überprüft, können Sie die VM bereitstellen.

Sobald die HAProxy-VM läuft, wechseln Sie im vSphere-Client im Hauptmenü zu "Arbeitslastverwaltung" und erstellen einen neuen Supervisor-Cluster. Bei "vCenter Server und Netzwerk" wählen Sie nun aber nicht "NSX-T", sondern "Distributed Switch", und dann unter "Cluster" den gewünschten Host-Cluster aus. Die Angaben bei "Größe der Steuerebene" und "Speicher" passen Sie ihren Gegebenheiten an.

Aufmerksamkeit verdient dann der "Lastausgleichsdienst". Hier tragen Sie zunächst einen Namen für ihn ein und wählen dann als Typ "HAProxy". Jetzt versorgen Sie bei "API-Adresse(n) der Datenebene" die Management-IP von HAProxy im Managementnetzwerk mit dem zuvor festgelegten Port 5556. Ferner müssen Sie hier Benutzername und Passwort des HAProxy- Admin-Users eingeben. Das Feld "IP-Adressbereich für virtuelle Server" nimmt die erwähnte IP-Range des Loadbalancers auf, aber diesmal im Gegensatz zur OVA-Bereitstellung nicht in CIDRNotation, also etwa "172.20.10.160 - 172.20.10.167". Schließlich müssen Sie das Root-Zertifikat der "Zertifizierungsstelle für den Server" einfügen. Das können Sie per Copy und Paste machen, wenn Sie sich dazu mit der Konsole der HAProxy- VM verbinden und die Datei "/etc/haproxy/ server.crt" öffnen.

Bei "Verwaltungsnetzwerk" müssen Sie die DVS-Portgruppe des Managementnetzwerks sowie die IP-Startadresse des Supervisor-VM-Adressbereiches (192.168. 0.180-190) angeben. Die übrigen Einstellungen sind wieder selbsterklärend.

Schließlich konfigurieren Sie noch das Workload-Netzwerk. Im Fall nur eines Workload-Netzwerks wird dieses sowohl von den Supervisor-Steuerebenen-Knoten als auch von den TKG-Gast-Cluster-Knoten verwendet. Daher erhalten die Knoten der Supervisor-Steuerebene eine zweite Netzwerkschnittstelle, die sich mit der Portgruppe des Workload-Netzwerks verbindet. Nach Fertigstellen des Setups verfügen die VMs der Supervisor-Steuerebene über Netzwerkschnittstellen sowohl im Verwaltungsnetzwerk als auch im Workload- Netzwerk. Den Default-Eintrag bei "Dienste-IP-Adresse" können Sie unverändert lassen. Der gefragte DNS-Server ist derjenige im Workload-Netzwerk. Nun fügen Sie bei "Arbeitslastnetzwerk" Ihr primäres Workload-Netzwerk hinzu. Dieses bekommt die DVS-Portgruppe für das Workload-Netzwerk sowie ein Default- Gateway im Workload-Netzwerk und den zugehörigen Workload-IP-Bereich, hier erneut nicht als CIDR.

Haben Sie die Konfiguration im Schritt "Überprüfen und Bestätigen" überprüft, lassen Sie den Supervisor-Cluster erstellen. Das kann bis zu 45 Minuten in Anspruch nehmen. Anschließend müssen Sie den Cluster im Lizenzmanagement mit einer "vSphere-mit-Tanzu"-Lizenz versehen. Lohn der Mühe sind dann zunächst drei neue "SupervisorControlPlaneVMs" in der Bestandsliste des vSphere-Clients. Später können Sie im Menü "Workload-Management" weitere Namespaces definieren und dort dann TKG-Cluster bereitstellen, in denen schließlich die Kubernetes-Deployments starten.

Böse Zungen behaupten, Kubernetes würde mit maximaler Komplexität ermöglichen, lediglich ein "Hello World" bereitzustellen. Ein Fünkchen Wahrheit steckt schon in dieser Aussage. Dennoch ist VMwares Entscheidung, nativen Kubernetes- Support in vSphere vom Vorhandensein des Cloud-Foundation-Stapels mit NSX-T abhängig zu machen, sicher richtig. Unternehmen, die verteilte cloudnative Anwendungen auf der eigenen Infrastruktur entwickeln und betreiben wollen, haben in der Regel auch die Größe, für die das Vorhandensein des Cloud Foundation Stacks selbstredend ist. Mit vSphere 7 Update 1 können sich nun aber auch kleinere Unternehmen von der Mächtigkeit des Konzepts überzeugen.