модульное планирование kubernetes с квотами ресурсов

#kubernetes #resources

#kubernetes #Ресурсы

Вопрос:

Я читал об управлении ресурсами k8s, но мне все еще не очень понятно. Допустим, у нас есть 2 узла k8s, каждый с 22 МБ памяти. Допустим, модуль A запрашивает 10 МБ и ограничивает 15 МБ (но допустим, фактическое использование составляет 5 МБ). итак, этот модуль запланирован на узле 1. Таким образом, узел 1 имеет 22 Мб памяти, 5 используется модулем A, но доступно еще 17 МБ, если модулю A. Модуль B имеет запрос 10 и ограничение 15 (в основном то же самое с модулем A). итак, этот модуль запланирован на узле 2

Таким образом, оба узла имеют 5 МБ использования из 22 МБ. Если модуль C имеет запрос 5 МБ и ограничение 10 МБ, будет ли этот модуль запланирован на каком-либо из узлов? Если да, что произойдет, для модуля C требуется 10 МБ памяти, а для другого модуля требуется 15 МБ памяти?

Что произойдет, если модуль C имеет запрос в 13 МБ и ограничение в 15 МБ? В этом случае 13 (запрос модуля C) 10 (запрос модуля A) будет равно 23 (больше 22)?

Пытается ли k8s убедиться, что запросы всех модулей <доступная память amp;amp; пределы всех модулей <доступная память?

Комментарии:

1. Предполагая , что ваш узел имеет 22 МБ ОЗУ, и ни один из них не используется другими компонентами, и вы попытались создать Pod на нем файл с запросом 10 МБ, а затем создать Pod файл с запросом 15 МБ, Pod он останется в Pending состоянии, поскольку Kubernetes не может гарантировать, что 15 МБ ОЗУ будет доступно(даже если сначала Pod не используются ресурсы). Я вижу, что вы просмотрели документацию K8S об этом, но видели ли вы документы о kube-scheduler ?

Ответ №1:

Отвечая на вопрос из сообщения:

Допустим, модуль A запрашивает 10 МБ и ограничивает 15 МБ (но допустим, фактическое использование составляет 5 МБ). итак, этот модуль запланирован на узле 1. Таким образом, узел 1 имеет 22 Мб памяти, 5 используется модулем A, но доступно еще 17 МБ, если модулю A. Модуль B имеет запрос 10 и ограничение 15 (в основном то же самое с модулем A). итак, этот модуль запланирован на узле 2

На самом деле это не вопрос, но я думаю, что в этой части требуется некоторое представление о том, как Pods планируются узлы. Компонент, который отвечает за указание Kubernetes, где a Pod должен быть запланирован, это: kube-scheduler . Это может привести к ситуации, когда вы говорите, что:

  • Pod A, req:10M, limit: 15M -> Node 1, mem: 22MB
  • Pod B req:10M, limit: 15M -> Node 2, mem: 22MB

Цитирование официальной документации:

Выбор узла в kube-планировщике

kube-scheduler выбирает узел для модуля в двухэтапной операции:

  • Фильтрация
  • Оценка

На этапе фильтрации определяется набор узлов, на которых возможно запланировать модуль. Например, фильтр PodFitsResources проверяет, достаточно ли у узла-кандидата доступных ресурсов для удовлетворения конкретных запросов модуля на ресурсы. После этого шага список узлов содержит любые подходящие узлы; часто их будет несколько. Если список пуст, этот модуль (пока) не может быть запланирован.

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

Наконец, kube-scheduler назначает модуль узлу с наивысшим рейтингом. Если существует более одного узла с одинаковыми оценками, kube-scheduler выбирает один из них случайным образом.

Kubernetes.io : Документы: Концепции: Планирование выселения: Kube sheduler: Реализация


Таким образом, оба узла имеют 5 МБ использования из 22 МБ. Если модуль C имеет запрос 5 МБ и ограничение 10 МБ, будет ли этот модуль запланирован на каком-либо из узлов? Если да, что произойдет, для модуля C требуется 10 МБ памяти, а для другого модуля требуется 15 МБ памяти?

В этом конкретном примере я бы гораздо больше сосредоточился на части запроса, а не на фактическом использовании. Предполагая, что нет другого фактора, который будет запрещать планирование, Pod C должно быть создано на одном из узлов (который kube-scheduler выбирает). Почему это так?:

  • resource.limits не будет запрещать планирование Pod (лимит может быть выше, чем объем памяти)
  • resource.requests будет отклонено планирование Pod (запрос не может превышать объем памяти)

Я рекомендую вам ознакомиться со следующими статьями, чтобы получить больше ссылок:


Что произойдет, если модуль C имеет запрос в 13 МБ и ограничение в 15 МБ? В этом случае 13 (запрос модуля C) 10 (запрос модуля A) будет равно 23 (больше 22)?

В этом примере Pod не будет запланировано как сумма запросов> память (при условии отсутствия Pod приоритета). Он Pod будет в Pending состоянии.


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