Как равномерно развернуть поды на всех узлах в Kubernetes?

У меня есть несколько кластеров Kubernetes с разными #of узлов в каждом. И в моем развертывании конфигурации есть «реплики: # узлы». Не существует конкретной конфигурации, настроенной для планирования этого модуля, но после развертывания я вижу странное поведение с точки зрения распределения модулей по узлам.

Пример:

Для кластера из 30 узлов (30 реплик) все 30 реплик подов распределены только по 25 узлам, а остальные 5 узлов идеально подходят для кластера. Подобные случаи для многих других различных кластеров, и это количество меняется в каждом новом / передислокация.

Вопрос:

Я хочу распределить реплики своих модулей по всем узлам. Если я установил "replicas: #nodes", то у меня должна быть одна реплика пода в каждом узле. Если я увеличиваю / удваиваю количество реплик, оно должно распределяться равномерно. есть ли какая-то конкретная конфигурация в развертывании yaml для Kubernetes?

Конфигурация с узлом AntiAffinity, но он по-прежнему ведет себя как указано выше. Пробовал с «requiredDuringSchedulingIgnoredDuringExecution», и тот действительно развернул по одному модулю на каждом узле, но если я увеличиваю количество реплик или какой-либо узел выходит из строя во время развертывания, тогда все развертывание терпит неудачу.

metadata:
  labels:
    app: test1
spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - test1
          topologyKey: kubernetes.io/hostname

person CRP08    schedule 21.12.2019    source источник
comment
Какие проблемы у вас возникают с тем, что поды не распределены равномерно? По какой причине для вас важно, чтобы модули были запланированы для всех узлов? Kubernetes абстрагируется от инфраструктуры, поэтому вы не должны слишком много думать об этом, если у вас нет проблем с этим.   -  person Jonas    schedule 21.12.2019
comment
Вероятно, вы ищете что-то вроде podAntiAffinity с preferredDuringSchedulingIgnoredDuringExecution, что взвешивает планирование, чтобы не помещать модуль на узел, где модули с определенной меткой уже существуют. Это не сбой планирования, если невозможно запланировать на другом узле, просто предпочитает немного больше не делать этого.   -  person Joachim Isaksson    schedule 21.12.2019
comment
@ Jonas: я столкнулся с худшим распределением модулей, 32 модуля распределены только по 3 узлам вместо кластера из 32 узлов.   -  person CRP08    schedule 24.12.2019
comment
@ JoachimIsaksson - уже пробовал использовать предложенную выше конфигурацию, но она все еще ведет себя так, как я привел в рассматриваемом примере. В моей конфигурации, где я хочу предпочесть node, не имеющий аналогичной метки pod. Но все же он распределен по 28 узлам вместо 32. У меня нет других модулей, работающих на этих узлах, которые могут вызвать проблему использования ресурсов.   -  person CRP08    schedule 24.12.2019
comment
Если 32 модуля подходят только к 3 узлам, почему у вас так много узлов ... похоже, что модули используют очень мало ресурсов. Так что с расписанием все в порядке. Не понимаю, в чем проблема?   -  person Jonas    schedule 24.12.2019
comment
Можете ли вы вставить логи из kube-scheduler? См., Например, stackoverflow.com/questions/58885793/   -  person Jonas    schedule 24.12.2019
comment
Анти-сродство должно сработать, у вас другая проблема. Можете ли вы опубликовать более подробную информацию, такую ​​как полное развертывание YAML, и предоставить выходные данные узла описания, один для узла с модулями на нем и один для узла без модулей на нем.   -  person Patrick W    schedule 24.12.2019
comment
Следует отметить, что количество модулей и узлов должно быть в равной степени делимым на количество имеющихся у вас зон доступности - мы видели проблемы в AWS, где у нас есть 4 узла и 16 реплик ... и разработчики ожидают они должны быть распределены равномерно, но метка failure-domain использует AZ, а это означает, что они не будут распределены равномерно.   -  person Andrew    schedule 06.01.2020


Ответы (2)


Если вам требуется развертывание одного модуля на узел, вы должны использовать daemonSet вместо набора реплик. В качестве альтернативы, если вам нужно более 1 модуля на узел и вы все еще хотите, чтобы распределение модулей было в основном равномерным, вы можете использовать антиаффинность модуля, как я обсуждал в этом сообщении

person Patrick W    schedule 21.12.2019
comment
См. Обновленные сведения о вопросе. У меня есть конфигурация для анти-сродства стручков, но она все равно не помогает мне в равномерном распределении. - person CRP08; 24.12.2019
comment
К сожалению, «предпочтительный» ничего не гарантирует. Планировщик попытается разложить поды как можно больше, но это все равно не будет идеальным распределением. Вес, который вы добавили, является важной частью принятия решения, но есть и много других факторов. - person Patrick W; 24.12.2019

см. Ограничения распространения топологии Pod https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ эта функция дает вам разрешение точно определять, как ваши модули будут распределяться по кластеру на основе регионов, зон, узлов и других определяемых пользователем домены топологии.

Таким образом, вы можете определить свои собственные правила распределения стручков.

person vvchik    schedule 24.10.2020
comment
какая версия k8s это поддерживает? - person Ostap; 28.01.2021
comment
1.19 (для более ранних версий необходимо включить некоторые дополнительные функции. См. Ссылку в ответе) - person vvchik; 03.05.2021