Plan de contrôle hébergé : définition
Le terme « plan de contrôle hébergé » renvoie à un plan de gestion dissocié qui doit renforcer le contrôle et la gestion des composants du plan de contrôle principal. Cet article présente ce concept et les avantages des plans de contrôle hébergés inclus dans les solutions Red Hat® OpenShift® Container Platform et Red Hat OpenShift Service on AWS.
Plan de contrôle hébergé : avantages
En plus de faciliter l'adoption d'une véritable stratégie de cloud hybride, les plans de contrôle hébergés pour OpenShift Container Platform offrent divers avantages.
Les plans de contrôle hébergés permettent d'exécuter des plans de contrôle sur des nœuds plus petits, ce qui réduit le coût des clusters.
Les plans de contrôle sont constitués de pods mis en service sur OpenShift Container Platform, ce qui garantit leur démarrage rapide. Les mêmes principes s'appliquent aux plans de contrôle et aux charges de travail, tels que la surveillance, la journalisation et la mise à l'échelle automatique.
Du point de vue de l'infrastructure, il est possible de transférer divers composants (HAProxy, surveillance des clusters, nœuds de stockage, etc.) vers un compte de fournisseur de cloud distinct, ce qui permet d'isoler l'utilisation du plan de contrôle.
La gestion d'un groupe de clusters est davantage centralisée, contribuant ainsi à limiter le nombre de facteurs externes susceptibles d'influer sur leur état. Les équipes d'ingénierie de la fiabilité des sites (SRE) disposent d'un espace centralisé pour résoudre les problèmes et accéder au plan de données, ce qui permet d'accélérer le temps de résolution et d'accroître la productivité.
Les plans de contrôle hébergés peuvent aussi améliorer l'isolation. La dissociation du plan de contrôle permet de renforcer les limites de sécurité entre la gestion et les charges de travail, ce qui réduit les risques de divulgation d'informations d'identification et de suppression accidentelle de l'infrastructure du plan de contrôle.
Ressources Red Hat
Plans de contrôle hébergés dans Red Hat OpenShift
Le plan de contrôle autonome est hébergé par un groupe dédié de nœuds physiques ou virtuels, dont le nombre doit respecter un seuil minimal. En outre, la pile réseau est partagée. L'accès administrateur permet de connaître l'état du cluster grâce à l'affichage de son plan de contrôle, des API de gestion des machines et d'autres composants.
Ce modèle autonome est parfois préférable, mais d'autres situations exigent que le plan de contrôle et le plan de données soient dissociés.
Dans ce cas, le plan de données se trouve sur un domaine de réseau distinct avec un environnement d'hébergement physique dédié. Le plan de contrôle est hébergé selon des primitives de haut niveau, tels que les déploiements natifs pour Kubernetes.
Les plans de contrôle hébergés pour Red Hat OpenShift offrent notamment les possibilités suivantes :
- Dissociation du plan de contrôle et du plan de données (nœuds de calcul)
- Séparation des domaines de réseau
- Interface centralisée pour les administrateurs et les équipes SRE
Autrement dit, le plan de contrôle fonctionne comme toute autre charge de travail. La même pile peut être utilisée pour surveiller, sécuriser et exploiter les applications, ainsi que pour gérer le plan de contrôle.
Plans de contrôle hébergés dans Red Hat OpenShift Service on AWS (ROSA)
Red Hat OpenShift Service on AWS (ROSA) inclut désormais des plans de contrôle hébergés. Ce nouveau modèle de déploiement pour ROSA repose sur l'hébergement du plan de contrôle dans un compte AWS du service ROSA, plutôt que dans le compte AWS de chaque client.
L'hébergement et la gestion du plan de contrôle dans un compte AWS du service ROSA permettent d'utiliser les ressources du client de la manière la plus efficace possible. Les utilisateurs de ROSA peuvent ainsi bénéficier d'importantes économies, d'une accélération du provisionnement, d'un renforcement de la posture de sécurité et d'une augmentation de la fiabilité. Ils pourront aussi bénéficier de divers avantages :
- Mise en route et suppression faciles et rapides des clusters lorsqu'ils sont inutilisés, pour plus d'efficacité et de rentabilité
- Plus de flexibilité et de portabilité en matière de facturation annuelle, permettant aux clients de changer facilement de types de nœuds
- Réduction de l'empreinte globale
- Disponibilité de l'API pour un nouveau cluster sous 15 minutes environ, accélérant ainsi la création et le déploiement des applications
- Mise à l'échelle automatique et fluide du plan de contrôle
- Plan de contrôle toujours hautement disponible dans plusieurs zones de disponibilité
- Mise à niveau sélective du plan de contrôle et des nœuds de calcul de manière indépendante, pour plus de contrôle et de flexibilité du côté des utilisateurs
- Renforcement de la résilience et de la fiabilité grâce à la délégation de la gestion de l'infrastructure du plan de contrôle, limitant les risques d'erreur ou de suppression de ressources
Pour en savoir plus sur la solution ROSA avec plans de contrôle hébergés ainsi que sur la marche à suivre pour vous lancer, cliquez ici.
Utilisation des plans de contrôle hébergés dans Red Hat OpenShift Service on AWS
L'hébergement et la gestion du plan de contrôle au sein d'un compte AWS du service ROSA plutôt que dans le compte de chaque client simplifient le travail des équipes.
Le provisionnement est rationalisé, ce qui accélère le déploiement des applications. En outre, l'ordonnancement des charges de travail dépend uniquement des nœuds de calcul, ce qui simplifie à la fois la création et le déploiement. Avec les plans de contrôlé hébergés inclus dans ROSA, il n'est plus nécessaire de mettre à l'échelle manuellement le plan de contrôle, car cette tâche est gérée automatiquement dans le compte AWS du service ROSA.
Puisque l'utilisateur final n'a plus à gérer l'infrastructure du plan de contrôle, les risques de suppression accidentelle de ressources cloud sont écartés. Les administrateurs AWS n'interagissent qu'avec les charges de travail et ne touchent pas aux artéfacts du plan de contrôle. Les utilisateurs peuvent mettre à niveau indépendamment le plan de contrôle et les nœuds de calcul de manière sélective, ce qui accroît le contrôle et la flexibilité de leur côté.
Conçue pour les services gérés, la dernière version de ROSA rationalise la manière dont les entreprises déploient et gèrent leurs clusters ROSA à grande échelle. En plus des avantages métier déjà évoqués, cette nouvelle architecture offre de nombreux avantages technologiques.
Les administrateurs de clusters peuvent mettre à niveau le plan de contrôle plus efficacement avec cette approche qu'avec la version classique de ROSA (autonome). Les plans de contrôle hébergés dissocient l'architecture. Ainsi, les administrateurs sont en mesure de gérer le plan de contrôle sans avoir à mettre à niveau l'ensemble du cluster. Diverses ressources sont déplacées en dehors des limites du cluster. Elles s'appuient désormais sur une source unique de vérité accessible via l'interface en ligne de commande (CLI) de ROSA ou la console web d'OpenShift Cluster Manager (OCM). Toutes les API des machines sont gérées de manière externe via la CLI de ROSA ou l'OCM en tant qu'objets de pool de machines. Les ressources d'API de nœud restent disponibles dans le cluster, et il est toujours possible d'étiqueter et de marquer les nœuds existants. Les composants OAuth ne sont plus exposés en interne au sein du cluster.
L'ensemble d'autorisations de la politique AWS s'appuie sur les politiques gérées qui ont été approuvées et publiées par AWS, ce qui permet de simplifier les prérequis et de renforcer la sécurité grâce à une application des autorisations basée sur des balises. Par ailleurs, l'indépendance des mises à niveau du plan de contrôle et des nœuds de calcul garantit un rythme de mise à niveau du plan de contrôle à la fois cohérent et axé sur la sécurité, sans incidence sur les nœuds de calcul.
Les équipes de développement n'ont plus à attendre la mise à disposition d'un cluster ou d'une infrastructure et peuvent ainsi consacrer plus de temps au développement et aux tests des applications. Elles peuvent aussi déployer des applications dans une seule zone de disponibilité, dans deux zones ou dans l'ensemble des zones de disponibilité d'une région sans avoir à se préoccuper de la disponibilité du plan de contrôle. Celui-ci est toujours distribué dans plusieurs zones de disponibilité. De plus, les équipes de développement peuvent provisionner rapidement un plan de contrôle dédié et isolé pour chaque cluster, qui peut être accessible au public ou exposé en privé via un point de terminaison AWS PrivateLink dédié dans leur cloud privé virtuel AWS.
Les plans de contrôle hébergés sont plus intéressants à grande échelle. Ils éliminent le besoin d'héberger les composants du plan de contrôle dans chaque cluster. Pour les clusters de plus petite taille qui comptent moins de nœuds, le bénéfice de cette architecture Red Hat OpenShift n'est pas aussi net. La réduction des nœuds de plan de contrôle dédiés permet toutefois de réaliser d'importantes économies en matière de cloud grâce à la diminution des coûts d'infrastructure liés à chaque cluster.
Bilan
Les plans de contrôle hébergés permettent de réduire les coûts, d'accélérer le provisionnement et d'optimiser la sécurité dans le cadre de la gestion des charges de travail. Par conséquent, ils sont adaptés à de nombreux cas d'utilisation, parmi lesquels :
- l'hébergement de clusters qui présentent des caractéristiques spécifiques ;
- la hiérarchisation des charges de travail ;
- la flexibilité des mises à niveau (les plans de contrôle peuvent être mis à niveau indépendamment des nœuds de calcul).
Étapes suivantes
Approfondissez vos connaissances en apprenant à créer des clusters à l'aide de la version de ROSA qui inclut des plans de contrôle hébergés.
Le blog officiel de Red Hat
Découvrez les dernières informations concernant notre écosystème de clients, partenaires et communautés.