Warum zeigt mein Workerknoten einen Fehler NetworkUnavailable an?

Beheben Sie Probleme mit dem Betriebszustand v Calico-Knoten und Netzwerkprobleme.

Virtual Private Cloud Klassische Infrastruktur Satellite

Wenn Sie Ihre Master-oder Workerknoten aktualisieren, wechseln Ihre Workerknoten in den Status Node network unavailable.

Ihre Workerknoten können in den Status NetworkUnavailable oder Node network unavailable wechseln, wenn der calico-node-Pod heruntergefahren wurde. Dies kann während eines Calico Patch-Updates passieren, sollte aber keine Auswirkungen auf die Verfügbarkeit Ihrer Anwendung haben.

Wenn Calico aktualisiert wird, wird der Taint node.kubernetes.io/network-unavailable:NoSchedule zu Ihrem Workerknoten hinzugefügt und die Bedingung Node network unavailable wird True. Beide Bedingungen werden gelöscht, wenn Calico erneut gestartet wird. Dies dauert in der Regel nur wenige Sekunden.

Dabei wird möglicherweise eine Fehlermeldung ähnlich dem folgenden Beispiel angezeigt.

[Kubernetes] Node network unavailable is Triggered on kubernetes.node.name = 10.184.XXX.XXX
[Kubernetes] Node network unavailable is Triggered on kubernetes.node.name = 10.184.XXX.XXX
[Kubernetes] Node network unavailable is Triggered on kubernetes.node.name = 10.184.XXX.XXX

Manchmal kann der Neustart länger dauern. In fast allen Fällen ist der Neustart schnell genug, um Probleme im Workerknotennetz zu vermeiden. Es gibt jedoch Situationen, in denen ein Calico-Neustart verzögert wird und daher Netzunterbrechungen auftreten können. In diesen Fällen sind Taints und Bedingungen für das Knotennetz so konzipiert, dass neue Apps nicht auf dem neuen Knoten bereitgestellt werden, bis Calico und der Knoten behoben sind. Calico-Aktualisierungen werden sehr kontrolliert implementiert, um die Auswirkungen auf die gesamte Anwendung zu minimieren, falls ein Knotenproblem auftritt.

Überwachen Sie den Zustand von Node network unavailable mit IBM Cloud Monitoring

Durch die Verwendung von Services zum Überwachen von Anwendungen wie IBM Cloud Monitoringkönnen Sie Alerts konfigurieren, wenn ein Workerknoten in einen Node network unavailable-Status wechselt, und jedes Mal zählen, wenn dies geschieht. Sie können auch Schwellenwerte konfigurieren und Ihre Alerts optimieren, um zuzulassen, dass sich Workerknoten während Calico-Routinepatches im Status Node network unavailable befinden.

Wenn Sie IBM Cloud Monitoring-Alerts einrichten, berücksichtigen Sie die folgenden Szenarios.

  • Ein Node network unavailable-Alert kann zu einem Problem werden, wenn ein calico-node-Pod den Status Running nicht erreicht und der Zähler für den Containerneustart weiter erhöht wird.
  • Ein Workerknoten verbleibt lange Zeit im Status Node network unavailable.

Nach einer Worker-Aktualisierung oder -Ersetzung wird der calico-node-Pod manchmal immer noch nicht im Red Hat OpenShift-VPC-Cluster gestartet. Der Pod calico_node wird möglicherweise in einem Status blockiert, in dem er in einem Red Hat OpenShift VPC-Cluster nicht gestartet werden kann. Dies ist bei IKS-oder Classic-Clustern kein Problem. Dies kann auftreten, wenn Sie die sysdig-admission-controller-webhook installiert haben und versuchen, eine Worker-Aktualisierung oder -Ersetzung durchzuführen. Dies geschieht aus folgenden Gründen:

  1. Der VPN-Client-Pod wird beim Start auf den neuen Worker verschoben.
  2. calico-node auf dem neuen Worker wird gestartet, aber blockiert, da er einen apiserver-Aufruf ausgibt und das Zeitlimit nach 2 Sekunden überschreitet.
  3. Der Aufruf apiserver versucht dann, den Webhook aufzurufen, der fehlschlägt, weil der VPN-Clientpod versucht hat, auf dem neuen Knoten zu starten. Der VPN-Knoten kann dies nicht erfolgreich tun, da calico-node noch nicht gestartet wurde.

Zusammenfassend lässt sich sagen, dass der Start des calico-node-Pods von der Funktionsweise des Webhooks abhängt, der Webhook vom VPN-Client-Pod und der VPN-Client-Pod vom calico-node-Start abhängig ist. Das System befindet sich in einer Schleifenabhängigkeit. Wenn Sie Protokolle aus einem erfolgreich bereitgestellten calico-node-Pod zusammenstellen können, wird möglicherweise ein Fehler wie der folgende angezeigt:

2022-09-08 07:13:19.719 [WARNING][9] startup/utils.go 228: Failed to set NetworkUnavailable; will retry error=Patch "https://172.21.0.1:443/api/v1/nodes/10.242.64.17/status?timeout=2s": net/http: request canceled (Client.Timeout exceeded while awaiting headers)

Problemumgehungen für calico-node

Sie können eine der folgenden Methoden verwenden, um das Problem zu umgehen und den calico-node-Pod erneut auszuführen.

  1. Entfernen Sie die sysdig-admission-controller-webhook aus dem System.
  2. Ändern Sie sysdig-admission-controller-webhook und ändern Sie das Zeitlimit in weniger als 2 Sekunden.
  3. Ändern Sie sysdig-admission-controller-webhook so, dass der Geltungsbereich auf die entsprechenden Namensbereiche festgelegt wird, und vermeiden Sie systemkritische Namensbereiche wie calico-system.
  4. Verwenden Sie den neuen Knoten als Cordon, aber bereinigen Sie ihn nicht. Löschen Sie den VPN-Pod und warten Sie, bis er auf einem anderen Worker gestartet wird. Hängen Sie den Knoten ab.

Nachdem Sie eine der vorherigen Problemumgehungen ausgeführt haben, kann der calico-node-Pod erfolgreich gestartet werden.