VMware Bitfusion und Tanzu – Teil 3: Bitfusion aus Kubernetes Pods und TKGS nutzen

Dies ist ein mehrteiliger Artikel rund um das Produkt VMware Bitfusion. Ich werde eine Einführung in die Technik geben, wie man einen Bitfusion Server einrichtet und wie man dessen Dienste aus Kubernetes Pods nutzen kann.

Wir haben in den Teilen 1 und 2 gesehen, was Bitfusion ist und wie man einen Bitfusion Server Cluster aufsetzt. Der herausfordernde Teil ist, diesen Bitfusion Cluster aus Kubernetes Pods nutzbar zu machen.

Damit Container auf Bitfusion GPU-Ressourcen zugreifen können, müssen ein paar Rahmenbedingugen erfüllt sein.

Ich setze in dieser Anleitung voraus, dass wir einen konfigurierten vSphere-Tanzu Cluster zur Verfügung haben, sowie einen Namespace, einen User, eine Storage-Class und die Kubernetes CLI Tools. Das Netzwerk kann entweder mit NSX-T oder mit Distributed-vSwitches und einem Loadbalancer wie zum Beispiel dem AVI-Loadbalancer organisiert sein.

Im beschriebenen PoC wurde aus Gründen der Einfachheit Tanzu on vSphere ohne NSX-T verwendet. Zum Einsatz kam der AVI-Loadbalancer, der jetzt offiziell NSX-Advanced-Loadbalancer genannt wird.

Außerdem benötigen wir ein Linux System mit Zugriff auf Github oder einen Mirror für die Vorbereitung des Clusters.

Der Ablauf ist folgender:

  • TKGS Cluster erzeugen
  • Bitfusion Baremetal Token laden und K8s Secret erzeugen
  • Git Projekt laden und Makefile anpassen
  • Device-Plugin auf TKGS-Cluster bereitstellen
  • Pod Deployment

TKGS-Cluster erzeugen

Login zu Tanzu Supervisor Control Plane.

kubectl vsphere login --vsphere-username <user> -server=https://<Controlplane> --insecure-skip-tls-verify 

In den gewünschten Namespace wechseln

kubectl config use-context <namespace-name>

YAML File für Guest Cluster Deployment erzeugen.

apiVersion: run.tanzu.vmware.com/v1alpha1 
kind: TanzuKubernetesCluster 
metadata: 
  name: <cluster-name> 
  namespace: <namespace-name> 
spec: 
  topology: 
    controlPlane: 
      count: 1 
      class: best-effort-large 
      storageClass: <storage-policy> 
    workers: 
      count: 3 
      class: best-effort-large 
      storageClass: <storage-policy>
      volumes: 
        - name: containerd 
          mountPath: /var/lib/containerd 
          capacity: 
            storage: 32Gi 
  distribution: 
    version: v1.19 

Die Master- und Worker-Node Spezifikationen wurden hier im Beispiel mit Formfaktor „best-effort-large“ erzeugt. Diese sind zweckmäßigerweise den eigenen Bedürfnissen anzupassen. Auch die Anzahl der Master Knoten wurde auf 1 beschränkt, da es sich um eine Testumgebung handelt. In produktiven Umgebungen wäre die zweckmäßige Anzahl 3.

Verfügbare Formfaktoren können abgerufen werden mit:

kubectl get virtualmachineclasses

Vor allem die Kategorie „best-effort“ oder „guaranteed“ sollten Beachtung finden. Bei guaranteed werden Ressourcen exklusiv reserviert. Sind alle Ressourcen gebucht, können keine weiteren Master- oder Workernodes ausgerollt werden. Best-effort versucht die Ressourcen bereitzustellen, kann diese aber nicht garantieren. Werden weitere Worker und Master ausgerollt, müssen diese sich die vorhandenen Ressourcen teilen und es kann zu Leistungseinbußen kommen.

Weitere Info in der VMware Dokumentation: Virtual Machine Classes for Tanzu Kubernetes Clusters

Deployment anwenden

kubectl apply -f cluster-deployment.yaml 

Nach Absetzen des Befehls muss gewartet werden, bis der neue Cluster komplett erzeugt wurde. Der Status kann mit describe kontrolliert werdem.

kubectl describe tkc <clustername>

Der Cluster muss vollständig im Status „Ready“ sein.

Anmelden am neuen TKGS-Cluster

