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
**Tipp**
[Informieren Sie](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) sich in Amazon EKS-Workshops über bewährte Verfahren.
[Karpenter ist ein](https://karpenter.sh/) Open-Source-Projekt zur Verbesserung des Knotenlebenszyklusmanagements innerhalb von 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:
+ Überwachen Sie Pods, die der Kubernetes-Scheduler aufgrund von Ressourcenbeschränkungen nicht planen kann.
+ Evaluieren Sie die Planungsanforderungen (Ressourcenanfragen, Knotenselektoren, Affinitäten, Toleranzen usw.) der Pods, die nicht planbar sind.
+ Stellen Sie neue Knoten bereit, die die Anforderungen dieser Pods erfüllen.
+ Entfernen Sie Knoten, wenn sie nicht mehr benötigt werden.
Mit Karpenter können Sie Einschränkungen NodePools bei der Knotenbereitstellung wie Taints, Labels, Anforderungen (Instanztypen, Zonen usw.) und Beschränkungen für die Gesamtzahl der bereitgestellten Ressourcen definieren. Bei der Bereitstellung von Workloads können Sie in den Pod-Spezifikationen verschiedene Planungsbeschränkungen wie Ressourcen requests/limits, Knotenselektoren, node/pod Affinitäten, Toleranzen und Einschränkungen der Topologieverteilung angeben. Karpenter stellt dann auf der Grundlage dieser Spezifikationen Knoten in der richtigen Größe bereit.
**Gründe für die Nutzung von Karpenter**
Vor der Einführung von Karpenter verließen sich Kubernetes-Benutzer hauptsächlich auf [Amazon EC2 Auto Scaling Scaling-Gruppen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html) und den [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/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 mit Kubernetes-Versionen verbunden und erfordert nicht, dass Sie zwischen AWS- und Kubernetes-APIs wechseln.
Karpenter konsolidiert die Zuständigkeiten für die Instanzorchestrierung 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. Es bietet vereinfachte Möglichkeiten für:
+ Stellen Sie Knoten auf der Grundlage der Workload-Anforderungen bereit.
+ Erstellen Sie mithilfe flexibler NodePool Optionen unterschiedliche Knotenkonfigurationen nach Instanztyp. Anstatt viele spezifische benutzerdefinierte Knotengruppen zu verwalten, können Sie mit Karpenter verschiedene Workload-Kapazitäten mit einer einzigen, flexiblen Lösung verwalten. NodePool
+ Erzielen Sie eine verbesserte Pod-Planung im großen Maßstab, indem Sie Knoten schnell starten und Pods planen.
Informationen und Dokumentation zur Verwendung von Karpenter finden Sie auf der Website [karpenter.sh](https://karpenter.sh/).
## Empfehlungen
Die bewährten Methoden sind in Abschnitte zu Karpenter selbst und zur Planung von Pods NodePools unterteilt.
## Bewährte Methoden von Karpenter
Die folgenden bewährten Methoden behandeln Themen, die sich auf Karpenter selbst beziehen.
### Sperren Sie AMIs in Produktionsclustern
Wir empfehlen dringend, dass Sie bekannte Amazon Machine Images (AMIs), die von Karpenter für Produktionscluster verwendet werden, anheften. Wenn Sie einen Aliasnamen verwenden`amiSelector`, der auf gesetzt ist`@latest`, oder eine andere Methode verwenden, die zur Bereitstellung ungetesteter AMIs führt, sobald sie veröffentlicht werden, birgt dies das Risiko von Workload-Ausfällen und Ausfallzeiten in Ihren Produktionsclustern. Aus diesem Grund empfehlen wir dringend, getestete, funktionierende Versionen von AMIs für Ihre Produktionscluster zu verwenden, während Sie neuere Versionen in Clustern testen, die nicht für die Produktion bestimmt sind. Sie könnten in Ihrem beispielsweise NodeClass wie folgt einen Alias einrichten:
```
amiSelectorTerms
- alias: al2023@v20240807
```
Informationen zur Verwaltung und Festlegung von AMIs in Karpenter finden Sie in der Karpenter-Dokumentation unter [Verwaltung von AMIs](https://karpenter.sh/docs/tasks/managing-amis/).
### Verwenden Sie Karpenter für Workloads mit wechselnden Kapazitätsanforderungen
[Karpenter bringt das Skalierungsmanagement näher an die nativen Kubernetes-APIs heran als [Autoscaling Groups (ASGs) und Managed Node Groups](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-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 Grundlage von Kennzahlen auf AWS-Ebene ausgelöst wird, wie z. B. der EC2-CPU-Last. [Cluster Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html#cluster-autoscaler) verbindet die Kubernetes-Abstraktionen mit AWS-Abstraktionen, verliert dadurch jedoch an Flexibilität, z. B. bei der Planung für eine bestimmte Availability Zone.
Karpenter entfernt eine AWS-Abstraktionsebene, um einen Teil der Flexibilität direkt in Kubernetes zu bringen. Karpenter eignet sich am besten für Cluster mit Workloads, die auf Zeiten hoher, hoher Nachfrage stoßen oder unterschiedliche Rechenanforderungen haben. MNGs und ASGs eignen sich gut für Cluster, auf denen Workloads ausgeführt werden, die tendenziell statischer und konsistenter sind. Sie können je nach Ihren Anforderungen 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-Charts 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.
### Karpenter unterstützt keine benutzerdefinierten Startvorlagen
Bei v1-APIs gibt es keine Unterstützung für benutzerdefinierte Startvorlagen. Sie können benutzerdefinierte Benutzerdaten and/or direkt verwenden, indem Sie benutzerdefinierte AMIs in der angeben EC2NodeClass. Weitere Informationen dazu finden Sie unter [NodeClasses](https://karpenter.sh/docs/concepts/nodeclasses/).
### Schließen Sie Instance-Typen 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 benötigt werden.
Das folgende Beispiel zeigt, wie die Bereitstellung großer Graviton-Instanzen vermieden werden kann.
```
- key: node.kubernetes.io/instance-type
operator: NotIn
values:
- m6g.16xlarge
- m6gd.16xlarge
- r6g.16xlarge
- r6gd.16xlarge
- c6g.16xlarge
```
### Aktivieren Sie die Behandlung von Unterbrechungen, wenn Sie Spot verwenden
Karpenter unterstützt die [systemeigene Behandlung von Unterbrechungen](https://karpenter.sh/docs/concepts/disruption/#interruption) und kann unfreiwillige Unterbrechungsereignisse wie Spot-Instance-Unterbrechungen, geplante Wartungsereignisse und Instanzereignisse behandeln, die Ihre Workloads stören termination/stopping könnten. Wenn Karpenter solche Ereignisse für Knoten erkennt, werden die betroffenen Knoten automatisch verunreinigt, entleert und im Voraus beendet, 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 Node, sodass Pods verschoben werden können, bevor die Instance zurückgeholt wird. Um die Behandlung von Unterbrechungen zu aktivieren, konfigurieren Sie das `--interruption-queue` CLI-Argument mit dem Namen der SQS-Warteschlange, die für diesen Zweck bereitgestellt wurde. [Es wird nicht empfohlen, Karpenter Disruption Handling zusammen mit Node Termination Handler zu verwenden, wie hier erklärt.](https://karpenter.sh/docs/faq/#interruption-handling)
Pods, für die Checkpoints oder andere Formen der ordnungsgemäßen Entleerung erforderlich sind und die 2 Minuten vor dem Herunterfahren benötigt werden, sollten die Karpenter-Interruptionsbehandlung in ihren Clustern aktivieren.
### **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 privaten [Cluster-Anforderungen](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html#private-cluster-requirements) 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 Ihnen ähnliche Fehler wie die unten aufgeführten angezeigt.
```
{"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..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 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 in Ihrer VPC keinen SSM-VPC-Endpunkt haben, führt dies zu dem folgenden Fehler:
```
{"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..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](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/using-pelong.html)***. Infolgedessen werden die Preisdaten im Laufe der Zeit veralten. 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..amazonaws.com/\": dial tcp 18.196.224.8:443: i/o timeout; RequestError: send request failed\ncaused by: Post \"https://api.pricing..amazonaws.com/\": dial tcp 18.185.143.117:443: i/o timeout","commit":"596ea97"}
```
In dieser [Dokumentation](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#private-clusters) erfahren Sie, wie Sie Karpenter in einem vollständig privaten EKS-Cluster verwenden und wissen, welche VPC-Endpoints erstellt werden müssen.
## Erstellen NodePools
Die folgenden bewährten Methoden behandeln Themen rund um das Erstellen NodePools.
### Erstellen Sie mehrere NodePools , wenn...
Wenn sich verschiedene Teams einen Cluster teilen und ihre Workloads auf unterschiedlichen Worker-Knoten 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 Ressourcen NodePools wird sichergestellt, dass jedem Team die am besten geeigneten Ressourcen zur Verfügung stehen.
### Erstellen Sie NodePools , die sich gegenseitig ausschließen oder gewichtet sind
Es wird empfohlen, solche zu erstellen NodePools , die sich gegenseitig ausschließen oder gewichtet sind, um ein einheitliches Planungsverhalten zu gewährleisten. Wenn dies nicht der Fall ist und mehrere Treffer NodePools zutreffen, wählt Karpenter nach dem Zufallsprinzip aus, was zu unerwarteten Ergebnissen führt. Zu den nützlichen Beispielen für die Erstellung von mehreren NodePools gehören die folgenden:
Eine NodePool mit GPU erstellen und nur spezielle Workloads auf diesen (teuren) Knoten ausführen lassen:
```
# 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 für den 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"
```
Bei einer allgemeinen Bereitstellung für ein anderes Team könnte die NodePool Spezifikation NodeAffinity enthalten. Ein Deployment könnte dann einen passenden Node verwenden. SelectorTerms `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 haben oder die eine Ablaufzeit erreicht haben. Der Ablauf von Knoten kann als Mittel zur Aktualisierung verwendet werden, sodass Knoten ausgemustert und durch aktualisierte Versionen ersetzt werden. Informationen zur Konfiguration des [Ablaufs](https://karpenter.sh/docs/concepts/disruption/) 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html) zur Bereitstellung von EC2-Instances. Diese Strategie weist EC2 an, Instances aus den tiefsten Pools für die Anzahl der Instances bereitzustellen, die Sie starten und bei denen das Risiko einer Unterbrechung am geringsten ist. EC2 Fleet fordert dann Spot-Instances aus den Pools mit dem niedrigsten Preis an. Je mehr Instance-Typen Sie Karpenter verwenden dürfen, desto besser kann EC2 die Laufzeit Ihrer Spot-Instance optimieren. Standardmäßig verwendet Karpenter alle Instance-Typen, die EC2 in der Region und den Availability Zones anbietet, in denen Ihr Cluster bereitgestellt wird. Karpenter wählt auf intelligente Weise aus dem Satz aller Instance-Typen auf der Grundlage ausstehender Pods aus, um sicherzustellen, dass Ihre Pods auf Instances mit entsprechender Größe und Ausstattung eingeplant werden. Wenn Ihr Pod beispielsweise keine GPU benötigt, ordnet Karpenter Ihrem Pod keinen EC2-Instanztyp zu, 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](https://github.com/aws/amazon-ec2-instance-selector) 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, dass alle Instanzen eines bestimmten Typs zurückgefordert werden und es keine geeigneten Alternativen gibt, um sie zu ersetzen. Ihre Pods bleiben so lange 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 aufgrund unzureichender Kapazität verringern, indem Sie Ihre Instances auf verschiedene Availability Zones verteilen, da Spot-Pools je nach AZs unterschiedlich sind. Die allgemeine bewährte Methode besteht jedoch darin, Karpenter bei der Verwendung von Spot die Verwendung verschiedener Instance-Typen zu gestatten.
## Pods planen
Die folgenden bewährten Methoden beziehen sich auf die Bereitstellung von Pods in einem Cluster unter Verwendung von Karpenter für die Knotenbereitstellung.
### Folgen Sie den Best Practices von EKS für Hochverfügbarkeit
Wenn Sie hochverfügbare Anwendungen ausführen müssen, befolgen Sie die allgemeinen [EKS-Best-Practice-Empfehlungen](https://docs.aws.amazon.com/eks/latest/best-practices/application.html#_recommendations). Einzelheiten zur [Verteilung von Pods auf Knoten und Zonen finden Sie in der Dokumentation zu Topology](https://karpenter.sh/docs/concepts/scheduling/#topology-spread) Spread in Karpenter. Verwenden Sie [Disruption Budgets](https://karpenter.sh/docs/troubleshooting/#disruption-budgets), um die Mindestanzahl verfügbarer Pods festzulegen, die verwaltet werden müssen, falls versucht wird, Pods zu räumen oder zu löschen.
### Verwenden Sie mehrschichtige Einschränkungen, um die von Ihrem Cloud-Anbieter verfügbaren Rechenfunktionen einzuschränken
Das Modell der mehrschichtigen Einschrä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 anfordern kann, gehören unter anderem die folgenden:
+ Muss in Verfügbarkeitszonen ausgeführt werden, in denen nur bestimmte Anwendungen verfügbar sind. Angenommen, Sie haben einen Pod, der mit einer anderen Anwendung kommunizieren muss, die auf einer EC2-Instance läuft, die sich in einer bestimmten Availability Zone befindet. Wenn Sie den AZ-übergreifenden Verkehr in Ihrer VPC reduzieren möchten, sollten Sie die Pods in der AZ zusammenlegen, in der sich die EC2-Instance befindet. Diese Art von Targeting wird häufig mithilfe von Knotenselektoren erreicht. Weitere Informationen zu [Node-Selektoren](https://karpenter.sh/docs/concepts/scheduling/#selecting-nodes) finden Sie in der Kubernetes-Dokumentation.
+ Bestimmte Arten von Prozessoren oder anderer Hardware sind erforderlich. Im Abschnitt [Accelerators](https://karpenter.sh/docs/concepts/scheduling/#acceleratorsgpu-resources) der Karpenter Docs finden Sie ein Beispiel für eine Pod-Spezifikation, bei der der Pod auf einer GPU ausgeführt werden muss.
### Erstellen Sie Abrechnungsalarme, um Ihre Rechenausgaben zu überwachen
Wenn Sie Ihren Cluster für die automatische Skalierung konfigurieren, sollten Sie Abrechnungsalarme einrichten, die Sie warnen, wenn Ihre Ausgaben einen Schwellenwert überschreiten, 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
**Anmerkung**
Es ist nicht möglich, ein globales Limit für den gesamten Cluster festzulegen. Grenzwerte gelten für bestimmte NodePools.
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 der Karpenter-Controller eine Meldung `memory resource usage of 1001 exceeds limit of 1000` oder eine ähnlich aussehende Meldung in die Logs des Controllers. Wenn Sie Ihre Container-Logs an CloudWatch Logs weiterleiten, können Sie einen [Metrikfilter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) erstellen, der nach bestimmten Mustern oder Begriffen in Ihren Logs sucht, und dann einen [CloudWatchAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) einrichten, der Sie warnt, wenn Ihr konfigurierter Metrik-Schwellenwert überschritten wird.
Weitere Informationen zur Verwendung von Limits mit Karpenter finden Sie in der [Karpenter-Dokumentation unter Festlegen von Ressourcenlimits](https://karpenter.sh/docs/concepts/nodepools/#speclimits).
```
spec:
limits:
cpu: 1000
memory: 1000Gi
```
Wenn Sie keine Limits verwenden oder die Instanztypen einschränken, die Karpenter bereitstellen kann, fügt Karpenter Ihrem Cluster nach Bedarf weiterhin Rechenkapazität hinzu. Durch die Konfiguration von Karpenter auf diese Weise kann Ihr Cluster zwar frei skaliert werden, dies kann jedoch auch erhebliche Kostenauswirkungen haben. Aus diesem Grund empfehlen wir die Konfiguration von Abrechnungsalarmen. Mit Abrechnungsalarmen können Sie benachrichtigt und proaktiv benachrichtigt werden, wenn die berechneten geschätzten Gebühren auf Ihren Konten einen definierten Schwellenwert überschreiten. Weitere Informationen finden Sie unter [Einrichtung eines CloudWatch Amazon-Abrechnungsalarms zur proaktiven Überwachung geschätzter Gebühren](https://aws.amazon.com/blogs/mt/setting-up-an-amazon-cloudwatch-billing-alarm-to-proactively-monitor-estimated-charges/).
Möglicherweise möchten Sie auch die Erkennung von Kostenanomalien aktivieren, eine AWS-Kostenmanagement-Funktion, die maschinelles Lernen verwendet, um Ihre Kosten und Nutzung kontinuierlich zu überwachen und ungewöhnliche Ausgaben zu erkennen. Weitere Informationen finden Sie im [AWS Cost Anomaly Detection Getting Started](https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html) Guide. Wenn Sie so weit gegangen sind, in AWS Budgets ein Budget zu erstellen, 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 [Konfiguration von AWS-Budgets-Aktionen](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html).
### Verwenden Sie den Karpenter. sh/doDie Anmerkung -not-disrupt, um zu verhindern, dass Karpenter einen Knoten deprovisioniert
Wenn Sie eine kritische Anwendung auf einem Karpenter-provisioned Knoten ausführen, z. B. einen Batch-Job 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 Anmerkung entfernt wird. `karpenter.sh/do-not-disrupt` Weitere Informationen finden Sie in der Dokumentation zu [Distruption](https://karpenter.sh/docs/concepts/disruption/#node-level-controls).
Wenn die einzigen Pods auf einem Knoten, die nicht auf Daemon gesetzt sind, diejenigen sind, die mit Jobs verknüpft sind, ist Karpenter in der Lage, diese Knoten anzuvisieren und zu beenden, solange der Jobstatus erfolgreich oder fehlgeschlagen ist.
### Konfigurieren Sie requests=limits für alle Nicht-CPU-Ressourcen, wenn Sie die Konsolidierung verwenden
Konsolidierung und Planung funktionieren im Allgemeinen, indem die Ressourcenanforderungen des 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, bei Überschreitung der Anforderung zu einem Burst-Wert führen. Wenn mehrere Pods auf demselben Knoten gleichzeitig platzen, kann dies dazu führen, dass einige der Pods aufgrund eines Speicherausfalls (OOM) beendet werden. Durch Konsolidierung kann dies wahrscheinlicher werden, da es funktioniert, Pods auf Knoten nur unter Berücksichtigung ihrer Anfragen zu packen.
### Wird verwendet LimitRanges , um Standardwerte für Ressourcenanfragen und Grenzwerte zu konfigurieren
Da Kubernetes keine Standardanforderungen oder Grenzwerte festlegt, ist der Ressourcenverbrauch eines Containers vom zugrunde liegenden Host, der CPU und dem Speicher unbegrenzt. 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 der Init-Container des Pods), um zu ermitteln, auf welchem Worker-Knoten der Pod eingeplant werden soll. In ähnlicher Weise berücksichtigt Karpenter die Anfragen eines Pods, um festzustellen, welchen Instanztyp 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 [Standardspeicheranforderungen und Grenzwerte für einen Namespace konfigurieren](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
### Wenden Sie korrekte 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](https://docs.aws.amazon.com/eks/latest/best-practices/data-plane.html#_recommendations)
## CoreDNS-Empfehlungen
### Aktualisieren Sie die Konfiguration von CoreDNS, um die Zuverlässigkeit aufrechtzuerhalten
Bei der Bereitstellung von CoreDNS-Pods auf von Karpenter verwalteten Knoten ist es angesichts des dynamischen Charakters von Karpenter bei schnell terminating/creating neuen Knoten zur Anpassung an die Nachfrage ratsam, die folgenden Best Practices einzuhalten:
[Dauer CoreDNS CoreDNS-Lameduck](https://docs.aws.amazon.com/eks/latest/best-practices/scale-cluster-services.html#_coredns_lameduck_duration)
[CoreDNS-Bereitschaftstest](https://docs.aws.amazon.com/eks/latest/best-practices/scale-cluster-services.html#_coredns_readiness_probe)
Dadurch wird sichergestellt, dass DNS-Abfragen nicht an einen CoreDNS-Pod weitergeleitet werden, der noch nicht bereit ist oder beendet wurde.
## Karpenter Baupläne
Da Karpenter bei der Bereitstellung von Rechenkapazität für die Kubernetes-Datenebene einen anwendungsorientierten Ansatz verfolgt, gibt es häufig auftretende Workload-Szenarien, bei denen Sie sich vielleicht fragen, wie sie richtig konfiguriert werden sollen. [Karpenter Blueprints](https://github.com/aws-ia/terraform-aws-eks-blueprints-addons) ist ein Repository, das eine Liste gängiger Workload-Szenarien gemäß den hier beschriebenen Best Practices enthält. 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 Arbeitslast (en) benötigen.
## Weitere Ressourcen
+ [Workshop zum Karpenter Immersion Day](https://catalog.workshops.aws/karpenter/en-US)
+ [Workshop zur Kostenoptimierung in Karpenter](https://ec2spotworkshops.com/karpenter.html)
+ [EKS-Werkstatt - Karpenter](https://www.eksworkshop.com/docs/autoscaling/compute/karpenter/)
+ [Karpenter gegen Cluster Autoscaler](https://youtu.be/FIBc8GkjFU0)
+ [Karpenter Session auf der re:Invent 2023](https://youtu.be/lkg_9ETHeks)
+ [Tutorial: Kubernetes-Cluster mit Amazon EC2 Spot und Karpenter günstiger ausführen](https://community.aws/tutorials/run-kubernetes-clusters-for-less-with-amazon-ec2-spot-and-karpenter#step-6-optional-simulate-spot-interruption)