Les pods sont la plus petite unité de Kubernetes. Ils doivent fonctionner jusqu’à ce qu’ils soient remplacés par un nouveau déploiement. S’il n’existe aucune commande permettant explicitement de redémarrer un pod, il existe plusieurs méthodes pour le faire que nous allons passer en revue dans cet article.
Si vous souhaitez devenir incollable sur la gestion des pods, notre formation Kubernetes vous permettra de devenir incollable sur la gestion de vos clusters et de vos applications conteneurisées. À l’issue de cette formation, vous saurez déployer et gérer des applications cloud native conteneurisées.
L’équipe Ambient IT
Pourquoi redémarrer un pod Kubernetes ?
Il existe plusieurs cas de figure dans lesquels vous pourriez avoir besoin de redémarrer un pod dans Kubernetes voici quelques exemples :
- Appliquer des changements de configuration : s’il y a des mises à jour sur la configuration du pod (configmaps, secrets, variables d’environnement), dans certains cas, vous pouvez avoir besoin de redémarrer manuellement le pod pour que les changements prennent effet.
- Débugage d’applications : si votre application ne fonctionne pas correctement, ou si vous rencontrez simplement des problèmes avec elle, il est souvent conseillé de redémarrer d’abord les pods sous-jacents pour réinitialiser leur état et faciliter le dépannage.
- Pod bloqué dans un état de terminaison : une suppression et une recréation suffisent dans la plupart des cas. Cependant, il y a des cas où un nœud est mis hors service, et les pods ne peuvent pas être expulsés de ce nœud, dans lesquels un redémarrage aidera à résoudre le problème.
- Forcer l’extraction d’une nouvelle image : pour s’assurer qu’un module utilise la dernière version d’une image, si vous utilisez la dernière balise, vous devez redémarrer manuellement le module pour forcer l’extraction d’une nouvelle image. Cette méthode n’est pas réellement considérée comme une bonne pratique, mais c’est un cas de figure qui peut arriver.
Les status des pods
Les pods Kubernetes peuvent avoir cinq statuts :
- Pending : indique qu’au moins un conteneur du pod n’a pas encore été créé.
- Running : tous les conteneurs ont été créés et le pod a été lié à un nœud.
- Failed : tous les conteneurs ont été terminés et au moins un conteneur a échoué.
- Succeded : tous les conteneurs du pod ont été terminés avec succès.
- Unknown : impossible d’obtenir une réponse sur l’état du pod
Chaque pod Kubernetes suit un cycle de vie défini. Il commence par la phase « pending » et passe à la phase « running« , si un ou plusieurs conteneurs primaires ont démarré avec succès. Ensuite, il passe à la phase « succeeded » ou « failed » en fonction du succès ou de l’échec des conteneurs dans le pod.
Un pod ne peut pas se réparer lui-même. Si le nœud où le pod est planifié tombe en panne, Kubernetes supprimera le pod. De même, les pods ne peuvent pas survivre aux expulsions résultant d’un manque de ressources ou de maintenance du nœud. Kubernetes utilise un contrôleur qui fournit une abstraction de haut niveau pour gérer les instances de pods.
Lorsque le pod est en cours d’exécution, le kubelet peut redémarrer chaque conteneur pour gérer certaines erreurs. Vous pouvez contrôler la politique de redémarrage d’un conteneur par le biais de la politique de redémarrage de la spécification au même niveau que vous définissez le conteneur :
- Always : le pod doit toujours être en cours d’exécution, de sorte que Kubernetes crée un nouveau conteneur chaque fois qu’un conteneur existant se termine.
- OnFailure : le conteneur ne redémarre que s’il se termine avec un code de retour différent de 0. Les conteneurs qui renvoient 0 (succès) n’ont pas besoin d’être redémarrés.
- Never : le conteneur ne redémarre pas
À noter que si vous n’entrez pas de valeur, la valeur par défaut sera réglée sur Always.
Comment redémarrer un pod Kubernetes ?
Méthode 1 : kubectl rollout restart
Cette méthode est la plus recommandée, car elle n’entraînera pas de temps d’arrêt puisque les pods fonctionneront. Un redémarrage de rollout tuera un pod à la fois, puis les nouveaux pods seront mis à l’échelle.
kubectl rollout restart deployment <deployment_name> -n <namespace>
Méthode 2 : Kubectl Set Env
L’une des solutions consiste à changer le nombre de répliques du pod qui doit être redémarré à l’aide de la commande kubectl scale. Pour redémarrer un module Kubernetes à l’aide de la commande scale :
Définissez le nombre de répliques du module à 0
kubectl scale deployment demo-deployment --replicas=0
La commande désactivera le module Kubernetes. Définissez le nombre de répliques à un nombre supérieur à zéro.
kubectl scale deployment demo-deployment --replicas=1
Cette commande crée de nouvelles répliques du pod que la commande précédente a détruit. Cependant, les nouvelles répliques auront des noms différents. Vous pouvez alors vérifier le nom des nouvelles répliques.
kubectl get pods
Méthode 3 : Kubectl Delete Pod
Utilisez la commande suivante pour supprimer l’objet API pod :
kubectl delete pod demo_pod -n demo_namespace
L’API Kubernetes étant déclarative, la suppression de l’objet pod contredit l’objet attendu. Par conséquent, le pod est recréé pour maintenir la cohérence avec le pod attendu.
Pour redémarrer plusieurs pods, utilisez la commande suivante :
kubectl delete replicaset demo_replicaset -n demo_namespace
Méthode 4 : kubectl get pod/kubectl replace
Vous pouvez remplacer un pod à l’aide de la commande kubectl get pod pour obtenir la déclaration YAML du pod en cours d’exécution et la transmettre à la commande kubectl replace avec l’option –force spécifiée afin d’obtenir un redémarrage. Ceci est utile s’il n’y a pas de fichier YAML disponible et que le pod est démarré.
kubectl get pod <nom_du_pod> -n <namespace> -o yaml | kubectl replace --force -f -
Conclusion
Si les méthodes de redémarrages des pods sont pratiques pour empêcher des interruptions de service dans vos applications, elle ne représente pas une véritable solution en elle-même. Si vos pods ont besoin d’être redémarrés régulièrement, une enquête approfondie doit être effectuée pour déterminer la source du problème.