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.

Karpenter

Karpenter ist ein Open-Source-Projekt zur Verbesserung des Node-Lifecycle-Managements in Kubernetes-Clustern. Es automatisiert die Bereitstellung und Deprovisionierung von Knoten auf der Grundlage der spezifischen Planungsanforderungen von Pods und ermöglicht so eine effiziente Skalierung und Kostenoptimierung. Ihre Hauptfunktionen sind:

Mit Karpenter können Sie Einschränkungen für die Bereitstellung von Knoten festlegen NodePools , wie z. B. Taints, Labels, Anforderungen (Instance-Typen, Zonen usw.) und Beschränkungen für die Gesamtzahl der bereitgestellten Ressourcen. Bei der Bereitstellung von Workloads können Sie in den Pod-Spezifikationen verschiedene Planungseinschränkungen wie Ressourcen requests/limits, Knotenselektoren, node/pod Affinitäten, Toleranzen und Topologiestreuungsbeschränkungen angeben. Karpenter stellt dann auf der Grundlage dieser Spezifikationen Knoten in der richtigen Größe bereit.

Gründe, Karpenter zu verwenden

Vor der Einführung von Karpenter verließen sich Kubernetes-Benutzer hauptsächlich auf Amazon EC2 Auto Scaling-Gruppen und den Kubernetes Cluster Autoscaler (CAS), um die Rechenkapazität ihrer Cluster dynamisch anzupassen. Mit Karpenter müssen Sie nicht Dutzende von Knotengruppen erstellen, um die Flexibilität und Vielfalt zu erreichen, die Sie mit Karpenter erhalten. Im Gegensatz zu CAS ist Karpenter nicht so eng an die Kubernetes-Versionen gekoppelt und Sie müssen nicht zwischen AWS- und Kubernetes-APIs wechseln.

Karpenter konsolidiert die Zuständigkeiten für die Instanz-Orchestrierung in einem einzigen System, das einfacher, stabiler und clusterfähiger ist. Karpenter wurde entwickelt, um einige der Herausforderungen zu bewältigen, die Cluster Autoscaler mit sich bringt, indem es vereinfachte Möglichkeiten bietet, um:

Informationen und Dokumentation zur Verwendung von Karpenter finden Sie auf der Website karpenter.sh.

Empfehlungen

Bewährte Methoden sind in Abschnitte über Karpenter selbst und Pod-Planung NodePools unterteilt.

Bewährte Verfahren bei Karpenter

Die folgenden bewährten Methoden beziehen sich auf Themen, die sich auf Karpenter selbst beziehen.

Sperren Sie AMIs in Produktionsclustern

Wir empfehlen dringend, dass Sie bekannte Amazon Machine Images (AMIs) anheften, die von Karpenter für Produktionscluster verwendet werden. Die Verwendung amiSelector mit einem auf gesetzten Alias oder die Verwendung einer anderen Methode@latest, die dazu führt, dass ungetestete AMIs bereitgestellt werden, sobald sie veröffentlicht werden, birgt das Risiko von Workload-Ausfällen und Ausfallzeiten in Ihren Produktionsclustern. Daher empfehlen wir dringend, getestete Arbeitsversionen von AMIs für Ihre Produktionscluster anzuheften, während Sie neuere Versionen in Nicht-Produktionsclustern testen. Sie könnten beispielsweise NodeClass wie folgt einen Alias in Ihrem einrichten:

amiSelectorTerms
  - alias: al2023@v20240807

Informationen zur Verwaltung und Fixierung von AMIs in Karpenter finden Sie unter AMIs verwalten in der Karpenter-Dokumentation.

Verwenden Sie Karpenter für Workloads mit wechselnden Kapazitätsanforderungen

Karpenter bringt das Skalierungsmanagement den nativen Kubernetes-APIs näher als Autoscaling Groups (ASGs) und Managed Node Groups (MNGs). https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html ASGs und MNGs sind AWS-native Abstraktionen, bei denen die Skalierung auf der Grundlage von Metriken auf AWS-Ebene, wie z. B. der EC2-CPU-Last, ausgelöst wird. Cluster Autoscaler verbindet die Kubernetes-Abstraktionen mit AWS-Abstraktionen, verliert dadurch jedoch an Flexibilität, beispielsweise bei der Planung für eine bestimmte Availability Zone.

