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, das Knotenlebenszyklusmanagement für Kubernetes-Cluster bereitstellt. Es automatisiert die Bereitstellung und Deprovisionierung von Knoten auf der Grundlage der Planungsanforderungen von Pods und ermöglicht so eine effiziente Skalierung und Kostenoptimierung. Ihre Hauptfunktionen sind:

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 der Pod-Spezifikation Planungseinschränkungen wie requests/limits, node selectors, node/pod Ressourcenaffinitäten, Toleranzen und Einschränkungen der Topologieverteilung angeben. Karpenter stellt dann Knoten in der richtigen Größe für diese Pods bereit.

Gründe für die Verwendung von Karpenter

Vor der Einführung von Karpenter verließen sich Kubernetes-Benutzer hauptsächlich auf Amazon EC2 Auto Scaling 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. Darüber hinaus ist Karpenter nicht so eng an Kubernetes-Versionen gebunden (wie es derzeit der Fall CAS ist) und Sie müssen nicht zwischen Kubernetes hin- und herspringen. AWS APIs

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:

Informationen und Dokumentation zur Verwendung von Karpenter finden Sie auf der Website 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.

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

Karpenter bringt das Skalierungsmanagement näher an die native Version von Kubernetes heran APIs als Autoscaling Groups () und Managed Node Groups ()ASGs. MNGs ASGsund MNGs sind AWS -native Abstraktionen, bei denen die Skalierung auf der Grundlage von Level-Metriken wie der AWS Last ausgelöst wird. EC2 CPU Cluster Autoscaler verbindet die Kubernetes-Abstraktionen zu AWS Abstraktionen, verliert dadurch aber 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 Perioden hoher, hoher Nachfrage stoßen oder unterschiedliche Rechenanforderungen haben. MNGsund 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. 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

Mit v1beta1 (APIsv0.32+) gibt es keine Unterstützung für benutzerdefinierte Startvorlagen. Sie können benutzerdefinierte Benutzerdaten verwenden und/oder benutzerdefinierte Daten direkt in der angeben. AMIs EC2NodeClass Weitere Informationen dazu finden Sie unter 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 und kann unfreiwillige Unterbrechungsereignisse wie Spot-Instance-Unterbrechungen, geplante Wartungsereignisse und Ereignisse zum Beenden/Stoppen von Instanzen verarbeiten, die Ihre Workloads stören könnten. Wenn Karpenter solche Ereignisse für Knoten erkennt, werden die betroffenen Knoten automatisch verdorben, 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.

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.

Amazon EKS Private Cluster ohne ausgehenden Internetzugang

Wenn Sie einen EKS Cluster in VPC einem Cluster bereitstellen, der keine Verbindung zum Internet hat, müssen Sie sicherstellen, dass Sie Ihre Umgebung gemäß den Anforderungen für private Cluster konfiguriert haben, die in EKS der Dokumentation aufgeführt sind. Darüber hinaus müssen Sie sicherstellen, dass Sie in Ihrem VPC einen STS VPC regionalen Endpunkt erstellt haben. Wenn nicht, werden ä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.<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. Pods, die so konfiguriert sind, dass sie Anmeldeinformationen IRSA abrufen, indem sie den AWS Security Token Service () AWS STS aufrufen. API Wenn es keinen ausgehenden Internetzugang gibt, müssen Sie in Ihrem VPC einen AWS STS VPC Endpunkt erstellen und verwenden.

Bei privaten Clustern müssen Sie außerdem einen VPCEndpunkt für SSM erstellen. Wenn Karpenter versucht, einen neuen Knoten bereitzustellen, fragt es die Launch-Vorlagenkonfigurationen und einen Parameter ab. SSM Wenn Sie keinen SSM VPC Endpunkt in Ihrem habenVPC, 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.<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 VPCEndpunkt für die Preislistenabfrage API. 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.<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 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 Geräte 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 entweder 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:

Einen NodePool mit diesen (teuren) Knoten erstellen GPU und nur zulassen, dass spezielle Workloads auf diesen (teuren) Knoten ausgeführt werden:

# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m0s
    consolidationPolicy: WhenEmpty
    expireAfter: Never
  template:
    metadata: {}
    spec:
      nodeClassRef:
        name: default
      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"

Für einen allgemeinen Einsatz für ein anderes Team könnte die NodePool Spezifikation Folgendes beinhalten: nodeAffinity Ein entsprechender Einsatz könnte dann verwendet nodeSelectorTerms werden. billing-team

# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: generalcompute
spec:
  disruption:
    expireAfter: Never
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        name: default
      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 mitnodeAffinity:

