Gestion de clusters Kubernetes multi-cloud

Outils et tableaux de bord fragmentés par cloud

Un cluster GKE sur GCP pour une unité commerciale, EKS pour une autre, un cluster RKE2 sur site pour une charge de travail réglementée, et maintenant un cluster OVHcloud pour le calcul souverain dans l'UE. Chacun de ces fournisseurs propose sa propre console, sa propre CLI, sa propre façon de faire les choses. Il n'existe aucune vue globale de l'état de santé, de la capacité ou de la politique de sécurité des clusters dans tous les environnements, seulement N fournisseurs et N ensembles d'outils, chacun nécessitant une expertise spécifique. 

La visibilité est la première victime, et toute autre tâche opérationnelle devient plus difficile sans elle. Chaque cloud supplémentaire multiplie la surface que votre équipe doit couvrir, et rien de tout cela ne rend la charge de travail applicative qui s'exécute au-dessus plus fiable.

Prolifération du RBAC et dérive de configuration entre les clusters

Le service Kubernetes géré de chaque fournisseur possède son propre modèle d'identité et d'autorisation, donc plusieurs clouds signifient plusieurs modèles. Définir une politique de sécurité cohérente pour un ingénieur, pour des développeurs ou pour un auditeur signifie répéter la même configuration dans trois ou quatre consoles et syntaxes. La dérive n'est pas un risque ici, c'est une certitude, et c'est le défi qui évolue le plus mal. Une autorisation accordée sur un cluster et oubliée sur un autre constitue une lacune de conformité qui apparaît lors d'un audit, et non avant.

La dérive s'étend bien au-delà des autorisations. Les règles de mise en réseau, les quotas de ressources, l'isolation des charges de travail et les règles d'admission qui étaient cohérentes lors de la configuration initiale divergent silencieusement à mesure que chaque cluster est corrigé, mis à niveau ou ajusté manuellement par la personne de garde. La dérive de la gouvernance de sécurité est la version la plus coûteuse : une règle de renforcement appliquée sur un cluster et jamais propagée est invisible jusqu'à ce qu'un incident ou un audit ne l'expose.

GitOps qui échoue à la frontière entre les clouds

GitOps devrait vous fournir une source unique de vérité pour ce qui s'exécute et où, ainsi qu'un pipeline de livraison continue pour chaque environnement. En pratique, la plupart des équipes exécutent des instances Fleet ou ArgoCD distinctes par cloud, ou maintiennent des pipelines par cloud, chacun avec ses propres identifiants, sa logique de synchronisation et sa gestion des échecs. Chaque pipeline ajouté est un point de défaillance supplémentaire. 

Dès qu'une application doit être déployée de manière cohérente dans plusieurs environnements, sur GKE dans GCP, sur EKS et sur site simultanément, la promesse d'un référentiel Git unique se fragmente en trois pipelines de livraison parallèles qui divergent. La gestion du trafic suit la même voie : les équilibreurs de charge, le routage du trafic mondial et la politique de trafic inter-clusters sont gérés cloud par cloud au lieu d'être traités comme une règle de mise en réseau unique. Les outils ancrés dans les hyperscalers ne règlent pas non plus ce problème proprement, car ils acheminent les données de télémétrie et d'autorisation via une infrastructure américaine, même lorsque vos nœuds de travail se trouvent dans une région de l'UE, quel que soit l'emplacement physique du matériel.

Le coût caché de l'auto-hébergement de Rancher par vous-même

L'auto-hébergement est une solution au défi du cloud-agnosticisme, car un seul outil centré sur Kubernetes gère alors n'importe quel cluster conforme à la CNCF. Il en crée une nouvelle : désormais, votre équipe maintient cet outil. La configuration de la haute disponibilité, un magasin de données de sauvegarde, la rotation des certificats et les mises à niveau trimestrielles s'ajoutent à votre backlog, en plus des clusters sous-jacents. Une couche de gestion auto-hébergée est un produit à part entière, avec une empreinte d'infrastructure qui doit être dimensionnée et corrigée correctement, avec la même attention SRE que le parc qu'elle gouverne. Une solution hébergée supprime cette couche.

Architecture : le Manager sur OVHcloud, des agents sur chaque cluster

Une distinction architecturale importe avant tout : OVHcloud ne gère pas directement vos clusters sur GKE, EKS ou AKS. Le Manager est ce qui est hébergé sur OVHcloud, dans la région UE de votre choix, un emplacement unique sous une juridiction unique. Un agent léger, uniquement sortant, s'exécute sur chacun de vos clusters Kubernetes, où qu'ils se trouvent, et renvoie des informations. Vos clusters GKE, EKS, AKS ou sur site existants restent là où ils sont, sous vos propres comptes et votre propre responsabilité.

