vSphere mit Tanzu auf Basis von vSphere-Networking (Distributed vSwitch) einrichten

Mit TKG lassen sich eigene Kubernetes-Cluster einschließlich Management- und Compute-Knoten auf Basis von VMs bereitstellen. Diese Variante ist Gegenstand der folgenden Anleitung.

Man unterscheidet dabei das Supervisor-Cluster-Netzwerk, welches wir in hier mit dem vSphere-Stack (Distributed vSwitch) errichten, und das Tanzu Kubernetes-Cluster-Netzwerk. Letzteres wird vom Tanzu Kubernetes Grid-Dienst bereitgestellt und unterstützt zwei Optionen für das Kubernetes Network Interface API (CNI), nämlich Antrea (Standard) und Calico. Bei beiden handelt es sich um Open-Source-Software.

Voraussetzungen und Vorbereitungen

Um diesen Workshop nachvollziehen zu können, müssen Sie folgende Vorbereitungen treffen:

• Stellen Sie sicher, dass sowohl DRS als auch HA in Ihrem Cluster aktiviert sind.
• Erstellen Sie für alle Hosts im Cluster einen Distributed vSwitch und legen auf diesem mindestens zwei (oder drei) Portgroups für Management (Supervisor), Workload und Frontend an. Diese sollten sich in eigenen VLANs befinden.

Die Port-Gruppe Frontend-Network wird nicht zwingend benötigt. Die Entscheidung dafür hängt davon ab, ob und wie sehr Sie die einzelnen Traffic-Arten voneinander isolieren möchten und ob Sie Workloads mit externem Zugriff planen. Abhängig davon kann die HA-Proxy-VM mit 2 oder 3 virtuellen Netzwerk­karten ausgestattet werden. Details dazu verrät die HA-Proxy-Dokumentation von VMware.

Im einfachsten Fall konfigurieren Sie einen Supervisor-Cluster mit einem Netzwerk für die VMs der Kubernetes-Steuerungsebenen und die Knoten von Tanzu Kubernetes-Clustern. Bei diesem Setup stellen Supervisor-Cluster, Tanzu Kubernetes-Cluster, HAProxy, DevOps-Benutzer und externe Dienste alle eine Verbindung mit derselben verteilten Portgruppe her. Diese ist hier als primäres Workload-Netzwerk definiert.

Ferner bestimmen Sie einen virtuellen HAProxy-Bereich für Verbindungen externer Dienste und DevOps-Benutzer.

Bei dieser Konfiguration wird HAProxy mit zwei virtuellen NICs bereitgestellt, wobei die eine mit dem Management-Netzwerk und die andere mit dem primären Workload-Netzwerk verbunden ist. Dabei müssen Sie die Zuteilung virtueller IPs im gewünschten Subnetz vorher sorgfältig planen.

Diese Konfiguration ist sinnvoll, wenn Sie keine weitere Schicht-2-Isolierung zwischen Ihren einzelnen Tanzu Kubernetes-Clustern benötigen.

Alternative Topologien könnten so aussehen:

• Ein primäres Workload-Netzwerk für den VM-Datenverkehr der Kubernetes-Steuerungs­ebene und ein oder mehrere Workload-Netzwerke, die sämtlichen Namespaces auf dem Supervisor-Cluster zugewiesen sind und sich mit den Tanzu Kubernetes-Cluster-Knoten verbinden.
  Auch in dieser Konfiguration wird die HAProxy-VM mit zwei virtuellen NICs bereitgestellt. Sie kann sich dann entweder mit dem primären Workload-Netzwerk oder dem Workload-Netzwerk verbinden, das für Namespaces verwendet wird.
• Eine HA-Proxy-Topologie mit mehreren isolierten Workload-Netzwerken und mit drei virtuellen NICs. In diesem Fall verbinden Sie HAProxy mit einem Frontend-Netzwerk. DevOps Benutzer und externe Dienste greifen dann über virtuelle IPs im Frontend-Netzwerk auf HAProxy zu.
  Diese Konfiguration ist dann empfehlens­wert, wenn Sie verhindern möchten, dass Ihren DevOps-Benutzer und externen Diensten eine direkte Route zu VMs der Steuerungsebene zur Verfügung steht.

