Mettre à jour le cluster

Pourquoi

Kubernetes publie une version mineure environ tous les quatre mois et n'en maintient que trois à la fois. Un cluster que l'on ne met pas à jour n'est pas stable : il cesse de recevoir les correctifs de sécurité, ses composants installés (Traefik, cert-manager, Argo CD) finissent par exiger une version plus récente, et le jour où il faut monter, l'écart est tel que l'on doit enchaîner plusieurs montées d'affilée en pleine urgence. Dans un service managé, un second facteur s'ajoute : Scaleway ne maintient pas indéfiniment une version. Au 5 octobre 2026, la 1.33 est déjà déclarée obsolète et sa fin de support arrive le 4 novembre ; un cluster qui y est encore sera monté d'office.

La question n'est donc pas « faut-il monter », mais « à quel moment et avec quelle sécurité ». Pour Signalements, la montée est une opération de routine, tant qu'on a posé trois choses : une application qui supporte la perte d'un nœud, des manifestes qui n'utilisent aucune API retirée, et une répétition en préproduction. Sans elles, chaque montée devient une intervention de nuit avec une part de hasard.

Les concepts

Le calendrier de Scaleway

Scaleway publie une version de Kubernetes dans les jours ou semaines qui suivent la sortie amont, la propose à la création de cluster et à la montée, puis la retire par étapes. Quatre jalons sont définis dans la politique de support :

• Fin de vie amont : la communauté Kubernetes cesse de publier des correctifs.
• Disponibilité chez Scaleway : la version peut être créée et visée par une montée.
• Obsolescence (deprecation) : la version disparaît des choix de création de cluster ; les clients concernés sont informés par un ticket de support et invités à monter.
• Fin de support : la version n'est plus supportée, et les clusters sont montés automatiquement vers la mineure suivante supportée. La documentation précise que Scaleway applique alors la dernière correction de cette mineure dans les 30 jours, avec une notification par ticket.

La documentation affirme que chaque mineure est supportée au moins douze mois avant l'obsolescence et indique une fenêtre de support de 14 mois. Les dates de l'extrait publié au 5 octobre 2026 :

Ces dates évoluent : la page de politique de support est la référence, la table ci-dessus n'est qu'une photographie.

Une mineure à la fois

