So debuggen Sie Kubernetes „FailedScheduling“-Fehler

Pod-Planungsprobleme sind einer der häufigsten Kubernetes-Fehler. Es gibt mehrere Gründe, warum ein neuer Pod in einem stecken bleiben kann Pending Staat mit FailedScheduling als seinen Grund. Ein Pod, der diesen Status anzeigt, startet keine Container, sodass Sie Ihre Anwendung nicht verwenden können.

Ausstehende Pods, die durch Planungsprobleme verursacht werden, starten normalerweise nicht ohne manuellen Eingriff. Sie müssen die Grundursache finden und Maßnahmen ergreifen, um Ihren Cluster zu reparieren. In diesem Artikel erfahren Sie, wie Sie dieses Problem diagnostizieren und beheben, damit Sie Ihre Arbeitsbelastung erhöhen können.

Identifizieren eines FailedScheduling-Fehlers

Es ist normal, dass Pods a anzeigen Pending Status für kurze Zeit, nachdem Sie sie zu Ihrem Cluster hinzugefügt haben. Kubernetes muss Containerinstanzen auf Ihren Knoten planen, und diese Knoten müssen das Image aus ihrer Registrierung abrufen. Das erste Anzeichen für einen Fehler bei der Pod-Planung ist, wenn er immer als angezeigt wird Pending nach Ablauf der üblichen Anlaufzeit. Sie können den Status überprüfen, indem Sie Kubectl's ausführen get pods bestellt:

$ kubectl Pods abrufen NAME BEREIT STATUS NEUSTARTS ALTER demo-pod 0/1 Ausstehend 0 4m05s

demo-pod mehr als vier Minuten, aber es ist immer noch in der Pending Bundesland. Pods brauchen normalerweise nicht so lange, um Container zu starten, also ist es an der Zeit, zu untersuchen, was Kubernetes erwartet.

Der nächste Diagnoseschritt besteht darin, den Ereignisverlauf des Pods mithilfe von abzurufen describe pod bestellt:

$ kubectl describe pod demo-pod ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- ... Warnung FailedScheduling 4m default- Scheduler 0/4 Knoten sind verfügbar: 1 Zu viele Pods, 3 Zu wenig CPU.

Das Ereignisprotokoll bestätigt a FailedScheduling der Fehler ist der Grund für die Erweiterung Pending Bundesland. Dieses Ereignis wird gemeldet, wenn Kubernetes einem der Worker-Knoten Ihres Clusters nicht die erforderliche Anzahl von Pods zuweisen kann.

Die Ereignismeldung verrät, warum das Scheduling derzeit nicht möglich ist: Es gibt vier Knoten im Cluster, aber keiner von ihnen kann den Pod übernehmen. Drei der Knoten verfügen über unzureichende CPU-Kapazität, während der andere eine Obergrenze für die Anzahl der Pods erreicht hat, die er akzeptieren kann.

Verstehen von FailedScheduling-Fehlern und ähnlichen Problemen

Kubernetes kann Pods nur auf Knoten mit freien Ressourcen planen. Knoten, denen die CPU oder der Arbeitsspeicher ausgehen, können keine Pods mehr aufnehmen. Pods können auch bei der Planung fehlschlagen, wenn sie explizit mehr Ressourcen anfordern, als ein Knoten bereitstellen kann. Dadurch bleibt Ihr Cluster stabil.

Die Kubernetes-Steuerungsebene weiß, welche Pods bereits Knoten in Ihrem Cluster zugewiesen sind. Es verwendet diese Informationen, um den Satz von Knoten zu bestimmen, die einen neuen Pod empfangen können. Ein Planungsfehler tritt auf, wenn kein Kandidat verfügbar ist, wodurch der Pod hängen bleibt Pending bis die Fähigkeit freigegeben wird.

Kubernetes kann Pods auch aus anderen Gründen nicht planen. Knoten können auf verschiedene Weise als nicht berechtigt angesehen werden, einen Pod zu hosten, selbst wenn sie über ausreichende Systemressourcen verfügen:

• Der Knoten wurde möglicherweise von einem Administrator gesperrt, um zu verhindern, dass er vor einem Wartungsvorgang neue Pods erhält.
• Der Knoten könnte einen Effekt haben, der verhindert, dass Pods geplant werden. Ihr Pod wird vom Knoten nicht akzeptiert, es sei denn, er hat eine übereinstimmende Toleranz.
• Ihr Pod fordert möglicherweise a hostPort die bereits mit dem Knoten verknüpft ist. Knoten können jeweils nur einem Pod eine bestimmte Portnummer bereitstellen.
• Ihr Pod verwendet möglicherweise a nodeSelector das bedeutet, dass es auf einem Knoten mit einem bestimmten Tag programmiert werden muss. Ungetaggte Knoten sind nicht zulässig.
• Die Affinitäten und Anti-Affinitäten von Pods und Knoten können unbefriedigend sein und einen Planungskonflikt verursachen, der verhindert, dass neue Pods akzeptiert werden.
• Der Pod kann eine haben nodeName Feld, das einen bestimmten zu planenden Knoten identifiziert. Der Pod wird angehalten, wenn dieser Knoten offline oder nicht geplant ist.

Es liegt in der Verantwortung von kube-scheduler, dem Kubernetes-Scheduler, um diese Bedingungen zu bearbeiten und die Gruppe von Knoten zu identifizieren, die einen neuen Pod hosten können. EIN FailedScheduling Das Ereignis tritt auf, wenn keiner der Knoten die Kriterien erfüllt.

