Chapitre 4. Architecture de l’avion de contrôle
Le plan de contrôle, qui est composé de machines de plan de contrôle, gère le cluster OpenShift dédié. Les machines à plan de contrôle gèrent les charges de travail sur les machines de calcul, qui sont également connues sous le nom de machines de travail. Le cluster gère lui-même toutes les mises à niveau vers les machines par les actions de l’opérateur de versions de cluster (CVO), et un ensemble d’opérateurs individuels.
4.1. Les rôles de machine dans OpenShift Dedicated Copier lienLien copié sur presse-papiers!
La fonction OpenShift Dedicated assigne différents rôles. Ces rôles définissent la fonction de la machine dans le cluster. Le cluster contient des définitions pour les types de rôles standard de maître et de travailleur.
4.1.1. Les travailleurs des clusters Copier lienLien copié sur presse-papiers!
Dans un cluster Kubernetes, les nœuds de travail exécutent et gèrent les charges de travail réelles demandées par les utilisateurs de Kubernetes. Les nœuds de travail annoncent leur capacité et le planificateur, qui est un service d’avion de contrôle, détermine sur quels nœuds commencer les pods et les conteneurs. Les services importants suivants s’appliquent à chaque nœud de travail:
- CRI-O, qui est le moteur de conteneur.
- kubelet, qui est le service qui accepte et répond aux demandes d’exécution et d’arrêt des charges de travail des conteneurs.
- Le proxy de service, qui gère la communication pour les pods entre les travailleurs.
- L’exécution de conteneurs crun ou runC de bas niveau, qui crée et exécute des conteneurs.
Consultez la documentation pour créer un ContainerRuntimeConfig CR pour obtenir des informations sur la façon d’activer runC au lieu du cron par défaut.
Dans OpenShift Dedicated, les ensembles de machines de calcul contrôlent les machines de calcul, qui sont assignées au rôle de la machine de travail. Les machines avec le rôle du travailleur propulsent les charges de travail qui sont régies par un pool de machines spécifique qui les met à l’échelle automatique. Étant donné qu’OpenShift Dedicated a la capacité de prendre en charge plusieurs types de machines, les machines ayant le rôle de travailleur sont classées comme machines de calcul. Dans cette version, les termes machine de travail et machine de calcul sont utilisés de manière interchangeable parce que le seul type par défaut de machine de calcul est la machine ouvrier. Dans les versions futures d’OpenShift Dedicated, différents types de machines de calcul, telles que les machines d’infrastructure, pourraient être utilisés par défaut.
Les ensembles de machines de calcul sont des regroupements de ressources de la machine de calcul sous l’espace de noms machine-api. Les ensembles de machines de calcul sont des configurations conçues pour démarrer de nouvelles machines de calcul sur un fournisseur de cloud spécifique. Inversement, les pools de configuration de machine (MCP) font partie de l’espace de noms de l’opérateur de configuration de machine (MCO). Le MCP est utilisé pour regrouper les machines afin que l’AGC puisse gérer leurs configurations et faciliter leurs mises à niveau.
4.1.2. Les plans de contrôle des clusters Copier lienLien copié sur presse-papiers!
Dans un cluster Kubernetes, les nœuds maîtres exécutent des services qui sont nécessaires pour contrôler le cluster Kubernetes. Dans OpenShift Dedicated, le plan de contrôle est composé de machines de plan de contrôle qui ont un rôle maître de machine. Ils contiennent plus que les services Kubernetes pour la gestion du cluster OpenShift dédié.
Dans la plupart des clusters dédiés à OpenShift, les machines de plan de contrôle sont définies par une série de ressources d’API automatiques autonomes. Les plans de contrôle sont gérés avec des ensembles de machines de plan de contrôle. Des contrôles supplémentaires s’appliquent aux machines de plan de contrôle pour vous empêcher de supprimer toutes les machines de plan de contrôle et de casser votre cluster.
Les clusters de zone de disponibilité unique et plusieurs clusters de zones de disponibilité nécessitent un minimum de trois nœuds de plan de contrôle.
Les services qui relèvent de la catégorie Kubernetes sur le plan de contrôle comprennent le serveur API Kubernetes, etcd, le gestionnaire du contrôleur Kubernetes et le planificateur Kubernetes.
Composante | Description |
---|---|
Kubernetes serveur API | Le serveur API Kubernetes valide et configure les données pour les pods, les services et les contrôleurs de réplication. Il fournit également un point focal pour l’état partagé du cluster. |
etc. | etcd stocke l’état persistant du plan de contrôle tandis que d’autres composants surveillent, etc., les changements à apporter dans l’état spécifié. |
Gestionnaire de contrôleur Kubernetes | Le gestionnaire du contrôleur Kubernetes veille etcd pour les modifications d’objets tels que les objets de réplication, d’espace de noms et de contrôleur de compte de service, puis utilise l’API pour appliquer l’état spécifié. De nombreux processus de ce type créent un cluster avec un leader actif à la fois. |
Kubernetes planificateur | Le planificateur Kubernetes montre les pods nouvellement créés sans nœud assigné et sélectionne le meilleur nœud pour héberger le pod. |
Il existe également des services OpenShift qui s’exécutent sur le plan de contrôle, qui comprennent le serveur API OpenShift, le gestionnaire de contrôleur OpenShift, le serveur OpenShift OAuth API et le serveur OpenShift OAuth.
Composante | Description |
---|---|
Le serveur d’API OpenShift | Le serveur API OpenShift valide et configure les données pour les ressources OpenShift, telles que des projets, des itinéraires et des modèles. Le serveur d’API OpenShift est géré par l’opérateur de serveur d’API OpenShift. |
Gestionnaire de contrôleur OpenShift | Le gestionnaire de contrôleur OpenShift veille etcd pour les modifications apportées aux objets OpenShift, tels que les objets de projet, d’itinéraire et de contrôleur de modèle, puis utilise l’API pour appliquer l’état spécifié. Le gestionnaire de contrôleur OpenShift est géré par l’opérateur OpenShift Controller Manager. |
Le serveur de l’API OpenShift OAuth | Le serveur API OpenShift OAuth valide et configure les données pour s’authentifier auprès d’OpenShift Dedicated, tels que les utilisateurs, les groupes et les jetons OAuth. Le serveur de l’API OpenShift OAuth est géré par l’opérateur d’authentification du cluster. |
Le serveur OpenShift OAuth | Les utilisateurs demandent des jetons au serveur OpenShift OAuth pour s’authentifier à l’API. Le serveur OpenShift OAuth est géré par l’opérateur d’authentification du cluster. |
Certains de ces services sur les machines de plan de contrôle fonctionnent comme des services système, tandis que d’autres fonctionnent comme des gousses statiques.
Les services système sont appropriés pour les services dont vous avez besoin pour toujours proposer ce système en particulier peu de temps après son démarrage. Dans le cas des machines de contrôle, celles-ci incluent sshd, ce qui permet la connexion à distance. Il comprend également des services tels que:
- Le moteur de conteneur CRI-O (crio), qui fonctionne et gère les conteneurs. L’OpenShift Dedicated 4 utilise CRI-O au lieu du moteur Docker Container.
- Kubelet (kubelet), qui accepte les demandes de gestion des conteneurs sur la machine à partir des services d’avion de contrôle.
CRI-O et Kubelet doivent fonctionner directement sur l’hôte en tant que services système, car ils doivent être exécutés avant de pouvoir exécuter d’autres conteneurs.
Les pods de plan de contrôle installateur* et révision-pruner-* doivent s’exécuter avec des autorisations root car ils écrivent dans le répertoire /etc/kubernetes, qui appartient à l’utilisateur root. Ces pods se trouvent dans les espaces de noms suivants:
-
à propos de OpenShift-etcd
-
comment utiliser OpenShift-kube-apiserver?
-
le gestionnaire OpenShift-kube-controller-manager
-
horaires OpenShift-kube-scheduler