Chapitre 8. Nœuds de télétravailleurs à la périphérie du réseau

Tous les nœuds envoient des battements de cœur à l'opérateur du gestionnaire de contrôleur Kubernetes (kube controller) dans le cluster OpenShift Container Platform toutes les 10 secondes. 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.

OpenShift Container Platform est conçue pour résister aux partitions de réseau et autres perturbations. Vous pouvez atténuer certaines des perturbations les plus courantes, telles que les interruptions dues à des mises à jour logicielles, des divisions de réseau et des problèmes de routage. Les stratégies d'atténuation consistent notamment à s'assurer que les pods sur les nœuds de travail distants demandent la quantité correcte de ressources CPU et mémoire, à configurer une politique de réplication appropriée, à utiliser la redondance entre les zones et à utiliser des budgets de perturbation des pods sur les charges de travail.

Si le contrôleur kube perd le contact avec un nœud après une période configurée, le contrôleur de nœud sur le plan de contrôle met à jour l'état du nœud à Unhealthy et marque l'état du nœud Ready comme Unknown. En réponse, le planificateur arrête de planifier des pods pour ce nœud. Le contrôleur de nœuds sur site ajoute une erreur node.kubernetes.io/unreachable avec un effet NoExecute au nœud et planifie l'éviction des pods sur le nœud après cinq minutes, par défaut.

Si un contrôleur de charge de travail, tel qu'un objet Deployment ou StatefulSet, dirige le trafic vers des pods sur le nœud malsain et que d'autres nœuds peuvent atteindre le cluster, OpenShift Container Platform achemine le trafic loin des pods sur le nœud. Les nœuds qui ne peuvent pas atteindre le cluster ne sont pas mis à jour avec le nouveau routage du trafic. Par conséquent, les charges de travail sur ces nœuds peuvent continuer à essayer d'atteindre le nœud malsain.

Vous pouvez atténuer les effets de la perte de connexion en procédant comme suit :

Pour plus d'informations sur l'utilisation de ces objets dans un cluster avec des nœuds de télétravail, voir À propos des stratégies de nœuds de télétravail.

Si un nœud de télétravail perd de l'énergie ou redémarre de façon anarchique, OpenShift Container Platform réagit à l'aide de plusieurs mécanismes par défaut.

Si l'opérateur du gestionnaire de contrôleur Kubernetes (contrôleur kube) perd le contact avec un nœud après une période configurée, le plan de contrôle met à jour la santé du nœud à Unhealthy et marque l'état du nœud Ready comme Unknown. En réponse, le planificateur arrête de planifier des pods sur ce nœud. Le contrôleur de nœuds sur site ajoute une tare node.kubernetes.io/unreachable avec un effet NoExecute au nœud et planifie l'éviction des pods sur le nœud au bout de cinq minutes, par défaut.

Sur le nœud, les pods doivent être redémarrés lorsque le nœud est remis sous tension et reconnecté au plan de contrôle.

Après le redémarrage du nœud, le kubelet redémarre également et tente de redémarrer les pods qui ont été planifiés sur le nœud. Si la connexion au plan de contrôle prend plus de temps que les cinq minutes par défaut, le plan de contrôle ne peut pas mettre à jour l'état du nœud et supprimer l'erreur node.kubernetes.io/unreachable. Sur le nœud, le kubelet met fin à tous les pods en cours d'exécution. Lorsque ces conditions sont levées, le planificateur peut commencer à planifier des pods sur ce nœud.

Vous pouvez atténuer les effets de la perte de puissance en :

Pour plus d'informations sur l'utilisation de ces objets dans un cluster avec des nœuds de télétravail, voir À propos des stratégies de nœuds de télétravail.

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 :

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.

Si vous utilisez des nœuds de travail à distance, réfléchissez aux objets à utiliser pour exécuter vos applications.

Il est recommandé d'utiliser des ensembles de démons ou des pods statiques en fonction du comportement souhaité en cas de problèmes de réseau ou de perte d'alimentation. En outre, vous pouvez utiliser les zones et les tolérances Kubernetes pour contrôler ou éviter les évictions de pods si le plan de contrôle ne peut pas atteindre les nœuds de travail distants.

Lorsque le plan de contrôle ne peut pas atteindre un nœud, le contrôleur de nœud, par défaut, applique node.kubernetes.io/unreachable taints et expulse les pods à un taux de 0,1 nœud par seconde. Cependant, dans un cluster qui utilise des zones Kubernetes, le comportement d'éviction des pods est modifié.

Si une zone est totalement perturbée et que tous les nœuds de la zone ont une condition Ready qui est False ou Unknown, le plan de contrôle n'applique pas l'erreur node.kubernetes.io/unreachable aux nœuds de cette zone.

Pour les zones partiellement perturbées, où plus de 55 % des nœuds ont une condition False ou Unknown, le taux d'éviction des pods est réduit à 0,01 nœud par seconde. Les nœuds des grappes plus petites, comptant moins de 50 nœuds, ne sont pas altérés. Votre cluster doit avoir plus de trois zones pour que ce comportement prenne effet.

Vous affectez un nœud à une zone spécifique en appliquant l'étiquette topology.kubernetes.io/region dans la spécification du nœud.

kind: Node
apiVersion: v1
metadata:
  labels:
    topology.kubernetes.io/region=east

Vous pouvez ajuster le temps pendant lequel le kubelet vérifie l'état de chaque nœud.

Pour définir l'intervalle qui affecte le moment où le contrôleur de nœuds sur site marque les nœuds avec la condition Unhealthy ou Unreachable, créez un objet KubeletConfig qui contient les paramètres node-status-update-frequency et node-status-report-frequency.

Le kubelet de chaque nœud détermine l'état du nœud tel que défini par le paramètre node-status-update-frequency et signale cet état au cluster en fonction du paramètre node-status-report-frequency. Par défaut, le kubelet détermine l'état du nœud toutes les 10 secondes et le signale toutes les minutes. Cependant, si l'état du nœud change, le kubelet signale le changement au cluster immédiatement. OpenShift Container Platform utilise le paramètre node-status-report-frequency uniquement lorsque la porte de fonctionnalité Node Lease est activée, ce qui est l'état par défaut dans les clusters OpenShift Container Platform. Si la porte de la fonctionnalité Node Lease est désactivée, le nœud signale son état en fonction du paramètre node-status-update-frequency.

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: disable-cpu-units
spec:
  machineConfigPoolSelector:
    matchLabels:
      machineconfiguration.openshift.io/role: worker 1
  kubeletConfig:
    node-status-update-frequency: 2
      - "10s"
    node-status-report-frequency: 3
      - "1m"

Le paramètre node-status-update-frequency fonctionne avec les paramètres node-monitor-grace-period et pod-eviction-timeout.

Une taint avec l'effet NoExecute affecte les pods qui s'exécutent sur le nœud de la manière suivante :

Vous pouvez retarder ou éviter l'éviction des pods en configurant les tolérances des pods avec l'effet NoExecute pour les taints node.kubernetes.io/unreachable et node.kubernetes.io/not-ready.

...
tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute" 1
- key: "node.kubernetes.io/not-ready"
  operator: "Exists"
  effect: "NoExecute" 2
  tolerationSeconds: 600
...

OpenShift Container Platform utilise la valeur tolerationSeconds après l'expiration de la valeur pod-eviction-timeout.

ne sont pas redémarrés en cas de panne. Les pods restent dans l'état terminating jusqu'à ce que le plan de contrôle puisse reconnaître que les pods sont terminés.

Pour éviter de programmer un nœud qui n'a pas accès au même type de stockage persistant, OpenShift Container Platform ne peut pas migrer les pods qui nécessitent des volumes persistants vers d'autres zones dans le cas d'une séparation de réseau.