Faire tourner un seul cluster Kubernetes est un problème résolu. En faire tourner quatre-vingts ne l’est pas. Chacun réclame les mêmes vingt-deux addons, dans des versions légèrement différentes. C’est donc là que la plupart des équipes plateforme commencent à souffrir. D’après le guide Kubernetes Fleet Management 2026 de Portainer, 48 % des spécialistes s’attendent à voir leur nombre de clusters croître de plus de 50 % en un an. 28 % de plus tablent sur une croissance de 20 à 50 %. À ce rythme, la livraison d’addons cesse d’être une corvée de scripting. Elle devient un problème de gouvernance. Cet article détaille un pattern concret. Vous regroupez les clusters dans une hiérarchie de flotte, puis vous y promouvez les addons palier par palier avec Sveltos. Les leçons proviennent de la plateforme Kubernetes interne d’un grand constructeur automobile européen.

À retenir

  • Une hiérarchie de flotte (chaîne de valeur, criticité, périmètre, environnement) permet de cibler les déploiements d’addons par requête plutôt que cluster par cluster.
  • Les sélecteurs de labels des ClusterProfile Sveltos, combinés aux chaînes dependsOn, offrent une promotion ordonnée et progressive, du dev jusqu’aux paliers de production.
  • Les annotations par cluster jouent le rôle de coupe-circuit auditable pour un addon isolé, sans toucher aux labels de déploiement à l’échelle de la flotte.
  • GKE refuse toute fenêtre de maintenance de moins de 4 heures consécutives : dérivez une seule fenêtre et projetez-la dans chaque sous-système.
  • 93 % des équipes plateforme en entreprise signalent des défis majeurs de coûts cloud (Portainer 2026), que le déploiement progressif aide à contenir.

Pourquoi la gestion d’addons à l’échelle d’une flotte s’effondre-t-elle ?

La livraison d’addons à l’échelle d’une flotte s’effondre parce que les deux stratégies évidentes échouent. Le guide 2026 de Portainer fait état de 42 % d’adoption de GitOps et de 35 % de multi-cloud. Pourtant, la plupart des équipes poussent encore leurs addons de l’une de deux manières : d’un coup, ou cluster par cluster. D’un coup, vous misez tous les clusters sur un seul chart. À l’inverse, le cluster par cluster est lent, manuel et dérive.

La voie médiane, c’est le déploiement progressif. Mais le déploiement progressif exige de la structure. Supposons que vous vouliez livrer la version N+1 de Kyverno d’abord à vos clusters de dev les moins critiques. Vous ne le pouvez pas, à moins que ces clusters ne portent déjà des labels de criticité et d’environnement. Sans cette taxonomie, chaque décision de promotion revient à un humain qui lit un tableur. D’expérience, faire l’impasse sur cette structure finit mal. Dans notre flotte, nous en avons découvert le coût le jour où une mise à niveau du moteur de politiques a cassé l’admission sur un cluster de production. Ce cluster n’aurait jamais dû figurer dans la première vague. Résultat : nous avons cessé de promouvoir quoi que ce soit à la main et bâti la hiérarchie qui suit.

Le guide de Portainer résume l’enjeu : avec 48 % des spécialistes qui s’attendent à une croissance de plus de 50 % du nombre de clusters en un an, et seulement 42 % sur GitOps et 35 % en multi-cloud, la livraison d’addons manuelle et cluster par cluster devient intenable pour les équipes plateforme (Portainer, 2026). Une telle structure est le socle de toute plateforme interne ; nous détaillons la conception du control plane sous-jacent dans notre guide pour construire un Kubernetes as a service.

Qu’est-ce qu’une hiérarchie de clusters en flotte ?

Une hiérarchie de clusters en flotte est un regroupement imbriqué de clusters exprimé sous forme de labels. N’importe quel sous-ensemble peut alors être ciblé comme une seule requête. Au lieu d’étiquettes à plat, vous imbriquez des niveaux : chaîne de valeur, puis criticité, puis type de cluster, puis périmètre, puis environnement. Chaque cluster appartient à exactement une flotte de chaîne de valeur. Et cette flotte imbrique des flottes enfants en dessous.

Les niveaux de la hiérarchie

