Afinidad y antiafinidad en Kubernetes

En circunstancias normales, el administrador no tiene que preocuparse por los nodos a los que asigna el Pod. Este proceso lo implementará automáticamente el programador. Pero a veces, necesitamos especificar algunas restricciones de programación, por ejemplo, algunas aplicaciones deben ejecutarse en un nodo con almacenamiento SSD, algunas aplicaciones deben ejecutarse en el mismo nodo, etc.

nodeSelector :
Primero planificamos la etiqueta para el Nodo, y luego, al crear la implementación, usamos la etiqueta nodeSelector para especificar en qué nodos se ejecuta el Pod.

Afinidad (afinidad) y antiafinidad (antiafinidad):

Afinidad: las dos aplicaciones de la Aplicación A y la Aplicación B interactúan con frecuencia, por lo que es necesario utilizar la afinidad para hacer que las dos aplicaciones estén lo más cerca posible, incluso en un nodo, para reducir la pérdida de rendimiento causada por la comunicación de red.
Antiafinidad: cuando la aplicación se implementa con varias copias, es necesario utilizar antiafinidad para dispersar cada instancia de la aplicación en cada nodo para mejorar la alta disponibilidad.

Contiene: nodeAffinity (afinidad del host), podAffinity (afinidad POD) y podAntiAffinity (antiafinidad POD)

Nombre de la estrategia	Objetivo de coincidencia	Operadores compatibles	Dominio de topología de soporte	Objetivos de diseño
nodeAffinity	Etiqueta de host	En, NotIn, Exists, DoesNotExist, Gt, Lt	no apoyo	Decidir en qué hosts se puede implementar el Pod
podAffinity	Etiquetas de vaina	En, NotIn, Existe, DoesNotExist	colocarse	Decidir qué pod se puede implementar en el mismo dominio de topología que qué pod
PodAntiAffinity	Etiquetas de vaina	En, NotIn, Existe, DoesNotExist	colocarse	Decide qué pods no se pueden implementar en la misma extensión

Escenarios de uso de NodeAffinity :

Implemente todos los pods del servicio S1 en hosts designados que cumplan con las reglas de etiquetado.
Implemente todos los pods del servicio S1 en otros hosts, excepto algunos hosts.
Escenarios de uso de PodAffinity:
Implemente un módulo de servicio específico en el mismo dominio de topología sin especificar un dominio de topología específico.
Si el servicio S1 usa el servicio S2, para reducir el retraso de la red entre ellos (u otras razones), implemente el POD del servicio S1 y el pod del servicio S2 en el mismo dominio de topología.
Escenarios de uso de PodAntiAffinity:
Dispersar el POD de un servicio en diferentes hosts o dominios topológicos para mejorar la estabilidad del propio servicio.
Otorgue a POD acceso exclusivo a un nodo para garantizar el aislamiento de recursos y asegurarse de que ningún otro pods comparta los recursos del nodo.
Distribuya los POD de los servicios que pueden afectarse entre sí en diferentes hosts.

Relación con el operador:

En: el valor de la etiqueta está en una lista
NotIn: el valor de la etiqueta no está en una lista
Gt: el valor de la etiqueta es mayor que cierto valor
Lt: el valor de la etiqueta es menor que cierto valor
Existe: existe una etiqueta
DoesNotExist: una etiqueta no existe

El método de programación de nodeSelector es un poco más simple. A través de la configuración de afinidad y antiafinidad, puede proporcionar estrategias más flexibles para la programación. Las principales mejoras son las siguientes:

Más soporte de expresión, no solo ADD y concordancia exacta
Puede establecer una estrategia de programación suave / preferencial en lugar de requisitos rígidos
Las restricciones de programación se pueden realizar mediante etiquetas Pod, no solo etiquetas de nodo

Las funciones de afinidad incluyen dos formas:

requiredDuringSchedulingIgnoredDuringExecution: estricto, estrictamente aplicado y cumple con la programación de reglas; de lo contrario, no se programará y se ejecutará en la etapa de preselección, por lo que no se programará para violar el acuerdo estricto
preferidoDuringSchedulingIgnoredDuringExecution: suave, haz tu mejor esfuerzo para ejecutar, da prioridad a la programación de reglas de cumplimiento y ejecuta en la etapa preferida
requiredDuringSchedulingRequiredDuringExecution, similar a requiredDuringSchedulingIgnoredDuringExecution. La diferencia es que si el nodo ya no satisface la afinidad del pod durante la ejecución del pod, el pod será desalojado del nodo.

IgnoreDuringExecution indica que si la etiqueta del nodo cambia durante la operación del pod, lo que hace que la política de afinidad no se cumpla, el pod actual seguirá ejecutándose.

Limitar
topología Clave:

Para afinidad y antiafinidad suave, no se permite topologyKey vacía;
Para la antiafinidad dura, el controlador LimitPodHardAntiAffinityTopology se utiliza para limitar la topologyKey a kubernetes.io/hostname;
Para la antiafinidad suave, una topologyKey vacía se interpreta como una combinación de kubernetes.io/hostname, failure-domain.beta.kubernetes.io/zone y failure-domain.beta.kubernetes.io/region;

ejemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      app: redis
  replicas: 3
  template:
    metadata:
      labels:
        app: redis
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - redis
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:latest

En el ejemplo anterior, se crea una implementación con tres instancias y se adopta la estrategia de antiafinidad entre pods. Cuando las instancias creadas están restringidas, si una instancia con la misma etiqueta ya existe en el nodo, la implementación no se realiza, lo que evita Implemente varias instancias idénticas en un nodo.

Basado en el ejemplo anterior:

Cree 3 instancias de servicio web más, lo mismo que la configuración de Redis anterior, primero asegúrese de que las dos web no se implementarán en el mismo nodo, luego aplique la política de afinidad entre pods y, primero, implemente la web en el nodo con el servicio Redis.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - redis
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: nginx:latest

⚠️Notas:

La estrategia de afinidad entre pods requiere una cantidad considerable de cálculos, lo que puede reducir significativamente el rendimiento del clúster. No se recomienda usarla en el rango de más de 100 nodos.
La política de antiafinidad entre pods requiere que todos los nodos tengan etiquetas coherentes. Por ejemplo, todos los nodos del clúster deben tener etiquetas que coincidan con la clave de topología. Si algunos nodos carecen de estas etiquetas, puede provocar un comportamiento anormal.
Si nodeSelector y nodeAffinity se especifican al mismo tiempo, se deben cumplir dos condiciones antes de que el pod pueda programarse en el nodo candidato.
Si el pod ya está programado en el nodo, cuando eliminamos o modificamos la etiqueta del nodo, el pod no se eliminará. En otras palabras, la selección de afinidad solo es válida durante la programación del pod.
Siempre que uno de los valores de la clave cumpla la condición, la clave actual cumple la condición
Si hay varias listas de claves en matchExpressions, el pod se puede programar en un determinado nodo [para afinidad dura] solo cuando se satisfacen todas las claves.

Afinidad y antiafinidad en Kubernetes

Supongo que te gusta