Chapitre 21. Clusters à la périphérie du réseau
21.1. Les défis de la périphérie du réseau Copier lienLien copié sur presse-papiers!
L'informatique en périphérie présente des défis complexes lorsqu'il s'agit de gérer de nombreux sites géographiquement éloignés. Utilisez le zero touch provisioning (ZTP) et GitOps pour approvisionner et gérer les sites à la périphérie du réseau.
21.1.1. Relever les défis de la périphérie du réseau Copier lienLien copié sur presse-papiers!
Aujourd'hui, les fournisseurs de services souhaitent déployer leur infrastructure à la périphérie du réseau. Cela pose des défis importants :
- Comment gérer les déploiements de plusieurs sites périphériques en parallèle ?
- Que se passe-t-il lorsque vous devez déployer des sites dans des environnements déconnectés ?
- Comment gérer le cycle de vie de grandes flottes de clusters ?
Zero touch provisioning (ZTP) et GitOps relèvent ces défis en vous permettant de provisionner des sites périphériques distants à l'échelle avec des définitions de site déclaratives et des configurations pour l'équipement bare-metal. Les configurations de modèle ou de superposition installent les fonctionnalités d'OpenShift Container Platform qui sont requises pour les charges de travail CNF. Le cycle de vie complet de l'installation et des mises à jour est géré par le pipeline ZTP.
ZTP utilise GitOps pour les déploiements d'infrastructure. Avec GitOps, vous utilisez des fichiers YAML déclaratifs et d'autres modèles définis stockés dans des dépôts Git. Red Hat Advanced Cluster Management (RHACM) utilise vos référentiels Git pour piloter le déploiement de votre infrastructure.
GitOps assure la traçabilité, le contrôle d'accès basé sur les rôles (RBAC) et une source unique de vérité pour l'état souhaité de chaque site. Les problèmes d'évolutivité sont traités par les méthodologies Git et les opérations basées sur les événements par le biais de webhooks.
Vous démarrez le flux de travail ZTP en créant des ressources personnalisées (CR) déclaratives de définition et de configuration de site que le pipeline ZTP transmet aux nœuds périphériques.
Le diagramme suivant montre comment ZTP fonctionne dans le cadre de la périphérie éloignée.
21.1.2. Utilisation de ZTP pour provisionner des clusters à la périphérie du réseau Copier lienLien copié sur presse-papiers!
Red Hat Advanced Cluster Management (RHACM) gère les clusters dans une architecture hub-and-spoke, où un seul cluster hub gère de nombreux clusters spoke. Les clusters concentrateurs exécutant RHACM provisionnent et déploient les clusters gérés en utilisant le zero touch provisioning (ZTP) et le service assisté qui est déployé lors de l'installation de RHACM.
Le service assisté gère le provisionnement d'OpenShift Container Platform sur des clusters à un seul nœud, des clusters à trois nœuds ou des clusters standard fonctionnant sur du bare metal.
Voici un aperçu de haut niveau de l'utilisation de ZTP pour provisionner et maintenir des hôtes bare-metal avec OpenShift Container Platform :
- Un hub cluster exécutant RHACM gère un registre d'images OpenShift qui reflète les images des versions d'OpenShift Container Platform. RHACM utilise le registre d'images OpenShift pour provisionner les clusters gérés.
- Vous gérez les hôtes nus dans un fichier d'inventaire au format YAML, versionné dans un dépôt Git.
- Vous préparez les hôtes pour le provisionnement en tant que clusters gérés, et utilisez RHACM et le service assisté pour installer les hôtes bare-metal sur site.
L'installation et le déploiement des clusters est un processus en deux étapes, comprenant une phase d'installation initiale et une phase de configuration ultérieure. Le diagramme suivant illustre ce processus :
21.1.3. Installation de clusters gérés avec des ressources SiteConfig et RHACM Copier lienLien copié sur presse-papiers!
GitOps ZTP utilise les ressources personnalisées (CR) SiteConfig
dans un référentiel Git pour gérer les processus d'installation des clusters OpenShift Container Platform. La CR SiteConfig
contient les paramètres spécifiques aux clusters requis pour l'installation. Elle comporte des options permettant d'appliquer certaines CR de configuration pendant l'installation, y compris des manifestes supplémentaires définis par l'utilisateur.
Le plugin ZTP GitOps traite les CR SiteConfig
pour générer une collection de CR sur le cluster hub. Cela déclenche le service assisté dans Red Hat Advanced Cluster Management (RHACM) pour installer OpenShift Container Platform sur l'hôte bare-metal. Vous pouvez trouver l'état de l'installation et les messages d'erreur dans ces CR sur le cluster du concentrateur.
Vous pouvez approvisionner des grappes individuelles manuellement ou par lots à l'aide de ZTP :
- Approvisionnement d'un seul cluster
-
Créez un CR
SiteConfig
unique et les CR d'installation et de configuration associés pour le cluster, et appliquez-les dans le cluster hub pour commencer le provisionnement du cluster. C'est un bon moyen de tester vos CR avant de les déployer à plus grande échelle. - Approvisionnement de nombreux clusters
-
Installez des clusters gérés par lots de 400 au maximum en définissant
SiteConfig
et les CR associés dans un référentiel Git. ArgoCD utilise les CRSiteConfig
pour déployer les sites. Le générateur de politiques RHACM crée les manifestes et les applique au cluster hub. Ceci démarre le processus de provisionnement du cluster.
21.1.4. Configuration de clusters gérés avec des politiques et des ressources PolicyGenTemplate Copier lienLien copié sur presse-papiers!
Le Zero Touch Provisioning (ZTP) utilise Red Hat Advanced Cluster Management (RHACM) pour configurer les clusters en utilisant une approche de gouvernance basée sur des règles pour appliquer la configuration.
Le générateur de politiques ou PolicyGen
est un plugin pour l'opérateur GitOps qui permet de créer des politiques RHACM à partir d'un modèle concis. L'outil peut combiner plusieurs CR en une seule politique, et vous pouvez générer plusieurs politiques qui s'appliquent à divers sous-ensembles de clusters dans votre flotte.
Pour des raisons d'évolutivité et pour réduire la complexité de la gestion des configurations dans le parc de grappes, utilisez des CR de configuration présentant autant de points communs que possible.
- Dans la mesure du possible, appliquer les RC de configuration à l'aide d'une politique commune à l'ensemble de la flotte.
- La préférence suivante consiste à créer des groupements logiques de clusters pour gérer autant que possible les configurations restantes dans le cadre d'une politique de groupe.
- Lorsqu'une configuration est propre à un site individuel, utilisez RHACM templating sur le cluster hub pour injecter les données spécifiques au site dans une stratégie commune ou de groupe. Il est également possible d'appliquer une politique de site individuelle pour le site.
Le diagramme suivant montre comment le générateur de politiques interagit avec GitOps et RHACM dans la phase de configuration du déploiement du cluster.
Pour les grandes flottes de clusters, il est courant que la configuration de ces clusters soit très cohérente.
La structure des politiques recommandée ci-après combine les CR de configuration pour atteindre plusieurs objectifs :
- Décrire les configurations courantes et les appliquer à la flotte.
- Réduire le nombre de politiques maintenues et gérées.
- Favoriser la flexibilité dans les configurations communes pour les variantes de grappes.
Catégorie de politique | Description |
---|---|
Communs |
Une politique qui existe dans la catégorie commune est appliquée à tous les clusters du parc. Utilisez les CR communs |
Groupes |
Une stratégie qui existe dans la catégorie des groupes est appliquée à un groupe de clusters dans le parc. Utilisez les CR de groupe |
Sites | Une politique qui existe dans la catégorie des sites est appliquée à un site spécifique de la grappe. Chaque cluster peut avoir ses propres politiques spécifiques gérées. |