Kubernetes impose un ordre entre les composants (voir la politique d'écart de versions) : le plan de contrôle d'abord, les nœuds ensuite, car un kubelet ne doit pas être plus récent que le serveur d'API, et peut en revanche être jusqu'à trois mineures en retard. Kapsule en fait des règles de l'API. La commande scw k8s cluster upgrade n'accepte que « une version de correction supérieure de la même mineure, ou la mineure directement suivante » ; l'aide de list-available-versions précise qu'« une montée qui saute une mineure ne fonctionnera pas ». Pour passer de 1.34 à 1.36, on passe donc par la 1.35, en répétant les deux étapes. Et on ne redescend pas : la documentation de Scaleway avertit qu'une version montée ne se rétrograde pas.

Plan de contrôle, puis pools

Le plan de contrôle est géré par Scaleway. Monter une version le remplace par un plan de contrôle de la nouvelle version, pendant que vos charges de travail continuent de tourner : tant que le plan de contrôle est indisponible, rien ne s'applique (pas de déploiement, pas de nouvel objet), mais les pods existants ne s'arrêtent pas. Les clusters à plan de contrôle mutualisé n'ont qu'un réplica résilient du serveur d'API ; les types dédiés en ont deux (voir leçon 1). Un outil qui interroge l'API en permanence (Argo CD, un opérateur) voit donc des erreurs passagères.

Les pools sont à vous : la montée de leurs nœuds est une opération distincte, déclenchée par scw k8s pool upgrade ou par l'option upgrade-pools=true de la montée du cluster. Un pool ne peut être monté qu'à la version du cluster. Sa montée consiste, d'après l'aide de la CLI, à vider et remplacer les nœuds du pool : un nœud n'est pas mis à jour sur place, il est remplacé par un nouveau nœud de la bonne version.

Le rythme du remplacement

La stratégie de remplacement se règle par pool avec la politique de mise à jour (upgrade-policy), deux nombres :

• max-surge : combien de nœuds supplémentaires peuvent être créés pendant la montée. Avec max-surge=1, le pool passe à size + 1 avant de redescendre à size une fois les nœuds remplacés.
• max-unavailable : combien de nœuds peuvent être en cours de montée en même temps.

Le fournisseur Terraform donne les valeurs par défaut : max_surge à 0 et max_unavailable à 1. Sans surcapacité, chaque nœud est donc vidé avant qu'un remplaçant n'existe : pendant ce temps, la capacité du pool baisse d'un nœud. Avec max_surge = 1 et max_unavailable = 0, le nouveau nœud arrive avant qu'on vide l'ancien : plus long et un peu plus cher (un nœud de plus pendant la montée), mais la capacité ne diminue jamais. Ce second choix suppose que le type de nœud soit disponible dans la zone et que votre quota le permette.

Il existe un troisième réglage, vu dans l'aide de scw k8s pool create : max-termination-grace-period, délai maximal avant que l'API force le vidage et la suppression d'un nœud en cours de suppression. L'aide précise qu'il « prend le pas sur les PodDisruptionBudget et sur terminationGracePeriodSeconds », avec 15 minutes par défaut et une limite d'une heure. Retenez-le : sur Kapsule, un PodDisruptionBudget trop strict ne bloque pas la montée pour toujours, il la retarde de quinze minutes, après quoi les pods sont arrêtés quand même.

La mise à jour automatique

La mise à jour automatique (auto-upgrade) applique les versions de correction de la mineure courante, au plan de contrôle et aux nœuds gérés, dans une fenêtre de maintenance de deux heures (voir le glossaire) que vous choisissez : un jour de la semaine (ou any) et une heure de début. Elle ne passe jamais à la mineure suivante : celle-là reste une décision. La documentation recommande de ne pas modifier l'espace de noms kube-system, qui peut empêcher la mise à jour automatique de fonctionner. Dans Terraform, activer l'option impose que la version du cluster soit donnée en x.y (par exemple 1.36), la correction étant alors choisie par Scaleway.

Les API retirées

Chaque version de Kubernetes peut retirer des versions d'API devenues obsolètes. Un manifeste qui déclare apiVersion: policy/v1beta1 pour un PodDisruptionBudget, valide jusqu'à la 1.24, est rejeté depuis la 1.25 ; de même autoscaling/v2beta2 pour un HorizontalPodAutoscaler ne fonctionne plus depuis la 1.26. L'erreur n'apparaît pas à la montée, mais au prochain kubectl apply ou à la prochaine synchronisation d'Argo CD, parfois des semaines plus tard. Les objets déjà stockés dans etcd sont, eux, convertis par l'API : le risque porte sur vos sources (Git, charts), pas sur l'existant. Le guide de migration des API obsolètes de Kubernetes liste, version par version, ce qui est retiré.

En pratique

1. Quelle version, jusqu'où ?

$ scw k8s cluster get <id-du-cluster>
$ scw k8s cluster list-available-versions <id-du-cluster>

La première commande affiche entre autres la version courante et si une montée est disponible ; la seconde liste les corrections supérieures et la seule mineure suivante. Comparez la version du cluster au calendrier : à moins de trois mois de l'obsolescence, planifiez la montée dans le trimestre.

2. Chercher les API retirées avant de toucher à quoi que ce soit

Plusieurs sources se recoupent, aucune ne suffit seule.

Dans le dépôt Git, le guide de migration indique les groupes et versions concernés ; on cherche les apiVersion du dépôt avec grep -rn "apiVersion:" . | sort | uniq -c, et l'on rend les charts Helm avec helm template avant de chercher dans la sortie. L'outil kubectl convert (greffon à installer séparément, indiqué par la documentation de Kubernetes) convertit un manifeste vers une autre version d'API :

$ kubectl convert -f pdb-ancien.yaml --output-version policy/v1

Dans le cluster, l'API signale chaque appel à une API obsolète : les clients reçoivent un avertissement (visible dans la sortie de kubectl), et le serveur expose la métrique apiserver_requested_deprecated_apis, qui compte les requêtes par groupe, version, ressource et version de retrait. Si votre identité a le droit de lire /metrics, kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis donne la liste de ce qui est encore appelé, et par qui il faut remonter (un contrôleur, un chart, un script). La métrique ne voit que ce qui a été appelé depuis le démarrage du serveur : attendez un cycle complet d'activité avant de la croire.

Avec des outils tiers : des analyseurs statiques comme pluto ou kubent croisent les manifestes ou les objets du cluster avec une base de versions retirées. Ils sont pratiques en CI ; nous les citons sans les détailler.

3. Répéter en préproduction

Une préproduction utile est un cluster Kapsule, pas un espace de noms du même cluster : une montée s'éprouve sur un plan de contrôle et des pools. Le cluster de préproduction est créé par le même code que la production (cours de la leçon 8), à la version actuelle de la production, avec les mêmes composants et une copie réduite de l'application :

1. Monter le plan de contrôle de la préproduction ; vérifier qu'Argo CD synchronise toujours, que Traefik répond, que les certificats se renouvellent.
2. Monter les pools avec la même politique de mise à jour que la production, pendant que des requêtes de test arrivent sur GET /sante (un script ou un outil de charge simple suffit).
3. Compter les erreurs et la durée de l'opération. Ce chiffre sert à fixer la fenêtre et à décider si la production demande un max-surge supérieur.

Si la préproduction coûte trop cher à garder, elle se crée à la demande pour la montée, puis se détruit : c'est aussi un test de la reproductibilité du cluster.

4. Monter le plan de contrôle

On monte d'abord les composants du cluster (voir l'étape 7 pour l'ordre), puis :

$ scw k8s cluster upgrade <id-du-cluster> version=1.36.0 --wait

version est la version cible ; l'option --wait rend la main quand le cluster est de nouveau stable. L'opération monte le plan de contrôle seulement, sauf si l'on ajoute upgrade-pools=true. Pendant ce temps, observez kubectl get --raw=/readyz et vos pods, et préparez-vous à des erreurs passagères de l'API. Les pools restent à l'ancienne version, ce qui est autorisé (le kubelet peut avoir jusqu'à trois mineures de retard) et laisse un point d'arrêt sûr.

