Bereitstellen eines Arbeitslastclusters für spezialisierte Hardware

Tanzu Kubernetes Grid unterstützt die Bereitstellung von Arbeitslastclustern auf bestimmten Typen von GPU-fähigen Hosts auf vSphere 7.0 und höher.

Bereitstellen eines GPU-fähigen Arbeitslastclusters

Um einen Knoten mit einer GPU in einem vSphere-Arbeitslastcluster zu verwenden, müssen Sie den PCI-Passthrough-Modus aktivieren. Der Vorgang ermöglicht den direkten Zugriff auf die GPU durch den Cluster unter Umgehung des ESXi-Hypervisors, wodurch ein Leistungsniveau erreicht wird, das der Leistung der GPU auf einem nativen System ähnelt. Bei Verwendung des PCI-Passthrough-Modus ist jedes GPU-Gerät einer virtuellen Maschine (VM) des vSphere-Arbeitslastclusters zugeordnet.

Hinweis

Um GPU-fähige Knoten zu vorhandenen Clustern hinzuzufügen, verwenden Sie den Befehl tanzu cluster node-pool set.

Voraussetzungen

Vorgehensweise

Um einen Arbeitslastcluster mit GPU-fähigen Hosts zu erstellen, führen Sie die folgenden Schritte aus, um PCI-Passthrough zu aktivieren, ein benutzerdefiniertes Systemimage zu erstellen, eine Clusterkonfigurationsdatei und Tanzu Kubernetes-Version zu erstellen, den Arbeitslastcluster bereitzustellen und einen GPU-Operator mithilfe von Helm zu installieren.

  1. Fügen Sie die ESXi-Hosts mit den GPU-Karten zu Ihrem vSphere Client hinzu.

  2. Aktivieren Sie PCI-Passthrough und notieren Sie die GPU-IDs wie folgt:

    1. Wählen Sie in Ihrem vSphere Client den zielseitigen ESXi-Host im GPU-Cluster aus.
    2. Wählen Sie Konfigurieren > Hardware > PCI-Geräte aus.
    3. Wählen Sie die Registerkarte Alle PCI-Geräte aus.
    4. Wählen Sie die gewünschte GPU in der Liste aus.
    5. Klicken Sie auf Passthrough umschalten.
    6. Notieren Sie sich unter "Allgemeine Informationen" die Geräte- und Anbieter-ID (in der Abbildung unten grün hervorgehoben). Die IDs sind für identische GPU-Karten identisch. Sie benötigen diese für die Clusterkonfigurationsdatei.

    vSphere Client-Schnittstelle mit einer Liste der PCI-Geräte. Unterhalb der Liste wird der Ort der Geräte-ID und der Anbieter-ID durch einen grünen Rahmen hervorgehoben.

  3. Erstellen Sie mithilfe der Vorlage in Workload-Clustervorlage eine Konfigurationsdatei für den Arbeitslastcluster und schließen Sie die folgenden Variablen ein:

    ...
VSPHERE_WORKER_PCI_DEVICES: "0x<VENDOR-ID>:0x<DEVICE-ID>"
VSPHERE_WORKER_CUSTOM_VMX_KEYS: 'pciPassthru.allowP2P=true,pciPassthru.RelaxACSforP2P=true,pciPassthru.use64bitMMIO=true,pciPassthru.64bitMMIOSizeGB=<GPU-SIZE>'
VSPHERE_IGNORE_PCI_DEVICES_ALLOW_LIST: "<BOOLEAN>"
VSPHERE_WORKER_HARDWARE_VERSION: vmx-17
WORKER_ROLLOUT_STRATEGY: "RollingUpdate"

    Dabei gilt:

    Hinweis

    Sie können nur einen GPU-Typ pro VM verwenden. Sie können beispielsweise nicht sowohl NVIDIA V100 als auch NVIDIA Tesla T4 auf einer einzelnen VM verwenden, aber Sie können mehrere GPU-Instanzen mit derselben Anbieter- und Geräte-ID verwenden.

    Die tanzu-CLI lässt das Aktualisieren der WORKER_ROLLOUT_STRATEGY -Spezifikation auf dem MachineDeployment nicht zu. Wenn das Cluster-Upgrade aufgrund nicht verfügbarer PCI-Geräte hängen bleibt, schlägt VMware vor, die MachineDeployment-Strategie mithilfe der kubectl-CLI zu bearbeiten. Die Rollout-Strategie wird unter spec.strategy.type definiert.

    Eine vollständige Liste der Variablen, die Sie für GPU-fähige Cluster konfigurieren können, finden Sie unter GPU-fähige Cluster in Referenz für die Variablen der Konfigurationsdatei.

  4. Erstellen Sie den Arbeitslastcluster, indem Sie Folgendes ausführen:

    tanzu cluster create -f CLUSTER-CONFIG-NAME

    Dabei ist CLUSTER-CONFIG-NAME der Name der Clusterkonfigurationsdatei, die Sie in den vorherigen Schritten erstellt haben.

  5. Fügen Sie das NVIDIA Helm-Repository hinzu:

    helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
&& helm repo update

  6. Installieren Sie den NVIDIA GPU-Operator:

    helm install --kubeconfig=./KUBECONFIG  --wait --generate-name -n gpu-operator --create-namespace nvidia/gpu-operator

    Dabei ist KUBECONFIG der Name und der Speicherort der kubeconfig für Ihren Arbeitslastcluster. Weitere Informationen finden Sie unter Abrufen von kubeconfig für Arbeitslastcluster.

    Informationen zu den Parametern in diesem Befehl finden Sie unter Installieren des GPU-Operators in der NVIDIA-Dokumentation.

  7. Stellen Sie sicher, dass der NVIDIA GPU-Operator ausgeführt wird:

    kubectl --kubeconfig=./KUBECONFIG  get pods -A

    Die Ausgabe entspricht:

    NAMESPACE         NAME                                                              READY   STATUS     RESTARTS   AGE
gpu-operator      gpu-feature-discovery-szzkr                                       1/1     Running     0         6m18s
gpu-operator      gpu-operator-1676396573-node-feature-discovery-master-7795vgdnd   1/1     Running     0         7m7s
gpu-operator      gpu-operator-1676396573-node-feature-discovery-worker-bq6ct       1/1     Running     0         7m7s
gpu-operator      gpu-operator-84dfbbfd8-jd98f                                      1/1     Running     0         7m7s
gpu-operator      nvidia-container-toolkit-daemonset-6zncv                          1/1     Running     0         6m18s
gpu-operator      nvidia-cuda-validator-2rz4m                                       0/1     Completed   0         98s
gpu-operator      nvidia-dcgm-exporter-vgw7p                                        1/1     Running     0         6m18s
gpu-operator      nvidia-device-plugin-daemonset-mln6z                              1/1     Running     0         6m18s
gpu-operator      nvidia-device-plugin-validator-sczdk                              0/1     Completed   0         22s
gpu-operator      nvidia-driver-daemonset-b7flb                                     1/1     Running     0         6m38s
gpu-operator      nvidia-operator-validator-2v8zk                                   1/1     Running     0         6m18s

Testen Ihres GPU-Clusters

Um Ihren GPU-fähigen Cluster zu testen, erstellen Sie ein Pod-Manifest für das Beispiel cuda-vector-add aus der Kubernetes-Dokumentation und stellen Sie es bereit. Der Container lädt eine CUDA-Berechnung mit der GPU herunter und führt diese aus.

  1. Erstellen Sie eine Datei mit dem Namen cuda-vector-add.yaml und fügen Sie Folgendes hinzu:

    apiVersion: v1
kind: Pod
metadata:
 name: cuda-vector-add
spec:
 restartPolicy: OnFailure
 containers:
   - name: cuda-vector-add
     # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
     image: "registry.k8s.io/cuda-vector-add:v0.1"
     resources:
       limits:
         nvidia.com/gpu: 1 # requesting 1 GPU

  2. Wenden Sie die Datei an:

    kubectl apply -f cuda-vector-add.yaml

  3. Führen Sie sie aus:

    kubectl get po cuda-vector-add

    Die Ausgabe entspricht:

    cuda-vector-add   0/1     Completed   0          91s

  4. Führen Sie sie aus:

    kubectl logs cuda-vector-add

    Die Ausgabe entspricht:

    [Vector addition of 50000 elements]
Copy input data from the host memory to the CUDA device
CUDA kernel launch with 196 blocks of 256 threads
Copy output data from the CUDA device to the host memory
Test PASSED
Done

Bereitstellen eines Arbeitslastclusters auf einer Edge-Site

Tanzu Kubernetes Grid v1.6+ unterstützt die Bereitstellung von Arbeitslastclustern auf VMware ESXi-Edge-Hosts. Sie können diesen Ansatz verwenden, wenn Sie viele Kubernetes-Cluster an verschiedenen Speicherorten ausführen möchten, die alle von einem zentralen Verwaltungscluster verwaltet werden.