Dans la pratique, les niveaux se lisent de haut en bas. La chaîne de valeur correspond à une unité métier. La criticité vaut Standard, Critical ou Strategic. Le type de cluster distingue les nœuds standard des nœuds autopilot. Le périmètre sépare Workload, Control Plane et Edge. Enfin, l’environnement vaut Dev, Int ou Ope. Un même cluster porte tous ces éléments sous forme de labels sur son objet SveltosCluster, plus un label par addon activé.

Cette stratification complète les primitives de flotte de GKE Enterprise plutôt qu’elle ne les remplace. Google vous fournit les Scopes, les Team Scopes, les Fleet Namespaces et le Rollout Sequencing pour l’ordonnancement des mises à jour du parent vers l’enfant. Par-dessus, l’équipe plateforme superpose sa propre taxonomie de chaîne de valeur et de criticité. Pourquoi s’en donner la peine ? Parce que la criticité métier n’est pas quelque chose que le modèle de regroupement de GKE connaît. Et pour des flottes d’entreprise réparties entre régions européennes et nord-américaines, c’est cette taxonomie métier qui décide de l’ordre de déploiement, pas la seule géographie.

Enregistrer un cluster dans la flotte

Avant que le moindre étiquetage n’ait de l’importance, un cluster doit rejoindre la flotte. D’abord, une fois son infrastructure prête, un contrôleur localise ou crée un secret kubeconfig. Ensuite, il applique un RBAC de bootstrap directement dans le cluster de charge. Ce RBAC reste minimal : un namespace projectsveltos, un compte de service et un cluster role limité aux kinds que les addons manipulent. Enfin, le contrôleur crée l’objet SveltosCluster dans le cluster de management. Le démantèlement exécute cette séquence en sens inverse. Trompez-vous d’ordre et vous corrompez l’état de la flotte. C’est précisément l’une des défaillances les plus courantes à l’échelle, et nous y reviendrons.

En interne, Sveltos cible les clusters à l’aide de sélecteurs de labels ClusterProfile et prend en charge le déploiement ordonné avec des chaînes de dépendances et le Secure Pull Mode ; il est désormais intégré au projet CNCF k0rdent maintenu par Mirantis (projectsveltos.io, 2026). Ce sont ces primitives qui rendent une hiérarchie de flotte imbriquée interrogeable et sûre à déployer.

Comment la promotion progressive fait-elle circuler les addons entre les paliers de la flotte ?

La promotion progressive fait circuler une version d’addon à travers les paliers de la flotte par vagues. Elle n’élargit le rayon d’impact qu’à mesure que la confiance grandit. Vous exprimez chaque vague sous la forme d’un ClusterProfile Sveltos dont le sélecteur correspond à un palier. Puis vous chaînez les profils avec dependsOn, pour qu’un palier plus avancé ne se déploie jamais tant que son prédécesseur n’est pas sain.

Cluster API v1.12, publié en janvier 2026, a ajouté les mises à jour in-place et les mises à niveau chaînées multi-versions qui complètent cette progression au niveau des addons (Cluster API Book, 2026).

ClusterProfile avec dépendances

Le mécanisme tient en deux profils et une arête de dépendance. Le profil du palier de dev sélectionne les clusters étiquetés pour l’environnement le moins critique. Le profil de staging en dépend. Sveltos déploie donc d’abord la dépendance, puis ne poursuit que lorsqu’elle se déclare saine.

apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
  name: kyverno-dev
spec:
  clusterSelector:
    matchExpressions:
      - key: platform.example.io/criticality
        operator: In
        values: ["Standard"]
      - key: platform.example.io/environment
        operator: In
        values: ["Dev"]
  helmCharts:
    - repositoryURL: https://kyverno.github.io/kyverno
      chartName: kyverno/kyverno
      chartVersion: "3.2.6"
      releaseName: kyverno
      releaseNamespace: kyverno
---
apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
  name: kyverno-staging
spec:
  dependsOn:
    - kyverno-dev
  clusterSelector:
    matchExpressions:
      - key: platform.example.io/criticality
        operator: In
        values: ["Standard"]
      - key: platform.example.io/environment
        operator: In
        values: ["Int"]
  helmCharts:
    - repositoryURL: https://kyverno.github.io/kyverno
      chartName: kyverno/kyverno
      chartVersion: "3.2.6"
      releaseName: kyverno
      releaseNamespace: kyverno