Karpenter entfernt eine Ebene der AWS-Abstraktion, um einen Teil der Flexibilität direkt in Kubernetes zu integrieren. Karpenter eignet sich am besten für Cluster mit Workloads, die in Zeiten hoher Nachfrage oder mit unterschiedlichen Rechenanforderungen konfrontiert sind. MNGs und ASGs eignen sich gut für Cluster, auf denen Workloads ausgeführt werden, die tendenziell statischer und konsistenter sind. Je nach Ihren Anforderungen können Sie eine Mischung aus dynamisch und statisch verwalteten Knoten verwenden.

Ziehen Sie andere Autoscaling-Projekte in Betracht, wenn...

Sie benötigen Funktionen, die in Karpenter noch entwickelt werden. Da Karpenter ein relativ neues Projekt ist, sollten Sie vorerst andere Autoscaling-Projekte in Betracht ziehen, wenn Sie Funktionen benötigen, die noch nicht Teil von Karpenter sind.

Führen Sie den Karpenter Controller auf EKS Fargate oder auf einem Worker-Knoten aus, der zu einer Knotengruppe gehört

Karpenter wird mithilfe eines Helm-Diagramms installiert. https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#4-install-karpenter Das Helm-Diagramm installiert den Karpenter-Controller und einen Webhook-Pod als Deployment, das ausgeführt werden muss, bevor der Controller für die Skalierung Ihres Clusters verwendet werden kann. Wir empfehlen mindestens eine kleine Knotengruppe mit mindestens einem Worker-Knoten. Als Alternative können Sie diese Pods auf EKS Fargate ausführen, indem Sie ein Fargate-Profil für den karpenter Namespace erstellen. Dadurch werden alle in diesem Namespace bereitgestellten Pods auf EKS Fargate ausgeführt. Führen Sie Karpenter nicht auf einem Knoten aus, der von Karpenter verwaltet wird.

In Karpenter werden keine benutzerdefinierten Startvorlagen unterstützt

Es gibt keine Unterstützung für benutzerdefinierte Startvorlagen mit v1-APIs. Sie können benutzerdefinierte Benutzerdaten and/or direkt verwenden, indem Sie benutzerdefinierte AMIs in der angeben EC2NodeClass. Weitere Informationen dazu finden Sie unter NodeClasses.

Schließen Sie Instanztypen aus, die nicht zu Ihrer Arbeitslast passen

Erwägen Sie, bestimmte Instanztypen mit dem node.kubernetes.io/instance-type Schlüssel auszuschließen, wenn sie für Workloads, die in Ihrem Cluster ausgeführt werden, nicht erforderlich sind.

Das folgende Beispiel zeigt, wie Sie die Bereitstellung großer Graviton-Instanzen vermeiden können.

- key: node.kubernetes.io/instance-type
  operator: NotIn
  values:
  - m6g.16xlarge
  - m6gd.16xlarge
  - r6g.16xlarge
  - r6gd.16xlarge
  - c6g.16xlarge

Interruption Handling bei Verwendung von Spot aktivieren

Karpenter unterstützt den systemeigenen Umgang mit Unterbrechungen und kann unfreiwillige Unterbrechungsereignisse wie Spot-Instance-Unterbrechungen, geplante Wartungsereignisse und Instance-Ereignisse, die Ihre Workloads stören könntentermination/stopping , verarbeiten. Wenn Karpenter solche Ereignisse für Knoten erkennt, werden die betroffenen Knoten automatisch verfälscht, entleert und im Voraus geschlossen, um mit der ordnungsgemäßen Bereinigung der Workloads zu beginnen, bevor sie unterbrochen werden. Bei Spot-Unterbrechungen mit einer Frist von 2 Minuten startet Karpenter schnell einen neuen Knoten, sodass die Pods verschoben werden können, bevor die Instanz wieder beansprucht wird. Um die Behandlung von Unterbrechungen zu ermöglichen, konfigurieren Sie das --interruption-queue CLI-Argument mit dem Namen der SQS-Warteschlange, die für diesen Zweck bereitgestellt wurde. Es wird nicht empfohlen, die Karpenter Interruption Handler zusammen mit dem Node Termination Handler zu verwenden, wie hier erklärt. https://karpenter.sh/docs/faq/#interruption-handling

