GPU-Geräte mit dynamischer Ressourcenzuweisung verwalten

Die dynamische Ressourcenzuweisung ist eine Kubernetes API, mit der Sie Ressourcen wie GPUs für Pods und Container in Ihren Google Distributed Cloud Bare Metal-Clustern anfordern und freigeben können. Diese Geräte werden von Drittanbietertreibern verwaltet und von Kubernetes dynamisch zugewiesen, ähnlich wie Speichervolumes. Ihre KI-Arbeitslasten müssen nicht auf bestimmte Knoten abzielen oder die genaue Anzahl der angehängten Geräte anfordern. In diesem Dokument erfahren Sie, wie Sie Ihre GPU-Arbeitslasten für die dynamische Ressourcenzuweisung konfigurieren.

Hinweis

Bevor Sie Ihre GPU-Arbeitslasten für die Verwendung der dynamischen Ressourcenzuweisung konfigurieren, müssen die folgenden Voraussetzungen erfüllt sein:

  • Ihr Bare-Metal-Cluster hat die Version 1.33.0 oder höher.
  • Ihr Betriebssystem ist entweder Ubuntu 22.04 oder Red Hat Enterprise Linux (RHEL) 9.4.
  • Sie haben Ihren Cluster aktualisiert, um die dynamische Ressourcenzuweisung zu aktivieren, wie unter Dynamische Ressourcenzuweisung aktivieren beschrieben.
  • Sie haben mindestens eine Knotenmaschine mit einer GPU und dem installierten NVIDIA-GPU-Treiber. Weitere Informationen finden Sie unter Gebündelten NVIDIA-GPU-Operator installieren oder deinstallieren.
  • Wenn Sie den gebündelten NVIDIA-GPU-Operator verwenden, wird in Version 1.33.0 oder höher standardmäßig das Container Device Interface (CDI) aktiviert. Wenn Sie einen manuell installierten GPU-Operator verwenden, muss CDI in der ClusterPolicy aktiviert sein.
  • Sie haben die Anleitung unter NVIDIA DRA-Treiber für GPUs befolgt, um den NVIDIA DRA-Treiber auf allen Knoten mit GPU zu installieren.

GPU-Arbeitslasten erstellen, die die dynamische Ressourcenzuweisung verwenden

Damit Ihre GPU-Arbeitslasten die dynamische Ressourcenzuweisung zum Anfordern von GPUs nutzen können, müssen sie sich in einem freigegebenen Namespace mit einer ResourceClaim befinden, die die Anfrage für die GPU-Gerätezuweisung beschreibt. Ihre Arbeitslasten müssen auf die ResourceClaim verweisen, damit Kubernetes GPU-Ressourcen zuweisen kann.

Mit den folgenden Schritten richten Sie eine Umgebung ein, in der Ihre Arbeitslasten die dynamische Ressourcenzuweisung verwenden, um GPU-Ressourcen anzufordern:

  1. Wenn Sie Ressourcen im Zusammenhang mit der dynamischen Ressourcenzuweisung erstellen möchten, erstellen Sie in Ihrem Cluster eine neue Namespace:

    cat <<EOF | kubectl apply --kubeconfig=CLUSTER_KUBECONFIG -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: NAMESPACE_NAME
    EOF
    

    Ersetzen Sie Folgendes:

    • CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Nutzerclusters.

    • NAMESPACE_NAME durch den Namen für den Namespace der dynamischen Ressourcenzuweisung.

  2. Erstellen Sie eine ResourceClaim, um die Anfrage für den GPU-Zugriff zu beschreiben:

    cat <<EOF | kubectl apply --kubeconfig=CLUSTER_KUBECONFIG -f -
    apiVersion: resource.k8s.io/v1beta1
    kind: ResourceClaim
    metadata:
      namespace: NAMESPACE_NAME
      name: RESOURCE_CLAIM_NAME
    spec:
        devices:
          requests:
          - name: gpu
            deviceClassName: gpu.nvidia.com
    EOF
    

    Ersetzen Sie RESOURCE_CLAIM_NAME durch den Namen Ihres Ressourcenanspruchs für GPU-Anfragen.

  3. Erstellen Sie Arbeitslasten, die auf die im vorherigen Schritt erstellte ResourceClaim verweisen.

    In den folgenden Arbeitslastbeispielen wird gezeigt, wie Sie auf eine ResourceClaim mit dem Namen gpu-claim im Namespace dra-test verweisen. Die Container im Pod pod1 sind NVIDIA-CUDA-Beispiele (Compute Unified Device Architecture), die für die Ausführung von CUDA-Arbeitslasten auf den GPUs entwickelt wurden. Wenn der Pod pod1 erfolgreich abgeschlossen wurde, bedeutet dies, dass die Funktion zur dynamischen Ressourcenzuweisung ordnungsgemäß funktioniert und GPU-Ressourcen in Ihrem Cluster verwalten kann.

    Ubuntu

    1. Wenden Sie das Manifest mit dem folgenden Befehl auf Ihren Cluster an:

      cat <<EOF | kubectl apply --kubeconfig=CLUSTER_KUBECONFIG -f -
      apiVersion: v1
      kind: Pod
      metadata:
        name: pod1
        namespace: dra-test
      spec:
        restartPolicy: OnFailure
        resourceClaims:
          - name: gpu
            resourceClaimName: gpu-claim
        containers:
          - name: ctr0
            image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0
            resources:
              claims:
                - name: gpu
          - name: ctr1
            image: nvcr.io/nvidia/k8s/cuda-sample:devicequery
            resources:
              claims:
                - name: gpu
      EOF
      

    RHEL

    1. Wenden Sie das Manifest mit dem folgenden Befehl auf Ihren Cluster an:

      cat <<EOF | kubectl apply --kubeconfig=CLUSTER_KUBECONFIG -f -
      apiVersion: v1
      kind: Pod
      metadata:
        name: pod1
        namespace: dra-test
      spec:
        restartPolicy: OnFailure
      
        resourceClaims:
          - name: gpu
            resourceClaimName: gpu-claim
        containers:
          - name: ctr0
            image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0
            resources:
              claims:
                - name: gpu
          - name: ctr1
            image: nvcr.io/nvidia/k8s/cuda-sample:devicequery
            resources:
              claims:
                - name: gpu
      EOF
      

Beschränkungen

Beachten Sie bei der Verwendung der dynamischen Ressourcenzuweisung die folgenden Einschränkungen:

  • Wenn Sie das RHEL-Betriebssystem mit einer unterstützten Version des NVIDIA-GPU-Operators verwenden, übernimmt das Container Device Interface (CDI) die Geräteinjektion und die SELinux-Kennzeichnung automatisch. Sie müssen die SELinux-Richtlinie nicht manuell konfigurieren oder den Pod-securityContext festlegen.

  • Dieses Feature verwendet die API-Gruppe resource.k8s.io/v1beta1, die sich von der Open-Source-Kubernetes-API-Gruppe für dieses Feature (resource.k8s.io/v1) unterscheidet. Die Open-Source-API-Gruppe v1 bietet mehr Funktionen und eine bessere Stabilität als die API-Gruppe v1beta1.

Nächste Schritte