Pour promouvoir, vous relevez la version du chart sur le profil de dev. Vous la regardez se poser, puis vous relevez le staging, puis la production. Chaque palier est un commit git distinct. Résultat : vous obtenez une piste d’audit propre et un point de rollback naturel. Par exemple, supposons que vous exploitiez 40 clusters répartis sur trois paliers. Un chart défectueux ne touche désormais que votre poignée de clusters de dev, pas les 40 d’un coup. C’est le pattern GitOps hub-and-spoke basé sur des agents que ITNEXT a documenté comme une approche émergente avec Sveltos en avril 2026.

Comment activer ou désactiver un seul addon sur un cluster ?

Vous activez ou désactivez un seul addon par cluster à l’aide d’une annotation, et non en modifiant les labels de flotte. Le pattern est addons.example.io/enable-<addon-name>: "false" sur la ressource du cluster. Un webhook la valide. Chaque addon par défaut le prend en charge. Et l’annotation ne fait jamais que désactiver, si bien qu’elle sert de coupe-circuit rapide et auditable pour un addon qui se comporte mal sur un cluster donné.

L’annotation d’activation

La distinction compte. Les labels de flotte décident quel palier reçoit quelle version d’addon. L’annotation décide si un cluster précis reçoit ou non un addon donné. Deux axes différents. Ne les confondez donc jamais.

apiVersion: platform.example.io/v1alpha1
kind: StandardCluster
metadata:
  name: vs1-workload-ope-03
  annotations:
    # Disable a single addon on this cluster only
    addons.example.io/enable-otel-collector: "false"
    # Pause all Sveltos reconciliation for manual debugging
    sveltos.example.io/pause: "true"
spec:
  # ...

Un webhook rejette toute annotation qui nomme un addon inconnu ou porte une valeur non booléenne. La plateforme réserve aussi délibérément ce contrôle aux opérateurs. L’API publique ne peut pas positionner ces annotations. Et le serveur les rejette explicitement, quand bien même la forme de la requête ne peut pas les transporter aujourd’hui. Pourquoi s’en donner la peine ? C’est une précaution redondante contre un futur changement qui transformerait par accident un contrôle d’opérateur en contrôle d’utilisateur final. L’annotation sveltos.example.io/pause est une trappe de sortie distincte. Elle interrompt entièrement la réconciliation, pour qu’un ingénieur puisse déboguer directement. Puis vous levez la pause pour reprendre GitOps.

Piège : N’utilisez pas l’annotation de pause comme mécanisme de configuration durable. Un cluster en pause dérive silencieusement de la référence de la flotte, et plus il reste en pause, plus la réconciliation devient surprenante quand vous la levez. Traitez la pause comme une session de débogage, qui se mesure en minutes, pas en jours.

Comment coordonner les fenêtres de maintenance entre les couches ?

Vous coordonnez les fenêtres de maintenance en dérivant une seule fenêtre logique à partir d’une source de vérité unique. Puis vous la projetez dans chaque sous-système. Un cluster exécute la propre politique de maintenance de GKE, l’ActiveWindow de Sveltos et le calendrier de rééquilibrage d’un autoscaler. Chacun utilise un format différent. Configurez-les séparément et ils divergent. Dérivez donc une fois, projetez trois fois.

Le piège du minimum de 4 heures de GKE

C’est l’échec qui fait retenir la leçon. Dans notre flotte, notre premier réglage par défaut utilisait une fenêtre de deux heures, de 02 h 00 à 04 h 00 heure de Paris. Nous n’attendions aucun souci. Pourtant, GKE l’a refusée sans détour en production.

Error 400: Error validating maintenance policy: maintenance policy would go longer
than 32d without 48h maintenance availability of >= 4h contiguous duration

GKE exige que chaque fenêtre de maintenance récurrente dure au moins quatre heures consécutives. Cela vaut indépendamment du cumul d’heures mensuel. Le correctif a donc porté le réglage par défaut à 02 h 00 – 06 h 00 heure de Paris. Plus important, il a ajouté une validation côté serveur d’API qui rejette toute fenêtre de moins de quatre heures au moment de la requête. Cela transforme une lente boucle d’échec à l’exécution en une erreur immédiate et lisible.