Pods, bei denen Checkpoints oder andere Formen der ordentlichen Entleerung erforderlich sind und die 2 Minuten vor dem Herunterfahren benötigen, sollten die Karpenter Interruptionshandling in ihren Clustern ermöglichen.

Privater Amazon EKS-Cluster ohne ausgehenden Internetzugang

Wenn Sie einen EKS-Cluster in einer VPC ohne Route zum Internet bereitstellen, müssen Sie sicherstellen, dass Sie Ihre Umgebung gemäß den Anforderungen für private Cluster konfiguriert haben, die in der EKS-Dokumentation aufgeführt sind. Darüber hinaus müssen Sie sicherstellen, dass Sie in Ihrer VPC einen regionalen STS-VPC-Endpunkt erstellt haben. Wenn nicht, werden Fehler angezeigt, die den unten aufgeführten ähneln.

{"level":"FATAL","time":"2024-02-29T14:28:34.392Z","logger":"controller","message":"Checking EC2 API connectivity, WebIdentityErr: failed to retrieve credentials\ncaused by: RequestError: send request failed\ncaused by: Post \"https://sts.<region>.amazonaws.com/\": dial tcp 54.239.32.126:443: i/o timeout","commit":"596ea97"}

Diese Änderungen sind in einem privaten Cluster erforderlich, da der Karpenter Controller IAM-Rollen für Dienstkonten (IRSA) verwendet. Mit IRSA konfigurierte Pods erhalten Anmeldeinformationen, indem sie die AWS Security Token Service (AWS STS) -API aufrufen. Wenn es keinen ausgehenden Internetzugang gibt, müssen Sie einen AWS STS-VPC-Endpunkt in Ihrer VPC erstellen und verwenden.

Bei privaten Clustern müssen Sie außerdem einen VPC-Endpunkt für SSM erstellen. Wenn Karpenter versucht, einen neuen Knoten bereitzustellen, fragt es die Launch-Vorlagenkonfigurationen und einen SSM-Parameter ab. Wenn Sie keinen SSM-VPC-Endpunkt in Ihrer VPC haben, wird der folgende Fehler verursacht:

{"level":"ERROR","time":"2024-02-29T14:28:12.889Z","logger":"controller","message":"Unable to hydrate the AWS launch template cache, RequestCanceled: request context canceled\ncaused by: context canceled","commit":"596ea97","tag-key":"karpenter.k8s.aws/cluster","tag-value":"eks-workshop"}
...
{"level":"ERROR","time":"2024-02-29T15:08:58.869Z","logger":"controller.nodeclass","message":"discovering amis from ssm, getting ssm parameter \"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id\", RequestError: send request failed\ncaused by: Post \"https://ssm.<region>.amazonaws.com/\": dial tcp 67.220.228.252:443: i/o timeout","commit":"596ea97","ec2nodeclass":"default","query":"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id"}

Es gibt keinen VPC-Endpunkt für die Preislistenabfrage-API. Infolgedessen werden die Preisdaten im Laufe der Zeit veraltet sein. Karpenter umgeht dies, indem es On-Demand-Preisdaten in seine Binärdatei aufnimmt, diese Daten jedoch nur aktualisiert, wenn Karpenter aktualisiert wird. Fehlgeschlagene Anfragen nach Preisdaten führen zu den folgenden Fehlermeldungen:

{"level":"ERROR","time":"2024-02-29T15:08:58.522Z","logger":"controller.pricing","message":"retreiving on-demand pricing data, RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.196.224.8:443: i/o timeout; RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.185.143.117:443: i/o timeout","commit":"596ea97"}

In dieser Dokumentation erfahren Sie, wie Sie Karpenter in einem vollständig privaten EKS-Cluster verwenden und wissen, welche VPC-Endpunkte erstellt werden müssen.

