Kubernetes 1.34 : faut-il mettre à jour vos serveurs ?

Kubernetes 1.34 : une mise à jour à évaluer, pas à appliquer par réflexe

Kubernetes 1.34 est une version mineure qui peut apporter des améliorations pertinentes pour l’exploitation quotidienne d’un cluster. Pour autant, la bonne question n’est pas seulement « quelles nouveautés sont disponibles ? », mais bien : cette version résout-elle un besoin concret de mon infrastructure, sans introduire un risque disproportionné ?

Sur un VPS ou un serveur dédié, Kubernetes n’est jamais isolé. Sa mise à jour touche potentiellement le plan de contrôle, les nœuds de calcul, le runtime de conteneurs, le plugin réseau CNI, le stockage CSI, les outils de sauvegarde et les chaînes de livraison continue. Une incompatibilité dans l’un de ces éléments peut avoir davantage d’impact qu’une amélioration fonctionnelle apportée par la nouvelle version.

Kubernetes publie une version mineure selon un cycle régulier, et le projet maintient généralement les trois dernières versions mineures. Cette politique ne signifie pas qu’il faut passer à chaque version dès sa sortie : elle donne surtout un cadre pour éviter de conserver un cluster hors support trop longtemps. Les règles officielles de compatibilité entre composants sont détaillées dans la version skew policy de Kubernetes.

Pour un environnement de production, Kubernetes 1.34 mérite donc une mise à niveau rapide dans trois cas :

votre version actuelle approche de la fin de support communautaire ;
vous avez besoin d’une évolution précise de la gestion des ressources ou du matériel ;
votre cycle de maintenance prévoit déjà une montée de version du système, du runtime ou de vos composants Kubernetes.

À l’inverse, un cluster stable, correctement supporté et peu dépendant des fonctionnalités introduites par cette version peut attendre quelques semaines. Cela laisse le temps aux distributions, opérateurs, pilotes CSI et CNI de publier leurs matrices de compatibilité et leurs correctifs éventuels.

Kubernetes 1.34 : les changements qui comptent pour l’infrastructure

Le changelog complet de Kubernetes 1.34 est conséquent. Les administrateurs de serveurs n’ont toutefois pas besoin d’en faire une lecture ligne par ligne avant de décider : quelques sujets ont une influence plus directe sur la capacité, les workloads et l’exploitation.

Les ressources définies au niveau du Pod

Kubernetes 1.34 introduit en bêta la possibilité de définir des demandes et limites de CPU et de mémoire au niveau du Pod, via la fonctionnalité Pod-level resources. Jusqu’ici, les ressources étaient habituellement déclarées conteneur par conteneur. Cette évolution permet de fixer une enveloppe globale pour un Pod et de mieux répartir les ressources entre ses conteneurs.

Le sujet est utile pour les Pods composés d’une application principale et de plusieurs conteneurs auxiliaires : proxy, collecteur de logs, agent de métriques ou sidecar de service mesh. Dans ce type d’architecture, chaque conteneur n’utilise pas nécessairement son maximum de CPU ou de mémoire au même moment. Une enveloppe au niveau du Pod peut donc être plus proche de la consommation réelle.

Mais cette souplesse demande de la prudence. Les politiques de quotas, les LimitRange, les tableaux de bord de capacité et certains contrôleurs internes peuvent reposer sur des hypothèses établies avec des ressources déclarées conteneur par conteneur. Avant d’activer ou d’utiliser cette possibilité, il faut vérifier son comportement avec vos règles d’admission et vos outils d’observabilité. La documentation officielle présente les ressources au niveau du Pod et leurs conditions d’utilisation.

Dynamic Resource Allocation pour les matériels spécialisés

La gestion dynamique des ressources, ou Dynamic Resource Allocation (DRA), est un autre sujet important pour les clusters qui consomment des ressources matérielles particulières : GPU, cartes réseau spécialisées, périphériques de calcul ou autres équipements exposés par un pilote adapté.

DRA s’appuie notamment sur des objets tels que les ResourceClaim afin de demander des ressources de manière plus structurée qu’avec les mécanismes historiques de ressources étendues. Il ne s’agit pas d’un bénéfice automatique pour tous les clusters : un VPS généraliste sans GPU, sans périphérique PCIe dédié et sans pilote compatible n’en tirera pas un avantage immédiat.

En revanche, cette évolution mérite une attention particulière pour un serveur dédié qui héberge des workloads d’intelligence artificielle, de rendu, de calcul scientifique ou de traitement vidéo. Dans ce contexte, la mise à jour Kubernetes doit être coordonnée avec le pilote du matériel, le runtime de conteneurs et l’opérateur éventuellement fourni par le constructeur. La documentation Kubernetes consacrée à DRA est le point de départ à consulter avant tout déploiement.

Une version qui impose aussi un travail de compatibilité

Les versions mineures de Kubernetes contiennent des ajouts, mais aussi des évolutions d’API, des dépréciations et des changements de comportements qui peuvent affecter les manifestes, les charts Helm ou les opérateurs. Ce risque est moins visible que les annonces de fonctionnalités, mais il est souvent le premier facteur de report en production.

Il faut notamment contrôler :

les API utilisées par vos manifestes, scripts et contrôleurs ;
la version de votre distribution Kubernetes : kubeadm, k3s, RKE2, Talos Linux, OpenShift ou service managé ;
la compatibilité du CNI, par exemple Cilium, Calico ou Flannel ;
la compatibilité du CSI et des pilotes de stockage ;
la prise en charge par containerd, CRI-O ou un autre runtime CRI ;
les versions des outils de sauvegarde, comme Velero, ainsi que celles de vos opérateurs.

Le guide des API dépréciées publié par Kubernetes est particulièrement utile pour auditer les manifestes avant une montée de version.

Quels gains attendre sur un VPS ou un serveur dédié ?

Une mise à jour vers Kubernetes 1.34 ne transforme pas mécaniquement un petit VPS en plateforme de production haute disponibilité. Les bénéfices dépendent de la topologie et du niveau de maturité du cluster.

Sur un VPS mono-nœud

Un cluster mono-nœud, souvent basé sur k3s ou kubeadm, est courant pour un environnement interne, une petite application SaaS ou un laboratoire. Dans ce cas, le principal intérêt de rester à jour est la sécurité, le maintien dans une fenêtre de support et la compatibilité avec l’écosystème Kubernetes.

Les bénéfices spécifiques de Kubernetes 1.34 seront généralement limités si les applications utilisent des déploiements simples, sans GPU, sans opérateurs complexes et sans forte densité de Pods. La mise à jour est néanmoins justifiée si elle évite de cumuler plusieurs versions de retard. Il est préférable d’effectuer des mises à niveau régulières et maîtrisées plutôt que de devoir franchir plusieurs versions mineures sous la contrainte.

Sur un VPS unique, le risque principal est l’interruption de service : le plan de contrôle et les workloads partagent la même machine. Il faut donc prévoir une fenêtre de maintenance, vérifier les sauvegardes et s’assurer que les données applicatives ne résident pas uniquement sur un volume local non sauvegardé.

Sur des serveurs dédiés multi-nœuds

Un cluster réparti sur plusieurs serveurs dédiés peut procéder plus sereinement, à condition d’avoir une redondance réelle. Il devient possible de vider un nœud, de le mettre à jour, de le remettre en service, puis de passer au suivant. Cette méthode réduit le risque, mais seulement si les applications possèdent plusieurs réplicas et si les règles de disruption sont correctement définies.

Dans cette configuration, Kubernetes 1.34 peut apporter de la valeur si vous cherchez à améliorer le pilotage de capacité. Les ressources au niveau du Pod intéressent notamment les équipes qui opèrent des applications avec plusieurs sidecars. DRA devient également un sujet concret lorsqu’un ou plusieurs nœuds accueillent des accélérateurs matériels.

Le serveur dédié donne plus de contrôle sur le noyau Linux, les pilotes, les disques NVMe et le réseau. Cette liberté a une contrepartie : l’équipe d’exploitation porte l’entière responsabilité de la compatibilité. Avant une mise à jour, un inventaire matériel et logiciel est indispensable.

Ce que Kubernetes 1.34 ne remplace pas

Une nouvelle version d’orchestrateur ne corrige pas une mauvaise répartition des ressources, l’absence de sauvegarde ou des alertes inexistantes. Si votre cluster souffre de saturation mémoire, de volumes non redondés ou de Pods sans limites de ressources, la priorité reste l’architecture et l’exploitation.

Avant de consacrer un créneau à Kubernetes 1.34, vérifiez que vous disposez d’une supervision adaptée. Prometheus, Grafana, Alertmanager et les métriques kube-state-metrics sont des composants fréquemment utilisés pour observer l’état des nœuds, des Pods et des ressources. Pour choisir une pile cohérente avec votre contexte, consultez notre guide sur le monitoring serveur selon l’infrastructure.

