1.2. Dimensionnement des nœuds du plan de contrôle
Les besoins en ressources des nœuds du plan de contrôle dépendent du nombre et du type de nœuds et d'objets dans le cluster. Les recommandations suivantes concernant la taille des nœuds du plan de contrôle sont basées sur les résultats d'un test focalisé sur la densité du plan de contrôle, ou Cluster-density. Ce test crée les objets suivants dans un nombre donné d'espaces de noms :
- 1 flux d'images
- 1 construire
-
5 déploiements, avec 2 répliques de pods à l'état
sleep, montant chacun 4 secrets, 4 cartes de configuration et 1 volume d'API descendant - 5 services, chacun pointant vers les ports TCP/8080 et TCP/8443 d'un des déploiements précédents
- 1 itinéraire menant au premier des services précédents
- 10 secrets contenant 2048 caractères aléatoires
- 10 cartes de configuration contenant 2048 caractères aléatoires
| Number of worker nodes | Densité de la grappe (espaces nominatifs) | Cœurs de l'unité centrale | Mémoire (GB) |
|---|---|---|---|
| 24 | 500 | 4 | 16 |
| 120 | 1000 | 8 | 32 |
| 252 | 4000 | 16, mais 24 si l'on utilise le plug-in réseau OVN-Kubernetes | 64, mais 128 si l'on utilise le plug-in réseau OVN-Kubernetes |
| 501, mais non testé avec le plug-in réseau OVN-Kubernetes | 4000 | 16 | 96 |
Les données du tableau ci-dessus sont basées sur une plateforme de conteneurs OpenShift fonctionnant au-dessus d'AWS, utilisant des instances r5.4xlarge comme nœuds de plan de contrôle et des instances m5.2xlarge comme nœuds de travail.
Dans un grand cluster dense comprenant trois nœuds de plan de contrôle, l'utilisation du processeur et de la mémoire augmente lorsque l'un des nœuds est arrêté, redémarré ou tombe en panne. Les pannes peuvent être dues à des problèmes inattendus d'alimentation, de réseau, d'infrastructure sous-jacente, ou à des cas intentionnels où le cluster est redémarré après avoir été arrêté pour réduire les coûts. Les deux nœuds restants du plan de contrôle doivent gérer la charge afin d'être hautement disponibles, ce qui entraîne une augmentation de l'utilisation des ressources. Ce phénomène se produit également lors des mises à niveau, car les nœuds du plan de contrôle sont isolés, vidés et redémarrés en série pour appliquer les mises à jour du système d'exploitation, ainsi que la mise à jour des opérateurs du plan de contrôle. Pour éviter les défaillances en cascade, maintenez l'utilisation globale des ressources CPU et mémoire sur les nœuds du plan de contrôle à un maximum de 60 % de la capacité disponible afin de gérer les pics d'utilisation des ressources. Augmentez l'UC et la mémoire des nœuds du plan de contrôle en conséquence pour éviter les temps d'arrêt potentiels dus au manque de ressources.
Le dimensionnement des nœuds varie en fonction du nombre de nœuds et d'objets dans la grappe. Il dépend également de la création active d'objets sur la grappe. Pendant la création des objets, le plan de contrôle est plus actif en termes d'utilisation des ressources que lorsque les objets sont dans la phase running.
Operator Lifecycle Manager (OLM) s'exécute sur les nœuds du plan de contrôle et son empreinte mémoire dépend du nombre d'espaces de noms et d'opérateurs installés par l'utilisateur qu'OLM doit gérer sur la grappe. Les nœuds du plan de contrôle doivent être dimensionnés en conséquence afin d'éviter les pertes de mémoire (OOM kills). Les points de données suivants sont basés sur les résultats des tests de maximisation des grappes.
| Nombre d'espaces de noms | Mémoire OLM au repos (GB) | Mémoire OLM avec 5 opérateurs utilisateurs installés (GB) |
|---|---|---|
| 500 | 0.823 | 1.7 |
| 1000 | 1.2 | 2.5 |
| 1500 | 1.7 | 3.2 |
| 2000 | 2 | 4.4 |
| 3000 | 2.7 | 5.6 |
| 4000 | 3.8 | 7.6 |
| 5000 | 4.2 | 9.02 |
| 6000 | 5.8 | 11.3 |
| 7000 | 6.6 | 12.9 |
| 8000 | 6.9 | 14.8 |
| 9000 | 8 | 17.7 |
| 10,000 | 9.9 | 21.6 |
Vous pouvez modifier la taille des nœuds du plan de contrôle dans un cluster OpenShift Container Platform 4.12 en cours d'exécution pour les configurations suivantes uniquement :
- Clusters installés avec une méthode d'installation fournie par l'utilisateur.
- Clusters AWS installés avec une méthode d'installation d'infrastructure fournie par l'installateur.
- Les clusters qui utilisent un jeu de machines du plan de contrôle pour gérer les machines du plan de contrôle.
Pour toutes les autres configurations, vous devez estimer le nombre total de nœuds et utiliser la taille de nœud suggérée pour le plan de contrôle lors de l'installation.
Les recommandations sont basées sur les points de données capturés sur les clusters OpenShift Container Platform avec OpenShift SDN comme plugin réseau.
Dans OpenShift Container Platform 4.12, la moitié d'un cœur de CPU (500 millicores) est désormais réservée par le système par défaut par rapport à OpenShift Container Platform 3.11 et aux versions précédentes. Les tailles sont déterminées en tenant compte de cela.
1.2.1. Sélection d'un type d'instance Amazon Web Services plus important pour les machines du plan de contrôle
Si les machines du plan de contrôle d'un cluster Amazon Web Services (AWS) ont besoin de plus de ressources, vous pouvez sélectionner un type d'instance AWS plus important pour les machines du plan de contrôle.
La procédure pour les clusters qui utilisent un jeu de machines du plan de contrôle est différente de la procédure pour les clusters qui n'utilisent pas de jeu de machines du plan de contrôle.
Si vous n'êtes pas sûr de l'état de la CR ControlPlaneMachineSet dans votre cluster, vous pouvez vérifier l'état de la CR.
1.2.1.1. Modifier le type d'instance Amazon Web Services à l'aide d'un jeu de machines du plan de contrôle
Vous pouvez modifier le type d'instance Amazon Web Services (AWS) que vos machines du plan de contrôle utilisent en mettant à jour la spécification dans la ressource personnalisée (CR) de l'ensemble de machines du plan de contrôle.
Conditions préalables
- Votre cluster AWS utilise un jeu de machines de plan de contrôle.
Procédure
Modifiez le jeu de machines CR de votre plan de contrôle en exécutant la commande suivante :
$ oc --namespace openshift-machine-api edit controlplanemachineset.machine.openshift.io cluster
Modifiez la ligne suivante sous le champ
providerSpec:providerSpec: value: ... instanceType: <compatible_aws_instance_type> 1- 1
- Spécifiez un type d'instance AWS plus important avec la même base que la sélection précédente. Par exemple, vous pouvez remplacer
m6i.xlargeparm6i.2xlargeoum6i.4xlarge.
Enregistrez vos modifications.
-
Pour les clusters qui utilisent la stratégie de mise à jour par défaut
RollingUpdate, l'opérateur propage automatiquement les modifications à votre configuration du plan de contrôle. -
Pour les clusters configurés pour utiliser la stratégie de mise à jour
OnDelete, vous devez remplacer manuellement les machines du plan de contrôle.
-
Pour les clusters qui utilisent la stratégie de mise à jour par défaut
Ressources supplémentaires
1.2.1.2. Modifier le type d'instance Amazon Web Services à l'aide de la console AWS
Vous pouvez modifier le type d'instance Amazon Web Services (AWS) utilisé par les machines du plan de contrôle en mettant à jour le type d'instance dans la console AWS.
Conditions préalables
- Vous avez accès à la console AWS avec les permissions nécessaires pour modifier l'Instance EC2 de votre cluster.
-
Vous avez accès au cluster OpenShift Container Platform en tant qu'utilisateur ayant le rôle
cluster-admin.
Procédure
- Ouvrez la console AWS et récupérez les instances des machines du plan de contrôle.
Choisissez une instance de machine de plan de contrôle.
- Pour la machine de plan de contrôle sélectionnée, sauvegardez les données etcd en créant un instantané etcd. Pour plus d'informations, voir "Sauvegarde de etcd".
- Dans la console AWS, arrêtez l'instance de machine du plan de contrôle.
-
Sélectionnez l'instance arrêtée et cliquez sur Actions
Instance Settings Change instance type. -
Remplacez l'instance par un type plus grand, en veillant à ce que le type soit de la même base que la sélection précédente, et appliquez les modifications. Par exemple, vous pouvez remplacer
m6i.xlargeparm6i.2xlargeoum6i.4xlarge. - Démarrer l'instance.
-
Si votre cluster OpenShift Container Platform possède un objet
Machinecorrespondant à l'instance, mettez à jour le type d'instance de l'objet pour qu'il corresponde au type d'instance défini dans la console AWS.
- Répétez ce processus pour chaque machine du plan de contrôle.
Ressources supplémentaires
