5.6. Assainissement, clôtures et entretien

5.6.1. À propos de l'assainissement des nœuds, des clôtures et de l'entretien

Le matériel est imparfait et les logiciels contiennent des bogues. Lorsque des défaillances au niveau des nœuds, telles que le blocage du noyau ou des contrôleurs d'interface réseau (NIC), surviennent, le travail demandé à la grappe ne diminue pas et les charges de travail des nœuds concernés doivent être redémarrées quelque part. Cependant, certaines charges de travail, telles que les volumes ReadWriteOnce (RWO) et les StatefulSets, peuvent nécessiter une sémantique "at-most-one".

Les défaillances affectant ces charges de travail risquent d'entraîner la perte ou la corruption de données, voire les deux. Il est important de veiller à ce que le nœud atteigne un état sûr ( fencing ) avant d'entamer la reprise de la charge de travail ( remediation ) et, idéalement, la reprise du nœud.

Il n'est pas toujours pratique de dépendre de l'intervention de l'administrateur pour confirmer l'état réel des nœuds et des charges de travail. Pour faciliter cette intervention, OpenShift Container Platform fournit plusieurs composants pour l'automatisation de la détection des défaillances, de la clôture et de la remédiation.

5.6.1.1. Remédiation autonome des nœuds

Le Self Node Remediation Operator est un opérateur complémentaire d'OpenShift Container Platform qui met en œuvre un système externe de clôture et de remédiation qui redémarre les nœuds malsains et supprime les ressources, telles que les Pods et les VolumeAttachments. Le redémarrage garantit que les charges de travail sont clôturées et la suppression des ressources accélère la reprogrammation des charges de travail affectées. Contrairement à d'autres systèmes externes, Self Node Remediation ne nécessite aucune interface de gestion, comme, par exemple, Intelligent Platform Management Interface (IPMI) ou une API pour le provisionnement des nœuds.

L'auto-remédiation des nœuds peut être utilisée par les systèmes de détection des défaillances, comme le bilan de santé de la machine ou le bilan de santé du nœud.

5.6.1.2. Bilan de santé de la machine

Machine Health Check utilise un système intégré de détection des défaillances, de clôture et de remédiation d'OpenShift Container Platform, qui surveille l'état des machines et les conditions des nœuds. Les bilans de santé des machines peuvent être configurés pour déclencher des systèmes de clôture et de remédiation externes, tels que Self Node Remediation.

5.6.1.3. Bilan de santé du nœud

L'opérateur Node Health Check est un opérateur complémentaire d'OpenShift Container Platform qui met en œuvre un système de détection des défaillances qui surveille l'état des nœuds. Il ne dispose pas d'un système de clôture ou de remédiation intégré et doit donc être configuré avec un système externe qui fournit de telles fonctionnalités. Par défaut, il est configuré pour utiliser le système Self Node Remediation.

5.6.1.4. Maintenance des nœuds

Les administrateurs sont confrontés à des situations où ils doivent interrompre la grappe, par exemple pour remplacer un disque, de la mémoire vive ou une carte d'interface réseau.

Avant cette maintenance, les nœuds concernés doivent être isolés et vidés. Lorsqu'un nœud est isolé, il n'est pas possible de programmer de nouvelles charges de travail sur ce nœud. Lorsqu'un nœud est vidé, pour éviter ou minimiser les temps d'arrêt, les charges de travail sur le nœud affecté sont transférées vers d'autres nœuds.

Bien que cette maintenance puisse être réalisée à l'aide d'outils de ligne de commande, l'opérateur de maintenance de nœuds offre une approche déclarative pour y parvenir en utilisant une ressource personnalisée. Lorsqu'une telle ressource existe pour un nœud, l'opérateur cordonne et draine le nœud jusqu'à ce que la ressource soit supprimée.

5.6.2. Utilisation de l'auto-remédiation des nœuds

Vous pouvez utiliser l'opérateur Self Node Remediation pour redémarrer automatiquement les nœuds en mauvais état. Cette stratégie de remédiation minimise les temps d'arrêt pour les applications avec état et les volumes ReadWriteOnce (RWO), et rétablit la capacité de calcul en cas de défaillances transitoires.

5.6.2.1. À propos de l'opérateur d'assainissement autonome des nœuds

L'opérateur Self Node Remediation s'exécute sur les nœuds de la grappe et redémarre les nœuds identifiés comme étant en mauvaise santé. L'opérateur utilise le contrôleur MachineHealthCheck ou NodeHealthCheck pour détecter l'état d'un nœud dans la grappe. Lorsqu'un nœud est identifié comme étant en mauvaise santé, la ressource MachineHealthCheck ou NodeHealthCheck crée la ressource personnalisée (CR) SelfNodeRemediation, qui déclenche l'opérateur Self Node Remediation.

Le CR SelfNodeRemediation ressemble au fichier YAML suivant :

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediation
metadata:
  name: selfnoderemediation-sample
  namespace: openshift-operators
spec:
status:
  lastError: <last_error_message> 1

1: Affiche la dernière erreur survenue pendant la remédiation. Lorsque la remédiation réussit ou qu'aucune erreur ne se produit, le champ reste vide.

L'opérateur Self Node Remediation minimise les temps d'arrêt des applications avec état et rétablit la capacité de calcul en cas de défaillance transitoire. Vous pouvez utiliser cet opérateur quelle que soit l'interface de gestion (IPMI ou API pour le provisionnement d'un nœud) et quel que soit le type d'installation du cluster (infrastructure provisionnée par l'installateur ou par l'utilisateur).

5.6.2.1.1. À propos des dispositifs de surveillance

Les dispositifs de surveillance peuvent être l'un des suivants :

Dispositifs matériels alimentés de manière indépendante
Dispositifs matériels qui partagent l'énergie avec les hôtes qu'ils contrôlent
Dispositifs virtuels mis en œuvre dans un logiciel, ou softdog

Les dispositifs matériels de surveillance (watchdog) et softdog disposent respectivement d'une minuterie électronique ou logicielle. Ces dispositifs de surveillance sont utilisés pour garantir que la machine entre dans un état sûr lorsqu'une condition d'erreur est détectée. Le cluster doit réinitialiser à plusieurs reprises la minuterie du chien de garde pour prouver qu'il est dans un état sain. Cette minuterie peut s'écouler en raison de conditions d'erreur, telles que des blocages, des pannes de CPU et des pertes d'accès au réseau ou au disque. Si le délai expire, le dispositif de chien de garde suppose qu'une erreur s'est produite et déclenche une réinitialisation forcée du nœud.

Les dispositifs de surveillance matériels sont plus fiables que les dispositifs softdog.

5.6.2.1.1.1. Comprendre le comportement de l'opérateur de remédiation des nœuds autonomes avec les dispositifs de surveillance

L'opérateur de remédiation du nœud autonome détermine la stratégie de remédiation en fonction des dispositifs de surveillance présents.

Si un dispositif de surveillance matériel est configuré et disponible, l'opérateur l'utilise pour la remédiation. Si un dispositif de surveillance matériel n'est pas configuré, l'opérateur active et utilise un dispositif softdog pour la remédiation.

Si aucun dispositif de surveillance n'est pris en charge, que ce soit par le système ou par la configuration, l'opérateur remédie aux nœuds en utilisant le redémarrage du logiciel.

Ressources supplémentaires

Configuration d'un chien de garde

5.6.2.2. Clôture du plan de contrôle

