Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Erstellen Sie ein NodeClass


**Wichtig**  
Sie müssen mit 0 Knoten in Ihrer Instance-Gruppe beginnen und Karpenter die automatische Skalierung übernehmen lassen. Wenn Sie mit mehr als 0 Knoten beginnen, skaliert Karpenter diese auf 0 herunter.

Eine Knotenklasse (`NodeClass`) definiert Einstellungen auf Infrastrukturebene, die für Knotengruppen in Ihrem Amazon EKS-Cluster gelten, einschließlich Netzwerkkonfiguration, Speichereinstellungen und Ressourcen-Tagging. A `HyperPodNodeClass` ist ein benutzerdefinierter Code`NodeClass`, der vorab erstellten Instanzgruppen zugeordnet wird. Dabei werden Einschränkungen definiert SageMaker HyperPod, welche Instanztypen und Availability Zones für die automatische Skalierung von Karpenter unterstützt werden.

**Überlegungen zur Erstellung einer Knotenklasse**
+ Sie können bis zu 10 Instance-Gruppen in einer angeben`NodeClass`.
+ Bei Verwendung der GPU-Partitionierung mit MIG (Multi-Instance-GPU) kann Karpenter automatisch Knoten mit MIG-fähigen Instanzgruppen bereitstellen. Stellen Sie sicher, dass Ihre Instanzgruppen von MIG unterstützte Instanztypen (ml.p4d.24xlarge, ml.p5.48xlarge oder ml.p5e/p5en.48xlarge) enthalten, und konfigurieren Sie die entsprechenden MIG-Labels während der Clustererstellung. Weitere Informationen zur Konfiguration [Verwenden von GPU-Partitionen in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md) der GPU-Partitionierung finden Sie unter.
+ Wenn benutzerdefinierte Labels auf Instanzgruppen angewendet werden, können Sie sie bei der Statusabfrage im `desiredLabels` Feld einsehen. `HyperpodNodeClass` Dazu gehören MIG-Konfigurationsbezeichnungen wie`nvidia.com/mig.config`. Wenn eingehende Jobs MIG-Ressourcen anfordern, skaliert Karpenter automatisch die Instanzen mit den entsprechenden MIG-Bezeichnungen.
+ Wenn Sie sich dafür entscheiden, eine Instanzgruppe zu löschen, empfehlen wir, sie aus Ihrer zu entfernen, `NodeClass` bevor Sie sie aus Ihrem HyperPod Cluster löschen. Wenn eine Instance-Gruppe gelöscht wird, während sie in einem `NodeClass` verwendet wird, wird die `NodeClass` als nicht `Ready` für die Bereitstellung markiert und für nachfolgende Skalierungsvorgänge nicht verwendet, bis die Instance-Gruppe aus `NodeClass` entfernt wird.
+ Wenn Sie Instance-Gruppen aus einer entfernen`NodeClass`, erkennt Karpenter eine Abweichung auf den Knoten, die von Karpenter in der Instance-Gruppe (n) verwaltet wurden, und unterbricht die Knoten auf der Grundlage Ihrer Budgetkontrollen für Störungen.
+ Die von der Instance-Gruppe verwendeten Subnetze sollten derselben AZ angehören. Subnetze werden entweder mit `OverrideVpcConfig` auf Instance-Gruppenebene oder Clusterebene spezifiziert. `VpcConfig` wird standardmäßig verwendet.
+ Derzeit wird nur On-Demand-Kapazität unterstützt. Instance-Gruppen mit Trainingsplan oder reservierter Kapazität werden nicht unterstützt.
+ Instance-Gruppen mit `DeepHealthChecks (DHC)` werden nicht unterstützt. Das liegt daran, dass die Fertigstellung eines DHC etwa 60 bis 90 Minuten in Anspruch nimmt und die Pods während dieser Zeit im Status „Ausstehend“ verbleiben, was zu einer Überprovisionierung führen kann.

In den folgenden Schritten wird erklärt, wie eine erstellt wird`NodeClass`.

1. Erstellen Sie eine YAML-Datei (z. B. nodeclass.yaml) mit Ihrer `NodeClass`-Konfiguration.

1. Wenden Sie die Konfiguration mit kubectl auf Ihren Cluster an.

1. Verweisen Sie `NodeClass` in Ihrer `NodePool` Konfiguration auf.

1. Im Folgenden finden Sie ein Beispiel`NodeClass`, das die Instance-Typen ml.c5.xlarge und ml.c5.4xlarge verwendet:

   ```
   apiVersion: karpenter.sagemaker.amazonaws.com/v1
   kind: HyperpodNodeClass
   metadata:
     name: sample-nc
   spec:
     instanceGroups:
       # name of InstanceGroup in HyperPod cluster. InstanceGroup needs to pre-created
       # MaxItems: 10
       - auto-c5-xaz1
       - auto-c5-4xaz2
   ```

1. Wenden Sie die Konfiguration an:

   ```
   kubectl apply -f nodeclass.yaml
   ```

1. Überwachen Sie den NodeClass Status, um sicherzustellen, dass die Bedingung Bereit im Status auf True gesetzt ist:

   ```
   kubectl get hyperpodnodeclass sample-nc -o yaml
   ```

   ```
   apiVersion: karpenter.sagemaker.amazonaws.com/v1
   kind: HyperpodNodeClass
   metadata:
     creationTimestamp: "<timestamp>"
     name: sample-nc
     uid: <resource-uid>
   spec:
     instanceGroups:
     - auto-c5-az1
     - auto-c5-4xaz2
   status:
     conditions:
     // true when all IGs in the spec are present in SageMaker cluster, false otherwise
     - lastTransitionTime: "<timestamp>"
       message: ""
       observedGeneration: 3
       reason: InstanceGroupReady
       status: "True"
       type: InstanceGroupReady
     // true if subnets of IGs are discoverable, false otherwise
     - lastTransitionTime: "<timestamp>"
       message: ""
       observedGeneration: 3
       reason: SubnetsReady
       status: "True"
       type: SubnetsReady
     // true when all dependent resources are Ready [InstanceGroup, Subnets]
     - lastTransitionTime: "<timestamp>"
       message: ""
       observedGeneration: 3
       reason: Ready
       status: "True"
       type: Ready
     instanceGroups:
     - desiredLabels:
       - key: <custom_label_key>
         value: <custom_label_value>
       - key: nvidia.com/mig.config
         value: all-1g.5gb
       instanceTypes:
       - ml.c5.xlarge
       name: auto-c5-az1
       subnets:
       - id: <subnet-id>
         zone: <availability-zone-a>
         zoneId: <zone-id-a>
     - instanceTypes:
       - ml.c5.4xlarge
       name: auto-c5-4xaz2
       subnets:
       - id: <subnet-id>
         zone: <availability-zone-b>
         zoneId: <zone-id-b>
   ```