vSphere Tanzu – GuestCluster

1. Oktober 2020 at 0:24

Mit vSphere with Tanzu (ehemals Project Pacific), bzw. VCF with Tanzu hat VMware es geschafft die Welt von Containern mit der von VMs zu verbinden. Dadurch ist ein ESXi-Server in der Lage Container auszuführen.
Dabei werden vSphere-Cluster zu sogenannten Workload Domains. Pro Workload Domain wird ein Set an sogenannten SupervisorControlPlaneVMs erstellt. Dies sind mindestens zwei, standardmäßig drei. Diese bilden die ControlPlane des Kubernetesclusters und jeder ESXi-Server in dieser Workload Domain ist eine WorkerNode.

Nun liegt die große Funktion von Tanzu aber etwas versteckt: Guest Cluster.
Dabei können innerhalb des SuperVisorClusters weitere Kubernetes Cluster deployt werden. Diese Cluster können dabei in einer anderen Version als der SuperVisorCluster laufen und sind von diesem auch größtenteils unabhängig. Doch wie erstellt man diese?
Dazu gibt es in den weiten des Internets verschiedene Möglichkeiten, eine möchte ich euch hier zeigen.

Vorraussetzungen

Zunächst einmal muss aber eine ContentLibrary angelegt werden um die entsprechenden Images der WorkloadDomain bereitzustellen. Dazu legt man eine neue ContentLibrary vom Typ “subscribed” an und gibt als subscribed URL diese an: https://wp-content.vmware.com/v2/latest/lib.json.
Nun kann man in der Konfiguration der Workload Domain diese ContentLibrary angeben:

WorkloadCluster ContentLibrary


Ebenso ist es notwendig mindestens einen Namespace anzulegen und diesem Namespace mindestens eine StoragePolicy zuzuweisen:

Namespace Storage Policies

In diesem Beispiel heißt der Namespace “namespace001”.

Deployment

Als nächstes ist es Zeit den GuestCluster zu deployen. Dazu verwende ich die folgende Definition. Diese erstellt einen Cluster mit dem Namen guest-cluster-01 im Namespace namespace001.

Dabei wird ein Guest Cluster mit einem Node in der ControlPlane und zwei Workern erstellt. Dabei wird der Cluster die Version 1.17.8 haben. Als CNI Plugin kann man entweder Antrea oder Calico verwenden.
Zu beachten ist das die angegebene Version in der vorher erstellten ContentLibrary vorhanden ist. Zu beachten ist der Unterschied in der Schreibweise:
ContentLibrary: ob-16551547-photon-3-k8s-v1.17.8---vmware.1-tkg.1.5417466
Definition: v1.17.8+vmware.1-tkg.1.5417466
Man lässt also alles vor der Version (v1.17.8) weg und tauscht die drei Minuszeichen gegen ein Plus.
Welche Vorlagen in der ContentLibrary vorhanden sind, kann man sich im vCenter anschauen.
Alternativ gibt es einen schnellen Weg über kubectl kubectl get virtualmachineimages. Dies zeigt uns eine Liste an verfügbaren Images an:

An dieser Stelle kann man sich einfach die Version kopieren.

Nachdem der Cluster erstellt wurde und läuft ist es Zeit sich auf diesen zu Verbinden:

Zu beachten ist hierbei das man den Namespace und den Namen des Clusters angibt den man erstellt hat. Die SuperVisorAPI ist natürlich die ControlPlane-Adresse des SuperVisorClusters.
Mittels dem Befehl kubectl config get-contexts kann man sich die aktuell vorhandenen Kontexts anzeigen lassen. Mittels kubectl config use-context <context> kann man dann in den Kontext des GuestClusters wechseln.

Berechtigungen?

Versucht man nun Pods in diesem GuestCluster zu deployen, schlägt dies vermutlich mit dieser Fehlermeldung fehl:

message: 'pods "hello-kubernetes-fb869d65c-" is forbidden: unable to validate
against any pod security policy: []'
reason: FailedCreate
status: "True"
type: ReplicaFailure

Dies liegt daran das ein SSO-User standardmäßig keine Berechtigung hat Workload im soeben erstellten GuestCluster zu deployen. Hierzu muss erst ein entsprechendes RoleBinding erstellt werden:

Segmentiert man den GuestCluster weiter mit Namespaces, so muss das RoleBinding für jeden Namespace erneut erstellt werden. Danach sollte das Deployen von Workload funktionieren. Mit der Anwendung dieser Definition erhält jeder Serviceaccount die Cluster Rolle psp:vmware-system-privileged. Diese Rolle wiederum wurde beim Tanzu Deployment automatisch angelegt und enthält die notwendigen Berchtigungen um Workload zu deployen.
Alternativ kann man innerhalb des GuestClusters eigene User anlegen und über das RoleBasedAccessManagement von Kubernetes mit den entsprechenden Rollen und Privilegien versehen.

Nacharbeiten

Nutzt man nun im SuperVisorCluster Harbor als Image Registry und hat dort ein privates, evtl. selbstsigniertes Zertifikat im Einsatz und möchte die dort gehosteten Images auch im GuestCluster nutzen, so muss man dessen Root-Zertifikat auf die GuestCluster kopieren. Aktuell muss man dazu ein Script auf dem Master der ControlPlane des SuperVisorClusters ausführen, in Zukunft soll dies automatisch geschehen:

Die entsprechende IP-Adresse und das Root-Passwort des Masters kann man über das vCenter erhalten. Dazu führt man dort einfach dieses Script aus: /usr/lib/vmware-wcp/decryptK8Pwd.py

Bei dem Script muss man den Namen und den Namespace, mit dem der GuestCluster definiert wurde, korrekt angeben. Alternativ kann man aber auch natürlich die Arbeit des Scripts auf andere Weise erledigen.
Das Script stammt nicht von mir persönlich, sondern wurde mir im Rahmen einer Installation von VMware übergeben.

Use-Cases

Ja, jetzt haben wir einen voll funktionierenden GuestCluster, aber wozu?
GuestCluster können verschiedene Anwendungen haben. Sei es Developer die ihre Software testen wollen und dazu einen ganzen Cluster unter ihrer Verwaltung haben wollen. Oder man betreibt mehrere Cluster für mehrere Abteilungen., Oder man nutzt automatisierte Systeme wie z.B. GitLab, Jenkins oder Ansible Tower die diese Cluster nutzen können um sich selbst den Anforderungen an sie entsprechend zu sizen.