Status „Zeitplan fehlgeschlagen“ auflösen

Die daneben angezeigte Meldung FailedScheduling offenbaren normalerweise, warum jeder Knoten in Ihrem Cluster den Pod nicht übernehmen konnte. Sie können diese Informationen verwenden, um mit der Problembehandlung zu beginnen. Im obigen Beispiel hatte der Cluster vier Pods, drei, bei denen das CPU-Limit erreicht wurde, und einer, der ein Pod-Anzahllimit überschritten hatte.

Die Clusterkapazität ist in diesem Fall die Hauptursache. Sie können Ihren Cluster mit neuen Knoten skalieren, um Probleme mit dem Hardwareverbrauch zu beheben, und Ressourcen hinzufügen, die zusätzliche Flexibilität bieten. Da dies auch Ihre Kosten erhöht, lohnt es sich, zuerst zu prüfen, ob Sie redundante Pods in Ihrem Cluster haben. Durch das Entfernen ungenutzter Ressourcen wird Kapazität für neue frei.

Sie können die auf jedem Ihrer Knoten verfügbaren Ressourcen mithilfe von überprüfen describe node bestellt:

$ kubectl describe node demo-node ... Zugewiesene Ressourcen: (Gesamtlimits können über 100 Prozent liegen, dh überbelegt sein.) Limits für Ressourcenanforderungen -------- -------- ---- -- CPU 812m (90%) 202m (22%) Arbeitsspeicher 905Mi (57%) 715Mi (45%) flüchtiger Speicher 0 (0%) 0 (0%) Hugepages-2Mi 0 (0%) 0 (0%)

Die Pods auf diesem Knoten fordern bereits 57 % des verfügbaren Arbeitsspeichers an. Wenn ein neuer Pod 1 Gi für sich selbst anfordern würde, wäre der Knoten nicht in der Lage, die Planungsanforderung anzunehmen. Die Überwachung dieser Informationen für jeden Ihrer Knoten kann Ihnen dabei helfen, zu beurteilen, ob Ihr Cluster überdimensioniert ist. Es ist wichtig, über freie Kapazität zu verfügen, falls einer Ihrer Knoten ausfällt und seine Workloads auf einen anderen umgeplant werden müssen.

Bei Planungsfehlern aufgrund fehlender planbarer Knoten wird eine Meldung ähnlich der folgenden in angezeigt FailedScheduling ein Event:

0/4 Knoten sind verfügbar: 4 Knoten waren nicht planbar

Knoten, die nicht geplant werden können, weil sie geloopt wurden, enthalten SchedulingDisabled in ihrem Statusfeld:

$ kubectl Knoten abrufen NAME STATUS ROLLEN ALTER VERSION node-1 Ready,SchedulingDisabled control-plane,master 26m v1.23.3

Sie können die Verknüpfung des Knotens aufheben, damit er neue Pods empfangen kann:

$ kubectl uncordon node-1 node/node-1 uncordoned

Wenn Knoten nicht geschlossen sind und über ausreichende Ressourcen verfügen, werden Planungsfehler normalerweise durch Kontamination oder Fehler verursacht nodeSelector Feld auf Ihrem Pod. Wenn du benutzt nodeSelectorStellen Sie sicher, dass Sie sich nicht vertippt haben und dass es Pods in Ihrem Cluster gibt, die die von Ihnen angegebenen Labels haben.

Wenn Knoten kontaminiert sind, stellen Sie sicher, dass Sie die entsprechende Toleranz in das Manifest Ihres Pods aufgenommen haben. Als Beispiel ist hier ein Knoten, der kontaminiert wurde, sodass Pods nicht planen, es sei denn, sie haben eine demo-taint: allow Toleranz:

$ kubectl taint nodes node-1 demo-taint=allow:NoSchedule

Bearbeiten Sie Ihre Pod-Manifeste, damit sie auf dem Knoten geplant werden können:

spec:
  Toleranzen:
    - Schlüssel: Demo-Taint
      Operator: Gleich
      Wert: erlauben
      bewirken: Kein plan

Lösen Sie das Problem, das die verursacht FailedScheduling state ermöglicht es Kubernetes, die Planung Ihrer ausstehenden Pods fortzusetzen. Sie werden automatisch ausgeführt, kurz nachdem die Steuerungsebene Änderungen an Ihren Knoten erkannt hat. Sie müssen Ihre Pods nicht neu starten oder manuell neu erstellen, es sei denn, das Problem wird durch Fehler in Ihrem Pod-Manifest verursacht, z. B. falsche Affinität oder nodeSelector Felder.

Zusammenfassung

FailedScheduling Fehler treten auf, wenn Kubernetes keinen neuen Pod auf einem Knoten in Ihrem Cluster platzieren kann. Dies wird häufig dadurch verursacht, dass Ihren vorhandenen Knoten die Hardwareressourcen wie CPU, Arbeitsspeicher und Festplatte ausgehen. Wenn dies der Fall ist, können Sie das Problem beheben, indem Sie Ihren Cluster so skalieren, dass er zusätzliche Knoten enthält.

Planungsfehler treten auch auf, wenn Pods Knotenaffinitäten, Anti-Affinitäten und Selektoren angeben, die derzeit nicht von den verfügbaren Knoten in Ihrem Cluster erfüllt werden können. Blockierte und kontaminierte Knoten schränken die Möglichkeiten von Kubernetes weiter ein. Diese Art von Problem kann gelöst werden, indem Sie Ihre Manifeste auf Tippfehler in den Labels überprüfen und Einschränkungen entfernen, die Sie nicht mehr benötigen.