Dans les versions précédentes, vous pouviez activer les fonctions Self Node Remediation et Node Health Check sur les nœuds de travail. En cas de défaillance d'un nœud, vous pouvez désormais suivre des stratégies de remédiation sur les nœuds du plan de contrôle.

L'auto-assainissement d'un nœud se produit dans deux scénarios principaux.

Connectivité au serveur API
- Dans ce scénario, le nœud du plan de contrôle à assainir n'est pas isolé. Il peut être directement connecté au serveur API ou indirectement connecté au serveur API par l'intermédiaire de nœuds de travail ou de nœuds du plan de contrôle, qui sont directement connectés au serveur API.
- En cas de connectivité avec le serveur API, le nœud du plan de contrôle ne fait l'objet d'une remédiation que si l'opérateur du bilan de santé du nœud a créé une ressource personnalisée (CR) SelfNodeRemediation pour le nœud.
Pas de connectivité avec le serveur API
- Dans ce scénario, le nœud du plan de contrôle à assainir est isolé du serveur API. Le nœud ne peut pas se connecter directement ou indirectement au serveur API.
- Lorsqu'il n'y a pas de connectivité avec le serveur API, le nœud du plan de contrôle sera remédié comme indiqué dans les étapes suivantes :
  - Vérifier l'état du nœud du plan de contrôle auprès de la majorité des nœuds homologues. Si la majorité des nœuds homologues ne peut être jointe, le nœud sera analysé plus en détail.
    Autodiagnostic de l'état du nœud du plan de contrôle
    Si l'autodiagnostic est réussi, aucune action n'est entreprise.
    Si l'autodiagnostic a échoué, le nœud sera clôturé et remédié.
    Les autodiagnostics actuellement pris en charge sont la vérification de l'état du service kubelet et la vérification de la disponibilité des points d'extrémité à l'aide de la configuration opt in.
  - Si le nœud n'a pas réussi à communiquer avec la plupart de ses homologues, vérifiez la connectivité du nœud de plan de contrôle avec d'autres nœuds de plan de contrôle. Si le nœud peut communiquer avec n'importe quel autre homologue du plan de contrôle, aucune mesure ne sera prise. Dans le cas contraire, le nœud sera clôturé et remédié.

5.6.2.3. Installation du Self Node Remediation Operator à l'aide de la console web

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer le Self Node Remediation Operator.

Note

L'opérateur du bilan de santé du nœud installe également l'opérateur de remédiation du nœud lui-même en tant que fournisseur de remédiation par défaut.

Conditions préalables

Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Dans la console web d'OpenShift Container Platform, naviguez vers Operators OperatorHub.
Recherchez l'opérateur d'assainissement autonome dans la liste des opérateurs disponibles, puis cliquez sur Install.
Conservez la sélection par défaut de Installation mode et namespace pour vous assurer que l'opérateur est installé dans l'espace de noms openshift-operators.
Cliquez sur Install.

Vérification

Pour confirmer que l'installation a réussi :

Naviguez jusqu'à la page Operators Installed Operators.
Vérifiez que l'Opérateur est installé dans l'espace de noms openshift-operators et que son statut est Succeeded.

Si l'opérateur n'est pas installé correctement :

Naviguez jusqu'à la page Operators Installed Operators et vérifiez que la colonne Status ne contient pas d'erreurs ou de défaillances.
Naviguez jusqu'à la page Workloads Pods et vérifiez les journaux de tous les pods du projet self-node-remediation-controller-manager qui signalent des problèmes.

5.6.2.4. Installation du Self Node Remediation Operator à l'aide de la CLI

Vous pouvez utiliser l'OpenShift CLI (oc) pour installer le Self Node Remediation Operator.

Vous pouvez installer le Self Node Remediation Operator dans votre propre espace de noms ou dans l'espace de noms openshift-operators.

Pour installer l'opérateur dans votre propre espace de noms, suivez les étapes de la procédure.

Pour installer l'opérateur dans l'espace de noms openshift-operators, passez à l'étape 3 de la procédure car les étapes de création d'une nouvelle ressource personnalisée (CR) Namespace et d'une CR OperatorGroup ne sont pas nécessaires.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer une ressource personnalisée (CR) Namespace pour l'opérateur de remédiation de nœud autonome :
1. Définissez le CR Namespace et enregistrez le fichier YAML, par exemple self-node-remediation-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: self-node-remediation
```
2. Pour créer le CR Namespace, exécutez la commande suivante :
```
$ oc create -f self-node-remediation-namespace.yaml
```
Créer un CR OperatorGroup:
1. Définissez le CR OperatorGroup et enregistrez le fichier YAML, par exemple self-node-remediation-operator-group.yaml:
```
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: self-node-remediation-operator
  namespace: self-node-remediation
```
2. Pour créer le CR OperatorGroup, exécutez la commande suivante :
```
$ oc create -f self-node-remediation-operator-group.yaml
```
Créer un CR Subscription:
1. Définissez le CR Subscription et enregistrez le fichier YAML, par exemple self-node-remediation-subscription.yaml:
```
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
    name: self-node-remediation-operator
    namespace: self-node-remediation 1
spec:
    channel: stable
    installPlanApproval: Manual 2
    name: self-node-remediation-operator
    source: redhat-operators
    sourceNamespace: openshift-marketplace
    package: self-node-remediation
