Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

4.6. Contrôler le placement des gousses en utilisant des contraintes de propagation de la topologie des pods

Il est possible d’utiliser des contraintes de propagation de la topologie pod pour fournir un contrôle fin sur le placement de vos gousses sur les nœuds, les zones, les régions ou d’autres domaines de topologie définis par l’utilisateur. Distribuer des pods à travers les domaines d’échec peut aider à atteindre une disponibilité élevée et une utilisation plus efficace des ressources.

4.6.1. Exemples de cas d’utilisation
Copier lien

  • En tant qu’administrateur, je veux que ma charge de travail s’étende automatiquement entre deux à quinze pods. Je veux m’assurer que lorsqu’il n’y a que deux gousses, elles ne sont pas placées sur le même nœud, pour éviter un seul point d’échec.
  • En tant qu’administrateur, je veux répartir mes pods uniformément sur plusieurs zones d’infrastructure afin de réduire la latence et les coûts de réseau. Je veux m’assurer que mon cluster peut s’auto-guérir si des problèmes se posent.

4.6.2. Considérations importantes
Copier lien

  • Les pods d’un Red Hat OpenShift Service sur le cluster AWS sont gérés par des contrôleurs de charge de travail tels que des déploiements, des ensembles étatiques ou des ensembles de démons. Ces contrôleurs définissent l’état souhaité pour un groupe de pods, y compris la façon dont ils sont distribués et mis à l’échelle à travers les nœuds du cluster. Il faut définir les mêmes contraintes de la topologie des gousses sur toutes les gousses d’un groupe afin d’éviter toute confusion. Lors de l’utilisation d’un contrôleur de charge de travail, tel qu’un déploiement, le modèle de pod gère généralement cela pour vous.
  • Le mélange de différentes contraintes de propagation de la topologie des pod peut rendre Red Hat OpenShift Service sur le comportement AWS déroutant et dépannage plus difficile. Il est possible d’éviter cela en veillant à ce que tous les nœuds d’un domaine de topologie soient systématiquement étiquetés. Le service OpenShift Red Hat sur AWS affiche automatiquement des étiquettes bien connues, telles que kubernetes.io/hostname. Cela permet d’éviter la nécessité d’un étiquetage manuel des nœuds. Ces étiquettes fournissent des informations de topologie essentielles, assurant une étiquetage uniforme des nœuds dans l’ensemble du cluster.
  • En raison d’une contrainte, seuls les pods dans le même espace de noms sont appariés et regroupés ensemble lors de la propagation.
  • Il est possible de spécifier plusieurs contraintes de propagation de la topologie des pods, mais vous devez vous assurer qu’elles ne sont pas en conflit les uns avec les autres. Les contraintes de propagation de la topologie des gousses doivent être satisfaites pour qu’une gousse soit placée.

4.6.3. Comprendre l’oscillation et maxSkew
Copier lien

Le skew fait référence à la différence dans le nombre de pods qui correspondent à un sélecteur d’étiquette spécifié dans différents domaines de topologie, tels que les zones ou les nœuds.

L’oscillation est calculée pour chaque domaine en prenant la différence absolue entre le nombre de pods dans ce domaine et le nombre de pods dans le domaine avec le plus faible nombre de pods programmés. La définition d’une valeur maxSkew guide le planificateur pour maintenir une répartition équilibrée des pod.

4.6.3.1. Exemple de calcul biaisé
Copier lien

Il y a trois zones (A, B et C) et vous voulez répartir vos gousses uniformément sur ces zones. Lorsque la zone A a 5 gousses, la zone B a 3 gousses, et la zone C a 2 gousses, pour trouver l’équitation, vous pouvez soustraire le nombre de gousses dans le domaine avec la plus faible quantité de gousses programmées du nombre de gousses actuellement dans chaque zone. Cela signifie que l’oscillation pour la zone A est 3, l’oscillation pour la zone B est 1, et l’oscillation pour la zone C est 0.

4.6.3.2. Le paramètre maxSkew
Copier lien