Piège : Validez contre le consommateur en aval le plus strict à la frontière de l’API, pas seulement au niveau du format. Un horodatage RFC3339 peut être parfaitement bien formé et décrire malgré tout une fenêtre que GKE refusera. Le contrôle de durée doit vivre là où la requête entre, pas là où elle finit par échouer.

Il y a un second piège ici. Il nous a fallu trois tentatives pour le régler correctement. Supposons que vous imposiez une ActiveWindow Sveltos sur un cluster tout neuf, et que la création se produise en dehors de la fenêtre. Sveltos refuse alors de déployer les addons, et le cluster n’atteint jamais l’état ready. Notre premier correctif était trop fragile, et le deuxième courait encore une course sur une seconde réconciliation. Le correctif qui a tenu comporte donc deux volets. Premièrement, ne fixer la fenêtre qu’une fois que chaque addon se déclare provisionné. Deuxièmement, rendre la fenêtre opt-in par cluster plutôt qu’active par défaut. La plupart des clusters n’ont pas besoin de cette contrainte. En parallèle, un réglage par défaut silencieux réintroduit l’interblocage pour quiconque ne sait pas qu’il faut le désactiver.

Comment faire remonter l’état des addons à l’échelle de la flotte ?

Vous faites remonter l’état des addons en lisant les enregistrements de déploiement par cluster que Sveltos écrit déjà. Pour chaque couple profil-cluster, Sveltos crée un ClusterSummary. Il contient la méthode de déploiement et l’état par ressource. Les lire directement nécessite un accès au cluster. La plateforme expose donc plutôt une API typée. Elle liste les addons, résout leur type et reconstruit le graphe de dépendances pour une vue de santé de la flotte.

Bien construire ce modèle de lecture repose sur la même discipline de fraîcheur du cache qui garde les contrôleurs Kubernetes fiables : l’état que vous exposez ne vaut que par la dernière réconciliation observée.

Lire correctement un ClusterSummary

Deux détails vous évitent des sorties confuses. Primo, le nom d’affichage d’un addon Helm doit provenir du nom du chart. N’utilisez pas le nom du ClusterProfile, qui est souvent un hash généré comme falco-install-4fcf3b5d. Secundo, le graphe de dépendances doit s’indexer sur le nom du profil, pas sur le nom d’affichage, parce que les arêtes dependsOn référencent l’identifiant stable. Trompez-vous sur l’un ou l’autre, et votre vue d’état affichera les bonnes données sous les mauvais libellés.

Ce modèle de lecture transforme donc « j’espère que le déploiement a fonctionné » en quelque chose de concret : « le palier de staging montre tous les addons provisionnés, on promeut en production ». De plus, pour des équipes qui opèrent à travers l’Europe et l’Amérique du Nord, un récapitulatif unique de santé de la flotte supprime le besoin de raisonner à la main sur chaque cluster régional.

Qu’est-ce qui casse en production, et comment l’éviter ?

Les deux défaillances qui coûtent le plus de temps sont les collisions de noms et le démantèlement non sécurisé. Ni l’une ni l’autre n’apparaît dans une démo. Les deux apparaissent à l’échelle. Et avec 93 % des équipes plateforme en entreprise qui signalent des défis majeurs de coûts cloud (Portainer 2026), la dernière chose que vous voulez, c’est un état d’addon orphelin qui consomme discrètement des ressources après une suppression ratée.

La collision de longueur de nom

Sveltos construit le nom d’un ClusterSummary en accolant le nom du cluster au nom du profil. Donc, si votre template de déclencheur d’événement embarque lui aussi le nom du cluster, vous le dupliquez. La chaîne combinée peut alors dépasser la limite de 63 caractères des labels Kubernetes. Nous l’avons découvert en production le jour où un nom de cluster plus long a fait passer un profil jusque-là correct au-dessus de la limite. L’erreur est brutale : metadata.labels: Invalid value ... must be no more than 63 characters. Le correctif est simple une fois qu’on le connaît. Concrètement, ne mettez jamais le nom du cluster dans votre template de nom de profil, parce que Sveltos l’ajoute déjà une fois.

Démanteler un SveltosCluster en toute sécurité