Erstellen NodePools

Die folgenden bewährten Methoden behandeln Themen im Zusammenhang mit der Erstellung NodePools.

Erstellen Sie mehrere NodePools , wenn...

Wenn verschiedene Teams einen Cluster gemeinsam nutzen und ihre Workloads auf verschiedenen Worker-Nodes ausführen müssen oder unterschiedliche Anforderungen an das Betriebssystem oder den Instanztyp haben, erstellen Sie mehrere NodePools. Beispielsweise möchte ein Team möglicherweise Bottlerocket verwenden, während ein anderes möglicherweise Amazon Linux verwenden möchte. Ebenso könnte ein Team Zugriff auf teure GPU-Hardware haben, die von einem anderen Team nicht benötigt würde. Durch die Verwendung mehrerer Geräte NodePools wird sichergestellt, dass jedem Team die am besten geeigneten Ressourcen zur Verfügung stehen.

Erstellen Sie NodePools Elemente, die sich gegenseitig ausschließen oder gewichtet sind

Es wird empfohlen, Elemente zu erstellen NodePools , die sich entweder gegenseitig ausschließen oder gewichtet sind, um ein einheitliches Planungsverhalten zu gewährleisten. Wenn dies nicht der Fall ist und mehrere NodePools übereinstimmen, wählt Karpenter nach dem Zufallsprinzip aus, welche verwendet werden soll, was zu unerwarteten Ergebnissen führt. Zu den hilfreichen Beispielen für die Erstellung mehrerer Elemente NodePools gehören die folgenden:

Erstellen Sie eine NodePool mit GPU und lassen Sie nur spezielle Workloads auf diesen (teuren) Knoten ausführen:

# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    metadata: {}
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: Never
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - p3.8xlarge
        - p3.16xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      taints:
      - effect: NoSchedule
        key: nvidia.com/gpu
        value: "true"

Bereitstellung mit Toleranz gegenüber dem Makel:

# Deployment of GPU Workload will have tolerations defined
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate-gpu
spec:
    spec:
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"

Für einen allgemeinen Einsatz für ein anderes Team könnte die NodePool Spezifikation NodeAffinity enthalten. Ein Deployment könnte dann den passenden Knoten SelectorTerms verwenden. billing-team

# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: generalcompute
spec:
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: Never
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - m5.large
        - m5.xlarge
        - m5.2xlarge
        - c5.large
        - c5.xlarge
        - c5a.large
        - c5a.xlarge
        - r5.large
        - r5.xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand

Bereitstellung mit NodeAffinity:

# Deployment will have spec.affinity.nodeAffinity defined
kind: Deployment
metadata:
  name: workload-my-team
spec:
  replicas: 200
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: "billing-team"
                  operator: "In"
                  values: ["my-team"]

Verwenden Sie Timer (TTL), um Knoten automatisch aus dem Cluster zu löschen

Sie können Timer auf bereitgestellten Knoten verwenden, um festzulegen, wann Knoten gelöscht werden sollen, die keine Workload-Pods enthalten oder die eine Ablaufzeit erreicht haben. Das Ablaufen von Knoten kann als Methode für ein Upgrade verwendet werden, sodass Knoten außer Betrieb genommen und durch aktualisierte Versionen ersetzt werden. Informationen zur Konfiguration des Ablaufs von Knoten finden Sie in der Karpenter-Dokumentation unter spec.template.spec Ablauf.

Vermeiden Sie es, die Instance-Typen, die Karpenter bereitstellen kann, zu stark einzuschränken, insbesondere wenn Sie Spot verwenden

