Kubernetes est open source, et exploiter votre propre cluster est un choix légitime. Ce qui mérite un examen détaillé, c'est ce qu'un cluster de production exige de vous en continu — en s'appuyant sur la documentation et la politique de versions du projet Kubernetes lui-même, et non sur des arguments marketing.
Chaque version de Kubernetes a une date d'expiration
Le projet Kubernetes maintient des branches de version pour les trois versions mineures les plus récentes. Chaque version mineure bénéficie d'environ quatorze mois de support des correctifs : douze mois de support standard, puis deux mois de maintenance, à l'issue desquels la série atteint sa fin de vie et ne reçoit plus de correctifs.
En septembre 2026, les versions mineures activement maintenues sont 1.37, 1.36 et 1.35. La version 1.34 est dans sa dernière fenêtre de maintenance et atteint sa fin de vie le 27 octobre 2026. La version 1.33 a déjà atteint sa fin de vie le 28 juin 2026.
Prendre du retard coûte cher, car les mises à niveau ne peuvent pas sauter de version mineure. La politique de compatibilité des versions impose à kube-apiserver de progresser d'une version mineure à la fois, même dans les clusters à instance unique. Un cluster encore en 1.33 nécessite donc quatre mises à niveau successives du plan de contrôle — 1.34, 1.35, 1.36 puis 1.37 — pour être à jour, et chacune demande sa propre préparation, par exemple vérifier que vos webhooks d'admission savent traiter les versions d'API que le nouveau serveur leur envoie.
Les nœuds ajoutent leur propre charge de travail. Les mises à niveau mineures sur place de kubelet ne sont pas prises en charge : chaque nœud doit d'abord être drainé. Un kubelet peut avoir jusqu'à trois versions mineures de retard sur le serveur d'API, mais la documentation avertit qu'un cluster dont les kubelets restent durablement trois versions en arrière doit les mettre à niveau avant même de pouvoir faire évoluer le plan de contrôle.
La haute disponibilité est une architecture dont vous êtes responsable
Un seul nœud de plan de contrôle est un point de défaillance unique. Le guide de haute disponibilité de kubeadm décrit deux topologies. Dans la topologie empilée par défaut, chaque nœud de plan de contrôle exécute aussi un membre etcd : perdre un nœud fait donc perdre à la fois une instance du plan de contrôle et un membre etcd ; la documentation demande d'exécuter au moins trois nœuds de plan de contrôle empilés. L'alternative, etcd externe, sépare les deux mais exige au minimum trois hôtes de plan de contrôle plus trois hôtes etcd.
etcd a besoin d'un quorum — une majorité de ses membres — pour accepter des modifications. Un cluster de trois membres tolère la défaillance d'un membre et un cluster de cinq membres en tolère deux, tandis qu'ajouter un quatrième membre n'apporte aucune tolérance aux pannes supplémentaire. La documentation Kubernetes recommande un nombre impair de membres et un cluster de cinq membres en production.
etcd est également sensible à l'environnement dans lequel il s'exécute :
- Disque et réseau. Les performances d'etcd dépendent des E/S disque et réseau. Une pénurie de ressources peut provoquer des dépassements de délai de heartbeat et laisser le cluster sans leader — or un cluster sans leader ne peut plus modifier son état, ce qui signifie qu'aucun nouveau pod ne peut être planifié.
- Ressources dédiées. La documentation conseille d'exécuter etcd sur des machines dédiées ou des environnements isolés afin de garantir ses besoins en ressources, et la FAQ d'etcd recommande vivement les SSD.
- Accès équivaut à root. L'accès à etcd équivaut à des droits root sur le cluster : idéalement, seul le serveur d'API doit pouvoir l'atteindre, protégé par des certificats TLS x509.
Une sauvegarde ne compte qu'une fois restaurée
La documentation Kubernetes est directe : si votre cluster utilise etcd comme stockage de référence, assurez-vous d'avoir un plan de sauvegarde des données. Concrètement, cela signifie des instantanés planifiés réalisés avec etcdctl, stockés à un endroit qui ne partage pas de domaine de défaillance avec le cluster, et une procédure de restauration avec etcdutl que quelqu'un a réellement répétée.
Les instantanés demandent aussi un traitement rigoureux, car ils contiennent tout ce que connaît le serveur d'API. Par défaut, le serveur d'API stocke les ressources dans etcd en texte clair, sans chiffrement au repos, tant que vous ne le configurez pas. Un instantané d'un cluster non chiffré peut donc emporter vos Secrets avec lui.
Les certificats expirent selon un calendrier
Les certificats clients générés par kubeadm expirent au bout d'un an. kubeadm les renouvelle automatiquement lorsque vous mettez à niveau le plan de contrôle : un cluster mis à niveau au moins une fois par an est donc pris en charge — et un cluster qui reste plus d'un an sans mise à niveau ne l'est pas. Vous pouvez vérifier les échéances avec kubeadm certs check-expiration et renouveler manuellement avec kubeadm certs renew all, commande qui, sur un plan de contrôle répliqué, doit être exécutée sur chaque nœud de plan de contrôle.
Les modules complémentaires sont des projets distincts, avec des cycles de vie distincts
Un cluster ne se résume pas à son plan de contrôle. Le réseau, l'ingress ou Gateway API, les pilotes de stockage, la gestion des certificats, les métriques et la supervision sont des projets distincts, chacun avec son propre cycle de publication, ses versions et ses dates de fin de vie. Sur un cluster auto-hébergé, les suivre tous est votre responsabilité.
En novembre 2025, le projet Kubernetes a annoncé le retrait d'Ingress NGINX, l'un des contrôleurs d'ingress les plus utilisés. La maintenance au mieux des efforts a pris fin en mars 2026 : il n'y a plus de nouvelles versions, de corrections de bogues ni de mises à jour de sécurité. Les déploiements existants continuent de fonctionner et les artefacts restent disponibles, mais toute vulnérabilité découverte par la suite ne sera pas corrigée. En janvier 2026, les comités Steering et Security Response de Kubernetes l'ont décrit comme une infrastructure critique pour environ la moitié des environnements cloud native et ont appelé à migrer vers Gateway API ou un autre contrôleur.
Le guide de migration du projet ajoute une mise en garde : Ingress NGINX a des comportements implicites, et une traduction qui semble correcte peut tout de même provoquer des pannes. Rien de tout cela n'est un défaut de Kubernetes. C'est la vie normale d'un grand écosystème open source — et précisément le travail qu'un cluster auto-hébergé fait peser sur votre équipe.
Comparaison côte à côte
| Catégorie | Auto-hébergé | Cluster géré Kube-DC |
|---|---|---|
| Cycle de vie des versions | Vous suivez les dates de publication et de fin de vie et mettez à niveau une version mineure à la fois, avec environ quatorze mois de support par version mineure | Mises à niveau progressives contrôlées par le tenant : le plan de contrôle et les pools de workers évoluent séparément, par étapes. Vous choisissez toujours la version cible et le moment |
| Plan de contrôle | Trois nœuds de plan de contrôle ou plus à concevoir, sécuriser et corriger vous-même | Des plans de contrôle hébergés s'exécutent comme des pods gérés sur la plateforme : vous obtenez votre propre API Kubernetes et une PKI par cluster sans exploiter de masters |
| etcd | Dimensionnement du quorum, disques dédiés, TLS, défragmentation et supervision sont à votre charge | Un datastore dédié ou partagé géré par la plateforme, avec mise à l'échelle verticale automatique du plan de contrôle et d'etcd activée par défaut |
| Sauvegardes | Vous concevez le calendrier des instantanés, le stockage et les exercices de restauration | Instantanés etcd planifiés, configurés par cluster, avec chiffrement par enveloppe en option, et restauration — en libre-service pour les datastores à réplique unique, assistée pour les datastores multi-répliques. Les instantanés sont stockés dans le stockage S3 du projet sur la plateforme : conservez donc votre propre copie hors plateforme si vous en avez besoin en dehors du domaine de défaillance du stockage de la plateforme |
| Certificats | Certificats kubeadm valables un an, renouvelés lors des mises à niveau ou par vous | PKI par cluster et certificats TLS etcd provisionnés automatiquement avec le cluster |
| Nœuds de travail | Vous provisionnez, imagez, corrigez et remplacez les nœuds | Pools de workers dimensionnés par pool (CPU, mémoire, disque, image), avec des limites de mise à l'échelle automatique par pool |
| API de métriques | Vous installez et maintenez metrics-server | Préinstallé et fonctionnel lors de notre propre test de bout en bout d'août 2026 |
| Délai avant le premier cluster | De quelques heures à quelques jours de mise en place, plus la maintenance continue | Créé depuis un projet dans le portail ou avec un seul manifeste ; la documentation de la plateforme décrit un provisionnement en quelques minutes |
| Astreinte | Votre équipe | Support par e-mail et ticket 24h/24 et 7j/7 avec un objectif de résolution de 4 heures (MTTR), inclus dans le prix |
| Ce qui reste à votre charge | Tout, du matériel aux charges de travail | Vos charges de travail, le contrôle d'accès et les modules complémentaires que vous installez dans votre cluster — c'est un cluster Kubernetes complet, administré par le tenant |
Quand l'auto-hébergement est le bon choix
Si votre équipe exploite déjà etcd en production, suit les notes de version de Kubernetes et de ses modules complémentaires, répète ses restaurations et assure une astreinte, l'auto-hébergement est une extension raisonnable de pratiques existantes. C'est aussi le bon choix lorsque vous avez besoin d'un contrôle qu'un service géré ne peut pas offrir, comme une configuration personnalisée du plan de contrôle ou un environnement entièrement isolé. Pour une équipe qui ne dispose pas déjà de cette capacité, chaque section ci-dessus devient un travail nouveau et continu.
Sources
- Kubernetes releases and patch support policy
- Kubernetes patch releases: support period
- Kubernetes version skew policy
- kubeadm: options for highly available topology
- Operating etcd clusters for Kubernetes
- etcd FAQ: cluster size and failure tolerance
- Encrypting confidential data at rest
- Certificate management with kubeadm
- Ingress NGINX retirement: what you need to know
- Ingress NGINX: statement from the Steering and Security Response Committees
- Kube-DC platform datasheet
Découvrir la plateforme
Cloud Acropolis Kube-DC vous donne vos propres clusters Kubernetes administrés par le tenant — plans de contrôle hébergés, pools de workers et mises à niveau progressives — sur des vCPU dédiés, un stockage NVMe reposant sur Ceph, une IPv4 publique dédiée et un stockage objet compatible S3. Vous commandez et gérez tout dans un portail en libre-service, avec un support par e-mail et ticket 24h/24 et 7j/7 et un objectif de résolution de 4 heures inclus. Chaque forfait comprend des clusters Kubernetes imbriqués, et le GPU partagé est disponible en option.
Découvrir Kube-DC Kubernetes