5. Régler et monter les pools

Choisissez la politique de remplacement, pool par pool. Le pool applications de Signalements ne doit pas perdre de capacité :

$ scw k8s pool update <id-du-pool-applications> \
    upgrade-policy.max-surge=1 upgrade-policy.max-unavailable=0
$ scw k8s pool upgrade <id-du-pool-applications> version=1.36.0 --wait

Le pool systeme (Traefik, Argo CD, External Secrets), plus petit, peut recevoir la même politique. Montez un pool à la fois, et vérifiez après chacun : kubectl get nodes -o wide pour les versions de kubelet, kubectl get pods -A | grep -v Running pour ce qui ne va pas, et l'état de GET /sante de l'application.

Ce que l'on observe, en prose et non en capture : un nouveau nœud apparaît, passe Ready, puis l'ancien est isolé (cordon), vidé (les pods sont évincés selon leur PodDisruptionBudget) et supprimé ; l'opération recommence pour le suivant. Avec la politique par défaut (pas de surcapacité), c'est l'ancien nœud qui disparaît d'abord.

Pour monter plusieurs mineures, répétez l'étape 4 et l'étape 5 pour chacune ; on laisse passer au moins un cycle complet d'activité entre deux.

6. Rendre la montée invisible

La mise à jour n'est invisible que si l'application tient sa part. Quatre éléments, déjà posés dans Déployer Signalements de bout en bout, prennent ici tout leur sens.

Au moins deux réplicas, répartis. Un seul réplica ne survit pas à l'éviction de son nœud, quoi que l'on configure :

spec:
  replicas: 3
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: signalements-api

Un PodDisruptionBudget qui dit combien de réplicas peuvent partir en même temps :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: signalements-api
  namespace: signalements
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: signalements-api
  unhealthyPodEvictionPolicy: AlwaysAllow

Le vidage d'un nœud passe par l'API d'éviction, qui refuse d'évincer un pod si cela fait dépasser le budget. unhealthyPodEvictionPolicy: AlwaysAllow autorise l'éviction des pods qui ne sont pas prêts même quand le budget est atteint, ce qui évite qu'un pod bloqué en CrashLoopBackOff empêche le vidage d'un nœud. Le revers, que la documentation de Kubernetes signale : un pod qui tentait de redevenir prêt peut être évincé avant d'y parvenir. Le défaut est IfHealthyBudget.

Une sonde de disponibilité qui dit la vérité. GET /sante de Signalements doit répondre « prêt » quand l'application sert vraiment : base joignable, migrations passées. Un pod qui se déclare prêt trop tôt reçoit du trafic qu'il ne sait pas traiter, au pire moment. Voir la leçon 4 des fondamentaux et la sonde.

Un arrêt gracieux. Quand un pod est évincé, il reçoit SIGTERM : gunicorn termine alors les requêtes en cours dans son délai de grâce. Un terminationGracePeriodSeconds supérieur à la durée de votre plus longue requête, et en deçà du max-termination-grace-period du pool (15 minutes par défaut), laisse le travail finir ; au-delà, l'API force. Un preStop court qui attend quelques secondes laisse au répartiteur le temps de retirer le pod de ses cibles avant l'arrêt effectif.