Chaque type de cluster, qu'il soit géré par le cloud, auto-géré ou natif OVHcloud, apparaît dans la même interface utilisateur, derrière la même API, et peut être provisionné via les mêmes ressources Terraform. Les équipes qui se standardisent sur Ansible ou Pulumi conservent également ces flux de travail. Si vos clusters partagent un magasin d'images de conteneurs, OVHcloud Managed Private Registry fournit un registre basé sur Harbor à partir duquel chaque cluster peut effectuer des extractions, quel que soit le cloud ou la région dans lequel il s'exécute.

Modèle A : importer des clusters GKE, EKS, AKS ou sur site existants

Si vous exécutez déjà des clusters Kubernetes sur GCP, AWS, Azure ou vos propres centres de données, vous ne migrez rien. Installez l'agent sur chaque cluster existant ; il ouvre une connexion sortante uniquement vers le Manager, et le cluster apparaît en quelques minutes. Il n'y a pas de re-platforming, pas d'interruption de déploiement et aucun changement dans la façon dont vous déployez actuellement des applications sur ce cluster. Les charges de travail existantes continuent de s'exécuter exactement comme avant.

Modèle B : provisionner de nouveaux clusters RKE2 ou k3s sur n'importe quelle infrastructure

Pour les nouveaux clusters plutôt que ceux importés, utilisez le Manager pour provisionner RKE2, une distribution Kubernetes de qualité production renforcée selon les benchmarks CIS, ou k3s, une distribution légère adaptée aux déploiements en périphérie. Les deux s'exécutent sur n'importe quelle infrastructure disposant de ressources de calcul : bare metal sur site, machines virtuelles ou instances IaaS sur n'importe quel fournisseur cloud, dans n'importe quelle région. Le flux de travail de provisionnement, le RBAC et la surveillance centralisée sont identiques dans chaque région, quel que soit l'emplacement physique des nœuds résultants.

Modèle C : ajouter OVHcloud MKS en tant que cluster souverain européen

Le troisième modèle d'architecture est la solution souveraine : un cluster natif OVHcloud pour toute charge de travail nécessitant spécifiquement la souveraineté européenne. Les clusters du service Kubernetes géré d'OVHcloud s'enregistrent dans le même Manager que vos clusters importés et provisionnés, et apparaissent comme des citoyens de premier ordre à leurs côtés, avec la même interface utilisateur, le même RBAC et les mêmes pipelines GitOps. Contrairement aux clusters sur des clouds tiers, OVHcloud gère entièrement le plan de contrôle MKS lui-même ; il s'agit donc du seul type de cluster de votre parc sans aucune charge opérationnelle de plan de contrôle de votre côté.

Contrôle d'accès unifié sur chaque cluster, définissez une fois, propagez partout

Définissez un rôle une fois et propagez-le à chaque cluster Kubernetes, au lieu de le répéter dans trois ou quatre consoles distinctes. Les utilisateurs se connectent partout via le même fournisseur d'identité. Chaque octroi, révocation et changement de permission par utilisateur aboutit dans une piste d'audit cohérente, ce qui fait la différence entre une revue d'accès qui prend un après-midi et une qui prend une semaine.

L'intégration d'un nouvel ingénieur devient une étape de provisionnement, et non une liste de contrôle par cloud, et les tickets concernant qui peut accéder à quoi cessent d'être des projets de recherche. Pour une organisation exécutant des clusters sur plus d'un cloud, ce point de contrôle unique est ce qui rend un audit de conformité réalisable, et ce qui lui permet de démontrer les engagements de confidentialité des données qu'elle a pris envers ses propres utilisateurs.

GitOps multi-cluster avec Rancher Fleet

Fleet vous permet de définir des applications une seule fois dans un dépôt GitHub et de les synchroniser par sélecteur d'étiquettes, par exemple tous les clusters de production de l'UE ou chaque environnement de staging, plutôt que de maintenir un pipeline distinct par fournisseur. La dérive entre ce qui est déclaré dans Git et ce qui est en cours d'exécution est détectée et réconciliée automatiquement sur chaque cluster du sélecteur, ce qui constitue un contrôle de version appliqué à l'infrastructure plutôt qu'au code seul.

Il s'agit d'une gestion centralisée pour l'isolation des charges de travail comme pour la politique d'espaces de noms : les mêmes règles s'appliquent partout, ce qui est le seul moyen d'assurer la cohérence sur des clusters que personne ne vérifie souvent. C'est la solution directe à la fragmentation des pipelines de livraison, avec une source unique de vérité et un moteur de synchronisation unique, que la charge de travail cible s'exécute sur GKE, sur site ou sur OVHcloud MKS. Notre guide de gestion multi-cluster est l'endroit idéal pour en savoir plus sur les opérations quotidiennes une fois qu'un parc est configuré, et sur la façon dont les équipes rationalisent les versions entre les régions.