# 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 von Knoten finden Sie in der Karpenter-Dokumentation unter spec.disruption.expireAfter 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 „Preis-/Kapazitätsoptimierung“ zur Bereitstellung von Instances. EC2 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. EC2Fleet fordert dann Spot-Instances aus den Pools mit dem niedrigsten Preis an. Je mehr Instance-Typen Sie Karpenter zur Verfügung stellen, desto besser EC2 kann die Laufzeit Ihrer Spot-Instance optimiert werden. Standardmäßig verwendet Karpenter alle Instanztypen, die in der Region und in den Verfügbarkeitszonen EC2 angeboten werden, in denen Ihr Cluster bereitgestellt wird. Karpenter wählt auf intelligente Weise aus dem Satz aller Instanztypen 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 benötigt, plant Karpenter Ihren Pod nicht für einen Instance-TypGPU, der a unterstützt. EC2 GPU 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. Der 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 von Land zu Land AZs unterschiedlich sind. Die allgemeine bewährte Methode besteht jedoch darin, Karpenter bei der Verwendung von Spot die Verwendung verschiedener Instance-Typen zu ermöglichen.

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 EKS bewährten Methoden für hohe Verfügbarkeit

Wenn Sie Anwendungen mit hoher Verfügbarkeit ausführen müssen, befolgen Sie die allgemeinen Empfehlungen für EKS bewährte Verfahren. Einzelheiten zur Verteilung von Pods auf Knoten und Zonen finden Sie in der Dokumentation zu Topology Spread in Karpenter. Verwenden Sie 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:

Erstellen Sie Abrechnungsalarme, um Ihre Computerausgaben 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

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 erstellen, der nach bestimmten Mustern oder Begriffen in Ihren Logs sucht, und dann einen CloudWatchAlarm 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.

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. Die Konfiguration von Karpenter auf diese Weise ermöglicht zwar eine freie Skalierung Ihres Clusters, kann aber 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.

Möglicherweise möchten Sie auch die Erkennung von Kostenanomalien aktivieren. Dabei handelt es sich um eine Funktion für das AWS Kostenmanagement, die maschinelles Lernen nutzt, um Ihre Kosten und Nutzung kontinuierlich zu überwachen und ungewöhnliche Ausgaben zu erkennen. Weitere Informationen finden Sie im Leitfaden Erste Schritte mit der Erkennung von AWS Kostenanomalien. 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 wird. Mit Budgetaktionen kannst du eine E-Mail senden, eine Nachricht zu einem SNS Thema posten oder eine Nachricht an einen Chatbot wie Slack senden. Weitere Informationen findest du unter AWSBudgetaktionen konfigurieren.

Verwenden Sie die do-not-disrupt Anmerkung karpenter.sh/, um zu verhindern, dass Karpenter einen Knoten deprovisioniert

Wenn Sie eine kritische Anwendung auf einem von Karpenter bereitgestellten Knoten ausführen, z. B. einen Batch-Job mit langer Laufzeit oder eine statusbehaftete Anwendung, und die des Knotens abgelaufen istTTL, 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.

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-Ressourcen, wenn Sie die Konsolidierung verwenden CPU

Konsolidierung und Planung funktionieren generell, 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 Speichermangels (OOM) beendet werden. Eine Konsolidierung kann die Wahrscheinlichkeit erhöhen, dass dies eintritt, da Pods auf Knoten nur unter Berücksichtigung ihrer Anfragen gepackt werden.

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 zugrundeliegenden Host und Speicher unbegrenzt. CPU 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, auf welchem Worker-Knoten der Pod eingeplant werden soll. In ähnlicher Weise berücksichtigt Karpenter die Anfragen eines Pods, um zu bestimmen, 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

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 Konfiguration und Größe von Ressourcenanforderungen/Grenzwerten für alle Workloads

Wichtigste Empfehlungen DNS

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

Bei der Bereitstellung von DNS Core-Pods auf von Karpenter verwalteten Knoten ist es angesichts des dynamischen Charakters von Karpenter bei der schnellen Terminierung/Erstellung neuer Knoten ratsam, sich an die folgenden bewährten Methoden zu halten:

Dauer des Kernlamädukts DNS

Kernbereitschaftstest DNS

Dadurch wird sichergestellt, dass DNS Anfragen nicht an einen Core DNS Pod gerichtet 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 häufig auftretende Workload-Szenarien, bei denen Sie sich vielleicht fragen, wie sie richtig konfiguriert werden sollen. Karpenter Blueprints 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

📝 Bearbeiten Sie diese Seite auf GitHub