```
  1
  Indiquez le site Namespace où vous souhaitez installer l'opérateur d'assainissement de l'auto-nœud. Pour installer l'opérateur d'auto-assainissement de nœud dans l'espace de noms openshift-operators, spécifiez openshift-operators dans le CR Subscription.
  2
  Définissez la stratégie d'approbation sur Manuel au cas où la version spécifiée serait remplacée par une version ultérieure dans le catalogue. Ce plan empêche une mise à niveau automatique vers une version ultérieure et nécessite une approbation manuelle avant que le CSV de départ ne puisse terminer l'installation.
2. Pour créer le CR Subscription, exécutez la commande suivante :
```
$ oc create -f self-node-remediation-subscription.yaml
```

Vérification

Vérifiez que l'installation a réussi en inspectant la ressource CSV :

$ oc get csv -n self-node-remediation

Exemple de sortie

NAME                               DISPLAY                          VERSION   REPLACES   PHASE
self-node-remediation.v.0.4.0      Self Node Remediation Operator   v.0.4.0              Succeeded

Vérifiez que l'opérateur de remédiation de nœuds autonomes est opérationnel :

$ oc get deploy -n self-node-remediation

Exemple de sortie

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
self-node-remediation-controller-manager    1/1     1            1           28h

Vérifier que l'opérateur d'assainissement autonome a créé la CR SelfNodeRemediationConfig:

$ oc get selfnoderemediationconfig -n self-node-remediation

Exemple de sortie

NAME                           AGE
self-node-remediation-config   28h

Vérifiez que chaque pod de remédiation de nœud autonome est planifié et en cours d'exécution sur chaque nœud de travail :

$ oc get daemonset -n self-node-remediation

Exemple de sortie

NAME                      DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE SELECTOR  AGE
self-node-remediation-ds  3        3        3      3           3          <none>         28h

Note

Cette commande n'est pas prise en charge pour les nœuds du plan de contrôle.

5.6.2.5. Configuration de l'opérateur de remédiation du nœud autonome

L'opérateur de remédiation du nœud autonome crée la CR SelfNodeRemediationConfig et la définition de ressource personnalisée (CRD) SelfNodeRemediationTemplate.

5.6.2.5.1. Comprendre la configuration de l'opérateur de remédiation du nœud autonome

L'opérateur d'assainissement de l'auto-nœud crée le CR SelfNodeRemediationConfig avec le nom self-node-remediation-config. Le CR est créé dans l'espace de noms de l'opérateur d'assainissement de l'auto-nœud.

Un changement dans le CR SelfNodeRemediationConfig recrée le jeu de démons Self Node Remediation.

Le CR SelfNodeRemediationConfig ressemble au fichier YAML suivant :

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationConfig
metadata:
  name: self-node-remediation-config
  namespace: openshift-operators
spec:
  safeTimeToAssumeNodeRebootedSeconds: 180 1
  watchdogFilePath: /dev/watchdog 2
  isSoftwareRebootEnabled: true 3
  apiServerTimeout: 15s 4
  apiCheckInterval: 5s 5
  maxApiErrorThreshold: 3 6
  peerApiServerTimeout: 5s 7
  peerDialTimeout: 5s 8
  peerRequestTimeout: 5s 9
  peerUpdateInterval: 15m 10

1: Indiquez le délai d'attente pour l'homologue survivant, après lequel l'opérateur peut supposer qu'un nœud malsain a été redémarré. L'opérateur calcule automatiquement la limite inférieure de cette valeur. Toutefois, si différents nœuds ont des délais d'attente différents, vous devez remplacer cette valeur par une valeur plus élevée.
2: Indiquez le chemin d'accès au fichier du dispositif de surveillance dans les nœuds. Si vous saisissez un chemin d'accès incorrect au dispositif de surveillance, l'opérateur de remédiation des nœuds détecte automatiquement le chemin d'accès au dispositif de surveillance.
Si un dispositif de surveillance n'est pas disponible, le CR SelfNodeRemediationConfig utilise un redémarrage logiciel.
3: Indiquez si vous souhaitez activer le redémarrage du logiciel des nœuds malades. Par défaut, la valeur de isSoftwareRebootEnabled est fixée à true. Pour désactiver le redémarrage du logiciel, fixez la valeur du paramètre à false.
4: Spécifiez le délai d'attente pour vérifier la connectivité avec chaque serveur API. Lorsque ce délai est écoulé, l'opérateur lance la remédiation. Le délai d'attente doit être supérieur ou égal à 10 millisecondes.
5: Spécifiez la fréquence de vérification de la connectivité avec chaque serveur API. Le délai d'attente doit être supérieur ou égal à 1 seconde.
6: Spécifier une valeur seuil. Une fois ce seuil atteint, le nœud commence à contacter ses homologues. La valeur du seuil doit être supérieure ou égale à 1 seconde.
7: Spécifiez la durée du délai d'attente pour que l'homologue se connecte au serveur API. La durée du délai d'attente doit être supérieure ou égale à 10 millisecondes.
8: Spécifiez la durée du délai d'attente pour l'établissement de la connexion avec l'homologue. La durée du délai doit être supérieure ou égale à 10 millisecondes.
9: Spécifiez la durée du délai d'attente pour obtenir une réponse de l'homologue. La durée du délai doit être supérieure ou égale à 10 millisecondes.
10: Spécifiez la fréquence de mise à jour des informations sur l'homologue, telles que l'adresse IP. Le délai d'attente doit être supérieur ou égal à 10 secondes.

Note

Vous pouvez modifier la CR self-node-remediation-config créée par l'opérateur d'assainissement autonome. Cependant, lorsque vous essayez de créer un nouveau CR pour l'opérateur d'assainissement autonome, le message suivant s'affiche dans les journaux :

controllers.SelfNodeRemediationConfig
ignoring selfnoderemediationconfig CRs that are not named 'self-node-remediation-config'
or not in the namespace of the operator:
'openshift-operators' {"selfnoderemediationconfig":
"openshift-operators/selfnoderemediationconfig-copy"}

5.6.2.5.2. Comprendre la configuration du modèle d'auto-assainissement des nœuds

L'opérateur d'assainissement autonome des nœuds crée également la définition de ressource personnalisée (CRD) SelfNodeRemediationTemplate. Ce CRD définit la stratégie de remédiation pour les nœuds. Les stratégies de remédiation suivantes sont disponibles :

ResourceDeletion: Cette stratégie de remédiation supprime les pods et les attachements de volume associés sur le nœud plutôt que sur l'objet nœud. Cette stratégie permet de récupérer les charges de travail plus rapidement. ResourceDeletion est la stratégie de remédiation par défaut.
NodeDeletion: Cette stratégie de remédiation est obsolète et sera supprimée dans une prochaine version. Dans la version actuelle, la stratégie ResourceDeletion est utilisée même si la stratégie NodeDeletion est sélectionnée.

L'opérateur de remédiation du nœud autonome crée le CR SelfNodeRemediationTemplate pour la stratégie self-node-remediation-resource-deletion-template, que la stratégie de remédiation ResourceDeletion utilise.

Le CR SelfNodeRemediationTemplate ressemble au fichier YAML suivant :

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  creationTimestamp: "2022-03-02T08:02:40Z"
  name: self-node-remediation-<remediation_object>-deletion-template 1
  namespace: openshift-operators
spec:
  template:
    spec:
      remediationStrategy: <remediation_strategy>  2

1: Spécifie le type de modèle de remédiation basé sur la stratégie de remédiation. Remplacez <remediation_object> par resource ou node; par exemple, self-node-remediation-resource-deletion-template.
2: Spécifie la stratégie de remédiation. La stratégie de remédiation est ResourceDeletion.

5.6.2.6. Dépannage de l'opérateur d'auto-assainissement des nœuds

5.6.2.6.1. Dépannage général

Enjeu: Vous souhaitez résoudre les problèmes liés à l'opérateur de remédiation des nœuds autonomes.
Résolution: Vérifier les journaux de l'opérateur.

5.6.2.6.2. Vérification du jeu de démons

Enjeu: Le Self Node Remediation Operator est installé mais le jeu de démons n'est pas disponible.
Résolution: Vérifiez que les journaux de l'opérateur ne contiennent pas d'erreurs ou d'avertissements.

5.6.2.6.3. Remédiation infructueuse

Enjeu

Un nœud malsain n'a pas été remédié.

Résolution

Vérifiez que le CR SelfNodeRemediation a été créé en exécutant la commande suivante :

$ oc get snr -A

Si le contrôleur MachineHealthCheck n'a pas créé la CR SelfNodeRemediation lorsque le nœud est devenu malsain, vérifiez les journaux du contrôleur MachineHealthCheck. En outre, assurez-vous que le CR MachineHealthCheck inclut les spécifications requises pour utiliser le modèle de remédiation.

Si le CR SelfNodeRemediation a été créé, assurez-vous que son nom correspond au nœud malsain ou à l'objet machine.

5.6.2.6.4. L'ensemble de démons et d'autres ressources de l'opérateur de remédiation des nœuds autonomes existent même après la désinstallation de l'opérateur

Enjeu

Les ressources de l'opérateur de remédiation du nœud autonome, telles que le jeu de démons, la CR de configuration et la CR du modèle de remédiation, existent même après la désinstallation de l'opérateur.

Résolution

Pour supprimer les ressources de l'opérateur de remédiation du nœud autonome, supprimez les ressources en exécutant les commandes suivantes pour chaque type de ressource :

$ oc delete ds <self-node-remediation-ds> -n <namespace>

oc delete snrc <self-node-remediation-config> -n <namespace>

oc delete snrt <self-node-remediation-template> -n <namespace>

5.6.2.7. Collecte de données sur l'opérateur de remédiation de l'auto-nœud

Pour collecter des informations de débogage sur l'opérateur d'assainissement autonome des nœuds, utilisez l'outil must-gather. Pour plus d'informations sur l'image must-gather de l'opérateur d'assainissement autonome des nœuds, voir Collecte de données sur des fonctionnalités spécifiques.

5.6.2.8. Ressources supplémentaires

5.6.3. Remédier aux nœuds avec les bilans de santé des machines

Les contrôles de santé des machines réparent automatiquement les machines en mauvais état dans un pool de machines particulier.

5.6.3.1. À propos des contrôles de santé des machines

Note

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.

Note

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 NotReady doit être suffisamment long pour permettre à la machine de terminer le processus de démarrage.

Pour arrêter le contrôle, retirez la ressource.

5.6.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 Machine est Failed.

5.6.3.2. Configurer les contrôles de santé des machines pour utiliser l'opérateur de remédiation de nœuds autonomes (Self Node Remediation Operator)

Utilisez la procédure suivante pour configurer les contrôles de santé des machines du plan de travail ou du plan de contrôle afin d'utiliser l'opérateur de remédiation du nœud autonome en tant que fournisseur de remédiation.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer un CR SelfNodeRemediationTemplate:

Définir le CR SelfNodeRemediationTemplate:

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  namespace: openshift-machine-api
  name: selfnoderemediationtemplate-sample
spec:
  template:
    spec:
      remediationStrategy: ResourceDeletion 1

1: Spécifie la stratégie de remédiation. La stratégie par défaut est ResourceDeletion.

Pour créer le CR SelfNodeRemediationTemplate, exécutez la commande suivante :
```
oc create -f <snrt-name>.yaml
```

Créez ou mettez à jour le CR MachineHealthCheck pour qu'il pointe vers le CR SelfNodeRemediationTemplate:

Définir ou mettre à jour le CR MachineHealthCheck:

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: machine-health-check
  namespace: openshift-machine-api
spec:
  selector:
    matchLabels: 1
      machine.openshift.io/cluster-api-machine-role: "worker"
      machine.openshift.io/cluster-api-machine-type: "worker"
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s"
    status: "False"
  - type:    "Ready"
    timeout: "300s"
    status: "Unknown"
  maxUnhealthy: "40%"
  nodeStartupTimeout: "10m"
  remediationTemplate: 2
    kind: SelfNodeRemediationTemplate
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
    name: selfnoderemediationtemplate-sample

1: Indique si le contrôle de l'état de la machine concerne les nœuds worker ou control-plane. L'étiquette peut également être définie par l'utilisateur.
2: Spécifie les détails du modèle de remédiation.

Pour créer un CR MachineHealthCheck, exécutez la commande suivante :
```
oc create -f <mhc-name>.yaml
```
Pour mettre à jour un CR MachineHealthCheck, exécutez la commande suivante :
```
$ oc apply -f <mhc-name>.yaml
```

5.6.4. Remédier aux nœuds avec les contrôles de santé des nœuds

Vous pouvez utiliser l'opérateur de contrôle de l'état des nœuds pour identifier les nœuds en mauvais état. L'opérateur utilise l'opérateur d'auto-remédiation des nœuds pour remédier aux nœuds malsains.

Ressources supplémentaires

Remédiation des nœuds avec l'opérateur de remédiation des nœuds autonomes

5.6.4.1. À propos de l'opérateur du bilan de santé du nœud

L'opérateur Node Health Check détecte l'état de santé des nœuds d'une grappe. Le contrôleur NodeHealthCheck crée la ressource personnalisée (CR) NodeHealthCheck, qui définit un ensemble de critères et de seuils permettant de déterminer l'état d'un nœud.

L'opérateur du bilan de santé du nœud installe également l'opérateur de remédiation du nœud lui-même en tant que fournisseur de remédiation par défaut.

Lorsque l'opérateur de contrôle de l'état des nœuds détecte un nœud malsain, il crée un CR de remédiation qui déclenche le fournisseur de remédiation. Par exemple, le contrôleur crée la CR SelfNodeRemediation, qui déclenche l'opérateur de remédiation de nœud autonome pour remédier au nœud malsain.

Le CR NodeHealthCheck ressemble au fichier YAML suivant :

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: nodehealthcheck-sample
spec:
  minHealthy: 51% 1
  pauseRequests: 2
    - <pause-test-cluster>
  remediationTemplate: 3
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
    name: self-node-remediation-resource-deletion-template
    namespace: openshift-operators
    kind: SelfNodeRemediationTemplate
  selector: 4
    matchExpressions:
      - key: node-role.kubernetes.io/worker
        operator: Exists
  unhealthyConditions: 5
    - type: Ready
      status: "False"
      duration: 300s 6
    - type: Ready
      status: Unknown
      duration: 300s 7

1: Spécifie le nombre de nœuds sains (en pourcentage ou en nombre) requis pour qu'un fournisseur de remédiation remédie simultanément aux nœuds du pool ciblé. Si le nombre de nœuds sains est égal ou supérieur à la limite définie par minHealthy, la remédiation a lieu. La valeur par défaut est 51 %.
2: Empêche le démarrage de toute nouvelle remédiation, tout en permettant aux remédiations en cours de persister. La valeur par défaut est vide. Cependant, vous pouvez saisir un tableau de chaînes de caractères qui identifient la cause de la mise en pause de la remédiation. Par exemple, pause-test-cluster.
Note
Au cours du processus de mise à niveau, les nœuds de la grappe peuvent devenir temporairement indisponibles et être identifiés comme malsains. Dans le cas des nœuds de travail, lorsque l'opérateur détecte que la grappe est en cours de mise à niveau, il cesse de remédier aux nouveaux nœuds malsains afin d'éviter que ces nœuds ne redémarrent.
3: Spécifie un modèle de remédiation à partir du fournisseur de remédiation. Par exemple, de l'opérateur de remédiation Self Node.
4: Spécifie une adresse selector qui correspond aux étiquettes ou aux expressions que vous souhaitez vérifier. La valeur par défaut est empty, qui sélectionne tous les nœuds.
5: Spécifie une liste des conditions qui déterminent si un nœud est considéré comme malsain.
6 7: Spécifie 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, le nœud sera remédié. Les délais d'attente prolongés peuvent entraîner de longues périodes d'indisponibilité pour une charge de travail sur un nœud malsain.

5.6.4.1.1. Comprendre le flux de travail de l'opérateur du bilan de santé du nœud

Lorsqu'un nœud est identifié comme étant en mauvaise santé, l'opérateur de contrôle de la santé des nœuds vérifie combien d'autres nœuds sont en mauvaise santé. Si le nombre de nœuds sains dépasse la quantité spécifiée dans le champ minHealthy du CR NodeHealthCheck, le contrôleur crée un CR de remédiation à partir des détails fournis dans le modèle de remédiation externe par le fournisseur de remédiation. Après la remédiation, le kubelet met à jour l'état de santé du nœud.

Lorsque le nœud devient sain, le contrôleur supprime le modèle de remédiation externe.

5.6.4.1.2. Comment les contrôles de santé des nœuds évitent les conflits avec les contrôles de santé des machines

Lorsque des contrôles de santé des nœuds et des contrôles de santé des machines sont déployés, le contrôle de santé des nœuds évite tout conflit avec le contrôle de santé des machines.

Note

OpenShift Container Platform déploie machine-api-termination-handler comme ressource par défaut MachineHealthCheck.

La liste suivante résume le comportement du système lorsque les contrôles de santé des nœuds et des machines sont déployés :

Si seul le contrôle de l'état de la machine par défaut existe, le contrôle de l'état des nœuds continue d'identifier les nœuds en mauvaise santé. Toutefois, le bilan de santé des nœuds ignore les nœuds malsains en état d'arrêt. Le contrôle de l'état de santé de la machine par défaut traite les nœuds malsains dont l'état est en voie d'achèvement.
Exemple de message du journal
```
INFO MHCChecker	ignoring unhealthy Node, it is terminating and will be handled by MHC	{"NodeName": "node-1.example.com"}
```
Si le contrôle de l'état de la machine par défaut est modifié (par exemple, unhealthyConditions est Ready) ou si des contrôles de l'état de la machine supplémentaires sont créés, le contrôle de l'état du nœud est désactivé.
Exemple de message du journal
```
INFO controllers.NodeHealthCheck disabling NHC in order to avoid conflict with custom MHCs configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}
```
Lorsque, à nouveau, seul le bilan de santé par défaut de la machine existe, le bilan de santé du nœud est réactivé.
Exemple de message du journal
```
INFO controllers.NodeHealthCheck re-enabling NHC, no conflicting MHC configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}
```

5.6.4.2. Clôture du plan de contrôle

N'utilisez pas le même NodeHealthCheck CR pour les nœuds de travail et les nœuds de plan de contrôle. Le regroupement de nœuds de travail et de nœuds de plan de contrôle peut entraîner une évaluation incorrecte du nombre minimal de nœuds sains et provoquer des mesures correctives inattendues ou manquantes. Cela est dû à la manière dont l'opérateur du bilan de santé des nœuds gère les nœuds de plan de contrôle. Vous devez regrouper les nœuds de plan de contrôle dans leur propre groupe et les nœuds de travail dans leur propre groupe. Si nécessaire, vous pouvez également créer plusieurs groupes de nœuds de travail.

Considérations relatives aux stratégies de remédiation :

Évitez les configurations du bilan de santé des nœuds qui impliquent plusieurs configurations chevauchant les mêmes nœuds, car elles peuvent entraîner un comportement inattendu. Cette suggestion s'applique aux nœuds du plan de travail et du plan de contrôle.
L'opérateur de contrôle de l'état des nœuds met en œuvre une limitation codée en dur consistant à remédier à un maximum d'un nœud de plan de contrôle à la fois. Plusieurs nœuds de plan de contrôle ne doivent pas être assainis en même temps.

5.6.4.3. Installation du Node Health Check Operator à l'aide de la console web

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer l'opérateur Node Health Check.

Conditions préalables

Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Dans la console web d'OpenShift Container Platform, naviguez vers Operators OperatorHub.
Recherchez l'opérateur du bilan de santé du nœud, puis cliquez sur Install.
Conservez la sélection par défaut de Installation mode et namespace pour vous assurer que l'opérateur sera installé dans l'espace de noms openshift-operators.
Assurez-vous que l'adresse Console plug-in est réglée sur Enable.
Cliquez sur Install.

Vérification

Pour confirmer que l'installation a réussi :

Naviguez jusqu'à la page Operators Installed Operators.
Vérifiez que l'Opérateur est installé dans l'espace de noms openshift-operators et que son statut est Succeeded.

Si l'opérateur n'est pas installé correctement :

Naviguez jusqu'à la page Operators Installed Operators et vérifiez que la colonne Status ne contient pas d'erreurs ou de défaillances.
Naviguez jusqu'à la page Workloads Pods et vérifiez les journaux de tous les pods du projet openshift-operators qui signalent des problèmes.

5.6.4.4. Installation de l'opérateur de contrôle de santé des nœuds à l'aide de la CLI

Vous pouvez utiliser le CLI OpenShift (oc) pour installer l'opérateur Node Health Check.

Pour installer l'opérateur dans votre propre espace de noms, suivez les étapes de la procédure.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer une ressource personnalisée (CR) Namespace pour l'opérateur du bilan de santé du nœud :
1. Définissez le CR Namespace et enregistrez le fichier YAML, par exemple node-health-check-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: node-health-check
```
2. Pour créer le CR Namespace, exécutez la commande suivante :
```
$ oc create -f node-health-check-namespace.yaml
```
Créer un CR OperatorGroup:
1. Définissez le CR OperatorGroup et enregistrez le fichier YAML, par exemple node-health-check-operator-group.yaml:
```
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: node-health-check-operator
  namespace: node-health-check
```
2. Pour créer le CR OperatorGroup, exécutez la commande suivante :
```
$ oc create -f node-health-check-operator-group.yaml
```
Créer un CR Subscription:
1. Définissez le CR Subscription et enregistrez le fichier YAML, par exemple node-health-check-subscription.yaml:
```
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
    name: node-health-check-operator
    namespace: node-health-check 1
spec:
    channel: stable 2
    installPlanApproval: Manual 3
    name: node-healthcheck-operator
    source: redhat-operators
    sourceNamespace: openshift-marketplace
    package: node-healthcheck-operator
```
  1
  Indiquez le site Namespace où vous souhaitez installer l'opérateur de contrôle de santé des nœuds. Pour installer l'opérateur de contrôle de santé des nœuds dans l'espace de noms openshift-operators, indiquez openshift-operators dans le CR Subscription.
  2
  Indiquez le nom du canal pour votre abonnement. Pour passer à la dernière version du Node Health Check Operator, vous devez modifier manuellement le nom du canal de votre abonnement de candidate à stable.
  3
  Définissez la stratégie d'approbation sur Manuel au cas où la version spécifiée serait remplacée par une version ultérieure dans le catalogue. Ce plan empêche une mise à niveau automatique vers une version ultérieure et nécessite une approbation manuelle avant que le CSV de départ ne puisse terminer l'installation.
