Rechercher

6.5. Amélioration de la stabilité des grappes dans les environnements à forte latence à l'aide de profils de latence des travailleurs

download PDF

Tous les nœuds envoient des battements de cœur à l'opérateur du contrôleur Kubernetes (kube controller) dans le cluster OpenShift Container Platform toutes les 10 secondes, par défaut. Si le cluster ne reçoit pas de battements de cœur d'un nœud, OpenShift Container Platform répond à l'aide de plusieurs mécanismes par défaut.

Par exemple, si l'opérateur du gestionnaire de contrôleur Kubernetes perd le contact avec un nœud après une période configurée :

  1. Le contrôleur de nœuds sur le plan de contrôle met à jour l'état du nœud à Unhealthy et marque l'état du nœud Ready comme Unknown.
  2. En réponse, l'ordonnanceur arrête de programmer des pods sur ce nœud.
  3. Le contrôleur de nœuds sur site ajoute au nœud une tare node.kubernetes.io/unreachable avec un effet NoExecute et planifie l'éviction de tous les pods du nœud après cinq minutes, par défaut.

Ce comportement peut poser des problèmes si votre réseau est sujet à des problèmes de latence, en particulier si vous avez des nœuds à la périphérie du réseau. Dans certains cas, l'opérateur du gestionnaire de contrôleur Kubernetes peut ne pas recevoir de mise à jour d'un nœud sain en raison de la latence du réseau. L'opérateur du gestionnaire de contrôleur Kubernetes expulserait alors les pods du nœud, même si celui-ci est sain. Pour éviter ce problème, vous pouvez utiliser worker latency profiles pour ajuster la fréquence à laquelle le kubelet et le Kubernetes Controller Manager Operator attendent les mises à jour d'état avant d'agir. Ces ajustements permettent de s'assurer que votre cluster fonctionne correctement dans le cas où la latence du réseau entre le plan de contrôle et les nœuds de travail n'est pas optimale.

Ces profils de latence des travailleurs sont trois ensembles de paramètres prédéfinis avec des valeurs soigneusement ajustées qui vous permettent de contrôler la réaction du cluster aux problèmes de latence sans avoir à déterminer les meilleures valeurs manuellement.

6.5.1. Comprendre les profils de latence des travailleurs

Les profils de latence des travailleurs sont des ensembles multiples de valeurs soigneusement ajustées pour les paramètres node-status-update-frequency, node-monitor-grace-period, default-not-ready-toleration-seconds et default-unreachable-toleration-seconds. Ces paramètres vous permettent de contrôler la réaction du cluster aux problèmes de latence sans avoir à déterminer manuellement les meilleures valeurs.

Tous les profils de latence des travailleurs configurent les paramètres suivants :

  • node-status-update-frequency. Spécifie le temps en secondes pendant lequel un kubelet met à jour son statut auprès de l'opérateur du gestionnaire de contrôleur Kubernetes.
  • node-monitor-grace-period. Spécifie la durée en secondes pendant laquelle l'opérateur Kubernetes Controller Manager attend une mise à jour d'un kubelet avant de marquer le nœud comme étant malsain et d'ajouter l'erreur node.kubernetes.io/not-ready ou node.kubernetes.io/unreachable au nœud.
  • default-not-ready-toleration-seconds. Spécifie la durée en secondes après le marquage d'un nœud insalubre que l'opérateur Kubernetes Controller Manager attend avant d'expulser les pods de ce nœud.
  • default-unreachable-toleration-seconds. Spécifie la durée en secondes pendant laquelle l'opérateur du gestionnaire de contrôle Kubernetes attend qu'un nœud soit marqué comme inaccessible avant d'expulser les pods de ce nœud.
Important

La modification manuelle du paramètre node-monitor-grace-period n'est pas possible.

Les opérateurs suivants surveillent les modifications apportées aux profils de latence des travailleurs et réagissent en conséquence :

  • L'opérateur de configuration de la machine (MCO) met à jour le paramètre node-status-update-frequency sur les nœuds de travail.
  • L'opérateur du gestionnaire de contrôleur Kubernetes met à jour le paramètre node-monitor-grace-period sur les nœuds du plan de contrôle.
  • L'opérateur du serveur API Kubernetes met à jour les paramètres default-not-ready-toleration-seconds et default-unreachable-toleration-seconds sur les nœuds de la plance de contrôle.

Bien que la configuration par défaut fonctionne dans la plupart des cas, OpenShift Container Platform propose deux autres profils de latence du travailleur pour les situations où le réseau connaît une latence plus élevée que d'habitude. Les trois profils de latence des travailleurs sont décrits dans les sections suivantes :

Profil de latence du travailleur par défaut

Avec le profil Default, chaque kubelet signale l'état de son nœud au Kubelet Controller Manager Operator (kube controller) toutes les 10 secondes. L'opérateur du gestionnaire du contrôleur de kubelet vérifie l'état du kubelet toutes les 5 secondes.

L'opérateur du gestionnaire de contrôle Kubernetes attend 40 secondes pour une mise à jour de l'état avant de considérer ce nœud comme malsain. Il marque le nœud avec la taint node.kubernetes.io/not-ready ou node.kubernetes.io/unreachable et expulse les pods sur ce nœud. Si un pod sur ce nœud a la tolérance NoExecute, le pod est expulsé en 300 secondes. Si le pod a le paramètre tolerationSeconds, l'expulsion attend la période spécifiée par ce paramètre.

ProfileComposantParamètresValeur

Défaut

