16.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/clusterAjouter
spec.workerLatencyProfile: MediumUpdateAverageReaction:Exemple d'objet
node.configapiVersion: 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: MediumUpdateAverageReaction1 ...- 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 5Exemple 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/clusterModifiez la valeur de
spec.workerLatencyProfileenLowUpdateSlowReaction:Exemple d'objet
node.configapiVersion: 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: LowUpdateSlowReaction1 ...- 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.