Cycle de vie des clusters : mises à niveau, provisionnement, déprovisionnement via l'interface utilisateur, l'API ou Terraform

Les mises à niveau de version de Kubernetes sont orchestrées sur chaque cluster avec des paramètres de montée en charge configurables, au lieu de fenêtres de maintenance distinctes par cluster et par cloud. Vous pouvez automatiser le provisionnement, la mise à niveau et le déprovisionnement via la même interface utilisateur, la même API, les mêmes ressources Terraform ou vos flux de travail Ansible existants, et vous obtenez une visibilité sur l'état actuel sans changer de console, en ne dépendant que du cluster lui-même.

Les commandes que vos ingénieurs connaissent déjà continuent de fonctionner à l'identique. Changez de contexte, puis exécutez les mêmes opérations :

kubectl create namespace payments-staging
kubectl get events --all-namespaces

Cette cohérence transforme la gestion du cycle de vie d'un exercice sujet aux erreurs en un processus automatisé et reproductible. Cela supprime la complexité qui augmenterait autrement avec chaque déploiement multi-région complexe, permettant à une petite équipe de gérer efficacement un vaste parc à grande échelle, du développement à la production.

Surveillance et journalisation centralisées avec Prometheus et Grafana

Prometheus et Grafana s'intègrent à l'échelle du parc, vous offrant une pile d'observabilité multi-cluster unifiée sur chaque cluster au lieu d'un outil et d'une configuration différents par cloud. Le stockage des métriques et l'agrégation des journaux sont activés de la même manière sur chaque nœud dans chaque région, et les mêmes tableaux de bord, règles d'alerte et guides de procédures s'appliquent, qu'une alerte se déclenche sur un cluster GKE, un cluster RKE2 sur site ou un nœud OVHcloud MKS. Les questions de fiabilité obtiennent une réponse unique au lieu d'une par fournisseur, et les tendances d'utilisation et de trafic deviennent visibles dans une vue globale unique.

Pourquoi ajouter un cluster souverain européen (CLOUD Act, dépendance à un seul hyperscaler)

Si chaque cluster que vous exécutez se trouve sur un hyperscaler américain, toutes ces données du plan de contrôle sont soumises au CLOUD Act américain, quel que soit l'emplacement physique des nœuds de travail. La solution consiste à ajouter OVHcloud Managed Kubernetes Service : un cluster dont le plan de contrôle s'exécute dans une région européenne, sans société mère américaine et sans exposition structurelle au CLOUD Act.

Cela est important pour toute organisation, indépendamment de l'outil que vous utilisez pour gérer le reste de vos clusters. Cette approche réduit la dépendance à un seul hyperscaler pour toute charge de travail critique, et offre aux équipes réglementées dans les secteurs de la santé, des services financiers et du secteur public une option sous juridiction européenne sans abandonner les clusters qu'elles utilisent déjà ailleurs.

MKS Free : ajoutez un cluster OVHcloud sans aucun coût

MKS est disponible en version gratuite dans les 14 régions, sans carte bancaire requise, donc valider un cluster souverain européen ne coûte rien. Il s'exécute au sein de votre projet Public Cloud existant, aux côtés de toute autre ressource et de tout autre nœud que votre équipe utilise déjà. Pour une charge de travail en production, MKS Standard s'exécute en 3-AZ dans la région de Paris avec un accord de niveau de service de 99,99 %. Chaque niveau s'enregistre exactement comme n'importe quel autre cluster, avec le même RBAC, le même GitOps et la même surveillance, dans la région de votre choix.

100 % open source, zéro verrouillage : votre stratégie de sortie est l'auto-hébergement, pas la migration

Rancher est publié sous licence Apache 2.0, et les distributions RKE2 et k3s qu'il provisionne sont des projets de la CNCF. OVHcloud n'exécute pas de fork propriétaire et n'ajoute pas de couche de fonctionnalités fermée : il s'agit du projet upstream identique, agnostique au cloud et hébergé pour vous en tant que solution managée. Si vous décidez plus tard de rapatrier la gestion en interne, votre stratégie de sortie consiste à auto-héberger ce même projet, sans migration ni réécriture de la configuration de vos clusters. Les clusters ne sont pas affectés dans les deux cas, car ils n'ont jamais été verrouillés par autre chose que Kubernetes standard et des agents standard.