kubectl-vsphere login --vsphere-username <username> --server=https://<Supervisor-Control-Plane> --insecure-skip-tls-verify --tanzu-kubernetes-cluster-namespace=<namespace-name> --tanzu-kubernetes-cluster-name=<cluster-name> 

Erweiterte Rechte setzen, damit der Benutzer Pods erzeugen darf:

kubectl create clusterrolebinding default-tkg-admin-priviledged-binding --clusterrole=psp:vmware-system-privileged --group=system:authenticated 

Token erzeugen

Damit ein Client (Pod, VM, etc.) auf eine Bitfusion GPU Ressource zugreifen kann, muss zunächst ein Secret (Token) im Tanzu Namespace erzeugt werden. Dieses Token muss im Containerimage bereitgestellt werden, was die Verwendung allgemein verfügbarer Images erschwert.

Alternativ kann auch das Bitfusion Device-Plugin verwendet werden. Letzteres ist die empfohlene Methode.

Das Token wird in der Bitfusion GUI des vCenters erzeugt. Menu > Bitfusion > Tokens > New Token. Über Download kann das Token als TAR-Archiv heruntergeladen und mit SCP auf die Linux Helper-VM übertragen werden.

Wir erzeugen ein Verzeichnis ‚tokens‘, in das das Tarfile entpackt wird.

mkdir tokens
tar -xvf <tarfile> -C tokens

Im Verzeichnis ‚tokens‘ werden drei Dateien ca.crt, client.yaml und servers.conf entpackt.

kubectl create secret generic bitfusion-secret --from-file=tokens -n kube-system

Device Plugin

Das Device Plugin vereinfacht die Konsumierung und Buchung von GPU-Ressourcen während der Laufzeit eines Pods. Der Bitfusion-Client wird damit automatisch bereitgestellt. Die Verwendung des Device-Plugins ist nicht zwingend erforderlich, erleichtert jedoch den Anwendern die Arbeit mit Bitfusion erheblich. Diese können aud Container Workloads GPU Ressourcen buchen, ohne sich um den Bitfusion Client kümmern zu müssen.

Dokumentation der bitfusion-with-kubernetes-integration (bwki) auf GitHub.

Quelle: GitHub bwki

Wird das Device-Plugin nicht verwendet, so muss die GPU im Pod manuell zugeteilt werden. Beispielsweise mit entsprechenden Python Befehlen.

bitfusion run –n 1 python3

Device-Plugin bereitstellen

git clone https://github.com/vmware/bitfusion-with-kubernetes-integration.git
cd bitfusion-with-kubernetes-integration-main/bitfusion_device_plugin

Makefile anpassen.

IMAGE_REPO ?= docker.io/bitfusiondeviceplugin 
DEVICE_IMAGE_NAME ?= bitfusion-device-plugin 
WEBHOOK_IMAGE_NAME ?= bitfusion-webhook 
PKG_IMAGE_NAME ?= bitfusion-client 
IMAGE_TAG ?= 0.2 
K8S_PLATFORM ?= community

In der Regel muss hier nur die URL zum Repository angepasst werden. Mit make deploy werden die notwendigen Komponenten bereitgestellt.

make deploy

Anpassung des Deployment YAML zur Buchung von GPU

Bei Verwendung des Device-Plugins können die Ressourcen im Deployment gebucht werden. Die Anwender müssen keine Bitfusion Kenntnisse haben, um diese Ressource nutzen zu können.

spec:
   containers:
      resources: 
         limits: 
            bitfusion.io/gpu-num: 1 
            bitfusion.io/gpu-percent: 25 

Im Beispiel oben wurde eine physische GPU zu 25% gebucht. Die prozentuale Angabe bezieht sich auf das GPU RAM und nicht auf Cores oder Rechenzeit.

Damit das Bitfusion Device-Plugin verwendet werden kann, muss es im TKGS-Cluster installiert werden. Zur Bereitstellung ist ein Linux Hilfssystem für die Compilierug notwendig.

Danksagung

Dieser Blogartikel wurde möglich durch die sehr gute Zusammenarbeit zwischen VMware, Kunde und Dienstleister. Mein besonderer Dank gilt an dieser Stelle Sabine, Christian und Torsten, die maßgeblich zum Erfolg des Projekts beigetragen haben. Danke auch an das VMware Team Jim Brogan, Kevin Hu und Christopher Banck, für die Unterstützung jenseits der Dokumentation.

Links

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.