Décider : mise à jour immédiate, planifiée ou reportée

La décision peut être prise avec une grille simple. Une mise à jour rapide est recommandée lorsqu’elle répond à un impératif de support, de sécurité ou de compatibilité. Une mise à jour planifiée convient à la majorité des clusters stables. Un report temporaire est raisonnable si un composant critique n’est pas encore validé.

Mise à jour prioritaire : votre version est en fin de support, un correctif requis impose une version plus récente, ou vous devez utiliser une fonctionnalité de gestion de ressources ou de matériel introduite ou stabilisée dans votre chaîne logicielle.
Mise à jour planifiée : le cluster fonctionne correctement, mais votre processus prévoit une maintenance trimestrielle ou semestrielle avec environnement de préproduction.
Attente justifiée : un pilote GPU, un CSI, un CNI, un opérateur métier ou une distribution Kubernetes ne valide pas encore la version 1.34.

Le bon critère n’est pas la nouveauté de Kubernetes, mais la capacité à revenir à un état maîtrisé si le comportement d’un composant change.

Les organisations qui exploitent plusieurs environnements peuvent aussi séparer la décision technique de la décision opérationnelle. Il est possible de valider Kubernetes 1.34 sur le cluster de développement, puis sur la préproduction, sans imposer immédiatement la même cadence à la production.

Préparer la mise à jour : compatibilité, sauvegardes et tests

Une préparation sérieuse réduit nettement le risque. Elle commence par une cartographie précise de l’existant, pas par l’exécution d’une commande de mise à niveau.

Établir l’inventaire du cluster

Relevez la version du serveur d’API, des kubelets, de kube-proxy, du runtime de conteneurs et de la distribution utilisée. Identifiez aussi les composants installés dans les espaces de noms système : CNI, CSI, ingress controller, cert-manager, ExternalDNS, outils GitOps tels qu’Argo CD ou Flux, outils de sauvegarde et opérateurs spécifiques.

Cette étape doit inclure les dépendances hors Kubernetes. Un cluster sur VPS peut, par exemple, dépendre d’un pare-feu réseau du fournisseur, d’un équilibreur de charge externe, d’un stockage objet S3 compatible ou d’un DNS administré. Le plan de reprise doit couvrir l’ensemble de la chaîne, et pas seulement les objets Kubernetes.

Contrôler les API et les manifestes

Auditez les dépôts Git contenant les manifestes YAML, les charts Helm, les overlays Kustomize et les scripts d’administration. Recherchez les anciennes versions d’API, mais aussi les composants qui manipulent directement l’API Kubernetes.

Des outils comme Pluto de Fairwinds ou kubent, aussi connu sous le nom de Kube No Trouble, peuvent aider à repérer des API dépréciées dans les ressources installées. Ils ne remplacent pas une revue manuelle : un manifeste valide peut encore être affecté par un changement de comportement, une configuration personnalisée ou une dépendance externe.

Sauvegarder ce qui doit réellement être restauré

Pour un cluster basé sur etcd, une sauvegarde cohérente d’etcd est essentielle avant toute intervention sur le plan de contrôle. Elle doit être stockée hors du serveur concerné et sa restauration doit avoir été testée. Une sauvegarde présente mais jamais restaurée ne constitue pas un plan de reprise fiable.

Il faut également sauvegarder les données applicatives. Selon votre architecture, cela peut inclure les bases PostgreSQL ou MariaDB, les volumes persistants, les fichiers déposés par les utilisateurs, les secrets gérés hors cluster et les configurations de l’infrastructure. Velero peut sauvegarder des ressources Kubernetes et, selon les fournisseurs et plugins utilisés, participer à la protection des volumes ; il ne dispense pas de vérifier la stratégie propre à chaque base de données.

La sécurisation de l’hôte reste tout aussi importante. Une mise à jour Kubernetes est un bon moment pour revoir les accès SSH, les mises à jour système, les règles pare-feu et les comptes de service. Notre article sur le durcissement Linux d’un serveur peut servir de checklist complémentaire.

Tester avec une charge représentative

Un environnement de préproduction utile doit reproduire les dépendances sensibles : même CNI, même classe de stockage, mêmes politiques réseau et versions proches des opérateurs de production. Un test qui ne déploie qu’un serveur NGINX ne valide pas une plateforme hébergeant des bases de données, des jobs asynchrones et un ingress chiffré par cert-manager.

