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 auf, 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.

Kostenoptimierung im EKS Auto Mode

Der automatische Modus von EKS optimiert kontinuierlich die Rechenkosten Ihres Clusters durch Konsolidierung, Bin-Packing und die richtige Dimensionierung. Bestimmte Workload-Konfigurationen können diese Optimierungen jedoch verhindern. In diesem Thema wird erklärt, wie die Kostenoptimierung funktioniert, was sie verhindern kann und wie Sie Ihren Cluster konfigurieren, um die Kosteneffizienz aufrechtzuerhalten.

Wie der automatische Modus von EKS die Kosten optimiert

Der EKS-Automatikmodus reduziert die Rechenkosten durch die folgenden Mechanismen:

Diese Optimierungen werden kontinuierlich ohne manuelles Eingreifen ausgeführt. Bestimmte Pod-Anmerkungen und NodePool Konfigurationen können jedoch verhindern, dass die Konsolidierung wirksam wird.

Built-in Knotenpools und Kostenplanken

Die integrierten Pools general-purpose und die system Knotenpools setzen bereits mehrere kostenschützende Standardeinstellungen durch:

Wenn Sie nur die integrierten Knotenpools verwenden, profitieren Sie bereits von diesen Leitplanken. Die Hinweise in diesem Thema zum Ausschluss von Instanzfamilien und zur Beschränkung der Instanzgrößen sind vor allem dann relevant, wenn Sie benutzerdefinierte Instanzen erstellen NodePools, die diese Einschränkungen nicht erben.

Die folgenden Abschnitte gelten jedoch auch bei integrierten Knotenpools weiterhin für Sie:

Was blockiert die Konsolidierung

Die Konsolidierung wird blockiert, wenn der automatische Modus von EKS feststellt, dass die Unterbrechung eines Knotens die Verfügbarkeitsanforderungen eines Workloads verletzen würde. Die folgenden Konfigurationen verhindern eine Konsolidierung:

Die Anmerkung „Nicht stören“

Die karpenter.sh/do-not-disrupt Anmerkung weist EKS Auto Mode an, einen Knoten beizubehalten, solange der kommentierte Pod darauf läuft. Dadurch wird verhindert, dass der Knoten konsolidiert, ersetzt oder beendet wird, selbst wenn der Knoten nicht ausgelastet ist.

metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

Zu berücksichtigende Alternativen:

Budgets für Pod-Störungen (PDBs)

PDBs, bei denen die aktuelle Anzahl an Replikaten festgelegt ist maxUnavailable: 0 oder dieser minAvailable entspricht, blockieren effektiv die gesamte Konsolidierung für die betroffenen Pods. Überprüfen Sie Ihre PDBs, um sicherzustellen, dass mindestens ein Pod gleichzeitig unterbrochen werden kann.

Verwenden Sie NodePool Limits als Kostenobergrenze

NodePool limitslegen Sie eine feste Obergrenze für die gesamten Rechenressourcen fest, die ein NodePool Unternehmen bereitstellen kann. Wenn das Limit erreicht ist, beendet der automatische Modus von EKS den Start neuer Knoten dafür NodePool. Dies passiert auch dann, wenn Pods noch ausstehen.

Wird limits als Kostenbegrenzung verwendet, insbesondere für NodePools nicht produktive, Test- oder Burst-Workloads, bei denen eine unbegrenzte Skalierung nicht angemessen ist.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
  limits:
    cpu: "500"
    memory: 1000Gi

In diesem Beispiel ci-runners NodePool darf die Summe von 500 vCPUs oder 1000 GiB Arbeitsspeicher auf allen von ihr bereitgestellten Knoten nicht überschreiten. Pods, die diesen Grenzwert überschreiten, bleiben so lange im Pending Status, bis Kapazität freigegeben wird.

Schließen Sie Instance-Familien aus Gründen der Kostenkontrolle aus

Standardmäßig wählt der automatische Modus von EKS aus einer Vielzahl von Instance-Typen aus, um die Flexibilität bei der Planung zu maximieren. Für Workloads, für die keine spezielle Hardware erforderlich ist, sollten Sie die Instance-Familien einschränken, um zu verhindern, dass teure Instance-Typen gestartet werden.

