#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
(запрос не может превышать объем памяти)
Я рекомендую вам ознакомиться со следующими статьями, чтобы получить больше ссылок:
- Sysdig.com : Блог: Kubernetes ограничивает запросы
- Cloud.google.com : Блог: Продукты: Контейнеры Kubernetes: Рекомендации Kubernetes: (это
GKE
блог, но он должен дать базовую идею, см. Раздел «Жизненный цикл модуля Kubernetes»)
Что произойдет, если модуль C имеет запрос в 13 МБ и ограничение в 15 МБ? В этом случае 13 (запрос модуля C) 10 (запрос модуля A) будет равно 23 (больше 22)?
В этом примере Pod
не будет запланировано как сумма запросов> память (при условии отсутствия Pod
приоритета). Он Pod
будет в Pending
состоянии.
Дополнительные ресурсы: