Kubernetes 1.36 : ce qui change pour vos clusters auto-hébergés

Préparez Kubernetes 1.36 par un inventaire des composants et des incompatibilités avant d’exécuter kubeadm upgrade. La réussite dépend autant du CNI, du stockage CSI, du runtime et des opérateurs que de Kubernetes ; validez donc la procédure sur un environnement représentatif.

Une mise à niveau sans interruption n’est possible que si le plan de contrôle est hautement disponible, si les applications sont répliquées et si les autres nœuds ont assez de capacité pour recevoir les pods évincés. Un cluster à nœud unique, une application à replica unique ou une dépendance non répliquée impose une fenêtre de maintenance ou l’ajout préalable de redondance.

Qualifier la cible et les dépendances

Vérifiez le statut de Kubernetes 1.36, le dernier correctif disponible et sa date de fin de support dans les informations de version officielles. Consultez ensuite les notes de version pour relever les Urgent Upgrade Notes, les API retirées ou dépréciées, les changements de valeurs par défaut et l’état des feature gates employés par le cluster.

Constituez un inventaire versionné du système d’exploitation, du kernel, du runtime CRI, du CNI, du CSI, de l’ingress controller, de cert-manager, des opérateurs et des outils de sauvegarde. Vérifiez, dans les matrices de leurs éditeurs, leur compatibilité avec Kubernetes 1.36 ; une version aujourd’hui fonctionnelle n’est pas nécessairement validée pour cette cible.

Recherchez les API dépréciées dans les manifests Git, Helm charts, Kustomize, CRD et outils CI/CD.
Relevez les feature gates de l’API server, du scheduler, du controller manager et du kubelet.
Contrôlez les changements de kubeadm relatifs aux certificats, à l’image de pause et au bootstrap.
Vérifiez explicitement le support de la cible par le CNI, le CSI, les opérateurs et les contrôleurs d’ingress.

Respectez la version skew policy : un kubelet ne doit jamais être plus récent que l’API server. Sur VPS, contrôlez aussi le kernel fourni, les cgroups, les modules réseau, le MTU et les règles de pare-feu ; évitez de combiner cette migration avec une mise à jour de kernel ou de firmware.

Rejouez les déploiements depuis Git sur une recette en 1.36 et testez les opérations de stockage utiles à vos applications : création, montage, expansion, snapshot et restauration. Vérifiez également les CronJobs, PodDisruptionBudgets, NetworkPolicies, Ingress et règles RBAC, ainsi que les contrôleurs qui créent des ressources Kubernetes.

Exécuter un roulage contrôlé

Avant l’intervention, exportez la configuration, sauvegardez etcd selon votre architecture et vérifiez une restauration. Assurez-vous que les PodDisruptionBudgets permettent les drains et que les replicas peuvent être placés sur les autres nœuds.

Mettez à jour le plan de contrôle dans l’ordre prévu par votre méthode d’installation ; avec kubeadm, suivez la procédure kubeadm officielle.
Traitez les workers un par un : cordon, drain contrôlé, mise à jour de kubelet et du runtime si nécessaire, redémarrage, puis validation.
Entre chaque nœud ou lot, contrôlez l’état Ready, les pods non relançables, les erreurs CSI, le DNS, la latence applicative et la saturation CPU ou mémoire.

Pour plusieurs control planes gérés par kubeadm, appliquez aussi les précautions de la documentation sur la haute disponibilité. Arrêtez le roulage et analysez l’écart avant de poursuivre si les contrôles ne sont pas conformes.

Valider après la migration

Ne clôturez pas l’opération parce que les nœuds sont Ready. Sur une période représentative, examinez les erreurs des composants de contrôle, les événements Kubernetes, les redémarrages de conteneurs, les volumes bloqués et les alertes réseau.

Supprimez les objets dépréciés détectés, revoyez les droits RBAC trop larges et confirmez l’application des politiques réseau attendues. La documentation de sécurité Kubernetes fournit un cadre, à adapter à vos flux réels.

Après stabilisation, mesurez les demandes et limites CPU/mémoire avant tout ajustement de capacité. Documentez enfin la version cible, les versions des add-ons, les écarts observés et la durée réelle de l’opération.