Ich habe Kubernetes mithilfe von kubeadm auf einem Single-Node-Server installiert. Ich habe festgestellt, dass alles einwandfrei läuft, wenn ich die Installation in einer bestimmten Reihenfolge durchführe. Dazu gehören die wichtigsten Kube-Systemkomponenten (API-Server, Proxy, Scheduler, etcd usw.), die zuerst hochgefahren und ausgeführt wurden (außer Coredns). Danach wurde das Cilium CNI-Plugin mithilfe von Helm für die Netzwerkverbindung installiert (wodurch Coredns funktionierte).
Nach dieser Installation konnte ich dann andere Dienste wie NVIDIAs GPU Operator und Kubeflow erfolgreich installieren und verwenden. Nach einem Neustart stelle ich jedoch fest, dass die verschiedenen Komponenten in einen Absturzschleifen-Backoff-Zustand geraten.
Ich denke, das hat etwas mit der Reihenfolge zu tun, in der die verschiedenen Ressourcen initialisiert werden, und mit der Länge der verschiedenen Timeouts. Gibt es eine Möglichkeit, entweder eine Reihenfolge festzulegen, in der die verschiedenen Komponenten beim Booten gestartet werden? Oder möglicherweise ein geeignetes Standard-Timeout oder Absturzverhalten von Pods zu konfigurieren?
Wahrscheinlich handelt es sich hier um einen Dominoeffekt, bei dem der Absturz einer Komponente den Absturz einer anderen zur Folge hat, was wiederum zu immer längeren Back-off-Zeiten und schließlich zu einem nicht mehr reagierenden Cluster führt.
Zur weiteren Information: Ich habe die iptables-Regeln gespeichert, damit sie beim Booten angewendet werden. Außerdem wechseln normalerweise alle Hauptkomponenten in den laufenden Zustand, mit Ausnahme des Kube-Schedulers, der in der Absturzschleife bleibt. Dann beginnen auch die anderen Komponenten abzustürzen, was wie ein Dominoeffekt aussieht.
Bisher habe ich hauptsächlich versucht, die Manifestdateien unter /etc/kubernetes/manifests/ zu aktualisieren, um verschiedene Timeouts und Fehlerschwellenwerte für die Kubernetes-Systempods zu verwenden, aber das schien das Problem nicht zu lösen. Ich konnte das Neustartverhalten des Servers replizieren, indem ich zuerst den Kubelet-Dienst stoppte, alle laufenden Pods/Container zerstörte und dann Kubelet neu startete.
Antwort1
Es stellt sich heraus, dass dieses Problem dem in diesem GitHub beschriebenen sehr ähnlich istAusgabe. Im Wesentlichen ohne Angabe der SystemdCgroup = trueOption für meine containerd CRI-Laufzeit (die dienvidiaContainerlaufzeitanstelle des Standardwerts von runc), stürzten die Pods unerklärlicherweise immer wieder ab. Dies geschah aufgrund einer Verletzung der Single-Writer-Regel von cgroups, da der Standardtreiber zum Verwalten von cgroups ist, cgroupfsder nicht mit kompatibel ist systemd. Sie können dieDokumentationfür weitere Details. Es enthält auch eine vollständige Spezifikation der CRI-Plugin-KonfigurationHier.
Andere relevante Containerd-Ressourcen sind: