Procédures additionnelles

1. Crash ou arrêt sale d’un node Nodes:crash

Si on stoppe violemment un node, il peut se passer des choses étranges. Lorsque cela se produit, l’origine du problème n’est pas notifiée aux masters : ils ne savent pas pourquoi le node n’est plus visible. Doivent-ils redémarrer les pods manquants ? Après tout, le problème peut être transitoire : le node peut redémarrer rapidement et les pods associés peuvent donc être à nouveau accessibles… 

Aussi, un mécanisme de timeout est en place. Le node est détecté comme étant NotReady, et avec les réglages que nous avons appliqués lors de la création des masters, un mécanisme d’éviction des pods démarre après un délai variable, d’environ 30 secondes à 1 minute. Les pods qui tournaient sur le node planté passent en statut Terminating. Un délai de grâce s’applique alors, qui a été fixé à 30 secondes, à la fin duquel Kubernetes remplace le pod absent par un nouveau. À ce délai s’ajoutent le délai de détection du node en panne, le délai de redémarrage du nouveau pod (récupération de l’image et lancement), etc.

Ces délais mettent en évidence la nécessité de vérifier l’état du cluster...

Pour consulter la suite, découvrez le livre suivant :
couv_EPHADIS.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Construction
Suivant
Introduction