3.14. À propos des contraintes de propagation de la topologie des pod pour la surveillance

Procédure

1. Éditez la carte de configuration de la configuration de l’utilisateur-workload-monitoring dans le projet openshift-user-workload-monitoring:

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   Copy to Clipboard Toggle word wrap

2. Ajoutez les paramètres suivants dans le champ data/config.yaml pour configurer les contraintes de propagation de la topologie pod:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       <component>: 

   1

   
         topologySpreadConstraints:
         - maxSkew: <n> 

   2

   
           topologyKey: <key> 

   3

   
           whenUnsatisfiable: <value> 

   4

   
           labelSelector: 

   5

   
             <match_option>

   Copy to Clipboard Toggle word wrap

   1

   Indiquez un nom du composant pour lequel vous souhaitez configurer des contraintes de propagation de la topologie de pod.

   2

   Indiquez une valeur numérique pour maxSkew, qui définit le degré auquel les pods sont autorisés à être distribués de manière inégale.

   3

   Indiquez une clé des étiquettes des nœuds pour topologyKey. Les nœuds qui ont une étiquette avec cette clé et des valeurs identiques sont considérés comme étant dans la même topologie. Le planificateur essaie de mettre un nombre équilibré de pods dans chaque domaine.

   4

   Indiquez une valeur pour quand Insatisfiable. Les options disponibles sont DoNotSchedule et ScheduleAnyway. Indiquez DoNotSchedule si vous voulez que la valeur maxSkew définisse la différence maximale autorisée entre le nombre de gousses correspondantes dans la topologie cible et le minimum global. Spécifiez ScheduleAnyway si vous voulez que le programmeur planifie toujours le pod, mais donne une priorité plus élevée aux nœuds qui pourraient réduire l’oscillation.

   5

   Indiquez le labelSelector pour trouver les gousses correspondantes. Les pods qui correspondent à ce sélecteur d’étiquettes sont comptés pour déterminer le nombre de pods dans leur domaine de topologie correspondant.

   Exemple de configuration pour Thanos Ruler

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         topologySpreadConstraints:
         - maxSkew: 1
           topologyKey: monitoring
           whenUnsatisfiable: ScheduleAnyway
           labelSelector:
             matchLabels:
               app.kubernetes.io/name: thanos-ruler

   Copy to Clipboard Toggle word wrap

3. Enregistrez le fichier pour appliquer les modifications. Les pods affectés par la nouvelle configuration sont automatiquement redéployés.