kubelet

node-status-update-frequency

10s

Gestionnaire de contrôleur Kubelet

node-monitor-grace-period

40s

Serveur API Kubernetes

default-not-ready-toleration-seconds

300s

Serveur API Kubernetes

default-unreachable-toleration-seconds

300s

Profil de latence du travailleur moyen

Utilisez le profil MediumUpdateAverageReaction si la latence du réseau est légèrement plus élevée que d'habitude.

Le profil MediumUpdateAverageReaction réduit la fréquence des mises à jour des kubelets à 20 secondes et modifie la période d'attente de ces mises à jour par l'opérateur du contrôleur Kubernetes à 2 minutes. La période d'éviction d'un pod sur ce nœud est réduite à 60 secondes. Si le pod a le paramètre tolerationSeconds, l'éviction attend la période spécifiée par ce paramètre.

L'opérateur Kubernetes Controller Manager attend 2 minutes pour considérer qu'un nœud n'est pas sain. Une minute plus tard, le processus d'expulsion commence.

ProfileComposantParamètresValeur

Moyenne des mises à jour

kubelet

node-status-update-frequency

20s

Gestionnaire de contrôleur Kubelet

node-monitor-grace-period

2m

Serveur API Kubernetes

default-not-ready-toleration-seconds

60s

Serveur API Kubernetes

default-unreachable-toleration-seconds

60s

Profil de latence faible pour les travailleurs

Utilisez le profil LowUpdateSlowReaction si la latence du réseau est extrêmement élevée.

Le profil LowUpdateSlowReaction réduit la fréquence des mises à jour des kubelets à 1 minute et modifie la période d'attente de ces mises à jour par l'opérateur du contrôleur Kubernetes à 5 minutes. La période d'éviction d'un pod sur ce nœud est réduite à 60 secondes. Si le pod a le paramètre tolerationSeconds, l'éviction attend la période spécifiée par ce paramètre.

L'opérateur Kubernetes Controller Manager attend 5 minutes pour considérer qu'un nœud n'est pas sain. Dans une minute, le processus d'expulsion commence.

ProfileComposantParamètresValeur

Faible mise à jourRéaction lente

kubelet

node-status-update-frequency

1m

Gestionnaire de contrôleur Kubelet

node-monitor-grace-period

5m

Serveur API Kubernetes

default-not-ready-toleration-seconds

60s

Serveur API Kubernetes

default-unreachable-toleration-seconds

60s

6.5.2. Utilisation des profils de latence des travailleurs

Pour mettre en œuvre un profil de latence du travailleur afin de gérer la latence du réseau, modifiez l'objet node.config pour ajouter le nom du profil. Vous pouvez modifier le profil à tout moment lorsque la latence augmente ou diminue.

Vous devez déplacer un profil de latence de travailleur à la fois. Par exemple, vous ne pouvez pas passer directement du profil Default au profil LowUpdateSlowReaction. Vous devez d'abord passer du profil default au profil MediumUpdateAverageReaction, puis à LowUpdateSlowReaction. De même, lorsque vous revenez au profil par défaut, vous devez d'abord passer du profil bas au profil moyen, puis au profil par défaut.

Note

Vous pouvez également configurer les profils de latence des travailleurs lors de l'installation d'un cluster OpenShift Container Platform.

Procédure

Pour quitter le profil de latence par défaut du travailleur :

  1. Passer au profil de latence du travailleur moyen :

    1. Modifiez l'objet node.config:

      $ oc edit nodes.config/cluster
    2. Ajouter spec.workerLatencyProfile: MediumUpdateAverageReaction:

      Exemple d'objet node.config

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: MediumUpdateAverageReaction 1
      
       ...

      1
      Spécifie la politique de latence du travailleur moyen.

      La programmation sur chaque nœud de travailleur est désactivée au fur et à mesure de l'application de la modification.

      Lorsque tous les nœuds reviennent à l'état Ready, vous pouvez utiliser la commande suivante pour vérifier dans le Kubernetes Controller Manager qu'elle a bien été appliquée :

      $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5

      Exemple de sortie

       ...
          - lastTransitionTime: "2022-07-11T19:47:10Z"
            reason: ProfileUpdated
            status: "False"
            type: WorkerLatencyProfileProgressing
          - lastTransitionTime: "2022-07-11T19:47:10Z" 1
            message: all static pod revision(s) have updated latency profile
            reason: ProfileUpdated
            status: "True"
            type: WorkerLatencyProfileComplete
          - lastTransitionTime: "2022-07-11T19:20:11Z"
            reason: AsExpected
            status: "False"
            type: WorkerLatencyProfileDegraded
          - lastTransitionTime: "2022-07-11T19:20:36Z"
            status: "False"
       ...

      1
      Spécifie que le profil est appliqué et actif.
  2. Optionnel : Passez au profil de faible latence du travailleur :

    1. Modifiez l'objet node.config:

      $ oc edit nodes.config/cluster
    2. Modifiez la valeur de spec.workerLatencyProfile en LowUpdateSlowReaction:

      Exemple d'objet node.config

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: LowUpdateSlowReaction 1
      
       ...

      1
      Spécifie l'utilisation de la politique de faible latence du travailleur.

      La programmation sur chaque nœud de travailleur est désactivée au fur et à mesure de l'application de la modification.

Pour transformer le profil bas en profil moyen ou le profil moyen en profil bas, modifiez l'objet node.config et réglez le paramètre spec.workerLatencyProfile sur la valeur appropriée.

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.