2. Pour créer le CR Subscription, exécutez la commande suivante :
```
$ oc create -f node-health-check-subscription.yaml
```

Vérification

Vérifiez que l'installation a réussi en inspectant la ressource CSV :

$ oc get csv -n openshift-operators

Exemple de sortie

NAME                              DISPLAY                     VERSION  REPLACES PHASE
node-healthcheck-operator.v0.2.0. Node Health Check Operator  0.2.0             Succeeded

Vérifiez que l'opérateur du bilan de santé du nœud est opérationnel :

$ oc get deploy -n openshift-operators

Exemple de sortie

NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
node-health-check-operator-controller-manager  1/1     1            1           10d

5.6.4.5. Création d'un bilan de santé d'un nœud

À l'aide de la console web, vous pouvez créer un bilan de santé des nœuds afin d'identifier les nœuds en mauvaise santé et de spécifier le type et la stratégie de remédiation pour y remédier.

Procédure

Dans la perspective Administrator de la console web OpenShift Container Platform, cliquez sur Compute NodeHealthChecks CreateNodeHealthCheck.
Indiquez si vous souhaitez configurer le contrôle de santé du nœud à l'aide de Form view ou de YAML view.
Saisissez une adresse Name pour le contrôle de santé du nœud. Le nom doit être composé de minuscules, de caractères alphanumériques, de "-" ou de ".", et doit commencer et se terminer par un caractère alphanumérique.
Spécifiez le type Remediator et Self node remediation ou Other. L'option Self node remediation fait partie de l'opérateur Self Node Remediation qui est installé avec l'opérateur Node Health Check. La sélection de Other nécessite la saisie de API version, Kind, Name et Namespace, qui pointent ensuite vers la ressource de modèle de remédiation d'un remédiateur.
Effectuez une sélection sur Nodes en spécifiant les étiquettes des nœuds que vous souhaitez assainir. La sélection correspond aux étiquettes que vous souhaitez vérifier. Si plusieurs étiquettes sont spécifiées, les nœuds doivent contenir chacune d'entre elles. La valeur par défaut est empty, ce qui permet de sélectionner à la fois les nœuds du plan de travail et les nœuds du plan de contrôle.
Note
Lors de la création d'un contrôle de l'état d'un nœud à l'aide de l'opérateur d'auto-remédiation des nœuds, vous devez sélectionner node-role.kubernetes.io/worker ou node-role.kubernetes.io/control-plane comme valeur.
Spécifiez le nombre minimum de nœuds sains, sous la forme d'un pourcentage ou d'un nombre, requis pour qu'un site NodeHealthCheck remédie aux nœuds du pool ciblé. Si le nombre de nœuds sains est égal ou supérieur à la limite définie par Min healthy, la remédiation a lieu. La valeur par défaut est 51 %.
Spécifiez une liste de Unhealthy conditions qui, si un nœud y répond, détermine si le nœud est considéré comme malsain et nécessite une remédiation. Vous pouvez spécifier les types Type, Status et Duration. Vous pouvez également créer votre propre type personnalisé.
Cliquez sur Create pour créer le bilan de santé du nœud.

Vérification

Accédez à la page Compute NodeHealthCheck et vérifiez que le contrôle de santé du nœud correspondant est répertorié et que son état est affiché. Une fois créés, les contrôles de santé des nœuds peuvent être interrompus, modifiés et supprimés.

5.6.4.6. Collecte de données sur l'opérateur du bilan de santé du nœud

Pour collecter des informations de débogage sur le Node Health Check Operator, utilisez l'outil must-gather. Pour plus d'informations sur l'image must-gather de l'opérateur de contrôle de santé des nœuds, voir Collecte de données sur des fonctionnalités spécifiques.

5.6.4.7. Ressources supplémentaires

5.6.5. Mise en mode maintenance des nœuds avec l'opérateur de maintenance des nœuds

Vous pouvez utiliser l'opérateur de maintenance des nœuds pour placer les nœuds en mode maintenance à l'aide de l'utilitaire oc adm ou des ressources personnalisées (CR) NodeMaintenance.

5.6.5.1. À propos de l'opérateur de maintenance des nœuds

L'opérateur de maintenance des nœuds surveille les CR NodeMaintenance nouveaux ou supprimés. Lorsqu'un nouveau CR NodeMaintenance est détecté, aucune nouvelle charge de travail n'est programmée et le nœud est isolé du reste du cluster. Tous les pods qui peuvent être expulsés le sont du nœud. Lorsqu'un CR NodeMaintenance est supprimé, le nœud référencé dans le CR est rendu disponible pour de nouvelles charges de travail.