Schließen Sie beschleunigte Instanzen aus

Wenn Ihre Workloads keine GPU- oder Accelerator-Ressourcen anfordern, schließen Sie beschleunigte Instance-Familien von Ihren NodePool aus. Dadurch werden Szenarien vermieden, in denen beschleunigte Instances bei Kapazitätsengpässen ausgewählt werden.

spec:
  template:
    spec:
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]

Indem Sie nur rechenoptimierte, allgemeine und speicheroptimierte Kategorien angeben, schließen Sie beschleunigte (P, G, Inf, Trn) und andere spezialisierte Instance-Familien von der Auswahl aus.

Wie die Instance-Auswahl mit Kapazitätsbeschränkungen interagiert

Der automatische EKS-Modus depriorisiert beschleunigte und exotische Instance-Typen bei der normalen Instance-Auswahl. Wenn jedoch anhaltende Startfehler auftreten, wird der automatische Modus von EKS von jedem verbleibenden verfügbaren Instance-Typ aus gestartet, um der Workload-Verfügbarkeit Priorität einzuräumen. Dies ist beispielsweise der Fall, wenn die EC2-Servicekontingente für alle bevorzugten Instance-Typen vorübergehend ausgeschöpft sind.

Um dieses Fallback-Verhalten zu verhindern, beschränken Sie Ihre NodePool Anforderungen explizit auf die Instance-Kategorien, die Ihre Workload benötigt. Wenn bevorzugte Typen nicht verfügbar sind und Ihre NodePool Konfiguration keine anderen Typen zulässt, bleiben Pods im Pending Status, anstatt für teure Instances geplant zu werden.

Beschränken Sie die Instanzgrößen

Sie können nicht nur Instanzfamilien einschränken, sondern auch die maximale Instanzgröße innerhalb Ihrer. NodePool Durch die Beschränkung der Instanzgrößen wird das Kostenrisiko für einzelne Knoten begrenzt, die nicht konsolidiert werden können. Beispielsweise kann ein durch eine do-not-disrupt Anmerkung blockierter Knoten nicht schrumpfen, selbst wenn seine Arbeitslast gering ist.

Verwenden Sie das eks.amazonaws.com/instance-cpu Label, um die maximale Instanzgröße gemäß Ihren NodePool Anforderungen zu begrenzen:

requirements:
  - key: "eks.amazonaws.com/instance-cpu"
    operator: Lte
    values: ["32"]

Diese Konfiguration verhindert, dass EKS Auto Mode in diesem Fall Instances startet, die größer als 32 vCPUs sind. NodePool

Um Optimierungsmöglichkeiten in einem vorhandenen Cluster zu identifizieren, überprüfen Sie Ihre größten laufenden Instances. Wenn große Knoten ständig an der Konsolidierung gehindert werden, sind die Kosten pro Knoten für diese ungenutzte Kapazität proportional höher.

Empfohlene Muster für ausgelastete Workloads

CI/CD Pipelines, Batch-Jobs und kurzlebige Runner erzeugen Burst-and-Idle-Muster, die eine spezielle Konfiguration erfordern, um die Kosteneffizienz aufrechtzuerhalten.

Empfohlene Standardwerte für Burst-Workloads

Beispiel: CI-Runner NodePool

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
        - key: "eks.amazonaws.com/instance-cpu"
          operator: Lte
          values: ["32"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
  limits:
    cpu: "500"
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Diese Konfiguration:

Lebenszyklus und Kosten des Knotens

Der EKS-Automatikmodus ersetzt Knoten automatisch, wenn sie von ihrer gewünschten Spezifikation abweichen (z. B. nach der Veröffentlichung eines neuen Auto-Modus-AMI) oder wenn sich die Lebensdauer des Knotens dem Ablauf nähert. Während des ordnungsgemäßen Austauschs:

Bei Clustern mit großen oder vielen Knoten kann diese Überlappung zu regelmäßigen Kostensteigerungen führen. Um die Auswirkungen zu minimieren:

Weitere Informationen zum Knotenlebenszyklus finden Sie unter Erfahren Sie mehr über Amazon EKS Auto Mode Managed Instances.