6.5. Aperçu des plans de contrôle hébergés (aperçu technologique)
Vous pouvez utiliser des plans de contrôle hébergés pour Red Hat OpenShift Container Platform afin de réduire les coûts de gestion, d'optimiser le temps de déploiement des clusters et de séparer les préoccupations liées à la gestion et à la charge de travail afin que vous puissiez vous concentrer sur vos applications.
Vous pouvez activer les plans de contrôle hébergés en tant que fonctionnalité d'aperçu technologique en utilisant le moteur multicluster pour l'opérateur Kubernetes version 2.0 ou ultérieure sur Amazon Web Services (AWS).
Les plans de contrôle hébergés sont une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.
Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.
6.5.1. Architecture des plans de contrôle hébergés
OpenShift Container Platform est souvent déployé dans un modèle couplé, ou autonome, où un cluster se compose d'un plan de contrôle et d'un plan de données. Le plan de contrôle comprend un point d'extrémité d'API, un point d'extrémité de stockage, un planificateur de charge de travail et un actionneur qui assure l'état. Le plan de données comprend le calcul, le stockage et le réseau où s'exécutent les charges de travail et les applications.
Le plan de contrôle autonome est hébergé par un groupe dédié de nœuds, qui peuvent être physiques ou virtuels, avec un nombre minimum pour assurer le quorum. La pile réseau est partagée. L'accès de l'administrateur à une grappe offre une visibilité sur le plan de contrôle de la grappe, les API de gestion des machines et d'autres composants qui contribuent à l'état d'une grappe.
Bien que le modèle autonome fonctionne bien, certaines situations exigent une architecture où le plan de contrôle et le plan de données sont découplés. Dans ce cas, le plan de données se trouve sur un domaine de réseau séparé avec un environnement d'hébergement physique dédié. Le plan de contrôle est hébergé en utilisant des primitives de haut niveau telles que les déploiements et les ensembles avec état qui sont natifs de Kubernetes. Le plan de contrôle est traité comme n'importe quelle autre charge de travail.
6.5.2. Avantages des plans de contrôle hébergés
Avec les plans de contrôle hébergés pour OpenShift Container Platform, vous pouvez ouvrir la voie à une véritable approche de cloud hybride et profiter de plusieurs autres avantages.
- Les frontières de sécurité entre la gestion et les charges de travail sont plus solides car le plan de contrôle est découplé et hébergé sur un cluster de service d'hébergement dédié. Par conséquent, vous êtes moins susceptible de divulguer les informations d'identification des clusters à d'autres utilisateurs. La gestion des comptes secrets de l'infrastructure étant également découplée, les administrateurs de l'infrastructure des clusters ne peuvent pas supprimer accidentellement l'infrastructure du plan de contrôle.
- Avec les plans de contrôle hébergés, vous pouvez exécuter de nombreux plans de contrôle sur un nombre réduit de nœuds. Les grappes sont donc plus abordables.
- Comme les plans de contrôle sont constitués de pods lancés sur OpenShift Container Platform, les plans de contrôle démarrent rapidement. Les mêmes principes s'appliquent aux plans de contrôle et aux charges de travail, telles que la surveillance, la journalisation et la mise à l'échelle automatique.
- Du point de vue de l'infrastructure, vous pouvez pousser les registres, HAProxy, la surveillance des clusters, les nœuds de stockage et d'autres composants de l'infrastructure vers le compte du fournisseur de cloud du locataire, isolant ainsi l'utilisation du locataire.
- D'un point de vue opérationnel, la gestion des grappes multiples est plus centralisée, ce qui réduit le nombre de facteurs externes qui affectent l'état et la cohérence de la grappe. Les ingénieurs de fiabilité du site disposent d'un endroit central pour déboguer les problèmes et naviguer vers le plan de données du cluster, ce qui peut réduire le temps de résolution (TTR) et augmenter la productivité.
6.5.3. Versioning pour les plans de contrôle hébergés
À chaque version majeure, mineure ou corrective d'OpenShift Container Platform, deux composants des plans de contrôle hébergés sont publiés :
- Opérateur HyperShift
- Interface de ligne de commande (CLI)
L'opérateur HyperShift gère le cycle de vie des clusters hébergés qui sont représentés par les ressources de l'API HostedCluster. L'opérateur HyperShift est publié avec chaque version d'OpenShift Container Platform.
Le CLI est un utilitaire d'aide au développement. Le CLI fait partie de toute version d'HyperShift Operator. Aucune politique de compatibilité n'est garantie.
L'API, hypershift.openshift.io, permet de créer et de gérer des clusters OpenShift Container Platform légers, flexibles et hétérogènes à l'échelle. L'API expose deux ressources orientées utilisateur : HostedCluster et NodePool. Une ressource HostedCluster encapsule le plan de contrôle et la configuration commune du plan de données. Lorsque vous créez une ressource HostedCluster, vous disposez d'un plan de contrôle entièrement fonctionnel sans nœuds attachés. Une ressource NodePool est un ensemble évolutif de nœuds de travail attaché à une ressource HostedCluster.
La politique de version de l'API s'aligne généralement sur la politique de version de l'API Kubernetes.
Ressources complémentaires
-
Pour plus d'informations sur les ressources
HostedClusteretNodePool, voir la référence API HyperShift.