Le paramètre maxSkew définit la différence maximale admissible, ou biaisé, dans le nombre de pods entre deux domaines de topologie. Lorsque maxSkew est défini à 1, le nombre de pods dans n’importe quel domaine de topologie ne doit pas différer de plus de 1 de tout autre domaine. Lorsque l’oscillation dépasse maxSkew, le planificateur tente de placer de nouvelles gousses d’une manière qui réduit l’oscillation, en adhérant aux contraintes.

À l’aide de l’exemple précédent, les valeurs d’axe dépassent la valeur maxSkew par défaut de 1. Le planificateur place de nouvelles gousses dans les zones B et C afin de réduire l’oscillation et d’obtenir une répartition plus équilibrée, en veillant à ce qu’aucun domaine de topologie ne dépasse l’écart de 1.

Il est possible de spécifier les pods à regrouper, quels domaines de topologie ils sont répartis entre eux, et l’oscillation acceptable.

Les exemples suivants montrent les configurations de contrainte de propagation de la topologie pod.

Exemple pour distribuer des pods qui correspondent aux étiquettes spécifiées en fonction de leur zone

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    region: us-east
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  topologySpreadConstraints:
  - maxSkew: 1
1 

    topologyKey: topology.kubernetes.io/zone
2 

    whenUnsatisfiable: DoNotSchedule
3 

    labelSelector:
4 

      matchLabels:
        region: us-east
5 

    matchLabelKeys:
      - my-pod-label
6 

  containers:
  - image: "docker.io/ocpqe/hello-pod"
    name: hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
Copy to Clipboard Toggle word wrap

1
La différence maximale de nombre de pods entre deux domaines de topologie. La valeur par défaut est 1, et vous ne pouvez pas spécifier une valeur de 0.
2
La clé d’une étiquette de nœud. Les nœuds avec cette clé et cette valeur identique sont considérés comme étant dans la même topologie.
3
Comment gérer une gousse si elle ne satisfait pas à la contrainte de propagation. La valeur par défaut est DoNotSchedule, qui indique au planificateur de ne pas programmer le pod. Définissez sur ScheduleAnyway pour toujours programmer le pod, mais le programmeur donne la priorité à honorer l’oscillation pour ne pas rendre le cluster plus déséquilibré.
4
Les pods qui correspondent à ce sélecteur d’étiquettes sont comptés et reconnus comme un groupe lors de la propagation pour satisfaire la contrainte. Assurez-vous de spécifier un sélecteur d’étiquette, sinon aucun pods ne peut être assorti.
5
Assurez-vous que cette spécification Pod définit également ses étiquettes pour correspondre à ce sélecteur d’étiquettes si vous voulez qu’il soit correctement compté à l’avenir.
6
Liste des touches d’étiquette de pod pour sélectionner les gousses à calculer.

Exemple de démonstration d’une contrainte de propagation de la topologie unique de la gousse

kind: Pod
apiVersion: v1
metadata:
  name: my-pod
  labels:
    region: us-east
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        region: us-east
  containers:
  - image: "docker.io/ocpqe/hello-pod"
    name: hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
Copy to Clipboard Toggle word wrap

L’exemple précédent définit un Pod spec avec une contrainte de propagation topologique d’une pod. Il correspond sur les gousses étiquetées région: us-est, distribue entre les zones, spécifie une biais de 1, et ne programme pas la gousse si elle ne répond pas à ces exigences.

Exemple démontrant les contraintes de propagation de la topologie des pod multiples

kind: Pod
apiVersion: v1
metadata:
  name: my-pod-2
  labels:
    region: us-east
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: node
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        region: us-east
  - maxSkew: 1
    topologyKey: rack
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        region: us-east
  containers:
  - image: "docker.io/ocpqe/hello-pod"
    name: hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
Copy to Clipboard Toggle word wrap

L’exemple précédent définit un Pod spec avec deux contraintes de propagation de la topologie de la pod. Les deux correspondent sur les gousses étiquetées région: us-est, spécifiez une biais de 1, et ne planifiez pas la gousse si elle ne répond pas à ces exigences.

La première contrainte distribue des pods en fonction d’un nœud d’étiquette défini par l’utilisateur, et la deuxième contrainte distribue des pods en fonction d’un rack d’étiquettes défini par l’utilisateur. Les deux contraintes doivent être remplies pour que la pod soit programmée.

Retour au début
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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2025 Red Hat