Wie behebe ich Probleme bei der Clusterskalierung mit der automatischen Skalierung von Karpenter in Amazon EKS?

Lösung

Behebe das Problem anhand der Fehlermeldung, die du erhältst.

Karpenter-Pods können nicht geplant werden, da nicht genügend Amazon-EKS-Knotengruppen-Instances vorhanden sind

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

In Karpenter Version 0.16.0 und höher wurde die Anzahl der Standardreplikate von 1 auf 2 geändert. Weitere Informationen findest du unter v0.16.0 auf der GitHub-Website. Wenn die Knotenkapazität im Cluster nicht ausreicht, um die konfigurierte Anzahl von Replikaten zu unterstützen, kannst du Karpenter-Pods nicht planen. Da Karpenter keine Knoten für den Betrieb seiner eigenen Pods bereitstellen kann, schlägt es aufgrund unzureichender Kapazität fehl, was zu ungeplanten Pods führt. Dann erhältst du die folgende Fehlermeldung:

„Warning FailedScheduling 3m default-scheduler 0/1 nodes are available: 1 Insufficient memory.“

Gehe wie folgt vor, um diesen Fehler zu beheben:

Reduzieren der Bereitstellungsreplikate von Karpenter auf eines

Wenn die Karpenter-Bereitstellung keine Redundanz erfordert, ändere sie, um ein einzelnes Replikat zu verwenden. Führe den folgenden Befehl aus:

kubectl scale deployment karpenter --replicas=1

Erhöhen der Knotenkapazität für die Karpenter-Pods

Um zwei Replikate von Karpenter auszuführen, stelle sicher, dass ausreichend Kapazität für zwei Replikate vorhanden ist. Wähle eine der folgenden Optionen:

Aufskalieren der Auto-Scaling-Gruppe

1. Erhöhe die Mindestanzahl von Instances in der Auto-Scaling-Gruppe. Führe den folgenden Befehl aus:

   aws autoscaling update-auto-scaling-group --auto-scaling-group-name your-node-group-name --min-size 2 --desired-capacity 2

   Hinweis: Ersetze your-node-group-name durch den Namen deiner Auto-Scaling-Gruppe.
2. Stelle sicher, dass es Knoten gibt, die Karpenter nicht verwaltet. Überprüfe die Knotenbezeichnungen auf Karpenter-Bezeichnungen, z. B. karpenter.sh/nodepool. Führe den folgenden Befehl aus:

   kubectl get nodes --show-labels | grep karpenter.sh/nodepool

Bestehende Knoten verwenden

Wenn der oder die vorhandenen Zielknoten Karpenter-Bezeichnungen wie karpenter.sh/nodepool haben, entferne die Bezeichnungen. Führe den folgenden Befehl aus:

kubectl label nodes your-node-name karpenter.sh/nodepool-

Hinweis: Ersetze your-node-name durch den Namen deines Knotens.

Fehler beim Anfügen und Einbinden von Volumes

Wenn mehrere Pods mit Persistent Volume Claims (PVCs, Persistente Volume-Ansprüche) auf demselben Knoten geplant sind, überschreitet der Knoten möglicherweise sein Limit für Volume-Anhänge. Dann erhältst du möglicherweise eine der folgenden Fehlermeldungen:

„Warning FailedAttachVolume pod/example-pod AttachVolume. Attach failed for volume " " : rpc error: code = Internal desc = Could not attach volume " " to node " ": attachment of disk " " failed, expected device to be attached but was attaching“

„Warning FailedMount pod/example-pod Unable to attach or mount volumes: unmounted volumes=[], unattached volumes=[]: timed out waiting for the condition“

Gehe wie folgt vor, um Fehler beim Anfügen und Einbinden von Volumes bei Workloads mit hohem PVC-Anteil zu beheben:

1. Wende topologySpreadConstraints und podAntiAffinity an, um zu verhindern, dass PVC-lastige Pods auf demselben Knoten geplant werden. Weitere Informationen findest du unter topologySpreadConstraints field (topologySpreadConstraints-Feld) und Pod affinity example (Beispiel für Pod-Affinität) auf der Kubernetes-Website. Diese Aktion verteilt PVC-lastige Pods auf verschiedene Knoten, um die Konzentration von Volume-Anhängen auf einem einzelnen Knoten zu vermeiden.
2. Verwende CSI-Treiber wie den Treiber für die Container Storage Interface (CSI, Container-Speicherschnittstelle) von Amazon Elastic Block Store (Amazon EBS) (aws-ebs-csi-driver) und füge dem NodePool Start-Taints hinzu. Diese Aktionen stellen sicher, dass Pods nicht vorzeitig auf Knoten geplant werden, bevor sie vollständig bereit sind.
   Beispielkonfiguration für Start-Taints in Amazon EBS:

   --yaml--
   apiVersion: karpenter.sh/v1
   kind: NodePool
   spec:
     template:
       spec:
         startupTaints:
           - key: ebs.csi.aws.com/agent-not-ready
             effect: NoExecute
   