Adressbereiche planen

Da wir unser Setup so einfach wie möglich halten wollen, konfigurieren wir die HA-Proxy-VM zwar mit drei Netzwerk­karten, verwenden aber für Frontend und Workload das gleiche VLAN. Für das weitere Vorgehen müssen Sie zunächst eine statische IP-Adresse für HA-Proxy im Management-Netzwerk, in diesem Beispiel 192.168.0.30 im VLAN 1 festlegen.

Achtung: Bei HA-Proxy muss diese Adresse im CIDR-Format angegeben werden also hier 192.168.0.30/24. Helfen kann dabei ein Subnet-Calculator.

Darüber hinaus legen Sie netzwerkseitig Folgendes fest:

• Eine statische IP-Adresse für HA-Proxy im Workload-Netzwerk. In diesem Beispiel: 172.20.10.1/24 im VLAN 400. Optional bestimmen Sie eine weitere IP-Adresse für HA-Proxy im Frontend-Netzwerk, das bei uns aber im gleichen VLAN liegt 172.20.10.2/24.
• Einen Bereich von IP-Adressen für die Supervisor-VMs im Management-Netzwerk. In diesem Beispiel soll das 192.168.0.180-190 sein.
• Einen Bereich von IP-Adressen für das Workload-Netzwerk. Diese werden sowohl von den Knoten der Supervisor-Steuerebene als auch von Knoten verwendet, die für TKG-Gast-Cluster bereitgestellt werden. In unserem Beispiel soll das 172.20.10.120-150 im VLAN 400 sein.
• Einen Bereich von IP-Adressen für den Load Balancer. Er kann sich entweder im Workload-Netzwerk oder im Frontend-Netzwerk befinden. In unserem Beispiel ist das 172.20.10.160-167.

Weitere Vorbereitungen

Ferner müssen Sie für vSAN die gewünschte Speicher­richtlinie für die Supervisor-Cluster-VMs erstellen. Wir kopieren hier einfach die Standard vSAN-Policy und nennen sie k8s-storage-policy.

Dann legen Sie eine Inhalts­bibliothek von Typ lokal an und fügen das HA-Proxy-OVA hinzu. Dieses kann von hier heruntergeladen werden.

Im nächsten Schritt erstellen Sie eine weitere Inhalts­bibliothek für die TKG-Images von Typ abonniert. Die Subscription-URL lautet https://wp-content.vmware.com/v2/latest/lib.json. Sie enthält die Images der virtuellen Maschinen, die der Bereitstellung des TKG-Clusters dienen.

HA-Proxy

Nun können Sie daran gehen, die HA-Proxy-VM auf Basis des OVA aus der Inhaltsbibliothek bereit­zustellen. Interessant wird es dabei im Abschnitt 5. Konfiguration.

Hier stehen die Optionen Default mit zwei und Frontend Network mit drei Netzwerk­karten zur Auswahl. Unter Punkt 7 Netzwerke auswählen weisen Sie jedem Netzwerktyp (Management, Workload, Frontend) eine der vorbereiteten Portgruppen zu.

Die meiste Aufmerksamkeit verdient dann der Abschnitt 8. Vorlage anpassen. Ordnen Sie bei 2. Network Config die oben festgelegten IP-Adressen und Netzwerk­bereiche für HA-Proxy dem Management- und Workload-Netzwerk im CIDR-Format zu. Die übrigen Einstellungen (DNS, Management Gateway, Workload-Gateway und Hostname) sind selbsterklärend.

Bei 3. Load Balancing gilt es erneut aufzupassen. Unter Load-Balancer IP-Ranges legen Sie den oben identifizierten Netzwerk­bereich 172.20.10.160-167 ebenfalls in CIDR-Notion fest, also 172.20.10.160/29.

Außerdem müssen Sie den Management-Port für die Dataplane-API angeben. Der lautet per Default auf 5556. Ferner legen Sie hier den Admin-User für HA-Proxy und dessen Passwort fest.

