Что такое Pod Affinity и Anti-Affinity в Kubernetes?

Kubernetes — это распределенная система, предназначенная для масштабирования реплик ваших сервисов в нескольких физических средах. Во многих случаях это хорошо работает «из коробки». Планировщик Kubernetes автоматически размещает ваши поды (экземпляры контейнеров) на узлах (рабочих машинах), у которых достаточно ресурсов для их поддержки.

Несмотря на все усилия, иногда планировщик не выбирает план, с которым вы согласны. Вы можете захотеть, чтобы поды были размещены вместе, если они будут регулярно обмениваться данными по сети; в качестве альтернативы, некоторые поды, требующие больших вычислительных ресурсов, могут быть лучше всего распределены по отдельным узлам, где это возможно.

В Kubernetes есть несколько механизмов, которые позволяют планировщику направлять процесс принятия решений таким образом, чтобы поды оказывались на определенных узлах. В этой статье мы сосредоточимся конкретно на понятиях «близость» и «анти-близость», которые дают вам детальный контроль над планированием. Сходства определяют правила, которые либо должны, либо должны быть соблюдены, прежде чем под можно будет выделить узлу.

Как работает аффинити?

Соответствия используются для выражения ограничений планирования подов, которые могут соответствовать характеристикам узлов-кандидатов и подов, которые уже работают на этих узлах. Pod, который имеет «близость» к данному узлу, с большей вероятностью будет назначен на него; и наоборот, «антиблизость» снижает вероятность того, что это будет запланировано. Общий баланс этих весов используется для определения окончательного размещения каждого модуля.

Оценки сходства могут давать как жесткие, так и мягкие результаты. «Жесткий» результат означает, что узел должен иметь характеристики, определенные выражением сходства. «Мягкие» привязки действуют как предпочтение, указывая планировщику, что ему следует использовать узел с характеристиками, если он доступен. Узел, который не соответствует условию, все равно будет выбран при необходимости.

Типы состояния близости

В настоящее время существует два различных вида сходства, которые вы можете определить:

• Привязка узлов – используется для ограничения узлов, которые могут получать Pod, путем сопоставления меток этих узлов. Сходство узла можно использовать только для установки положительного сходства, привлекающего поды к узлу.
• Связь между модулями — используется для ограничения узлов, которые могут получать модуль, путем сопоставления меток существующих модулей, уже запущенных на каждом из этих узлов. Inter-Pod Affinity может быть как притягивающим, так и отталкивающим анти-родством.

В простейшем возможном примере под, который включает условие привязки к узлу label=value, будет запланирован только для узлов с меткой label=value. Pod с тем же условием, но определенный как межмодульное соответствие, будет назначен на узел, на котором уже размещен Pod с меткой label=value.

Настройка сходства узлов

Node Affinity имеет два различных подтипа:

• requiredDuringSchedulingIgnoredDuringExecution – это жесткое сопоставление сходства, требующее, чтобы узел соответствовал заданным вами ограничениям.
• preferredDuringSchedulingIgnoredDuringExecution – это «мягкое» сопоставление для выражения предпочтения, которое игнорируется, если оно не может быть выполнено.

Часть этих подробных имен IgnoredDuringExecution указывает на то, что сходство учитывается только при планировании подов. После того, как Pod добрался до Node, сходство не переоценивается. Изменения в узле не приведут к выселению пода из-за измененных значений сходства. В будущем выпуске Kubernetes может быть добавлена поддержка этого поведения с помощью зарезервированной фразы requiredDuringSchedulingRequiredDuringExecution.

Привязки узлов привязываются к модулям через их поле манифеста spec.affinity.nodeAffinity:

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: demo-container
    # ...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
            - key: hardware-class
              operator: In
              values:
                - a
                - b
                - c
          - matchExpressions:
            - key: internal
              operator: Exists

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: demo-container
    # ...
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: hardware-class
            operator: In
            values:
              - a
              - b
              - c

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: demo-container
    # ...
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: hardware-class
                operator: In
                values:
                  - a
                  - b
                  - c
          topologyKey: topology.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          podAffinityTerm:
            - labelSelector:
                matchExpressions:
                  - key: app-component
                    operator: In
                    values:
                      - background-worker
          topologyKey: topology.kubernetes.io/zone

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
    - name: demo
      # ...
  nodeSelector:
    hardware-class: a
    internal: true