Pourquoi mon noeud worker affiche-t-il une erreur NetworkUnavailable ?

Dépannage des problèmes liés à l'état de santé des nœuds d' Calico et des problèmes de réseau.

Cloud privé virtuel Infrastructure classique Satellite

Lorsque vous mettez à jour votre maître ou vos noeuds worker, vos noeuds worker passent à l'état Node network unavailable.

Vos noeuds worker peuvent passer à l'état NetworkUnavailable ou Node network unavailable chaque fois que le pod calico-node a été arrêté. Cela peut se produire lors d'une mise à jour du correctif Calico, mais ne devrait pas avoir d'impact sur la disponibilité de votre application.

Lorsque Calico est mis à jour, la tache node.kubernetes.io/network-unavailable:NoSchedule est ajoutée à votre noeud worker et la condition Node network unavailable devient True. Ces deux conditions sont effacées lorsque Calico redémarre, ce qui ne prend généralement que quelques secondes.

Pendant ce temps, un message d'erreur similaire à l'exemple suivant peut s'afficher.

[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

Parfois, le redémarrage peut prendre plus de temps. Dans presque tous les cas, le redémarrage est suffisamment rapide pour éviter tout problème de réseau de noeud worker. Toutefois, dans certains cas, le redémarrage de Calico est retardé et il peut donc y avoir des interruptions réseau. Dans ces cas, la condition et la tache d'indisponibilité du réseau de noeud sont conçues pour empêcher le déploiement de nouvelles applications sur le nouveau noeud jusqu'à ce que Calico et le noeud soient corrigés. Les mises à jour de Calico sont déployées de manière très contrôlée afin de minimiser l'impact global de l'application en cas de problème de noeud.

Surveillez l'état de Node network unavailable avec IBM Cloud Monitoring

En utilisant des services pour surveiller des applications telles que IBM Cloud Monitoring, vous pouvez configurer des alertes lorsqu'un noeud worker passe à l'état Node network unavailable et compter chaque fois que cela se produit. Vous pouvez également configurer des seuils et optimiser vos alertes afin de les autoriser lorsque les noeuds worker sont à l'état Node network unavailable lors de l'utilisation des correctifs Calico de routine.

Lorsque vous configurez des alertes IBM Cloud Monitoring, tenez compte des scénarios suivants.

• Une alerte Node network unavailable peut devenir un problème lorsqu'un pod calico-node ne parvient pas à atteindre l'état Running et que son nombre de redémarrages de conteneur continue d'augmenter.
• Un noeud worker reste à l'état Node network unavailable pendant une longue période.

Après la mise à jour ou le remplacement d'un agent, le pod calico-node ne démarre toujours pas sur le cluster VPC Red Hat OpenShift. Le pod calico_node peut être bloqué dans un état où il ne peut pas démarrer sur un cluster de VPC Red Hat OpenShift. Il ne s'agit pas d'un problème sur les clusters IKS ou Classic. Cela peut se produire lorsque sysdig-admission-controller-webhook est installé et que vous tentez d'effectuer une mise à jour ou un remplacement d'agent. Cela se produit pour les raisons suivantes:

1. Le pod du client VPN est déplacé vers le nouvel agent au fur et à mesure de son démarrage.
2. calico-node sur le nouvel agent démarre, mais est bloqué car il émet un appel apiserver et expire au bout de 2 secondes.
3. L'appel apiserver tente ensuite d'appeler le webhook qui échoue car le pod du client VPN tentait de démarrer sur le nouveau noeud. Le noeud VPN ne peut pas le faire car calico-node n'a pas encore démarré.

En résumé, le démarrage du pod calico-node dépend du webhook qui fonctionne ; le webhook dépend du pod du client VPN et le pod du client VPN dépend du démarrage de calico-node. Le système est bloqué dans une dépendance en boucle. Si vous êtes en mesure de collecter des journaux à partir d'un pod calico-node déployé avec succès, une erreur de ce type peut s'afficher:

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)