Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

4.2. Placer des gousses par rapport à d’autres gousses en utilisant des règles d’affinité et d’anti-affinité

Affinité est une propriété de pods qui contrôle les nœuds sur lesquels ils préfèrent être programmés. L’anti-affinité est une propriété de gousses qui empêche une gousse d’être programmée sur un nœud.

Dans Red Hat OpenShift Service sur AWS, l’affinité de pod et la pod anti-affinité vous permettent de limiter les nœuds que votre pod est éligible pour être programmé sur la base des étiquettes de valeur clé sur d’autres gousses.

4.2.1. Comprendre l’affinité des gousses
Copier lien

L’affinité des pod et la pod anti-affinité vous permettent de limiter les nœuds sur lesquels votre pod est admissible à être programmé sur la base des étiquettes clé / valeur sur d’autres gousses.

  • L’affinité des gousses peut indiquer au planificateur de localiser une nouvelle gousse sur le même nœud que les autres gousses si le sélecteur d’étiquettes sur la nouvelle gousse correspond à l’étiquette sur la gousse actuelle.
  • La pod anti-affinité peut empêcher le planificateur de localiser une nouvelle gousse sur le même nœud que les gousses avec les mêmes étiquettes si le sélecteur d’étiquettes sur la nouvelle gousse correspond à l’étiquette sur la gousse actuelle.

À titre d’exemple, en utilisant des règles d’affinité, vous pouvez diffuser ou emballer des pods au sein d’un service ou par rapport à des pods dans d’autres services. Les règles anti-affinité vous permettent d’empêcher les pods d’un service particulier de planifier sur les mêmes nœuds que les pods d’un autre service qui sont connus pour interférer avec l’exécution des pods du premier service. De plus, vous pouvez répartir les pods d’un service entre les nœuds, les zones de disponibilité ou les ensembles de disponibilité afin de réduire les défaillances corrélées.

Note

Le sélecteur d’étiquettes peut correspondre à des pods avec plusieurs déploiements de pod. Employez des combinaisons uniques d’étiquettes lors de la configuration des règles anti-affinité pour éviter de faire correspondre les pods.

Il existe deux types de règles d’affinité de pod: requises et préférées.

Les règles requises doivent être respectées avant qu’un pod puisse être programmé sur un nœud. Les règles préférées précisent que, si la règle est respectée, le programmeur tente d’appliquer les règles, mais ne garantit pas l’exécution.

Note

En fonction de votre priorité de pod et des paramètres de préemption, le planificateur peut ne pas être en mesure de trouver un nœud approprié pour un pod sans violer les exigences d’affinité. Dans l’affirmative, un pod pourrait ne pas être programmé.

Afin d’éviter cette situation, configurez soigneusement l’affinité des pods avec des pods de priorité égale.

Configurez l’affinité des pod/anti-affinité à travers les fichiers Pod spec. Il est possible de spécifier une règle requise, une règle préférée ou les deux. Lorsque vous spécifiez les deux, le nœud doit d’abord respecter la règle requise, puis tente de respecter la règle préférée.

L’exemple suivant montre un Pod spec configuré pour l’affinité des pod et anti-affinité.

Dans cet exemple, la règle d’affinité des pod indique que le pod ne peut programmer sur un nœud que si ce nœud a au moins un pod déjà en cours d’exécution avec une étiquette qui a la sécurité clé et la valeur S1. La règle anti-affinité de pod dit que la gousse préfère ne pas programmer sur un nœud si ce nœud est déjà en train d’exécuter un pod avec une étiquette ayant la sécurité clé et la valeur S2.

Exemple de fichier de configuration Pod avec affinité de pod

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  affinity:
    podAffinity:
1 

      requiredDuringSchedulingIgnoredDuringExecution:
2 

      - labelSelector:
          matchExpressions:
          - key: security
3 

            operator: In
4 

            values:
            - S1
5 

        topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
Copy to Clipboard Toggle word wrap

1
La strophe pour configurer l’affinité des pod.
2
Définit une règle requise.
3 5
La clé et la valeur (étiquette) qui doivent être assorties pour appliquer la règle.
4
L’opérateur représente la relation entre l’étiquette sur la gousse existante et l’ensemble de valeurs dans les paramètres de correspondanceExpression dans la spécification du nouveau pod. Il peut être dans, NotIn, existe ou n’existe pas.

Exemple de fichier de configuration Pod avec pod anti-affinité

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  affinity:
    podAntiAffinity:
