6.2. Rôles des machines dans OpenShift Container Platform
OpenShift Container Platform attribue aux hôtes différents rôles. Ces rôles définissent la fonction de la machine au sein du cluster. Le cluster contient des définitions pour les types de rôles standard master et worker.
Le cluster contient également la définition du rôle bootstrap. La machine d'amorçage n'étant utilisée que lors de l'installation de la grappe, sa fonction est expliquée dans la documentation relative à l'installation de la grappe.
6.2.1. Compatibilité entre le plan de contrôle et l'hôte du nœud
La version d'OpenShift Container Platform doit correspondre entre l'hôte du plan de contrôle et l'hôte du nœud. Par exemple, dans un cluster 4.12, tous les hôtes du plan de contrôle doivent être 4.12 et tous les nœuds doivent être 4.12.
Les décalages temporaires lors des mises à niveau de clusters sont acceptables. Par exemple, lors de la mise à niveau d'OpenShift Container Platform 4.11 à 4.12, certains nœuds passeront à la version 4.12 avant d'autres. Un décalage prolongé des hôtes du plan de contrôle et des hôtes des nœuds peut exposer les machines de calcul plus anciennes à des bogues et à des fonctionnalités manquantes. Les utilisateurs doivent résoudre les hôtes de plan de contrôle et les hôtes de nœuds asymétriques dès que possible.
Le service kubelet ne doit pas être plus récent que kube-apiserver, et peut être jusqu'à deux versions mineures plus anciennes selon que la version de votre OpenShift Container Platform est paire ou impaire. Le tableau ci-dessous indique la compatibilité de version appropriée :
| Version d'OpenShift Container Platform | Prise en charge kubelet skew |
|---|---|
| Versions mineures de OpenShift Container Platform [1] | Jusqu'à une version plus ancienne |
| Même les versions mineures de OpenShift Container Platform [2] | Jusqu'à deux versions plus anciennes |
- Par exemple, OpenShift Container Platform 4.9, 4.11.
- Par exemple, OpenShift Container Platform 4.8, 4.10, 4.12.
6.2.2. Travailleurs en grappe
Dans un cluster Kubernetes, les nœuds de travail sont l'endroit où les charges de travail réelles demandées par les utilisateurs de Kubernetes s'exécutent et sont gérées. Les nœuds de travail annoncent leur capacité et le planificateur, qui est un service de plan de contrôle, détermine sur quels nœuds démarrer les pods et les conteneurs. D'importants services sont exécutés sur chaque nœud de travail, notamment CRI-O, le moteur de conteneurs ; Kubelet, le service qui accepte et exécute les demandes d'exécution et d'arrêt des charges de travail des conteneurs ; un proxy de service, qui gère la communication entre les pods et les travailleurs ; et le runtime de conteneur de bas niveau runC ou crun (Technology Preview), qui crée et exécute les conteneurs.
Pour plus d'informations sur l'activation de crun au lieu de runC par défaut, voir la documentation relative à la création d'un CR ContainerRuntimeConfig.
Dans OpenShift Container Platform, les ensembles de machines de calcul contrôlent les machines de calcul, auxquelles est attribué le rôle de machine worker. Les machines dotées du rôle worker pilotent des charges de travail de calcul qui sont régies par un pool de machines spécifique qui les met à l'échelle automatiquement. Comme OpenShift Container Platform a la capacité de prendre en charge plusieurs types de machines, les machines ayant le rôle worker sont classées comme des machines compute. Dans cette version, les termes worker machine et compute machine sont utilisés de manière interchangeable car le seul type de machine de calcul par défaut est la machine de travail. Dans les versions futures d'OpenShift Container Platform, d'autres types de machines de calcul, telles que les machines d'infrastructure, pourraient être utilisées par défaut.
Les ensembles de machines de calcul sont des regroupements de ressources de machines 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. À l'inverse, les pools de configuration de machines (MCP) font partie de l'espace de noms Machine Config Operator (MCO). Un MCP est utilisé pour regrouper des machines afin que le MCO puisse gérer leurs configurations et faciliter leurs mises à niveau.
6.2.3. Plans de contrôle des clusters
Dans un cluster Kubernetes, les nœuds master exécutent les services nécessaires au contrôle du cluster Kubernetes. Dans OpenShift Container Platform, le plan de contrôle est composé de machines de plan de contrôle qui ont un rôle de machine master. Elles contiennent plus que les services Kubernetes pour gérer le cluster OpenShift Container Platform.
Pour la plupart des clusters OpenShift Container Platform, les machines du plan de contrôle sont définies par une série de ressources API de machines autonomes. Pour les combinaisons de fournisseurs de cloud et de versions d'OpenShift Container Platform prises en charge, les plans de contrôle peuvent être 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.
Trois nœuds de plan de contrôle exactement doivent être utilisés pour tous les déploiements de production.
Les services qui relèvent de la catégorie Kubernetes sur le plan de contrôle comprennent le serveur API Kubernetes, etcd, le gestionnaire de contrôleur Kubernetes et le planificateur Kubernetes.
| Composant | Description |
|---|---|
| Serveur API Kubernetes | 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 central pour l'état partagé du cluster. |
| etcd | etcd stocke l'état persistant du plan de contrôle tandis que d'autres composants surveillent etcd à la recherche de changements qui les amèneraient à l'état spécifié. |
| Gestionnaire de contrôleur Kubernetes | Le gestionnaire de contrôleur Kubernetes surveille etcd pour détecter les modifications apportées aux 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é. Plusieurs processus de ce type créent un cluster avec un leader actif à la fois. |
| Ordonnanceur Kubernetes | Le planificateur Kubernetes surveille 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, notamment le serveur API OpenShift, le gestionnaire de contrôleur OpenShift, le serveur API OpenShift OAuth et le serveur OpenShift OAuth.
| Composant | Description |
|---|---|
| Serveur API OpenShift | Le serveur API OpenShift valide et configure les données pour les ressources OpenShift, telles que les projets, les routes et les modèles. Le serveur OpenShift API est géré par l'opérateur OpenShift API Server. |
| Gestionnaire de contrôleur OpenShift | Le gestionnaire de contrôleur OpenShift surveille etcd pour les changements d'objets OpenShift, tels que les objets de projet, de route et de contrôleur de modèle, et utilise ensuite l'API pour appliquer l'état spécifié. Le gestionnaire de contrôleur OpenShift est géré par l'opérateur de gestionnaire de contrôleur OpenShift. |
| Serveur OpenShift OAuth API | Le serveur OpenShift OAuth API valide et configure les données d'authentification à OpenShift Container Platform, telles que les utilisateurs, les groupes et les jetons OAuth. Le serveur OpenShift OAuth API est géré par le Cluster Authentication Operator. |
| Serveur OpenShift OAuth | Les utilisateurs demandent des jetons au serveur OpenShift OAuth pour s'authentifier auprès de l'API. Le serveur OpenShift OAuth est géré par le Cluster Authentication Operator. |
Certains de ces services sur les machines du plan de contrôle s'exécutent en tant que services systemd, tandis que d'autres s'exécutent en tant que pods statiques.
Les services Systemd sont appropriés pour les services qui doivent toujours apparaître sur un système particulier peu de temps après son démarrage. Pour les machines du plan de contrôle, il s'agit notamment de sshd, qui permet de se connecter à distance. Ils comprennent également des services tels que :
- Le moteur de conteneurs CRI-O (crio), qui exécute et gère les conteneurs. OpenShift Container Platform 4.12 utilise CRI-O à la place de Docker Container Engine.
- Kubelet (kubelet), qui accepte les demandes de gestion des conteneurs sur la machine à partir des services du plan de contrôle.
CRI-O et Kubelet doivent être exécutés directement sur l'hôte en tant que services systemd, car ils doivent fonctionner avant que vous puissiez exécuter d'autres conteneurs.
Les pods de plan de contrôle installer-* et revision-pruner-* doivent être exécutés avec les permissions de l'utilisateur root car ils écrivent dans le répertoire /etc/kubernetes, qui appartient à l'utilisateur root. Ces modules se trouvent dans les espaces de noms suivants :
-
openshift-etcd -
openshift-kube-apiserver -
openshift-kube-controller-manager -
openshift-kube-scheduler