Bei der Verwendung von Spot verwendet Karpenter die Zuweisungsstrategie „Price Capacity Optimized“, um EC2-Instances bereitzustellen. Diese Strategie weist EC2 an, Instances aus den tiefsten Pools für die Anzahl der Instances bereitzustellen, die Sie starten und bei denen das geringste Risiko einer Unterbrechung besteht. EC2 Fleet fordert dann Spot-Instances aus dem preisgünstigsten dieser Pools an. Je mehr Instance-Typen Sie Karpenter verwenden lassen, desto besser kann EC2 die Laufzeit Ihrer Spot-Instance optimieren. Standardmäßig verwendet Karpenter alle Instance-Typen, die EC2 in der Region und den Verfügbarkeitszonen anbietet, in denen Ihr Cluster bereitgestellt wird. Karpenter wählt auf der Grundlage ausstehender Pods intelligent aus allen Instance-Typen aus, um sicherzustellen, dass Ihre Pods auf entsprechend dimensionierten und ausgestatteten Instances eingeplant werden. Wenn Ihr Pod beispielsweise keine GPU benötigt, plant Karpenter Ihren Pod nicht für einen EC2-Instance-Typ ein, der eine GPU unterstützt. Wenn Sie sich nicht sicher sind, welche Instance-Typen Sie verwenden sollen, können Sie den Amazon ec2-instance-selector ausführen, um eine Liste von Instance-Typen zu generieren, die Ihren Rechenanforderungen entsprechen. Die CLI verwendet beispielsweise Speicher, vCPU, Architektur und Region als Eingabeparameter und stellt Ihnen eine Liste von EC2-Instances zur Verfügung, die diese Einschränkungen erfüllen.

$ ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 -r ap-southeast-1
c5.large
c5a.large
c5ad.large
c5d.large
c6i.large
t2.medium
t3.medium
t3a.medium

Sie sollten Karpenter nicht zu viele Einschränkungen auferlegen, wenn Sie Spot-Instances verwenden, da dies die Verfügbarkeit Ihrer Anwendungen beeinträchtigen kann. Nehmen wir zum Beispiel an, alle Instances eines bestimmten Typs werden zurückgefordert und es gibt keine geeigneten Alternativen, um sie zu ersetzen. Ihre Pods bleiben im Status „Ausstehend“, bis die Spot-Kapazität für die konfigurierten Instance-Typen wieder aufgefüllt ist. Sie können das Risiko von Fehlern bei unzureichender Kapazität verringern, indem Sie Ihre Instances auf verschiedene Availability Zones verteilen, da Spot-Pools je nach AZs unterschiedlich sind. Im Allgemeinen empfiehlt es sich jedoch, Karpenter zu gestatten, bei der Verwendung von Spot eine Vielzahl von Instance-Typen zu verwenden.

Pods planen

Die folgenden bewährten Methoden beziehen sich auf die Bereitstellung von Pods in einem Cluster mithilfe von Karpenter für die Knotenbereitstellung.

Folgen Sie den Best Practices von EKS für hohe Verfügbarkeit

Wenn Sie Anwendungen mit hoher Verfügbarkeit ausführen müssen, folgen Sie den allgemeinen EKS-Empfehlungen für bewährte Verfahren. Einzelheiten zur Verteilung von Pods auf Knoten und Zonen finden Sie in der Dokumentation zur Verteilung der Topologie in Karpenter. Verwenden Sie Disruption Budgets, um die Mindestanzahl verfügbarer Pods festzulegen, die gewartet werden müssen, falls versucht wird, Pods zu entfernen oder zu löschen.

Verwenden Sie mehrstufige Beschränkungen, um die von Ihrem Cloud-Anbieter verfügbaren Rechenfunktionen einzuschränken

Das Modell der mehrschichtigen Beschränkungen von Karpenter ermöglicht es Ihnen, einen komplexen Satz von NodePool Einschränkungen für die Pod-Bereitstellung zu erstellen, um die bestmöglichen Übereinstimmungen für die Pod-Planung zu erzielen. Zu den Einschränkungen, die eine Pod-Spezifikation verlangen kann, gehören beispielsweise die folgenden:

Erstellen Sie Abrechnungsalarme, um Ihre Computerausgaben zu überwachen

Wenn Sie Ihren Cluster so konfigurieren, dass er automatisch skaliert, sollten Sie Abrechnungsalarme erstellen, die Sie warnen, wenn Ihre Ausgaben einen Schwellenwert überschritten haben, und Ihrer Karpenter-Konfiguration Ressourcenlimits hinzufügen. Das Festlegen von Ressourcenlimits mit Karpenter ähnelt dem Festlegen der maximalen Kapazität einer AWS-Autoscaling-Gruppe, da es die maximale Menge an Rechenressourcen darstellt, die von einem Karpenter instanziiert werden können. NodePool