Topologie: Sie können Edge-Arbeitslastcluster in der Produktion mit einem einzelnen Steuerungsebenenknoten und nur einem oder zwei Hosts ausführen. Obwohl dies weniger CPU, Arbeitsspeicher und Netzwerkbandbreite benötigt, verfügen Sie nicht über dieselben Stabilitäts- und Wiederherstellungseigenschaften wie Standardproduktions-Tanzu Kubernetes Grid-Cluster. Weitere Informationen finden Sie unter Referenzarchitektur 1.0 zur VMware Tanzu Edge-Lösung.

Lokale Registrierung: Um Kommunikationsverzögerungen zu minimieren und die Stabilität zu maximieren, sollte jeder Edge-Cluster über eine eigene lokale Harbor-Container-Registrierung verfügen. Eine Übersicht über diese Architektur finden Sie unter Container-Registrierung in Architekturübersicht. Informationen zum Installieren einer lokalen Harbor-Registrierung finden Sie unter Bereitstellen einer Offline-Harbor-Registrierung auf vSphere.

Zeitüberschreitungen: Wenn sich der Verwaltungscluster eines Edge-Arbeitslastclusters ortsfern in einem Hauptdatencenter befindet, müssen Sie möglicherweise bestimmte Zeitüberschreitungen anpassen, damit der Verwaltungscluster genügend Zeit hat, um eine Verbindung mit den Arbeitslastcluster-Rechnern herzustellen. Informationen zum Anpassen dieser Zeitüberschreitungen finden Sie unter Verlängern der Zeitüberschreitungen, damit Edge-Cluster höhere Latenzen bewältigen können unten.

Angeben einer lokalen VM-Vorlage

Wenn Ihre Edge-Arbeitslastcluster ihren eigenen isolierten Speicher und nicht den gemeinsam genutzten vCenter-Speicher verwenden, müssen Sie sie so konfigurieren, dass sie Knoten-VM-Vorlagen-Images als OVA-Dateien vom lokalen Speicher abrufen.

Hinweis

Sie können tanzu cluster upgrade nicht verwenden, um ein Upgrade der Kubernetes-Version eines Edge-Arbeitslastclusters mit einer lokalen VM-Vorlage durchzuführen. Führen Sie stattdessen ein Upgrade des Clusters durch, indem Sie das Upgrade eines Edge-Clusters mit einer lokalen VM-Vorlage im Thema Upgrade von Arbeitslastclustern durchführen.

So geben Sie eine einzelne VM-Vorlage für den Cluster oder verschiedene Vorlagen für die Bereitstellung von Worker- und Steuerungsebenen-Maschinen an:

  1. Erstellen Sie die Clusterkonfigurationsdatei und generieren Sie das Clustermanifest als Schritt 1 des zweistufigen Prozesses, der unter Erstellen eines klassenbasierten Clusters beschrieben wird.

  2. Stellen Sie sicher, dass die VM-Vorlagen für den Cluster:

    • über eine gültige Kubernetes-Version für TKG verfügen.
    • über eine gültige OVA-Version verfügen, die mit der Eigenschaft spec.osImages eines TKr übereinstimmt.
    • auf das lokale vCenter hochgeladen werden und einen gültigen Bestandspfad haben, zum Beispiel /dc0/vm/ubuntu-2004-kube-v1.26.8+vmware.1-tkg.1.

  3. Bearbeiten Sie die Cluster-Objektspezifikation im Manifest wie folgt, je nachdem, ob Sie eine clusterweite VM-Vorlage oder mehrere VM-Vorlagen definieren:

    • Clusterweite VM-Vorlage:

      • Legen Sie unter annotations run.tanzu.vmware.com/resolve-vsphere-template-from-path auf die leere Zeichenfolge fest.
      • Legen Sie im vcenter-Block unter spec.topology.variables template auf den Bestandspfad für die VM-Vorlage fest.

      • Beispiel:

        annotations:
  run.tanzu.vmware.com/resolve-vsphere-template-from-path: ""
...
spec:
 topology:
   class: tkg-vsphere-default-v1.0.0
   variables:
   - name: vcenter
     value:
       cloneMode: fullClone
       datacenter: /dc0
       datastore: /dc0/datastore/sharedVmfs-0
       folder: /dc0/vm/folder0
       network: /dc0/network/VM Network
       resourcePool: /dc0/host/cluster0/Resources/rp0
       ...
       template: VM-TEMPLATE
       ...

        Dabei ist VM-TEMPLATE der Pfad zur VM-Vorlage für den Cluster.

    • Mehrere VM-Vorlagen pro machineDeployment:

      • Legen Sie unter annotations run.tanzu.vmware.com/resolve-vsphere-template-from-path auf die leere Zeichenfolge fest.
      • Fügen Sie in variables.overrides für jeden machineDeployments-Block unter spec.topology.worker und controlplane eine Zeile für vcenter hinzu, in der template für den Bestandspfad für die VM-Vorlage festgelegt wird.

      • Beispiel:

        annotations:
  run.tanzu.vmware.com/resolve-vsphere-template-from-path: ""
...
spec:
 workers:
   machineDeployments:
   - class: tkg-worker
     metadata:
       annotations:
         run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=ubuntu
     name: md-1
     replicas: 2
     variables:
       overrides:
       - name: vcenter
         value:
           ...
           datacenter: /dco
           template: VM-TEMPLATE
           ...

        Dabei ist VM-TEMPLATE der Pfad zur VM-Vorlage für die machineDeployment.

  4. Verwenden Sie die geänderte Konfigurationsdatei, um den Cluster als Schritt 2 des unter Erstellen eines klassenbasierten Clusters beschriebenen Prozesses zu erstellen.

Verlängern der Zeitüberschreitungen, damit Edge-Cluster höhere Latenzen bewältigen können

Wenn Ihr Verwaltungscluster auf Edge-Sites ausgeführte Arbeitslastcluster remote verwaltet oder mehr als 20 Arbeitslastcluster verwaltet, können Sie bestimmte Zeitüberschreitungen anpassen, sodass die Cluster-API Maschinen, die vorübergehend offline sind oder länger als 12 Minuten mit ihrem Remoteverwaltungscluster kommunizieren, nicht blockiert oder beschneidet, insbesondere wenn Ihre Infrastruktur unterversorgt ist.

Es gibt drei Einstellungen, die Sie anpassen können, um den Edge-Clustern zusätzliche Zeit für die Kommunikation mit ihrer Steuerungsebene zu verschaffen:

  • MHC_FALSE_STATUS_TIMEOUT: Erweitern Sie den Standardwert 12m auf beispielsweise 40m, um zu verhindern, dass der MachineHealthCheck-Controller die Maschine neu erstellt, wenn die zugehörige Ready-Bedingung mehr als 12 Minuten auf False festgelegt bleibt. Weitere Informationen zu Systemzustandsprüfungen von Maschinen finden Sie unter Konfigurieren von Maschinenintegritätsprüfungen für Tanzu Kubernetes-Cluster.

  • NODE_STARTUP_TIMEOUT: Erweitern Sie den Standardwert 20m auf beispielsweise 60m, um zu verhindern, dass der MachineHealthCheck-Controller neue Maschinen daran hindert, dem Cluster beizutreten, da deren Start länger als 20 Minuten dauerte, was als fehlerhaft betrachtet wird.

  • etcd-dial-timeout-duration: Verlängern Sie die Standard-10m beispielsweise auf 40s im Manifest capi-kubeadm-control-plane-controller-manager, um zu verhindern, dass etcd-Clients auf dem Verwaltungscluster beim Prüfen der Integrität von etcd auf den Arbeitslastclustern vorzeitig fehlschlagen. Der Verwaltungscluster nutzt seine Fähigkeit zur Herstellung der Verbindung mit etcd als Maßstab für die Maschinenintegrität. Beispiel:

    1. Führen Sie in einem Terminal Folgendes aus:

      kubectl edit  capi-kubeadm-control-plane-controller-manager -n capi-system

    2. Ändern Sie den Wert für --etcd-dial-timeout-duration:

      - args:
     - --leader-elect
     - --metrics-bind-addr=localhost:8080
     - --feature-gates=ClusterTopology=false
     - --etcd-dial-timeout-duration=40s
     command:
     - /manager
     image: projects.registry.vmware.com/tkg/cluster-api/kubeadm-control-plane-controller:v1.0.1_vmware.1

Darüber hinaus sollten Sie Folgendes beachten:

  • capi-kubedm-control-plane-manager : Wenn er aus irgendeinem Grund von den Arbeitslastclustern "abgetrennt" wird, müssen Sie ihn möglicherweise einem neuen Knoten zuweisen, damit er etcd in Arbeitslastclustern ordnungsgemäß überwachen kann.

  • Pinniped-Konfigurationen in TKG gehen alle davon aus, dass Ihre Arbeitslastcluster mit Ihrem Verwaltungscluster verbunden sind. Im Falle einer Trennung sollten Sie sicherstellen, dass Arbeitslast-Pods Administrator- oder Dienstkonten verwenden, um mit dem API-Server auf Ihren Edge-Sites zu kommunizieren. Andernfalls beeinträchtigt die Trennung vom Verwaltungscluster, dass sich Ihre Edge-Sites über Pinniped bei ihren lokalen Arbeitslast-API-Servern authentifizieren können.

check-circle-line exclamation-circle-line close-line
Scroll to top icon