Kubernetes - Как отлаживать неудачное планирование «0 узлов доступно»

Вначале я советую взглянуть на Компонент планировщика Kubernetes:

Компонент на главном сервере, который наблюдает за вновь созданными модулями, которым не назначен узел, и выбирает узел, на котором они будут работать. [-] Факторы, принимаемые во внимание при принятии решений о планировании, включают индивидуальные и коллективные требования к ресурсам, аппаратные / программные / политические ограничения, сходство а также спецификации анти-сродства, локальность данных, взаимодействие между рабочими нагрузками и сроки.

Планировщик наблюдает за вновь созданными модулями, которым не назначен узел. Для каждого модуля, который обнаруживает планировщик, планировщик становится ответственным за поиск лучшего узла для этого модуля для запуска. Для каждого вновь созданного модуля или других незапланированных модулей kube-scheduler выбирает оптимальный узел, на котором они будут работать. Однако у каждого контейнера в подах разные требования к ресурсам, и у каждого пода также разные требования. Следовательно, существующие узлы необходимо фильтровать в соответствии с конкретными требованиями планирования.

Согласно документации:

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

kube-scheduler выбирает узел для модуля за 2 этапа. Стандартный kube-планировщик на основе Политики по умолчанию:

• Фильтрация
• Подсчет очков

Изучая эти две политики, вы можете найти дополнительную информацию о том, где были приняты решения. Например:

for scoring at the stage CalculateAntiAffinityPriorityMap This policy helps implement pod anti-affinity.

Ниже вы можете найти быстрый обзор, основанный на влиянии Решения планировщика Kubernetes

• Имя узла: добавляя имя узла к параметру .spec.nodeName определения модуля, вы заставляете этот модуль запускаться на этом конкретном узле. Любой алгоритм выбора, используемый планировщиком, игнорируется. Этот метод наименее рекомендуется.
• Селектор узлов: размещая значимые метки на ваших узлах, Pod может использовать параметр nodeSelector, чтобы указать одну или несколько карт меток ключ-значение, которые должны существовать на целевом узле, чтобы их выбрали для запуска этого Pod. Этот подход более рекомендуется, поскольку он добавляет большую гибкость и устанавливает слабосвязанные отношения узел-под.
• Сходство узла: этот метод добавляет еще больше гибкости при выборе узла, который следует учитывать при планировании конкретного модуля. При использовании привязки к узлу для модуля может потребоваться строгое планирование на узлах с определенными метками. Он также может выражать некоторую степень предпочтения по отношению к конкретным узлам, влияя на планировщик, чтобы придать им больший вес.
• Родство стручка и анти-сродство: когда сосуществование Pod (или несовместимость) с другими Pod'ами на одном узле важно, вы можете использовать этот метод. Сходство Pod позволяет Pod требовать, чтобы он развертывался на узлах, на которых есть Pod с определенными метками. Точно так же Pod может заставить планировщик не размещать его на узлах, имеющих Pod с определенными метками.
• Пороки и терпимость: в этом методе вместо того, чтобы решать, для каких узлов будет запланирован Pod, вы решаете, какие узлы не должны принимать никакие Pod'ы вообще или только выбранные Pod'ы. Заражая узел, вы инструктируете планировщик не рассматривать этот узел для любого размещения модуля, за исключением случаев, когда модуль допускает заражение. Терпимость состоит из ключа, значения и эффекта заражения. Используя оператор, вы можете решить, должно ли заражение полностью соответствовать допуску для успешного размещения Pod или соответствовать только подмножеству данных.

Согласно k8s документация:

1. NodeName - простейшая форма ограничения выбора узла, но из-за ее ограничений обычно не используется. Некоторые из ограничений использования nodeName для выбора узлов:

• Если названный узел не существует, модуль не будет запущен, а в некоторых случаях может быть автоматически удален.
• Если названный узел не имеет ресурсов для размещения модуля, модуль выйдет из строя, и его причина будет указывать причину, например OutOfmemory или OutOfcpu. Имена узлов в облачных средах не всегда предсказуемы или стабильны.

2. В аффинность / антиаффинность функция, значительно расширяет типы ограничений, которые вы можете выразить. Ключевые улучшения: - Язык стал более выразительным (не просто «И для точного соответствия») - вы можете указать, что правило является «мягким» / «предпочтительным», а не жестким требованием, поэтому, если планировщик не может удовлетворить это, модуль все равно будет запланирован - вы можете ограничить метки на других модулях, работающих на узле (или другом топологическом домене), а не против меток на самом узле, что позволяет правила о том, какие модули могут и не могут быть совмещены

Функция близости состоит из двух типов близости: сходство узлов и межстабовое сродство / анти-сродство. Сходство узла похоже на существующий nodeSelector (но с первыми двумя преимуществами, перечисленными выше),

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

Надеюсь на эту помощь.

Дополнительные ресурсы:

• Сродство и анти-сродство

• планировщик Performance Tuning

• Разбираемся с пороками и терпимостью в Kubernetes

• Kubernetes Taints и Tolerations PreferNoSchedule