Note

L'utilisation d'un CR NodeMaintenance pour les tâches de maintenance des nœuds permet d'obtenir les mêmes résultats que les commandes oc adm cordon et oc adm drain à l'aide du traitement CR standard de OpenShift Container Platform.

5.6.5.2. Installation de l'opérateur de maintenance des nœuds

Vous pouvez installer l'opérateur de maintenance de nœuds à l'aide de la console Web ou de la CLI OpenShift (oc).

Note

Si la version 4.10 ou moins d'OpenShift Virtualization est installée dans votre cluster, elle inclut une version obsolète de l'opérateur de maintenance Node.

5.6.5.2.1. Installation de l'opérateur de maintenance de nœuds à l'aide de la console web

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer l'opérateur de maintenance Node.

Conditions préalables

Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Dans la console web d'OpenShift Container Platform, naviguez vers Operators OperatorHub.
Recherchez l'opérateur de maintenance du nœud, puis cliquez sur Install.
Conservez la sélection par défaut de Installation mode et namespace pour vous assurer que l'opérateur sera installé dans l'espace de noms openshift-operators.
Cliquez sur Install.

Vérification

Pour confirmer que l'installation a réussi :

Naviguez jusqu'à la page Operators Installed Operators.
Vérifiez que l'Opérateur est installé dans l'espace de noms openshift-operators et que son statut est Succeeded.

Si l'opérateur n'est pas installé correctement :

Naviguez jusqu'à la page Operators Installed Operators et vérifiez que la colonne Status ne contient pas d'erreurs ou de défaillances.
Naviguez jusqu'à la page Operators Installed Operators Node Maintenance Operator Details, et vérifiez que la section Conditions ne contient pas d'erreurs avant la création du pod.
Naviguez jusqu'à la page Workloads Pods, recherchez le pod Node Maintenance Operator dans l'espace de noms installé et vérifiez les journaux dans l'onglet Logs.

5.6.5.2.2. Installation de l'opérateur de maintenance de nœuds à l'aide de la CLI

Vous pouvez utiliser le CLI OpenShift (oc) pour installer l'opérateur de maintenance Node.

Vous pouvez installer l'opérateur de maintenance de nœuds dans votre propre espace de noms ou dans l'espace de noms openshift-operators.

Pour installer l'opérateur dans votre propre espace de noms, suivez les étapes de la procédure.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer un CR Namespace pour l'opérateur de maintenance des nœuds :
1. Définissez le CR Namespace et enregistrez le fichier YAML, par exemple node-maintenance-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: nmo-test
```
2. Pour créer le CR Namespace, exécutez la commande suivante :
```
$ oc create -f node-maintenance-namespace.yaml
```
Créer un CR OperatorGroup:
1. Définissez le CR OperatorGroup et enregistrez le fichier YAML, par exemple node-maintenance-operator-group.yaml:
```
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: node-maintenance-operator
  namespace: nmo-test
```
2. Pour créer le CR OperatorGroup, exécutez la commande suivante :
```
$ oc create -f node-maintenance-operator-group.yaml
```
Créer un CR Subscription:
1. Définissez le CR Subscription et enregistrez le fichier YAML, par exemple node-maintenance-subscription.yaml:
```
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: node-maintenance-operator
  namespace: nmo-test 1
spec:
  channel: stable
  InstallPlaneApproval: Automatic
  name: node-maintenance-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  StartingCSV: node-maintenance-operator.v4.12.0