Nachdem Sie unter Bereit zum Abschließen die Zusammen­fassung überprüft haben, können Sie die VM bereitstellen.

Workload-Management

Läuft die HA-Proxy-VM, dann wechseln Sie im Hauptmenü des vSphere-Clients zu Arbeitslast­verwaltung und erstellen einen neuen Supervisor-Cluster. Das läuft weitgehend ähnlich ab wie in unserem Artikel zum Bereitstellen des Supervisor-Clusters auf Basis von NSX-T.

Der erste Unterschied zum jenem Vorgehen besteht jedoch darin, dass Sie bei vCenter Server und Netzwerk nicht NSX-T auswählen, sondern Distributed Switch. Im Schritt 2. Cluster wählen Sie dann wieder den gewünschten Host-Cluster aus.

Spannend wird es dann im Schritt 5. Lastaus­gleichsdienst. Hier legen Sie für diesen erst einen Namen fest und wählen dann bei Typ den Eintrag HA Proxy aus. Bei API-Adresse(n) der Datenebene geben Sie die Management-IP von HA-Proxy im Management-Netzwerk ein, und zwar mit dem oben festgelegten Port 5556. Außerdem bestimmen Sie hier den Benutzer­namen und das Passwort des HA-Proxy-Admins.

Das Feld IP-Adressbereich für virtuelle Server nimmt den erwähnten IP-Range des Load-Balancers auf, hier aber nicht in CIDR-Notation, in unserem Beispiel also 172.20.10.160 - 172.20.10.167.

Ferner müssen Sie das root-Zertifikat der Zertifizierungsstelle für den Server einfügen. Das können Sie per Copy & Paste erledigen. Verbinden Sie sich dazu mit der Konsole der HA-Proxy-VM und öffnen die Datei /etc/haproxy/server.crt.

Im Schritt 6. Verwaltungsnetzwerk müssen Sie bei Netzwerk die DVS-Portgruppe des Management-Netzwerks sowie die Startadresse des Supervisor-VM-Adressbereiches (in unserem Beispiel 192.168.0.180-190) angeben, also 192.168.0.190. Die übrigen Einstellungen sind wieder selbst­erklärend.

Das letzte Netzwerk, das konfiguriert werden muss, ist das Workload-Netzwerk. Es wird in unserem Beispiel sowohl von den Supervisor-Knoten als auch von den TKG-Gast-Cluster-Knoten verwendet. Nach Abschluss des Setups sollten die VMs der Supervisor-Steuerebene über Netzwerk­schnitt­stellen sowohl im Verwaltungsnetzwerk als auch im Workload-Netzwerk verfügen.

Den Default-Eintrag bei Dienste-IP-Adresse können Sie übernehmen. Der DNS-Server muss derjenige im Workload-Netzwerk sein, hier 172.20.10.10. Dann fügen Sie bei Arbeits­lastnetzwerk ein primäres Workload-Netzwerk hinzu.

Dieses bekommt die vorgesehene DVS-Port-Gruppe, ein Default Gateway und den zugehörigen Workload-IP-Bereich. Diesen haben wie eingangs exemplarisch mit 172.20.10.120 – 172.20.10.150 identifiziert, der hier ebenfalls nicht in CIDR-Notation anzugeben ist.

Nachdem Sie die Konfiguration im Schritt 9. Überprüfen und Betätigen noch einmal überprüft haben, können Sie den Supervisor-Cluster erstellen lassen. Das kann bis zum 45 Minuten in Anspruch nehmen.

Anschließend müssen Sie den Cluster im Lizenz-Management mit einer Lizenz für vSphere mit Tanzu lizenzieren. Lohn der Mühe sind dann erstmal drei neue Supervisor­Control­PlaneVMs in der Bestandsliste des vSphere-Clients.

Außerdem können Sie nun den Konfigurations­status des Supervisor-Clusters im Menü Arbeitslast­verwaltung“ sowie die IP-Adresse des Knotens der Steuerebene, hier 172.20.10.160 sehen. Der Status sollte auf Wird ausgeführt stehen.