Der folgende Ausschnitt weist Karpenter an, nur maximal 1000 CPU-Kerne und 1000 Gi Arbeitsspeicher bereitzustellen. Karpenter beendet das Hinzufügen von Kapazität erst, wenn das Limit erreicht oder überschritten wird. Wenn ein Limit überschritten wird, schreibt memory resource usage of 1001 exceeds limit of 1000 der Karpenter Controller eine ähnlich aussehende Meldung in die Logs des Controllers. Wenn Sie Ihre Container-Logs an CloudWatch Logs weiterleiten, können Sie einen Metrikfilter erstellen, um in Ihren Logs nach bestimmten Mustern oder Begriffen zu suchen, und dann einen CloudWatch Alarm erstellen, der Sie warnt, wenn Ihr konfigurierter Metrik-Schwellenwert überschritten wird.

Weitere Informationen zur Verwendung von Grenzwerten mit Karpenter finden Sie in der Karpenter-Dokumentation unter Ressourcenlimits festlegen.

spec:
  limits:
    cpu: 1000
    memory: 1000Gi

Wenn Sie keine Limits verwenden oder die Instanztypen, die Karpenter bereitstellen kann, einschränken, fügt Karpenter Ihrem Cluster bei Bedarf weiterhin Rechenkapazität hinzu. Wenn Sie Karpenter auf diese Weise konfigurieren, kann Ihr Cluster zwar beliebig skaliert werden, dies kann jedoch auch erhebliche Auswirkungen auf die Kosten haben. Aus diesem Grund empfehlen wir, Abrechnungsalarme zu konfigurieren. Abrechnungsalarme ermöglichen es Ihnen, gewarnt und proaktiv benachrichtigt zu werden, wenn die berechneten geschätzten Gebühren in Ihren Konten einen bestimmten Schwellenwert überschreiten. Weitere Informationen finden Sie unter Einen CloudWatch Amazon-Fakturierungsalarm einrichten, um geschätzte Gebühren proaktiv zu überwachen.

Möglicherweise möchten Sie auch die Erkennung von Kostenanomalien aktivieren. Dabei handelt es sich um eine AWS-Kostenmanagement-Funktion, die maschinelles Lernen nutzt, um Ihre Kosten und Nutzung kontinuierlich zu überwachen und ungewöhnliche Ausgaben zu erkennen. Weitere Informationen finden Sie im Handbuch Erste Schritte mit AWS Cost Anomaly Detection. Wenn Sie in AWS Budgets sogar ein Budget erstellt haben, können Sie auch eine Aktion konfigurieren, die Sie benachrichtigt, wenn ein bestimmter Schwellenwert überschritten wurde. Mit Budgetaktionen können Sie eine E-Mail senden, eine Nachricht zu einem SNS-Thema posten oder eine Nachricht an einen Chatbot wie Slack senden. Weitere Informationen finden Sie unter Aktionen zur Konfiguration von AWS-Budgets.

Benutze den Karpenter. sh/do-not-disrupt-Anmerkung, um zu verhindern, dass Karpenter die Bereitstellung eines Knotens aufhebt

Wenn Sie eine wichtige Anwendung auf einem Karpenter-provisioned Knoten ausführen, z. B. einen Batchjob mit langer Laufzeit oder eine statusbehaftete Anwendung, und die TTL des Knotens abgelaufen ist, wird die Anwendung unterbrochen, wenn die Instanz beendet wird. Indem Sie dem Pod eine karpenter.sh/do-not-disrupt Anmerkung hinzufügen, weisen Sie Karpenter an, den Knoten beizubehalten, bis der Pod beendet oder die Annotation entfernt wird. karpenter.sh/do-not-disrupt Weitere Informationen finden Sie in der Disruption-Dokumentation.

Wenn auf einem Knoten nur noch Pods ohne Daemonset übrig sind, die mit Jobs verknüpft sind, kann Karpenter diese Knoten als Ziel auswählen und beenden, solange der Jobstatus erfolgreich oder fehlgeschlagen lautet.

