Après la mise à jour de la version de kubernetes sur nos nodes, nous allons nous intéresser désormais à une nouvelle bonne pratique : le redémarrage des nœuds du cluster AKS pour appliquer les mises à jour du système.
Pour résumer, les mises à jours de sécurité ou du noyau des nodes (qui sont des VM Linux dans la grande majorité des cas) sont automatiquement installées par Microsoft. Cependant c’est à vous de faire en sorte de redémarrer vos nodes pour qu’elles soient appliquées !
Attention, cet article s’applique à un AKS déployé avec des nodes Linux. Le processus de mise à jour des nœuds Windows Server est totalement différent. En effet, ceux-ci ne reçoivent pas de mises à jour . Ce sont de nouveaux nodes qui sont déployés avec la nouvelle version afin de remplacer les anciens.
Bref ! afin d’automatiser ce redémarrage, on peux utiliser Kured (Kubernetes Reboot Daemon), un projet open source de Weaveworks.
Comment ça fonctionne ?
Tout d’abord, il faut savoir que quand une mise à jour est installée et que celle-ci nécessite un redémarrage, un fichier « reboot-required » est créé dans le dossier /var/run sur chaque nœud du cluster.
Avec kured, un DaemonSet est mis en place et exécute un pod sur chaque nœud du cluster. Ces derniers recherchent l’existence du fichier /var/run/reboot-required par défaut toutes les heures. Ainsi lorsqu’il trouve ce fichier il va :
- Empêcher de nouveaux pods de se créer sur ce node (le state du node est positionné sur SchedulingDisabled)
- Déplacer un à un l’ensemble des pods existant
- Redémarrer le node
En revanche, pour limiter les perturbations, un seul nœud à la fois est autorisé à être redémarré par kured.
Comment l’utiliser ?
Pour déployer kured, nous allons utiliser son chart Helm ! Helm est un projet officiel de Kubernetes et fait partie de la Cloud Native Computing Foundation.
Dans Kubernetes la configuration des services se fait via des fichiers yaml. Quand on a une seule application, cela ne pose pas trop de problème mais quand on souhaite déployer une stack plus complète, c’est un peu plus compliqué … C’est là que Helm intervient !
Pour une présentation plus complète, je vous renvoi à cet article 🙂 A savoir que le composant server mentionné dans l’article, Tiller, est géré par Microsoft pour notre cluster k8s, vous n’avez donc pas à vous en soucier.
Mise en oeuvre
J’ajoute d’abord le repo Helm :
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
Ensuite, je met à jour mon repo local :
helm repo update
Je créé un namespace spécifique pour Kured :
kubectl create namespace kured
Et enfin je déploie la solution :
helm install kured stable/kured --namespace kured --set nodeSelector."beta.kubernetes.io/os"=linux
Ici je me suis provisionné un cluster avec 3 nodes, j’ai donc un pod Kured par node comme expliqué ci-dessus.
Quelques options pour notre installation
Dans la commande vu précédemment, il est possible de préciser des jours et des plages horaires de reboot. Autant s’éviter les problèmes évident en laissant un node redémarrer un mardi aprem à 11h …
Il faudra utiliser les options :
- reboot-days : les jours ou le reboot est autorisé
- start-time : heure de début de la plage horaire autorisé
- end-time : heure de fin de la plage horaire autorisé
- time-zone : le fuseau horaire d’application de la plage horaire
Bloquer un redemarrage
Il est également possible d’empêcher un redémarrage de noeud si un certain type de pod est exécuté dessus (identifié par un label selector) qui sera précisé au déploiement de kured : blocking-pod-selector. ça peux servir pour éviter le reboot d’un node pendant qu’un pod exécute un traitement critique…
En dehors de cette solution ci-dessus, si kured à planifié le redémarrage d’un node, peu importe les pods exécutés, il fera le ménage et relancera la vm. Vous êtes prévenu 🙂
Et voila ! Nous avons automatiser le redémarrage de nos nodes AKS avec une solution facile à mettre en oeuvre et qui a largement fais ces preuves.
A très vite !
Thomas