7.3. Déploiement des contrôles de santé des machines
Comprendre et déployer les contrôles de santé des machines.
Vous ne pouvez utiliser les fonctionnalités avancées de gestion et de mise à l'échelle des machines que dans les clusters où l'API Machine est opérationnelle. Les clusters dont l'infrastructure est fournie par l'utilisateur nécessitent une validation et une configuration supplémentaires pour utiliser l'API Machine.
Les clusters avec le type de plateforme d'infrastructure none ne peuvent pas utiliser l'API Machine. Cette limitation s'applique même si les machines de calcul attachées au cluster sont installées sur une plateforme qui prend en charge cette fonctionnalité. Ce paramètre ne peut pas être modifié après l'installation.
Pour afficher le type de plateforme de votre cluster, exécutez la commande suivante :
$ oc get infrastructure cluster -o jsonpath='{.status.platform}'7.3.1. À propos des contrôles de santé des machines
Vous ne pouvez appliquer un contrôle de l'état des machines qu'aux machines du plan de contrôle des clusters qui utilisent des jeux de machines du plan de contrôle.
Pour surveiller l'état des machines, créez une ressource afin de définir la configuration d'un contrôleur. Définissez une condition à vérifier, telle que le maintien de l'état NotReady pendant cinq minutes ou l'affichage d'une condition permanente dans le détecteur de problèmes de nœuds, ainsi qu'une étiquette pour l'ensemble des machines à surveiller.
Le contrôleur qui observe une ressource MachineHealthCheck vérifie la condition définie. Si une machine échoue au contrôle de santé, elle est automatiquement supprimée et une autre est créée pour la remplacer. Lorsqu'une machine est supprimée, un événement machine deleted s'affiche.
Pour limiter l'impact perturbateur de la suppression des machines, le contrôleur ne draine et ne supprime qu'un seul nœud à la fois. S'il y a plus de machines malsaines que le seuil maxUnhealthy ne le permet dans le groupe de machines ciblées, la remédiation s'arrête et permet donc une intervention manuelle.
Les délais d'attente doivent être étudiés avec soin, en tenant compte de la charge de travail et des besoins.
- Les délais d'attente prolongés peuvent entraîner de longues périodes d'indisponibilité de la charge de travail sur la machine en état d'insalubrité.
-
Des délais trop courts peuvent entraîner une boucle de remédiation. Par exemple, le délai de vérification de l'état de
NotReadydoit être suffisamment long pour permettre à la machine de terminer le processus de démarrage.
Pour arrêter le contrôle, retirez la ressource.
7.3.1.1. Limitations lors du déploiement des contrôles de santé des machines
Il y a des limites à prendre en compte avant de déployer un bilan de santé machine :
- Seules les machines appartenant à un jeu de machines sont remédiées par un bilan de santé de la machine.
- Si le nœud d'une machine est supprimé du cluster, un contrôle de santé de la machine considère que la machine n'est pas en bonne santé et y remédie immédiatement.
-
Si le nœud correspondant à une machine ne rejoint pas le cluster après le
nodeStartupTimeout, la machine est remédiée. -
Une machine est remédiée immédiatement si la phase de ressource
MachineestFailed.
Ressources supplémentaires
7.3.2. Exemple de ressource MachineHealthCheck
La ressource MachineHealthCheck pour tous les types d'installation basés sur le cloud, et autre que bare metal, ressemble au fichier YAML suivant :
apiVersion: machine.openshift.io/v1beta1 kind: MachineHealthCheck metadata: name: example 1 namespace: openshift-machine-api spec: selector: matchLabels: machine.openshift.io/cluster-api-machine-role: <role> 2 machine.openshift.io/cluster-api-machine-type: <role> 3 machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> 4 unhealthyConditions: - type: "Ready" timeout: "300s" 5 status: "False" - type: "Ready" timeout: "300s" 6 status: "Unknown" maxUnhealthy: "40%" 7 nodeStartupTimeout: "10m" 8
- 1
- Indiquez le nom du bilan de santé de la machine à déployer.
- 2 3
- Spécifiez une étiquette pour le pool de machines que vous souhaitez vérifier.
- 4
- Indiquez le jeu de machines à suivre au format
<cluster_name>-<label>-<zone>. Par exemple,prod-node-us-east-1a. - 5 6
- Spécifiez la durée du délai d'attente pour une condition de nœud. Si une condition est remplie pendant la durée du délai, la machine sera remédiée. Les délais d'attente prolongés peuvent entraîner de longues périodes d'indisponibilité pour une charge de travail sur une machine en mauvais état.
- 7
- Spécifiez le nombre de machines autorisées à être assainies simultanément dans le pool ciblé. Il peut s'agir d'un pourcentage ou d'un nombre entier. Si le nombre de machines malsaines dépasse la limite fixée par
maxUnhealthy, la remédiation n'est pas effectuée. - 8
- Spécifiez le délai d'attente pour qu'un contrôle de l'état de santé d'une machine attende qu'un nœud rejoigne la grappe avant qu'une machine ne soit considérée comme étant en mauvais état.
Le site matchLabels n'est qu'un exemple ; vous devez définir vos groupes de machines en fonction de vos besoins spécifiques.
7.3.2.1. Court-circuitage du contrôle de santé de la machine remédiation
Le court-circuitage garantit que les contrôles de santé des machines ne remédient aux machines que lorsque le cluster est sain. Le court-circuitage est configuré via le champ maxUnhealthy de la ressource MachineHealthCheck.
Si l'utilisateur définit une valeur pour le champ maxUnhealthy, avant de remédier à des machines, MachineHealthCheck compare la valeur de maxUnhealthy avec le nombre de machines dans son pool cible qu'il a déterminé comme n'étant pas en bonne santé. La remédiation n'est pas effectuée si le nombre de machines malsaines dépasse la limite fixée par maxUnhealthy.
Si maxUnhealthy n'est pas défini, la valeur par défaut est 100% et les machines sont remédiées quel que soit l'état du cluster.
La valeur appropriée de maxUnhealthy dépend de l'échelle du cluster que vous déployez et du nombre de machines couvertes par MachineHealthCheck. Par exemple, vous pouvez utiliser la valeur maxUnhealthy pour couvrir plusieurs ensembles de machines de calcul dans plusieurs zones de disponibilité, de sorte que si vous perdez une zone entière, votre paramètre maxUnhealthy empêche toute autre remédiation au sein du cluster. Dans les régions Azure globales qui ne disposent pas de plusieurs zones de disponibilité, vous pouvez utiliser des ensembles de disponibilité pour assurer une haute disponibilité.
Si vous configurez une ressource MachineHealthCheck pour le plan de contrôle, définissez la valeur de maxUnhealthy sur 1.
Cette configuration garantit que le contrôle de l'état des machines ne prend aucune mesure lorsque plusieurs machines du plan de contrôle semblent être en mauvaise santé. Plusieurs machines de plan de contrôle malsaines peuvent indiquer que le cluster etcd est dégradé ou qu'une opération de mise à l'échelle visant à remplacer une machine défaillante est en cours.
Si le cluster etcd est dégradé, une intervention manuelle peut être nécessaire. Si une opération de mise à l'échelle est en cours, le bilan de santé de la machine doit permettre de la terminer.
Le champ maxUnhealthy peut être défini comme un nombre entier ou un pourcentage. Il existe différentes implémentations de remédiation en fonction de la valeur de maxUnhealthy.
7.3.2.1.1. Réglage de l'insalubrité maximale par l'utilisation d'une valeur absolue
Si maxUnhealthy est défini sur 2:
- La remédiation sera effectuée si 2 nœuds ou moins sont malsains
- La remédiation ne sera pas effectuée si 3 nœuds ou plus sont malsains
Ces valeurs sont indépendantes du nombre de machines contrôlées par le bilan de santé.
7.3.2.1.2. Fixation de l'insalubrité maximale à l'aide de pourcentages
Si maxUnhealthy est défini sur 40% et qu'il y a 25 machines en cours de vérification :
- La remédiation sera effectuée si 10 nœuds ou moins sont malsains
- La remédiation ne sera pas effectuée si 11 nœuds ou plus sont malsains
Si maxUnhealthy est défini sur 40% et qu'il y a 6 machines en cours de contrôle :
- La remédiation sera effectuée si 2 nœuds ou moins sont malsains
- La remédiation ne sera pas effectuée si 3 nœuds ou plus sont malsains
Le nombre de machines autorisé est arrondi à la baisse lorsque le pourcentage de machines maxUnhealthy contrôlées n'est pas un nombre entier.
7.3.3. Création d'une ressource pour le bilan de santé d'une machine
Vous pouvez créer une ressource MachineHealthCheck pour les ensembles de machines de votre cluster.
Vous ne pouvez appliquer un contrôle de l'état des machines qu'aux machines du plan de contrôle des clusters qui utilisent des jeux de machines du plan de contrôle.
Conditions préalables
-
Installer l'interface de ligne de commande
oc.
Procédure
-
Créez un fichier
healthcheck.ymlqui contient la définition du contrôle de l'état de santé de votre machine. Appliquez le fichier
healthcheck.ymlà votre cluster :$ oc apply -f healthcheck.yml
7.3.4. Mise à l'échelle manuelle d'un ensemble de machines de calcul
Pour ajouter ou supprimer une instance d'une machine dans un ensemble de machines de calcul, vous pouvez mettre à l'échelle manuellement l'ensemble de machines de calcul.
Ce guide s'applique aux installations d'infrastructure entièrement automatisées et fournies par l'installateur. Les installations d'infrastructure personnalisées et fournies par l'utilisateur n'ont pas d'ensembles de machines de calcul.
Conditions préalables
-
Installer un cluster OpenShift Container Platform et la ligne de commande
oc. -
Connectez-vous à
ocen tant qu'utilisateur disposant de l'autorisationcluster-admin.
Procédure
Affichez les ensembles de machines de calcul qui se trouvent dans le cluster en exécutant la commande suivante :
$ oc get machinesets -n openshift-machine-api
Les ensembles de machines de calcul sont répertoriés sous la forme de
<clusterid>-worker-<aws-region-az>.Affichez les machines de calcul qui se trouvent dans le cluster en exécutant la commande suivante :
$ oc get machine -n openshift-machine-api
Définissez l'annotation sur la machine de calcul que vous souhaitez supprimer en exécutant la commande suivante :
$ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"
Mettez à l'échelle l'ensemble de machines de calcul en exécutant l'une des commandes suivantes :
$ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
Ou bien :
$ oc edit machineset <machineset> -n openshift-machine-api
AstuceVous pouvez également appliquer le YAML suivant pour mettre à l'échelle l'ensemble des machines de calcul :
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: name: <machineset> namespace: openshift-machine-api spec: replicas: 2
Vous pouvez augmenter ou diminuer le nombre de machines de calcul. Il faut quelques minutes pour que les nouvelles machines soient disponibles.
ImportantPar défaut, le contrôleur de machine tente de drainer le nœud soutenu par la machine jusqu'à ce qu'il y parvienne. Dans certaines situations, comme dans le cas d'un budget de perturbation de pods mal configuré, l'opération de vidange peut ne pas aboutir. Si l'opération de vidange échoue, le contrôleur de machine ne peut pas procéder au retrait de la machine.
Vous pouvez éviter de vider le nœud en annotant
machine.openshift.io/exclude-node-drainingdans une machine spécifique.
Vérification
Vérifiez la suppression de la machine prévue en exécutant la commande suivante :
$ oc get machines
7.3.5. Comprendre la différence entre les ensembles de machines de calcul et le pool de configuration des machines
MachineSet décrivent les nœuds d'OpenShift Container Platform par rapport au fournisseur de nuages ou de machines.
L'objet MachineConfigPool permet aux composants MachineConfigController de définir et de fournir l'état des machines dans le contexte des mises à niveau.
L'objet MachineConfigPool permet aux utilisateurs de configurer la manière dont les mises à niveau sont déployées sur les nœuds OpenShift Container Platform dans le pool de configuration de la machine.
L'objet NodeSelector peut être remplacé par une référence à l'objet MachineSet.