Fehler beim veralteten Speicher-Plug-in

Karpenter unterstützt keine veralteten In-Tree-Speicher-Plugins wie Amazon EBS. Wenn du ein statisch bereitgestelltes Persistent Volume (PV) mit einem In-Tree-Plug-in verwendest, kann Karpenter die Volume-Anhangsgrenzen des Knotens nicht ermitteln. Dieses Szenario kann zu Zeitplanfehlern führen, und du erhältst möglicherweise die folgende Fehlermeldung:

„ERROR controller.node_state PersistentVolume source 'AWSElasticBlockStore' uses an in-tree storage plugin which is unsupported by Karpenter and is deprecated by Kubernetes.“

Um dieses Problem zu beheben, verwende CSI-Treiber für Amazon EBS und aktualisiere die PV-Konfigurationen, um den CSI-Treiber zu verwenden.

Zeitplan- oder Behälterfehler aufgrund nicht spezifizierter Ressourcenanforderungen

Karpenter packt Pods auf der Grundlage von Ressourcenanforderungen in Behälter. Wenn die Anforderungen zu gering sind oder fehlen, weist Karpenter demselben Knoten möglicherweise zu viele Pods zu. Dieses Szenario kann zu Ressourcenkonflikten und CPU-Drosselung führen. Wenn Speicherlimits festgelegt sind und Pods versuchen, mehr Speicher als ihr Limit zu verwenden, kann es außerdem zu Out-Of-Memory (OOM, nicht genügend Arbeitsspeicher)-Abbrüchen kommen. Möglicherweise erhältst du die folgende Fehlermeldung:

„Warning OOMKilled pod/your-pod-name Container "container-name" was killed due to OOM (Out of Memory). Memory limit: 512Mi, Memory usage: 513Mi“

Um diese Probleme zu vermeiden, verwende LimitRange-Konfigurationen, um die Mindestressourcenanforderungen für ein genaues Bin-Packing festzulegen. LimitRange-Konfigurationen helfen dabei, Höchstgrenzen festzulegen, um einen übermäßigen Verbrauch zu verhindern. Sie bieten auch Standardlimits für nicht spezifizierte Pods. Weitere Informationen findest du unter Verwenden von LimitRanges, um Standardwerte für Ressourcenanforderungen und Limits zu konfigurieren.

Das Starten von Windows-Pods schlägt mit einem Image-Abruf-Fehler fehl

Ein Pod kann nicht gestartet werden, wenn seine Container-Betriebssystemversion nicht mit der Windows-Betriebssystemversion übereinstimmt. Du erhältst eine Fehlermeldung, die der folgenden ähnelt:

„Failed to pull image "mcr.microsoft.com/windows/servercore:xxx": rpc error: code = NotFound desc = failed to pull and unpack image "mcr.microsoft.com/windows/servercore:xxx": no match for platform in manifest: not found“

Um dieses Problem zu beheben, definiere den nodeSelector deines Pods, um sicherzustellen, dass die Container auf einer kompatiblen Betriebssystem-Host-Version geplant sind. Weitere Informationen findest du unter Versionskompatibilität von Windows-Containern auf der Microsoft-Website.

Knoten wurden nicht richtig initialisiert

Das System bestimmt die Knoteninitialisierung auf der Grundlage der Knotenbereitschaft, der erwarteten Ressourcenregistrierung und der Entfernung von NodePool-Start-Taints. Wenn eine dieser Bedingungen nicht erfüllt ist, kann der Karpenter-Knoten nicht initialisiert werden und der Knoten verbleibt im NotReady-Status. Daher kann das System den Knoten nicht verwenden, um Workloads zu planen oder zu konsolidieren. Möglicherweise erhältst du die folgende Fehlermeldung:

„Nodes provisioned by Karpenter are in a NotReady state“

Stelle sicher, dass der Knotenstatus Bereit ist. Ist dies nicht der Fall, überprüfe die Kubelet-Protokolle, um potenzielle Probleme mit Berechtigungen, Sicherheitsgruppen oder Netzwerken zu identifizieren.

Stelle sicher, dass alle erforderlichen Ressourcen wie nvidia.com/gpu oder vpc.amazonaws.com/pod-eni korrekt auf dem Knoten registriert sind.

Führe den folgenden Befehl aus, um die nvidia.com/gpu-Ressourcen auf dem Knoten zu überprüfen:

kubectl describe node your-node-name

Hinweis: Ersetze your-node-name durch den Namen deines Knotens.

Beispielausgabe:

...
Capacity:
  nvidia.com/gpu.shared: 80