7. Mettre à jour ce que vous avez installé

Kapsule met à jour ses composants (plan de contrôle, pilotes, CNI selon la politique du service) ; ceux que vous avez installés vous appartiennent. Pour lyneko-apps : Traefik, cert-manager, Argo CD, External Secrets. Chaque projet publie une table de compatibilité entre ses versions et celles de Kubernetes : lisez-la avant la montée, pas après.

L'ordre dépend du sens de l'incompatibilité :

• si la nouvelle version de Kubernetes retire une API que le composant utilise, il faut mettre à jour le composant avant ;
• si la nouvelle version du composant exige une fonction de la version suivante de Kubernetes, il faut monter Kubernetes avant.

La table de chaque projet dit dans quel cas on est. Les montées de composants se font par Git (Argo CD) : une modification de version de chart, une revue, une synchronisation. Un composant qui s'installe par helm hors Argo CD doit être inventorié, sinon on l'oublie : helm list -A donne la liste.

Sous le capot

Le remplacement d'un nœud. L'aide de la CLI dit que la montée d'un pool « vide et remplace » ses nœuds. Le vidage suit la séquence de Kubernetes que kubectl drain exécute à la main : marquer le nœud non planifiable (cordon), évincer les pods par l'API d'éviction (qui respecte les PodDisruptionBudget), attendre la fin des arrêts, puis supprimer l'instance et sa machine. Les pods gérés par un contrôleur (Deployment, StatefulSet) sont recréés ailleurs ; les pods nus sont perdus. Le délai de max-termination-grace-period borne la durée de ce vidage côté Scaleway.

Ce qui est perdu. Le disque système du nœud est détruit avec lui, ce qui inclut les emptyDir et les données de hostPath : la documentation de Scaleway avertit que la montée d'un pool peut entraîner la perte des données stockées localement sur un nœud. Les volumes persistants (Block Storage) sont, eux, détachés et rattachés au nouveau nœud, dans la même zone : un pod avec un volume persistant ne peut repartir que sur un nœud de la zone du volume. Un pool mono-nœud dans une zone, ou un pool dont le type n'est plus disponible dans sa zone, bloque ces pods en Pending.

La version d'un pool. Un pool créé après une montée du cluster prend la version du cluster. Un pool resté à l'ancienne version la conserve : l'API n'exige pas de les aligner, dans la limite de l'écart supporté par Kubernetes. En Terraform, la propriété upgrade_pools du cluster choisit si la montée du cluster entraîne celle des pools (cela se fait alors « hors » de Terraform, car la configuration du pool ne change pas) ou si elles sont séparées, et la version du pool n'est prise en compte qu'avec upgrade_pools = false.

Pièges courants

ImagePullBackOff après la montée d'un pool. Le nouveau nœud n'a pas les mêmes images en cache, et les identifiants du registre (voir leçon 5) ont expiré ou manquent : l'image se tire alors au démarrage du pod. kubectl describe pod donne la cause. Pensez à vérifier l'expiration des clés avant la montée.

Un pod en Pending après un remplacement. Le nœud n'a plus assez de ressources pour les requests du pod (voir Ressources, planification et qualité de service), ou une contrainte de zone (volume) ne peut pas être satisfaite. L'événement du pod le dit, par exemple « Insufficient cpu » ou une affinité de volume non satisfaite.

Le PodDisruptionBudget à maxUnavailable: 0. Il interdit toute éviction volontaire : le vidage reste bloqué jusqu'à ce que max-termination-grace-period (15 minutes par défaut) le force. Un budget qui interdit tout n'est pas une protection, c'est un retard garanti, suivi d'une coupure.

Les pools montés dans le mauvais ordre. Une tentative de monter un pool alors que le cluster est encore à l'ancienne version échoue : l'aide dit que cela ne fonctionne que si la version visée est celle du cluster.

unable to recognize "x.yaml": no matches for kind "PodDisruptionBudget" in version "policy/v1beta1". Voilà le visage d'une API retirée : l'erreur arrive à l'application d'un manifeste, pas à la montée. La correction est apiVersion: policy/v1, plus les changements de champs éventuels que le guide de migration indique.

Le cluster en retard de trois mineures. Chaque montée passe par une version intermédiaire : le travail est triplé, et les API retirées s'accumulent. Un cluster en 1.33 à la fin de support n'a plus de marge.

Sécurité

• Les correctifs de sécurité sont dans les versions de correction, pas dans les mineures. La mise à jour automatique des correctifs est donc la mesure de sécurité la plus rentable de la leçon : elle s'active une fois et travaille ensuite seule.
• Une version hors support n'est plus corrigée : l'amont ne publie plus de correctifs après la fin de vie, et Scaleway ne la supporte plus. La tolérer, c'est accepter des vulnérabilités connues sur l'API exposée.
• L'accès à l'opération. Qui peut déclencher une montée peut déclencher un remplacement de tous les nœuds : réservez KubernetesFullAccess et placez l'opération dans une procédure, avec une trace.
• Les images tirées pendant la montée : l'indisponibilité du registre pendant un remplacement bloque les redémarrages. Pensez à imagePullPolicy et aux copies locales pour les images critiques (voir la leçon 7 du cours Scaleway).

En production

Un calendrier, pas une surprise. Chaque version du calendrier de Scaleway devient trois rendez-vous : une montée de préproduction dès que la version est disponible, une montée de production dans les trois mois, et une alarme à l'obsolescence. Une équipe qui a ce calendrier n'est jamais montée d'office.

Le critère de réussite. Sur Signalements : zéro erreur côté utilisateur pendant la montée, mesurée sur GET /sante et sur le taux de réponses 5xx dans Cockpit (leçon 7). Si ce n'est pas le cas en préproduction, la cause se corrige avant de monter la production : réplicas, budget, sondes.

Multi-zone. Un cluster dont les pools sont répartis sur plusieurs zones monte pool par pool : une zone entière n'est jamais retirée à la fois. Le plan de contrôle reste dans une seule zone (voir leçon 2) ; pendant sa montée, ce qui tourne reste en place mais rien ne se configure.

Le cluster jetable. À terme, la réponse la plus robuste à une montée délicate est un nouveau cluster créé par le même code, qui reçoit le trafic par bascule (DNS ou répartiteur) avant d'éteindre l'ancien. Plus coûteux, mais réversible : on revient à l'ancien. Le cours Kubernetes : administrer un cluster examinera ce modèle.

Exercices

1. Planifier (niveau 200). Un cluster est en 1.34, nous sommes le 5 octobre 2026. Quelle est la date limite avant la montée forcée, et quelles montées faut-il enchaîner pour atteindre la 1.36 ?

2. Surge ou pas (niveau 300). Le pool applications compte 3 nœuds, chacun tenant environ 70 % de sa capacité. Comparez la montée avec les valeurs par défaut (max_surge 0, max_unavailable 1) et avec max_surge 1, max_unavailable 0.

3. Le vidage qui traîne (niveau 300). Pendant la montée de préproduction, le vidage d'un nœud dure exactement quinze minutes, puis les pods sont arrêtés d'un coup. Quelle est la cause la plus probable, et comment la vérifier ?

Récapitulatif

• Scaleway déclare obsolète une version environ 12 mois après sa publication, puis monte d'office les clusters à la fin de support (14 mois), avec un ticket de notification : on monte soi-même avant.
• La montée se fait une mineure à la fois, en deux étapes : scw k8s cluster upgrade pour le plan de contrôle (les pods continuent de tourner), puis scw k8s pool upgrade pour les pools, dont les nœuds sont remplacés et non mis à jour sur place.
• La politique de mise à jour du pool règle le rythme : max-surge (nœuds en plus) et max-unavailable (nœuds en cours de montée) ; max-termination-grace-period force le vidage au bout de 15 minutes par défaut, par-dessus les PodDisruptionBudget.
• La mise à jour automatique applique les corrections de la mineure courante dans une fenêtre de deux heures ; elle ne change jamais de mineure.
• Les API retirées se détectent avant la montée (guide de migration, kubectl convert, métrique apiserver_requested_deprecated_apis, pluto ou kubent) : l'erreur surgit au prochain apply, pas à la montée.
• Une montée sans coupure suppose des réplicas répartis, un PodDisruptionBudget, des sondes exactes et un arrêt gracieux ; elle se répète sur un cluster de préproduction.
• Les composants que vous avez installés (Traefik, cert-manager, Argo CD) se mettent à jour par Git, dans l'ordre que dicte leur table de compatibilité.

Pour aller plus loin

• La page de politique de support de Scaleway, à consulter à chaque version publiée.
• Le guide de migration des API obsolètes de Kubernetes, et le billet de son blog sur les avertissements de dépréciation.
• La documentation de Kubernetes sur kubectl drain et l'API d'éviction.
• La leçon 8, pour écrire en Terraform la fenêtre de maintenance, la politique des pools et le cluster de préproduction.
• Les cours Helm et Kubernetes : administrer un cluster, pour la gestion des versions de charts et les montées par bascule.