SupportConsoleDéveloppeursCommencer un essaiContact

5.7. Comprendre le redémarrage des nœuds

Pour redémarrer un nœud sans provoquer de panne pour les applications fonctionnant sur la plate-forme, il est important d'évacuer d'abord les pods. Pour les pods qui sont rendus hautement disponibles par le niveau de routage, il n'y a rien d'autre à faire. Pour les autres modules qui ont besoin de stockage, généralement des bases de données, il est essentiel de s'assurer qu'ils peuvent continuer à fonctionner même si l'un d'entre eux est temporairement hors ligne. Bien que la mise en œuvre de la résilience pour les pods avec état soit différente pour chaque application, dans tous les cas, il est important de configurer l'ordonnanceur pour utiliser l'anti-affinité des nœuds afin de s'assurer que les pods sont correctement répartis sur les nœuds disponibles.

Un autre défi consiste à gérer les nœuds qui gèrent une infrastructure critique telle que le routeur ou le registre. Le même processus d'évacuation des nœuds s'applique, bien qu'il soit important de comprendre certains cas limites.

5.7.1. À propos du redémarrage des nœuds exécutant une infrastructure critique

Lors du redémarrage des nœuds qui hébergent des composants d'infrastructure critiques d'OpenShift Container Platform, tels que les pods de routeur, les pods de registre et les pods de surveillance, assurez-vous qu'il y a au moins trois nœuds disponibles pour exécuter ces composants.

Le scénario suivant montre comment des interruptions de service peuvent se produire avec des applications exécutées sur OpenShift Container Platform lorsque seuls deux nœuds sont disponibles :

  • Le nœud A est déclaré inséparable et toutes les nacelles sont évacuées.
  • Le pod de registre fonctionnant sur ce nœud est maintenant redéployé sur le nœud B. Le nœud B exécute maintenant les deux pods de registre.
  • Le nœud B est maintenant considéré comme non planifiable et est évacué.
  • Le service exposant les deux points d'extrémité de pods sur le nœud B perd tous les points d'extrémité, pendant une brève période, jusqu'à ce qu'ils soient redéployés sur le nœud A.

Lorsque trois nœuds sont utilisés pour les composants d'infrastructure, ce processus n'entraîne pas d'interruption de service. Toutefois, en raison de la planification des pods, le dernier nœud évacué et remis en rotation n'a pas de pod de registre. L'un des autres nœuds dispose de deux modules de registre. Pour planifier le troisième module de registre sur le dernier nœud, utilisez l'anti-affinité de module pour empêcher l'ordonnanceur de placer deux modules de registre sur le même nœud.

Informations complémentaires

5.7.2. Redémarrage d'un nœud à l'aide d'un pod anti-affinité

L'anti-affinité des pods est légèrement différente de l'anti-affinité des nœuds. L'anti-affinité de nœud peut être violée s'il n'y a pas d'autres emplacements appropriés pour déployer un pod. L'anti-affinité des pods peut être définie comme requise ou préférée.

Ainsi, si seuls deux nœuds d'infrastructure sont disponibles et que l'un d'entre eux est redémarré, le pod de registre d'images de conteneurs ne peut pas s'exécuter sur l'autre nœud. oc get pods signale le pod comme étant non prêt jusqu'à ce qu'un nœud approprié soit disponible. Une fois qu'un nœud est disponible et que tous les pods sont de nouveau prêts, le nœud suivant peut être redémarré.

Procédure

Pour redémarrer un nœud en utilisant l'anti-affinité des pods :

  1. Modifiez la spécification du nœud pour configurer l'anti-affinité du pod : 

    apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity: 1
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 100 3
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: registry 4
              operator: In 5
              values:
              - default
          topologyKey: kubernetes.io/hostname
    1
    Stanza pour configurer l'anti-affinité du pod.
    2
    Définit une règle préférentielle.
    3
    Spécifie un poids pour une règle préférentielle. Le nœud ayant le poids le plus élevé est privilégié.
    4
    Description de l'étiquette du pod qui détermine quand la règle anti-affinité s'applique. Spécifiez une clé et une valeur pour l'étiquette.
    5
    L'opérateur représente la relation entre l'étiquette de la capsule existante et l'ensemble des valeurs des paramètres matchExpression dans la spécification de la nouvelle capsule. Il peut s'agir de In, NotIn, Exists ou DoesNotExist.

    Cet exemple suppose que le pod du registre d'images de conteneurs a une étiquette de registry=default. L'anti-affinité de pod peut utiliser n'importe quelle expression de correspondance de Kubernetes.

  2. Activer le prédicat de l'ordonnanceur MatchInterPodAffinity dans le fichier de stratégie d'ordonnancement.
  3. Effectuer un redémarrage gracieux du nœud.

