Comment économiser des ressources et du temps lors du lancement de dizaines de clusters OpenShift

Quiconque a déployé Kubernetes ou OpenShift en production connaît cette difficulté. Vous souhaitez créer un petit cluster isolé pour la mise en scène ou pour une équipe distincte, mais déployer au moins trois nœuds pour les nœuds maîtres avec etcd et les contrôleurs est excessif. Si vous avez besoin de dix, trente ou une centaines de clusters, les factures cloud deviennent astronomiques et le temps nécessaire pour créer un nouvel environnement s'étire sur des dizaines de minutes.

Les ingénieurs Red Hat ont rencontré le même problème et ont publié une solution en open source. Le projet s'appelle HyperShift (ou Hosted Control Planes). En essence, c'est une couche qui déplace le plan de contrôle du cluster depuis des nœuds séparés vers des pods réguliers au sein d'un cluster de gestion central.

Explorons comment cela fonctionne et qui en bénéficie.

Le focus architectural principal

Dans une configuration classique d'OpenShift ou Kubernetes, chaque cluster dispose de ses propres machines virtuelles ou physiques dédiées pour le serveur API, etcd, les contrôleurs et l'ordonnanceur. Vous payez pour ces nœuds même si le cluster est principalement inactif.

HyperShift sépare le plan de contrôle des nœuds workers.

Vous avez un grand cluster de gestion. Lorsque vous devez créer un nouveau cluster OpenShift pour des utilisateurs ou des équipes de développement, HyperShift déploie les composants de gestion du nouveau cluster — etcd, kube-apiserver, openshift-apiserver — sous forme de pods standard (Deployment et StatefulSet) directement dans le cluster de gestion.

Pendant ce temps, les nœuds workers sont créés séparément où vous en avez besoin : dans AWS, Azure ou sur du bare metal. Ils se connectent au serveur API fonctionnant comme un pod dans l'infrastructure de gestion.

Pourquoi changer l'approche familière

Si vous gérez plusieurs clusters, les avantages sont immédiatement visibles dans trois domaines.

Premièrement — l'efficacité énergétique. Au lieu d'acheter au moins trois machines virtuelles pour les nœuds maîtres de chaque cluster individuel, vous exploitez les ressources d'un cluster de gestion existant. En conséquence, des dizaines de plans de contrôle s'exécutent sur un seul pool de ressources, atteignant un empaquetage beaucoup plus dense.

Deuxièmement — la vitesse de provisionnement de l'infrastructure. Le démarrage complet d'un nœud avec un système d'exploitation, la configuration d'etcd et l'initialisation des composants prend 15 à 45 minutes. Les pods du plan de contrôle dans HyperShift démarrent en quelques minutes, voire en quelques secondes. Cela change complètement l'approche pour les environnements dev/test : un cluster devient une ressource temporaire facile à créer pour une tâche et rapide à supprimer.

Troisièmement — la séparation des responsabilités et la sécurité. Les développeurs et les applications n'ont accès qu'à leurs nœuds workers et au serveur API. Ils n'ont aucun accès physique ou réseau aux machines exécutant le plan de contrôle ou etcd. L'équipe des opérations met à jour et surveille de manière centralisée tous les serveurs API à un seul endroit.

Comment cela se présente en pratique

HyperShift maintient une compatibilité à 100 % avec l'API Kubernetes standard et les outils OpenShift Container Platform (OCP). Du point de vue d'un développeur ou d'un pipeline CI/CD, le cluster créé est indistinguishable d'un cluster classique : vous obtenez un kubeconfig standard et travaillez via kubectl ou oc.

La gestion se fait via l'utilitaire CLI hypershift ou via des Custom Resources (CRD), ce qui s'intègre parfaitement dans les approches GitOps comme ArgoCD.

Voici un exemple de ce à quoi ressemble la création d'un cluster dans AWS via CLI :

hypershift create cluster aws \
  --name dev-cluster \
  --node-pool-replicas 2 \
  --base-domain example.com \
  --pull-secret /path/to/pull-secret.json \
  --aws-creds /path/to/aws-credentials

En arrière-plan, la commande créera les CRD HostedCluster et NodePool. HyperShift lancera les pods du plan de contrôle dans le cluster de gestion, provisionnera une paire d'instances EC2 dans AWS pour les nœuds workers et les liera ensemble.

Sous le capot et nuances

Le projet est écrit en Go et est activement développé par l'équipe OpenShift. Le dépôt compte déjà plus de 500 forks, bien que les étoiles soient encore relativement peu nombreuses — à peine plus de cinq cents. C'est parce que HyperShift a longtemps été une technologie interne Red Hat pour le service ROSA (Red Hat OpenShift Service on AWS), et devient maintenant progressivement la norme pour les installations on-premises et multi-cloud.

Les caractéristiques importantes incluent :

• Isolation complète entre le cluster de gestion et les workloads clients.
• Support pour le déploiement de nœuds workers sur différents fournisseurs : AWS, Azure, KubeVirt, Bare Metal.
• Vecteur de mise à jour unifié. La mise à jour de la version OpenShift pour le plan de contrôle peut être effectuée indépendamment en modifiant la version dans le CRD sans redémarrer immédiatement tous les nœuds workers.

Y a-t-il des pièges ? Bien sûr. Le cluster de gestion devient un point de défaillance unique pour les plans de contrôle de tous vos clusters clients. Si le cluster de gestion tombe en panne, les services s'exécutant sur les nœuds workers continueront de fonctionner, mais la gérabilité sera perdue jusqu'à ce que l'infrastructure soit restaurée. Par conséquent, la fiabilité du cluster de gestion et les sauvegardes etcd ont des exigences élevées.

Qui devrait y jeter un œil

HyperShift n'est pas nécessaire si vous avez un seul cluster monolithique pour toute l'entreprise. Mais il devient une bouée de sauvetage si :

• Vous construisez une plateforme pour des équipes internes et souhaitez fournir des clusters isolés à la demande.
• Vous vendez une solution SaaS basée sur Kubernetes avec une séparation physique des clients.
• Vous en avez assez de payer pour des nœuds maîtres inactifs dans les clouds publics.

Vous pouvez essayer le projet en utilisant la documentation officielle à hypershift.pages.dev. Vous aurez besoin d'un cluster OpenShift 4.x existant comme cluster de gestion et d'un accès à AWS ou des machines virtuelles locales pour créer des workers.