Supprimer un SveltosCluster d’un coup, ou effacer tous ses labels, peut corrompre l’état de Sveltos et laisser des addons échoués. Nous l’avons appris lors d’un vrai démantèlement, où c’est l’approche par retrait des labels qui nous a évité des addons orphelins. La séquence sûre comporte quatre étapes. D’abord, ne retirer que les labels qui pilotent la correspondance des profils. Ensuite, attendre que chaque ClusterSummary de ce cluster disparaisse, à mesure que Sveltos retire chaque addon. Dans la pratique, cela prend jusqu’à environ cinq minutes. Si un finalizer reste bloqué après le délai, forcez sa suppression. Ce n’est qu’alors que vous supprimez le SveltosCluster. Retirer d’abord les labels, plutôt que supprimer l’objet, laisse les sélecteurs cesser de correspondre naturellement. Résultat : Sveltos exécute son propre chemin de retrait gracieux.

Sveltos prend en charge les déploiements ordonnés avec des chaînes de dépendances et le Secure Pull Mode, et il est intégré au projet k0rdent de la CNCF (projectsveltos.io, 2026). Ces mêmes arêtes de dépendance qui orchestrent un déploiement gouvernent aussi l’ordre de démantèlement, de sorte que retirer les labels de sélecteur laisse Sveltos retirer les addons gracieusement au lieu de les rendre orphelins.

Conclusion

La gestion d’addons à l’échelle d’une flotte est en réalité un problème d’étiquetage et d’ordonnancement déguisé en costume Kubernetes. Une fois que les clusters portent une hiérarchie imbriquée de chaîne de valeur, criticité, périmètre et environnement, tout change. « Promouvoir cet addon » devient une requête que vous élargissez délibérément, pas un tableur que vous entretenez à la main. Les sélecteurs de ClusterProfile et les chaînes dependsOn de Sveltos vous donnent l’ordonnancement. Les annotations par cluster vous donnent le coupe-circuit. Et une fenêtre de maintenance unique et dérivée maintient GKE, Sveltos et l’autoscaler d’accord. Avec 48 % des équipes qui s’attendent à voir leurs clusters croître de plus de 50 % en un an (Portainer, 2026), les équipes qui construisent cette structure tôt gardent le contrôle à mesure que la flotte se multiplie. Pour la pratique plus large dans laquelle tout cela s’inscrit, voyez notre guide du platform engineering à l’échelle. Commencez donc par la hiérarchie. Puis laissez la promotion progressive faire le reste.

Réponses directes

Questions fréquentes

Ai-je besoin de Cluster API pour utiliser Sveltos pour les addons de flotte ?

Non. Sveltos cible n'importe quel cluster enregistré via des sélecteurs de labels, qu'il vienne de Cluster API, de GKE ou d'un enregistrement manuel. Cluster API v1.12, publié en janvier 2026, ajoute les mises à niveau in-place et chaînées qui se marient bien avec la progression des addons (Cluster API Book, 2026). Mais Sveltos lui-même n'a besoin que d'un objet SveltosCluster portant les bons labels.

En quoi la promotion progressive diffère-t-elle d'un déploiement canari ?

Les déploiements canari répartissent le trafic au sein d'un même cluster pour tester une nouvelle version d'application. La promotion progressive fait circuler un addon entre les paliers de clusters, du dev au staging puis à la production. Elle utilise des chaînes dependsOn, pour qu'un palier plus avancé attende qu'un palier antérieur se déclare sain. L'un teste du code applicatif, l'autre des addons de plateforme.

Que se passe-t-il si un addon échoue en cours de promotion ?

Parce que chaque palier est un ClusterProfile distinct verrouillé par dependsOn, une défaillance sur un palier précoce empêche les paliers suivants de se déployer. Les paliers sains conservent leur version qui fonctionne. Vous corrigez le chart, vous committez, et le pipeline reprend à partir du palier en échec. Une mauvaise version n'atteint jamais automatiquement la production.

Puis-je mélanger GKE et d'autres fournisseurs dans une même flotte ?

Oui, et les flottes d'entreprise réparties entre l'Europe et l'Amérique du Nord le font couramment. Sveltos abstrait le cluster derrière son jeu de labels SveltosCluster, donc un sélecteur de ClusterProfile correspond aux clusters quel que soit le fournisseur. La projection de la fenêtre de maintenance est spécifique au fournisseur, mais la logique de promotion des addons reste identique partout.