1 

      preferredDuringSchedulingIgnoredDuringExecution:
2 

      - weight: 100
3 

        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
4 

              operator: In
5 

              values:
              - S2
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
Copy to Clipboard Toggle word wrap

1
Configuration de la pod anti-affinité.
2
Définit une règle préférée.
3
Indique un poids pour une règle préférée. Le nœud avec le poids le plus élevé est préféré.
4
Description de l’étiquette de pod qui détermine quand la règle anti-affinité s’applique. Indiquez une clé et une valeur pour l’étiquette.
5
L’opérateur représente la relation entre l’étiquette sur la gousse existante et l’ensemble de valeurs dans les paramètres de correspondanceExpression dans la spécification du nouveau pod. Il peut être dans, NotIn, existe ou n’existe pas.
Note

Lorsque les étiquettes sur un nœud changent au moment de l’exécution, de telle sorte que les règles d’affinité sur une gousse ne sont plus respectées, la gousse continue de fonctionner sur le nœud.

4.2.2. Configuration d’une règle d’affinité de pod
Copier lien

Les étapes suivantes démontrent une configuration simple à deux pod qui crée un pod avec une étiquette et une gousse qui utilise l’affinité pour permettre la planification avec cette gousse.

Note

Il est impossible d’ajouter une affinité directement à un pod programmé.

Procédure

  1. Créer un pod avec une étiquette spécifique dans le pod spec:

    1. Créez un fichier YAML avec le contenu suivant: 

      apiVersion: v1
kind: Pod
metadata:
  name: security-s1
  labels:
    security: S1
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: security-s1
    image: docker.io/ocpqe/hello-pod
    securityContext:
      runAsNonRoot: true
      seccompProfile:
        type: RuntimeDefault
      Copy to Clipboard Toggle word wrap

    2. Créez le pod. 

      $ oc create -f <pod-spec>.yaml
      Copy to Clipboard Toggle word wrap

  2. Lors de la création d’autres pods, configurez les paramètres suivants pour ajouter l’affinité:

    1. Créez un fichier YAML avec le contenu suivant: 

      apiVersion: v1
kind: Pod
metadata:
  name: security-s1-east
# ...
spec:
  affinity:
      1 
      
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      2 
      
      - labelSelector:
          matchExpressions:
          - key: security
      3 
      
            values:
            - S1
            operator: In
      4 
      
        topologyKey: topology.kubernetes.io/zone
      5 
      
# ...
      Copy to Clipboard Toggle word wrap
      1
      Ajoute une affinité de gousse.
      2
      Configure le paramètre requisDuringSchedulingIgnoredDuringExecution ou le paramètre préféréDuringSchedulingIgnoredDuringExecution.
      3
      Indique la clé et les valeurs qui doivent être remplies. Lorsque vous souhaitez que la nouvelle gousse soit programmée avec l’autre pod, utilisez les mêmes paramètres de clé et de valeurs que l’étiquette sur le premier pod.
      4
      Indique un opérateur. L’opérateur peut être dans, NotIn, existant ou ne pas exister. À titre d’exemple, utilisez l’opérateur In pour exiger que l’étiquette soit dans le nœud.
      5
      Indiquez une topologyKey, qui est un label Kubernetes prépeuplé que le système utilise pour désigner un tel domaine de topologie.

    2. Créez le pod. 

      $ oc create -f <pod-spec>.yaml
      Copy to Clipboard Toggle word wrap

4.2.3. Configuration d’une règle anti-affinité de pod
Copier lien

Les étapes suivantes démontrent une configuration simple à deux pod qui crée un pod avec une étiquette et un pod qui utilise une règle préférée anti-affinité pour tenter d’empêcher la planification avec ce pod.

Note

Il est impossible d’ajouter une affinité directement à un pod programmé.

Procédure

  1. Créer un pod avec une étiquette spécifique dans le pod spec:

    1. Créez un fichier YAML avec le contenu suivant: 

      apiVersion: v1
kind: Pod
metadata:
  name: security-s1
  labels:
    security: S1
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: security-s1
    image: docker.io/ocpqe/hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
      Copy to Clipboard Toggle word wrap

    2. Créez le pod. 

      $ oc create -f <pod-spec>.yaml
      Copy to Clipboard Toggle word wrap

  2. Lors de la création d’autres pods, configurez les paramètres suivants:

    1. Créez un fichier YAML avec le contenu suivant: 

      apiVersion: v1