```
  1
  Spécifiez le site Namespace où vous souhaitez installer l'opérateur de maintenance de nœuds.
  Important
  Pour installer l'opérateur de maintenance de nœuds dans l'espace de noms openshift-operators, spécifiez openshift-operators dans le CR Subscription.
2. Pour créer le CR Subscription, exécutez la commande suivante :
```
$ oc create -f node-maintenance-subscription.yaml
```

Vérification

Vérifiez que l'installation a réussi en inspectant la ressource CSV :

$ oc get csv -n openshift-operators

Exemple de sortie

NAME                               DISPLAY                     VERSION   REPLACES  PHASE
node-maintenance-operator.v4.12    Node Maintenance Operator   4.12                Succeeded

Vérifiez que l'opérateur de maintenance des nœuds est en cours d'exécution :

$ oc get deploy -n openshift-operators

Exemple de sortie

NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
node-maintenance-operator-controller-manager   1/1     1            1           10d

L'opérateur de maintenance de nœuds est pris en charge dans un environnement de réseau restreint. Pour plus d'informations, voir Utilisation d'Operator Lifecycle Manager sur des réseaux restreints.

5.6.5.3. Mise en mode maintenance d'un nœud

Vous pouvez placer un nœud en mode maintenance à partir de la console Web ou de la CLI en utilisant NodeMaintenance CR.

5.6.5.3.1. Mise en mode maintenance d'un nœud à l'aide de la console web

Pour mettre un nœud en mode maintenance, vous pouvez créer une ressource personnalisée (CR) NodeMaintenance à l'aide de la console web.

Conditions préalables

Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installez l'opérateur de maintenance du nœud à partir du site OperatorHub.

Procédure

Depuis la perspective Administrator dans la console web, naviguez vers Operators Installed Operators.
Sélectionnez l'opérateur de maintenance du nœud dans la liste des opérateurs.
Dans l'onglet Node Maintenance, cliquez sur Create NodeMaintenance.
Dans la page Create NodeMaintenance, sélectionnez Form view ou YAML view pour configurer le CR NodeMaintenance.
Pour appliquer la CR NodeMaintenance que vous avez configurée, cliquez sur Create.

Vérification

Dans l'onglet Node Maintenance, inspectez la colonne Status et vérifiez que son statut est Succeeded.

5.6.5.3.2. Mise en mode maintenance d'un nœud à l'aide de la CLI

Vous pouvez mettre un nœud en mode maintenance avec une ressource personnalisée (CR) NodeMaintenance. Lorsque vous appliquez une CR NodeMaintenance, tous les pods autorisés sont expulsés et le nœud devient inutilisable. Les pods expulsés sont mis en file d'attente pour être déplacés vers un autre nœud du cluster.

Conditions préalables

Install the OpenShift Container Platform CLI oc.
Connectez-vous au cluster en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez le document NodeMaintenance CR suivant et enregistrez le fichier sous nodemaintenance-cr.yaml:
```
apiVersion: nodemaintenance.medik8s.io/v1beta1
kind: NodeMaintenance
metadata:
  name: nodemaintenance-cr  1
spec:
  nodeName: node-1.example.com 2
  reason: "NIC replacement" 3
```
1
Le nom du CR de maintenance du nœud.
2
Le nom du nœud à mettre en mode maintenance.
3
Description en texte clair du motif de la maintenance.
Appliquez le CR de maintenance des nœuds en exécutant la commande suivante :
```
$ oc apply -f nodemaintenance-cr.yaml
```

Vérification

Vérifiez l'état d'avancement de la tâche de maintenance en exécutant la commande suivante :
```
$ oc describe node <node-name>
```
où <node-name> est le nom de votre nœud ; par exemple, node-1.example.com

Vérifier la sortie de l'exemple :

Events:
  Type     Reason                     Age                   From     Message
  ----     ------                     ----                  ----     -------
  Normal   NodeNotSchedulable         61m                   kubelet  Node node-1.example.com status is now: NodeNotSchedulable

5.6.5.3.3. Vérification de l'état des tâches de maintenance des nœuds en cours de CR

Vous pouvez vérifier l'état des tâches NodeMaintenance CR en cours.

Conditions préalables

Install the OpenShift Container Platform CLI oc.
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Vérifiez l'état des tâches de maintenance des nœuds en cours, par exemple l'objet NodeMaintenance CR ou nm, en exécutant la commande suivante :
```
$ oc get nm -o yaml
```
Exemple de sortie
```
apiVersion: v1
items:
- apiVersion: nodemaintenance.medik8s.io/v1beta1
  kind: NodeMaintenance
  metadata:
...
  spec:
    nodeName: node-1.example.com
    reason: Node maintenance
  status:
    drainProgress: 100   1
    evictionPods: 3   2
    lastError: "Last failure message" 3
    lastUpdate: "2022-06-23T11:43:18Z" 4
    phase: Succeeded
    totalpods: 5 5