...

Wenn diese Ressourcen fehlen, stelle sicher, dass das entsprechende DaemonSet oder die entsprechenden Plug-ins ausgeführt werden. Führe den folgenden Befehl aus, um nach DaemonSet zu suchen:

kubectl get ds -n your-daemonset-namespace

Hinweis: Ersetze your-daemonset-namespace durch deinen DaemonSet-Namespace.

Planungsfehler aufgrund verschiedener Einschränkungen und Beschränkungen

Ein Pod kann aufgrund von Affinitäts-, Anti-Affinitäts- oder Topologie-Verteilungsbeschränkungen nicht geplant werden.

Ein Pod wird nicht geplant, wenn Affinitäts-, Anti-Affinitäts- oder Topologie-Verteilungsbeschränkungen bestimmte Knoten oder Zonen erfordern, aber an den erforderlichen Standorten keine geeigneten Knoten vorhanden sind. Wenn das System aufgrund von Knoten- oder Zonenanforderungen, die nicht erfüllt sind, keinen Pod platzieren kann, wird möglicherweise die folgende Fehlermeldung angezeigt:

„Warning FailedScheduling pod/"pod-name" 0/3 nodes are available: 1 node(s) didn't match pod affinity rules, 2 node(s) didn't match pod topology spread constraints rules, 3 nodes(s) didn't match inter-pod anti-affinity rules.“

Um diesen Fehler zu beheben, überprüfe die Affinitäts- und Anti-Affinitätseinstellungen oder die Topologie-Verteilungsbeschränkungen des Pods und passe sie an die verfügbaren Knoten an. Du kannst diese Einschränkungen lockern oder mehr Knoten in den erforderlichen Zonen bereitstellen.

Ein Pod konnte aufgrund unzureichender Ressourcen nicht geplant werden

Pods bleiben aufgrund von Ressourcenanforderungen, welche die verfügbare Knotenkapazität überschreiten, ungeplant. Wenn es keine Knoten gibt, die über ausreichend CPU, Arbeitsspeicher oder andere Ressourcen verfügen, um den Pod aufzunehmen, wird möglicherweise die folgende Fehlermeldung angezeigt:

„Warning FailedScheduling 30s (x13 over 60m) default-scheduler 0/5 nodes are available: 1 Insufficient memory. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod.“

Um dieses Problem zu beheben, stelle sicher, dass die Ressourcenanforderungen in der Pod-Spezifikation die tatsächliche Nutzung widerspiegeln. Passe bei Bedarf die Ressourcenanforderungen und Limits an, oder stelle größere Knoten mit mehr Kapazität bereit, um den Ressourcenbedarf zu decken.

Taints verhindern, dass Pods geplant werden

Wenn Cluster-Administratoren benutzerdefinierte Taints auf bestimmte Knoten anwenden, müssen die Pods über entsprechende Toleranzen verfügen. Wenn sie keine passenden Toleranzen haben, kann das System keine Pods auf diesen Knoten planen. Du erhältst die folgende Fehlermeldung:

„0/5 nodes are available: 3 node(s) had taint {dedicated: gpu}, that the pod didn't tolerate, 2 node(s) had taint {dedicated: non-gpu}, that the pod didn't tolerate.“

Um diesen Fehler zu beheben, füge der Pod-Spezifikation die entsprechenden Toleranzen hinzu, damit sie die Taints tolerieren können. Oder du kannst die unnötigen benutzerdefinierten Taints auf den Knoten entfernen oder ändern, wenn sie zu restriktiv sind.

Führe den folgenden Befehl aus, um einen Taint von einem Knoten zu entfernen:

kubectl taint nodes your-node-name your-custom-taint-

Hinweis: Ersetze your-node-name durch den Namen deines Knotens und your-custom-taint durch den Namen deines benutzerdefinierten Taints.

NodeAffinity- oder NodeSelector-Einschränkungen sind nicht erfüllt

Wenn es Knotenaffinitäts- oder Knotenauswahlbeschränkungen gibt, die mit keinem verfügbaren Knoten im Cluster übereinstimmen, kann der Scheduler keine Pods platzieren. Du erhältst die folgende Fehlermeldung:

„Warning FailedScheduling  3m    default-scheduler 0/4 nodes are available: 1 node(s) didn't match Pod's node affinity/selector, 3 node(s) didn't satisfy existing pods anti-affinity rules, 4 node(s) didn't match Pod's node affinity rules.“

Um diesen Fehler zu beheben, ändere die Knotenaffinitäts- oder die Knotenauswahl-Anforderungen des Pods, um flexibler zu sein. Oder du kannst bei Bedarf zusätzliche Knoten bereitstellen, welche die Kriterien des Pods erfüllen. Weitere Informationen findest du unter Node affinity (Knotenaffinität) und nodeSelector auf der Kubernetes-Website.