Les tests devraient couvrir au minimum :

le déploiement et le rollback d’une application via votre chaîne CI/CD ;
la création et l’attachement d’un volume persistant ;
la résolution DNS interne et l’accès aux services externes ;
les règles NetworkPolicy si elles sont utilisées ;
l’émission ou le renouvellement de certificats ;
la restauration d’une sauvegarde ;
le comportement des alertes et tableaux de bord après la mise à niveau.

Un plan de déploiement progressif pour les nœuds

La procédure exacte dépend de votre distribution. kubeadm, k3s, RKE2 et les offres managées ne s’administrent pas de la même manière. Il faut donc suivre en priorité la documentation de votre distribution, puis respecter les règles de compatibilité amont de Kubernetes.

Sur un cluster auto-hébergé avec plusieurs nœuds, l’ordre général reste le même : mettre à jour le plan de contrôle, puis les nœuds workers un par un. Évitez de traiter simultanément tous les nœuds, même si votre automatisation le permet.

Commencer par un nœud pilote

Sélectionnez un worker non critique ou disposant de suffisamment de capacité de repli. Mettez-le en cordon pour empêcher l’arrivée de nouveaux Pods, puis évacuez les workloads avec drain. Vérifiez auparavant les PodDisruptionBudget : ils sont précisément conçus pour limiter les interruptions volontaires, et peuvent bloquer un drainage si l’application ne possède pas assez de réplicas disponibles.

Attention aux Pods qui utilisent des données locales éphémères. L’option de drainage qui supprime les données de type emptyDir est parfois nécessaire, mais elle efface ces données. Il faut savoir exactement quels workloads seront touchés avant de l’utiliser.

Après la mise à jour du nœud, contrôlez son retour à l’état Ready, l’état du runtime, le démarrage des Pods système et la capacité des applications à se reprogrammer. Attendez une période d’observation adaptée à votre trafic avant de poursuivre avec le nœud suivant.

Définir des critères d’arrêt explicites

Un plan fiable inclut des critères qui obligent à s’arrêter. Par exemple : hausse anormale des erreurs HTTP, Pods en CrashLoopBackOff, volumes qui ne se montent plus, échecs DNS, alertes de saturation mémoire ou indisponibilité d’un ingress controller.

Documentez aussi une stratégie de retour arrière réaliste. Dans Kubernetes, le downgrade n’est pas toujours une opération triviale, notamment pour le plan de contrôle et la base etcd. La meilleure protection reste donc la validation préalable, la sauvegarde testée et la progression nœud par nœud.

Les cas où il est préférable d’attendre avant Kubernetes 1.34

Reporter une mise à jour n’est pas un échec lorsqu’il repose sur des éléments techniques précis. Il est préférable d’attendre si votre CNI, votre CSI ou un opérateur critique ne publie pas de compatibilité explicite avec votre version cible. C’est particulièrement vrai pour les clusters équipés de GPU, de matériel réseau spécifique ou de stockage distribué.

Il faut également reporter si vous ne disposez pas d’une restauration validée. Une mise à jour de production sans sauvegarde d’etcd vérifiée, sans export des configurations importantes ou sans copie des données applicatives est un risque inutile.

Enfin, attendez si votre capacité est insuffisante pour évacuer un nœud. Dans un cluster à trois workers très chargés, drainer un serveur peut faire tomber sous le seuil de ressources nécessaire au maintien des réplicas. La montée de version doit alors être précédée d’une optimisation des demandes de ressources, d’un ajout temporaire de capacité ou d’une fenêtre de maintenance assumée.

Conclusion : Kubernetes 1.34 doit s’inscrire dans votre cycle d’exploitation

Kubernetes 1.34 est une évolution intéressante, notamment pour les équipes qui souhaitent mieux gérer les ressources des Pods ou exploiter du matériel spécialisé via Dynamic Resource Allocation. Pour un cluster généraliste sur VPS, son intérêt est souvent plus opérationnel que spectaculaire : rester dans une fenêtre de support, conserver la compatibilité de l’écosystème et éviter une dette de version difficile à résorber.

La décision ne doit donc pas reposer sur une liste de nouveautés. Vérifiez vos dépendances, auditez vos API, testez vos sauvegardes, validez la préproduction et déployez par étapes. Si votre infrastructure arrive à maturité ou que vous hésitez entre plusieurs modèles d’hébergement, commencez aussi par revoir les fondamentaux avec notre guide de choix entre VPS et serveur dédié.