Konfigurieren Sie requests=limits für alle Nicht-CPU-Ressourcen, wenn Sie die Konsolidierung verwenden

Konsolidierung und Planung funktionieren im Allgemeinen, indem die Ressourcenanforderungen der Pods mit der Menge der zuweisbaren Ressourcen auf einem Knoten verglichen werden. Die Ressourcengrenzen werden nicht berücksichtigt. Beispielsweise können Pods, deren Speicherlimit größer als die Speicheranforderung ist, die Anforderung überschreiten. Wenn mehrere Pods auf demselben Knoten gleichzeitig platzen, kann dies dazu führen, dass einige der Pods aufgrund eines Speicherausfalls (OOM) beendet werden. Durch eine Konsolidierung kann dies wahrscheinlicher werden, da es funktioniert, Pods auf Knoten zu packen, wobei nur deren Anfragen berücksichtigt werden.

Wird verwendet LimitRanges , um Standardwerte für Ressourcenanforderungen und Grenzwerte zu konfigurieren

Da Kubernetes keine Standardanforderungen oder Grenzwerte festlegt, ist der Ressourcenverbrauch eines Containers durch den zugrunde liegenden Host, die CPU und den Arbeitsspeicher ungebunden. Der Kubernetes-Scheduler untersucht die Gesamtzahl der Anfragen eines Pods (je höher die Gesamtzahl der Anfragen aus den Containern des Pods oder die Gesamtressourcen aus den Init-Containern des Pods), um zu ermitteln, für welchen Worker-Knoten der Pod geplant werden soll. In ähnlicher Weise berücksichtigt Karpenter die Anfragen eines Pods, um zu ermitteln, welche Art von Instanz er bereitstellt. Sie können einen Grenzbereich verwenden, um einen sinnvollen Standard für einen Namespace anzuwenden, falls Ressourcenanforderungen von einigen Pods nicht spezifiziert werden.

Siehe Konfigurieren von Standardspeicheranforderungen und Grenzwerten für einen Namespace

Wenden Sie genaue Ressourcenanforderungen auf alle Workloads an

Karpenter ist in der Lage, Knoten zu starten, die am besten zu Ihren Workloads passen, wenn die Informationen über Ihre Workload-Anforderungen korrekt sind. Dies ist besonders wichtig, wenn Sie die Konsolidierungsfunktion von Karpenter verwenden.

Weitere Informationen finden Sie unter Ressourcen Requests/Limits für alle Workloads konfigurieren und dimensionieren

CoreDNS-Empfehlungen

Aktualisieren Sie die Konfiguration von CoreDNS, um die Zuverlässigkeit aufrechtzuerhalten

Bei der Bereitstellung von CoreDNS-Pods auf Knoten, die von Karpenter verwaltet werden, ist es ratsam, sich an die folgenden Best Practices zu halten, da Karpenter schnell terminating/creating neue Knoten zur Anpassung an die Nachfrage entwickelt.

Dauer des CoreDNS-Lameducks

CoreDNS-Bereitschaftstest

Dadurch wird sichergestellt, dass DNS-Abfragen nicht an einen CoreDNS-Pod weitergeleitet werden, der noch nicht bereit ist oder beendet wurde.

Baupläne von Karpenter

Da Karpenter bei der Bereitstellung von Rechenkapazität für die Kubernetes-Datenebene einen anwendungsorientierten Ansatz verfolgt, gibt es gängige Workload-Szenarien, bei denen Sie sich vielleicht fragen, wie Sie sie richtig konfigurieren können. Karpenter Blueprints ist ein Repository, das eine Liste gängiger Workload-Szenarien enthält, die den hier beschriebenen Best Practices folgen. Sie verfügen über alle Ressourcen, die Sie benötigen, um sogar einen EKS-Cluster mit konfiguriertem Karpenter zu erstellen und jeden der im Repository enthaltenen Blueprints zu testen. Sie können verschiedene Blueprints kombinieren, um schließlich den zu erstellen, den Sie für Ihre Workload (s) benötigen.

Weitere Ressourcen