...
```
1
Le pourcentage d'achèvement de la vidange du nœud.
2
Le nombre de nacelles dont l'expulsion est prévue.
3
La dernière erreur d'expulsion, le cas échéant.
4
La dernière fois que le statut a été mis à jour.
5
Nombre total de pods avant que le nœud ne passe en mode maintenance.

5.6.5.4. Reprise d'un nœud en mode maintenance

Vous pouvez reprendre un nœud depuis le mode de maintenance à partir de la console Web ou de l'interface CLI en utilisant NodeMaintenance CR. La reprise d'un nœud le fait sortir du mode de maintenance et le rend à nouveau planifiable.

5.6.5.4.1. Reprise d'un nœud en mode maintenance à l'aide de la console web

Pour reprendre un nœud en mode maintenance, vous pouvez supprimer une ressource personnalisée (CR) NodeMaintenance à l'aide de la console web.

Conditions préalables

Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installez l'opérateur de maintenance du nœud à partir du site OperatorHub.

Procédure

Depuis la perspective Administrator dans la console web, naviguez vers Operators Installed Operators.
Sélectionnez l'opérateur de maintenance du nœud dans la liste des opérateurs.
Dans l'onglet Node Maintenance, sélectionnez le CR NodeMaintenance que vous souhaitez supprimer.
Cliquez sur le menu Options à l'extrémité du nœud et sélectionnez Delete NodeMaintenance.

Vérification

Dans la console OpenShift Container Platform, cliquez sur Compute Nodes.
Inspectez la colonne Status du nœud pour lequel vous avez supprimé le CR NodeMaintenance et vérifiez que son statut est Ready.

5.6.5.4.2. Reprise d'un nœud en mode maintenance à l'aide de la CLI

Vous pouvez reprendre un nœud en mode maintenance qui a été initié avec un CR NodeMaintenance en supprimant le CR NodeMaintenance.

Conditions préalables

Install the OpenShift Container Platform CLI oc.
Connectez-vous au cluster en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Lorsque votre tâche de maintenance du nœud est terminée, supprimez le CR actif NodeMaintenance:
```
$ oc delete -f nodemaintenance-cr.yaml
```
Exemple de sortie
```
nodemaintenance.nodemaintenance.medik8s.io "maintenance-example" deleted
```

Vérification

Vérifiez l'état d'avancement de la tâche de maintenance en exécutant la commande suivante :
```
$ oc describe node <node-name>
```
où <node-name> est le nom de votre nœud ; par exemple, node-1.example.com

Vérifier la sortie de l'exemple :

Events:
  Type     Reason                  Age                   From     Message
  ----     ------                  ----                  ----     -------
  Normal   NodeSchedulable         2m                    kubelet  Node node-1.example.com status is now: NodeSchedulable

5.6.5.5. Travailler avec des nœuds nus

Pour les clusters avec nœuds bare-metal, vous pouvez placer un nœud en mode maintenance et reprendre un nœud depuis le mode maintenance en utilisant le contrôle de la console web Actions.

Note

Les grappes dotées de nœuds nus peuvent également placer un nœud en mode de maintenance et reprendre un nœud en mode de maintenance à l'aide de la console web et de l'interface de ligne de commande (CLI), comme indiqué. Ces méthodes, qui font appel à la console web Actions, ne s'appliquent qu'aux clusters bare-metal.

5.6.5.5.1. Maintenance des nœuds nus

Lorsque vous déployez OpenShift Container Platform sur une infrastructure bare-metal, vous devez prendre en compte des considérations supplémentaires par rapport au déploiement sur une infrastructure cloud. Contrairement aux environnements cloud, où les nœuds de cluster sont considérés comme éphémères, le reprovisionnement d'un nœud bare-metal nécessite beaucoup plus de temps et d'efforts pour les tâches de maintenance.

Lorsqu'un nœud bare-metal tombe en panne à cause d'une erreur du noyau ou d'une défaillance matérielle de la carte NIC, les charges de travail sur le nœud en panne doivent être redémarrées sur un autre nœud de la grappe pendant que le nœud en panne est réparé ou remplacé. Le mode de maintenance des nœuds permet aux administrateurs de grappes d'éteindre les nœuds avec élégance, de déplacer les charges de travail vers d'autres parties de la grappe et de s'assurer que les charges de travail ne sont pas interrompues. Des informations détaillées sur la progression et l'état des nœuds sont fournies pendant la maintenance.

5.6.5.5.2. Passage d'un nœud bare-metal en mode maintenance

Mettre un nœud bare-metal en mode maintenance à l'aide du menu Options kebab qui se trouve sur chaque nœud dans la liste Compute Nodes, ou en utilisant la commande Actions de l'écran Node Details.

Procédure

Dans la perspective Administrator de la console web, cliquez sur Compute Nodes.
Vous pouvez définir le nœud à gérer à partir de cet écran, ce qui facilite l'exécution d'actions sur plusieurs nœuds, ou à partir de l'écran Node Details, où vous pouvez afficher des détails complets sur le nœud sélectionné :
- Cliquez sur le menu Options à l'extrémité du nœud et sélectionnez Start Maintenance.
- Cliquez sur le nom du nœud pour ouvrir l'écran Node Details et cliquez sur Actions Start Maintenance.
Cliquez sur Start Maintenance dans la fenêtre de confirmation.

Le nœud n'est plus planifiable. S'il avait des machines virtuelles avec la stratégie d'éviction LiveMigration, il les migrera en direct. Tous les autres pods et machines virtuelles sur le nœud sont supprimés et recréés sur un autre nœud.

Vérification

Naviguez jusqu'à la page Compute Nodes et vérifiez que le nœud correspondant a le statut Under maintenance.

5.6.5.5.3. Reprise d'un nœud bare-metal depuis le mode maintenance

Reprendre un nœud bare-metal depuis le mode maintenance à l'aide du menu Options kebab qui se trouve sur chaque nœud dans la liste Compute Nodes, ou en utilisant la commande Actions de l'écran Node Details.

Procédure

Dans la perspective Administrator de la console web, cliquez sur Compute Nodes.
Vous pouvez reprendre le nœud à partir de cet écran, ce qui facilite l'exécution d'actions sur plusieurs nœuds, ou à partir de l'écran Node Details, où vous pouvez afficher des détails complets sur le nœud sélectionné :
- Cliquez sur le menu Options à l'extrémité du nœud et sélectionnez Stop Maintenance.
- Cliquez sur le nom du nœud pour ouvrir l'écran Node Details et cliquez sur Actions Stop Maintenance.
Cliquez sur Stop Maintenance dans la fenêtre de confirmation.

Le nœud devient planifiable. Si des instances de machines virtuelles fonctionnaient sur le nœud avant la maintenance, elles ne migreront pas automatiquement vers ce nœud.

Vérification

Naviguez jusqu'à la page Compute Nodes et vérifiez que le nœud correspondant a le statut Ready.

5.6.5.6. Collecte de données sur l'opérateur de maintenance du nœud

Pour collecter des informations de débogage sur l'opérateur de maintenance de nœuds, utilisez l'outil must-gather. Pour plus d'informations sur l'image must-gather de l'opérateur de maintenance de nœuds, voir Collecte de données sur des fonctionnalités spécifiques.

5.6. Assainissement, clôtures et entretien

5.6.1. À propos de l'assainissement des nœuds, des clôtures et de l'entretien

5.6.1.1. Remédiation autonome des nœuds

5.6.1.2. Bilan de santé de la machine

5.6.1.3. Bilan de santé du nœud

5.6.1.4. Maintenance des nœuds

5.6.2. Utilisation de l'auto-remédiation des nœuds

5.6.2.1. À propos de l'opérateur d'assainissement autonome des nœuds

5.6.2.1.1. À propos des dispositifs de surveillance

5.6.2.1.1.1. Comprendre le comportement de l'opérateur de remédiation des nœuds autonomes avec les dispositifs de surveillance

5.6.2.2. Clôture du plan de contrôle

5.6.2.3. Installation du Self Node Remediation Operator à l'aide de la console web

5.6.2.4. Installation du Self Node Remediation Operator à l'aide de la CLI

5.6.2.5. Configuration de l'opérateur de remédiation du nœud autonome

5.6.2.5.1. Comprendre la configuration de l'opérateur de remédiation du nœud autonome

5.6.2.5.2. Comprendre la configuration du modèle d'auto-assainissement des nœuds

5.6.2.6. Dépannage de l'opérateur d'auto-assainissement des nœuds

5.6.2.6.1. Dépannage général

5.6.2.6.2. Vérification du jeu de démons

5.6.2.6.3. Remédiation infructueuse

5.6.2.6.4. L'ensemble de démons et d'autres ressources de l'opérateur de remédiation des nœuds autonomes existent même après la désinstallation de l'opérateur

5.6.2.7. Collecte de données sur l'opérateur de remédiation de l'auto-nœud

5.6.2.8. Ressources supplémentaires

5.6.3. Remédier aux nœuds avec les bilans de santé des machines

5.6.3.1. À propos des contrôles de santé des machines

5.6.3.1.1. Limitations lors du déploiement des contrôles de santé des machines

5.6.3.2. Configurer les contrôles de santé des machines pour utiliser l'opérateur de remédiation de nœuds autonomes (Self Node Remediation Operator)

5.6.4. Remédier aux nœuds avec les contrôles de santé des nœuds

5.6.4.1. À propos de l'opérateur du bilan de santé du nœud

5.6.4.1.1. Comprendre le flux de travail de l'opérateur du bilan de santé du nœud

5.6.4.1.2. Comment les contrôles de santé des nœuds évitent les conflits avec les contrôles de santé des machines

5.6.4.2. Clôture du plan de contrôle

5.6.4.3. Installation du Node Health Check Operator à l'aide de la console web

5.6.4.4. Installation de l'opérateur de contrôle de santé des nœuds à l'aide de la CLI

5.6.4.5. Création d'un bilan de santé d'un nœud

5.6.4.6. Collecte de données sur l'opérateur du bilan de santé du nœud

5.6.4.7. Ressources supplémentaires

5.6.5. Mise en mode maintenance des nœuds avec l'opérateur de maintenance des nœuds

5.6.5.1. À propos de l'opérateur de maintenance des nœuds

5.6.5.2. Installation de l'opérateur de maintenance des nœuds

5.6.5.2.1. Installation de l'opérateur de maintenance de nœuds à l'aide de la console web

5.6.5.2.2. Installation de l'opérateur de maintenance de nœuds à l'aide de la CLI

5.6.5.3. Mise en mode maintenance d'un nœud

5.6.5.3.1. Mise en mode maintenance d'un nœud à l'aide de la console web

5.6.5.3.2. Mise en mode maintenance d'un nœud à l'aide de la CLI

5.6.5.3.3. Vérification de l'état des tâches de maintenance des nœuds en cours de CR

5.6.5.4. Reprise d'un nœud en mode maintenance

5.6.5.4.1. Reprise d'un nœud en mode maintenance à l'aide de la console web

5.6.5.4.2. Reprise d'un nœud en mode maintenance à l'aide de la CLI

5.6.5.5. Travailler avec des nœuds nus

5.6.5.5.1. Maintenance des nœuds nus

5.6.5.5.2. Passage d'un nœud bare-metal en mode maintenance

5.6.5.5.3. Reprise d'un nœud bare-metal depuis le mode maintenance

5.6.5.6. Collecte de données sur l'opérateur de maintenance du nœud

5.6.5.7. Ressources supplémentaires

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links