Unzureichende IP-Adressen im Subnetz

Wenn Karpenter versucht, neue Knoten bereitzustellen, schlägt dies aufgrund unzureichender IP-Adressen im Subnetz fehl. Dieses Szenario tritt auf, wenn der Classless Inter-Domain Routing (CIDR)-Bereich des Subnetzes erschöpft ist und keine neuen Amazon Elastic Compute Cloud (Amazon EC2)-Instances unterstützt werden können. Du erhältst die folgende Fehlermeldung:

„error": "creating machine, creating instance, with fleet error(s), InsufficientFreeAddressesInSubnet: There are not enough free addresses in subnet 'subnet-a to satisfy the requested number of instances.“

Ergreife eine der folgenden Maßnahmen, um diesen Fehler zu beheben:

Wenn die IP-Adressen des Subnetzes erschöpft sind, füge Amazon Virtual Private Cloud (Amazon VPC) einen zusätzlichen IPv4 CIDR-Block als sekundäres CIDR hinzu.

-oder-

Verwende benutzerdefinierte Netzwerke, um den Pods und Knoten separate IP-Adressbereiche zuzuweisen. Führe den folgenden Befehl aus, um ein benutzerdefiniertes Netzwerk zu aktivieren:

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

Weitere Informationen zu benutzerdefinierten Netzwerken findest du unter Wie wähle ich bestimmte IP-Adress-Subnetze für Pods in meinem Amazon-EKS-Cluster aus?

Ein Pod kann aufgrund inkompatibler Anforderungen nicht geplant werden

Karpenter plant keine Pods, die Knotengruppenbezeichnungen wie eks.amazonaws.com/nodegroup angeben, die mit keinen in den Konfigurationen des Knotenpools definierten Werten übereinstimmen. Wenn diese Diskrepanz auftritt, kann Karpenter keine Pods auf Knoten platzieren, da die erforderlichen Knotenbezeichnungen fehlen. Du erhältst eine der folgenden Fehlermeldungen:

„incompatible requirements, label \"eks.amazonaws.com/nodegroup\" does not have known values"“

¨“incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [us-east-1a] not in topology.kubernetes.io/zone In [us-east-1b us-east-1c]“

„incompatible requirements, key nodes.ktp.io/role, nodes.ktp.io/role In [ktp-atom-apps] not in nodes.ktp.io/role In [kube-apps]“

Wenn du möchtest, dass Pods von Karpenter geplant werden können, entferne den verwalteten knotengruppenspezifischen nodeSelector, um diesen Fehler zu beheben.

Beispiel:

kubectl edit pod your-pod-name
or  
kubectl edit deployment your-deployment-name
or
kubectl edit daemonset your-daemonset-name

Hinweis: Ersetze your-pod-name, your-deployment-name oder your-daemonset-name durch den Namen deines Pods, deiner Bereitstellung oder deines DaemonSets.

Fehler bei der Knotenkonsolidierung

Die Knotenkonsolidierung von Karpenter kann aufgrund von Planungsbeschränkungen oder bestimmten Pod-Konfigurationen, welche die Pod-Migration verhindern, fehlschlagen.

Einschränkungen bei der Zeitplanung

Die Knotenkonsolidierung schlägt fehl, wenn Pods aus den folgenden Gründen nicht migriert werden können:

• Affinität oder Anti-Affinität zwischen den Pods: Pods, die eine gemeinsame Platzierung mit anderen Pods erfordern oder vermeiden.
• Einschränkungen der Topologieverteilung: Pods, die auf verschiedene Zonen, Knoten oder Racks verteilt werden müssen.
• Andere Einschränkungen bei der Zeitplanung: Alle anderen Einschränkungen, die verhindern, dass Pods auf andere Knoten verschoben werden.

Überprüfe und passe die Pod-Affinitäts- und Anti-Affinitätsregeln an, damit sie weniger restriktiv sind. Passe die Einschränkungen der Topologieverteilung an, um mehr Flexibilität zu ermöglichen, und andere Planungseinschränkungen, die möglicherweise zu streng sind.

Pod-spezifische Vorbeugung

Wenn es bestimmte Arten von Pods gibt, die auf den Knoten ausgeführt werden, kann Karpenter die Knoten möglicherweise nicht konsolidieren. Karpenter kann diese Pods aufgrund von Anmerkungen, Planungsbeschränkungen, Pod-Disruption-Budgets (PDBs, Pod-Unterbrechungsbudgets) oder aufgrund eines fehlenden Controller-Eigentümers nicht entfernen. Die Konsolidierung könnte fehlschlagen, weil Karpenter diese Einstellungen nicht verletzt, auch wenn kube-scheduler die Pods technisch an anderer Stelle unterbringen könnte.