5.7.3. Comprendre comment redémarrer les nœuds utilisant des routeurs

Dans la plupart des cas, un pod exécutant un routeur OpenShift Container Platform expose un port hôte.

Le prédicat de l'ordonnanceur PodFitsPorts garantit qu'aucun pod de routeur utilisant le même port ne peut s'exécuter sur le même nœud, et que l'anti-affinité des pods est réalisée. Si les routeurs s'appuient sur le basculement IP pour la haute disponibilité, il n'y a rien d'autre à faire.

Pour les router pods qui dépendent d'un service externe tel que AWS Elastic Load Balancing pour la haute disponibilité, il est de la responsabilité de ce service de réagir aux redémarrages des router pods.

Dans de rares cas, un router pod peut ne pas avoir de port hôte configuré. Dans ce cas, il est important de suivre la procédure de redémarrage recommandée pour les nœuds d'infrastructure.

5.7.4. Redémarrer un nœud avec élégance

Avant de redémarrer un nœud, il est recommandé de sauvegarder les données etcd afin d'éviter toute perte de données sur le nœud.

Note

Pour les clusters OpenShift à un seul nœud qui nécessitent que les utilisateurs exécutent la commande oc login plutôt que d'avoir les certificats dans le fichier kubeconfig pour gérer le cluster, les commandes oc adm peuvent ne pas être disponibles après le cordon et la vidange du nœud. Cela est dû au fait que le pod openshift-oauth-apiserver n'est pas en cours d'exécution en raison du cordon. Vous pouvez utiliser SSH pour accéder aux nœuds comme indiqué dans la procédure suivante.

Dans un cluster OpenShift à un seul nœud, les pods ne peuvent pas être reprogrammés lors du cordonage et de la vidange. Cependant, cela donne aux pods, en particulier à vos pods de charge de travail, le temps de s'arrêter correctement et de libérer les ressources associées.

Procédure

Pour effectuer un redémarrage gracieux d'un nœud :

  1. Marquer le nœud comme non ordonnançable : 

    oc adm cordon <node1> $ oc adm cordon <node1>

  2. Drainer le nœud pour supprimer tous les pods en cours d'exécution : 

    $ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force

    Il se peut que vous receviez des erreurs indiquant que les pods associés à des budgets de perturbation de pods personnalisés (PDB) ne peuvent pas être expulsés.

    Exemple d'erreur

    error when evicting pods/"rails-postgresql-example-1-72v2w" -n "rails" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

    Dans ce cas, exécutez à nouveau la commande drain, en ajoutant le drapeau disable-eviction, ce qui permet de contourner les contrôles PDB : 

    $ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force --disable-eviction

  3. Accéder au nœud en mode débogage : 

    $ oc debug node/<node1>

  4. Changez votre répertoire racine en /host: 

    $ chroot /host

  5. Redémarrer le nœud : 

    $ systemctl reboot

    En un instant, le nœud entre dans l'état NotReady.

    Note

    Avec certains clusters OpenShift à un seul nœud, les commandes oc peuvent ne pas être disponibles après avoir cordonné et drainé le nœud parce que le pod openshift-oauth-apiserver n'est pas en cours d'exécution. Vous pouvez utiliser SSH pour vous connecter au nœud et effectuer le redémarrage. 

    $ ssh core@<master-node>.<cluster_name>.<base_domain>
    $ sudo systemctl reboot

  6. Une fois le redémarrage terminé, marquez le nœud comme planifiable en exécutant la commande suivante : 

    oc adm uncordon <node1> $ oc adm uncordon <node1>
    Note

    Avec certains clusters OpenShift à nœud unique, les commandes oc peuvent ne pas être disponibles après avoir cordonné et drainé le nœud parce que le pod openshift-oauth-apiserver n'est pas en cours d'exécution. Vous pouvez utiliser SSH pour vous connecter au nœud et le déconnecter. 

    $ ssh core@<target_node>
    $ sudo oc adm uncordon <node> --kubeconfig /etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost.kubeconfig

  7. Vérifiez que le nœud est prêt : 

    oc get node <node1> $ oc get node <node1>

    Exemple de sortie

    NAME    STATUS  ROLES    AGE     VERSION
<node1> Ready   worker   6d22h   v1.18.3+b0068a8

Informations complémentaires

Pour plus d'informations sur la sauvegarde des données etcd, voir Sauvegarde des données etcd.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.