Unterstützung für die Verbesserung dieser Seite beitragen
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.
Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten unter, der sich im rechten Bereich jeder Seite befindet.
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.
Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird
Bei der Ausführung von Workloads in einem EKS-Cluster mit EKS Auto Mode kann es erforderlich sein, zu steuern, ob bestimmte Workloads in Knoten von EKS Auto Mode oder anderen Rechentypen ausgeführt werden. In diesem Thema wird beschrieben, wie Sie mithilfe von Knoten-Selektoren und Affinitätsregeln sicherstellen können, dass Ihre Workloads in der vorgesehenen Recheninfrastruktur geplant werden.
Die Beispiele in diesem Thema veranschaulichen, wie Sie mithilfe des eks.amazonaws.com/compute-type-Labels die Bereitstellung von Workloads auf Knoten in EKS Auto Mode entweder erfordern oder verhindern können. Dies ist besonders nützlich für Cluster im gemischten Modus, in denen sowohl EKS Auto Mode als auch andere Rechentypen ausgeführt werden, beispielsweise selbstverwaltete Karpenter-Bereitsteller oder EKS-verwaltete Knotengruppen.
Knoten von EKS Auto Mode haben den Wert des Labels von eks.amazonaws.com/compute-type auf auto festgelegt. Mit diesem Label können Sie steuern, ob eine Workload in Knoten bereitgestellt wird, die von EKS Auto Mode verwaltet werden.
Erfordern, dass eine Arbeitslast auf EKS-Auto-Mode-Knoten bereitgestellt wird
Anmerkung
Dieser nodeSelector-Wert ist für EKS Auto Mode nicht erforderlich. Dieser nodeSelector-Wert ist nur relevant, wenn Sie einen Cluster im gemischten Modus ausführen, dessen Knotentypen nicht von EKS Auto Mode verwaltet werden. Beispielsweise können Sie in Ihrem Cluster über EKS-verwaltete Knotengruppen statische Rechenkapazität bereitstellen und über dynamische Rechenkapazität verfügen, die von EKS Auto Mode verwaltet wird.
Sie können diesen nodeSelector zu Bereitstellungen oder anderen Workloads hinzufügen, um zu verlangen, dass Kubernetes sie in Knoten von EKS Auto Mode plant.
apiVersion: apps/v1 kind: Deployment spec: template: spec: nodeSelector: eks.amazonaws.com/compute-type: auto
Erfordern Sie, dass keine Arbeitslast auf EKS-Auto-Mode-Knoten bereitgestellt wird
Sie können diesen nodeAffinity zu Bereitstellungen oder anderen Workloads hinzufügen, um zu verlangen, dass Kubernetes sie nicht in Knoten von EKS Auto Mode plant.
affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - auto
Zielen Sie auf ein bestimmtes NodePool
Ein Amazon EKS Auto Mode-Cluster kann mehrere haben NodePool. Möglicherweise möchten Sie, dass ein Workload nur auf Knoten eines bestimmten Computers ausgeführt wird NodePool. Um dies zu erreichen, können Workloads mit einem der folgenden Labels übereinstimmen:
-
Ein benutzerdefiniertes Label, das Sie auf der NodePool definieren. Wenn Sie Labels unter
spec.template.metadata.labelsin a hinzufügen NodePool, wendet Amazon EKS Auto Mode diese Labels auf jeden Knoten an, den er NodePool bereitstellt. Benutzerdefinierte Labels sind der empfohlene Ansatz. Ein benutzerdefiniertes Label verknüpft die Arbeitslast nicht mit einem bestimmten NodePool Namenworkload-class: gpu-inference, sondern mit einer Fähigkeit, z. B. -
Das bekannte
karpenter.sh/nodepoolLabel. Amazon EKS Auto Mode wendet dieses Label auf jeden Knoten an, den es bereitstellt, wobei der Name des NodePool als Wert verwendet wird. Verwenden Sie dieses Label, wenn Sie kein benutzerdefiniertes Label definiert haben und ein Zielkennzeichen als NodePool Zielnamen verwenden möchten.
Wählen Sie ein benutzerdefiniertes NodePool Label als Ziel
Definieren Sie zunächst ein Etikett auf dem NodePool.
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu spec: template: metadata: labels: workload-class: gpu-inference
Weitere Hinweise zur NodePool Konfiguration finden Sie unterErstellen eines Knotenpools für EKS Auto Mode.
Ordnen Sie als Nächstes das Label aus dem Workload zu.
apiVersion: apps/v1 kind: Deployment metadata: name: inference spec: template: spec: nodeSelector: workload-class: gpu-inference
Pods aus diesem Bereitstellungszeitplan nur auf Knoten, die von diesem Bereitstellungszeitplan gpu NodePool bereitgestellt werden. Workloads ohne diese Option nodeSelector werden weiterhin auf der Standardeinstellung NodePool ausgeführt.
Nehmen Sie ein Ziel mit NodePool Namen an
NodePool Namensänderungen wirken sich auf die Planung aus
Wenn Sie einen Workload anhand des Namens anheften, kann dies dazu führen, dass die Pods den Pending Status beibehalten, wenn Sie das Ziel NodePool umbenennen oder löschen. Verwenden Sie eine benutzerdefinierte Funktionsbezeichnung für jeden Workload, von dem Sie erwarten, dass er eine einzelne NodePool Definition überdauert.
apiVersion: apps/v1 kind: Deployment spec: template: spec: nodeSelector: karpenter.sh/nodepool: <your-nodepool-name>
Weitere Informationen darüber, wie Karpenter Pods zuordnet NodePools, finden Sie in der Karpenter-Dokumentation unter