kind: Pod
metadata:
  name: security-s2-east
# ...
spec:
# ...
  affinity:
      1 
      
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      2 
      
      - weight: 100
      3 
      
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
      4 
      
              values:
              - S1
              operator: In
      5 
      
          topologyKey: kubernetes.io/hostname
      6 
      
# ...
      Copy to Clipboard Toggle word wrap
      1
      Ajoute une pod anti-affinité.
      2
      Configure le paramètre requisDuringSchedulingIgnoredDuringExecution ou le paramètre préféréDuringSchedulingIgnoredDuringExecution.
      3
      Dans le cas d’une règle préférée, spécifie un poids pour le nœud, 1-100. Le nœud qui a le poids le plus élevé est préféré.
      4
      Indique la clé et les valeurs qui doivent être remplies. Lorsque vous voulez que le nouveau pod ne soit pas programmé avec l’autre pod, utilisez les mêmes paramètres de clé et de valeurs que l’étiquette sur la première gousse.
      5
      Indique un opérateur. L’opérateur peut être dans, NotIn, existant ou ne pas exister. À titre d’exemple, utilisez l’opérateur In pour exiger que l’étiquette soit dans le nœud.
      6
      Indique une topologyKey, qui est un label Kubernetes prépeuplé que le système utilise pour désigner un tel domaine de topologie.

    2. Créez le pod. 

      $ oc create -f <pod-spec>.yaml
      Copy to Clipboard Toggle word wrap

Les exemples suivants démontrent l’affinité des pod et la pod anti-affinité.

4.2.4.1. Affinité des pod
Copier lien

L’exemple suivant montre l’affinité des pod pour les gousses avec des étiquettes et des sélecteurs d’étiquettes assortis.

  • L’équipe de pod4 a l’équipe de label:4. 

    apiVersion: v1
kind: Pod
metadata:
  name: team4
  labels:
     team: "4"
# ...
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
# ...
    Copy to Clipboard Toggle word wrap

  • Le pod team4a a l’équipe de sélecteur d’étiquettes:4 sous PodAffinity. 

    apiVersion: v1
kind: Pod
metadata:
  name: team4a
# ...
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: team
            operator: In
            values:
            - "4"
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-affinity
    image: docker.io/ocpqe/hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
# ...
    Copy to Clipboard Toggle word wrap
  • Le pod team4a est prévu sur le même nœud que le groupe Team4.

4.2.4.2. Anti-affinité de pod
Copier lien

L’exemple suivant montre la pod anti-affinité pour les gousses avec des étiquettes assorties et des sélecteurs d’étiquettes.

  • Le pod-s1 a la sécurité de l’étiquette:s1. 

    apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
  labels:
    security: s1
# ...
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
# ...
    Copy to Clipboard Toggle word wrap

  • Le pod pod-s2 a le sélecteur d’étiquette de sécurité:s1 sous PodAntiAffinity. 

    apiVersion: v1
kind: Pod
metadata:
  name: pod-s2
# ...
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - s1
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-antiaffinity
    image: docker.io/ocpqe/hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
# ...
    Copy to Clipboard Toggle word wrap
  • Le pod-s2 ne peut pas être programmé sur le même nœud que pod-s1.

4.2.4.3. Affinité de pod sans étiquettes correspondantes
Copier lien

L’exemple suivant montre l’affinité des pods pour les gousses sans assortir les étiquettes et les sélecteurs d’étiquettes.

  • Le pod-s1 a la sécurité de l’étiquette:s1. 

    apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
  labels:
    security: s1
# ...
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
# ...
    Copy to Clipboard Toggle word wrap

  • Le pod pod-s2 a la sécurité du sélecteur d’étiquettes:s2. 

    apiVersion: v1
kind: Pod
metadata:
  name: pod-s2
# ...
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - s2
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-affinity
    image: docker.io/ocpqe/hello-pod
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
# ...
    Copy to Clipboard Toggle word wrap

  • Le pod-s2 n’est pas programmé à moins qu’il n’y ait un nœud avec un pod qui a l’étiquette de sécurité:s2. Lorsqu’il n’y a pas d’autre pod avec cette étiquette, la nouvelle gousse reste dans un état en attente:

    Exemple de sortie

    NAME      READY     STATUS    RESTARTS   AGE       IP        NODE
pod-s2    0/1       Pending   0          32s       <none>
    Copy to Clipboard Toggle word wrap

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