6.5. Amélioration de la stabilité des grappes dans les environnements à forte latence à l'aide de profils de latence des travailleurs
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 :
-
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œudReady
commeUnknown
. - En réponse, l'ordonnanceur arrête de programmer des pods sur ce nœud.
-
Le contrôleur de nœuds sur site ajoute au nœud une tare
node.kubernetes.io/unreachable
avec un effetNoExecute
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'erreurnode.kubernetes.io/not-ready
ounode.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.
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
etdefault-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
ounode.kubernetes.io/unreachable
et expulse les pods sur ce nœud. Si un pod sur ce nœud a la toléranceNoExecute
, le pod est expulsé en 300 secondes. Si le pod a le paramètretolerationSeconds
, l'expulsion attend la période spécifiée par ce paramètre.Profile Composant Paramètres Valeur 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ètretolerationSeconds
, 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.
Profile Composant Paramètres Valeur 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ètretolerationSeconds
, 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.
Profile Composant Paramètres Valeur 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.
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 :
Passer au profil de latence du travailleur moyen :
Modifiez l'objet
node.config
:$ oc edit nodes.config/cluster
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.
Optionnel : Passez au profil de faible latence du travailleur :
Modifiez l'objet
node.config
:$ oc edit nodes.config/cluster
Modifiez la valeur de
spec.workerLatencyProfile
enLowUpdateSlowReaction
: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.