Учитывает ли Kubernetes текущее использование памяти при планировании модулей - PullRequest
1 голос
/ 07 июня 2019

Документы Kubernetes для https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ состояния:

Планировщик гарантирует, что для каждого типа ресурса сумма запросов ресурсов запланированных контейнеров будет меньше емкостиthe node.

Учитывает ли Kubernetes текущее состояние узла при расчете емкости?Чтобы подчеркнуть то, что я имею в виду, приведу конкретный пример:

Предполагается, что у меня есть узел с 10 ГБ ОЗУ, работающий по 10 модулей с 500 млн. Запросов ресурсов без ограничений.Допустим, они «лопаются», и каждый Pod фактически использует 1Gi RAM.В этом случае узел полностью используется (10 x 1Gi = 10Gi), но запросы ресурсов - только 10 x 500Mi = 5Gi.Будет ли Kubernetes рассмотреть планирование другого модуля на этом узле, потому что только 50% объема памяти на узле было requested, или он будет использовать тот факт, что 100% памяти используется в настоящее время, и узел находится на полную емкость

Ответы [ 3 ]

0 голосов
/ 14 июня 2019

Определенно ДА , Kubernetes учитывает использование памяти во время процесса планирования модуля.

Планировщик обеспечивает, чтобы для каждого типа ресурса сумма запросов ресурсов запланированных контейнеров была меньшеемкость узла.Обратите внимание, что хотя фактическое использование ресурсов памяти или ЦП на узлах очень низкое, планировщик по-прежнему отказывается разместить Pod на узле, если проверка емкости не удалась.Это защищает от нехватки ресурсов на узле, когда впоследствии увеличивается использование ресурса, например, во время ежедневного пика частоты запросов.

В планировании есть два ключевых понятия.Во-первых, планировщик пытается отфильтровать узлы, которые способны запускать данный модуль, на основании запросов ресурсов и других требований планирования.Во-вторых, планировщик взвешивает подходящие узлы на основе абсолютного и относительного использования ресурсов узлов и других факторов.Самый высокий взвешенный приемлемый узел выбран для планирования модуля.Хорошее объяснение календарного планирования в Kuberneres вы можете найти здесь: kubernetes-scheduling.

Простой пример : ваш модуль обычно использует 100 Mi ОЗУ, но вы запускаете его с50 Ми просьба.Если у вас есть узел с 75 Mi free, планировщик может выбрать запуск модуля там.Когда позднее потребление памяти модуля увеличивается до 100 Mi, это подвергает узел давлению , и в этот момент ядро ​​ может решить убить ваш процесс.Поэтому важно правильно настроить как запросы, так и ограничения памяти.Об использовании памяти, запросах и ограничениях вы можете прочитать здесь: memory-resource.

Контейнер может превысить свой запрос памяти, если у узла есть доступная память.Но контейнеру не разрешено использовать больше, чем его предел памяти.Если контейнер выделяет больше памяти, чем его предел, контейнер становится кандидатом на завершение.Если контейнер продолжает использовать память за пределами своего предела, контейнер завершается.Если завершенный контейнер может быть перезапущен, kubelet перезапускает его, как и при любом другом типе сбоя во время выполнения.

Надеюсь, это поможет.

0 голосов
/ 28 июня 2019

По умолчанию kubernetes будет использовать cgroups для управления и контроля «выделяемой» памяти для модулей на узле, но также возможно полностью полагаться на статические резервирования и pod запросы .Таким образом, это зависит от вашего кластерного развертывания.

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

Лучше всего установить разумную память запросов и ограничения для всехрабочие нагрузки, чтобы помочь планировщику как можно больше.Если депонирование kubernetes не настраивает мониторинг памяти cgroup, это является обязательным требованием для всех рабочих нагрузок.Если при развертывании используется мониторинг памяти cgroup, запросы дают планировщику дополнительную информацию о том, будут ли запланированные модули размещаться на узле.

Емкость и выделяемые ресурсы

Резервные вычислительные ресурсы Kubernetes docco дают хороший обзор того, как просматривается память на узле.

      Node Capacity
---------------------------
|     kube-reserved       |
|-------------------------|
|     system-reserved     |
|-------------------------|
|    eviction-threshold   |
|-------------------------|
|                         |
|      allocatable        |
|   (available for pods)  |
|                         |
|                         |
---------------------------

Планировщик по умолчанию проверяет, не находится ли узел под давлением памяти, затем просматривает выделяемую память, доступную на узле, и определяет, поместятся ли в нее новые модули запросов .

Доступная выделяемая память - это total-available-memory - kube-reserved - system-reserved - eviction-threshold - scheduled-pods.

Запланированные блоки

Значение для scheduled-pods можно вычислить с помощью динамической группы,или статически с помощью pods запросов ресурсов .

Опция kubelet --cgroups-per-qos, которая по умолчанию установлена ​​на true, включает отслеживание cgroup запланированных модулей.Запущенные pubs kubernetes будут в

Если --cgroups-per-qos=false, то выделяемая память будет уменьшена только на запросов ресурсов , запланированных на узле.

Порог выселения

eviction-threshold - это уровень свободной памяти, когда Kubernetes начинает выселять капсулы.По умолчанию это 100 МБ, но его можно установить через командную строку kubelet.Этот параметр относится как к выделенному значению для узла, так и к состоянию нагрузки на память узла в следующем разделе.

Зарезервировано системой

kubelets system-reservedзначение может быть настроено как статическое значение (--system-reserved=) или отслеживаться динамически через cgroup (--system-reserved-cgroup=).Это для любых системных демонов, работающих за пределами kubernetes (sshd, systemd и т. Д.).Если вы настраиваете cgroup, все процессы должны быть помещены в эту cgroup.

Kube Reserved

kubelets kube-reserved значение может быть сконфигурировано как статическое значение (через --kube-reserved=) или динамически отслеживаться через cgroup (--kube-reserved-cgroup=).Это для любых сервисов kubernetes, работающих вне kubernetes, обычно kubelet и среды выполнения контейнера.

Емкость и доступность на узле

Емкость хранится в объекте Node.

$ kubectl get node node01 -o json | jq '.status.capacity'
{
  "cpu": "2",
  "ephemeral-storage": "61252420Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "4042284Ki",
  "pods": "110"
}

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

$ kubectl get node node01 -o json | jq '.status.allocatable'
{
  "cpu": "2",
  "ephemeral-storage": "56450230179",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "3939884Ki",
  "pods": "110"
}

Использование памяти и давление

Узел-куб также может иметь событие "давление памяти".Эта проверка выполняется вне вышеприведенных проверок ресурсов allocatable и больше относится к системному уровню.Давление памяти смотрит на текущее использование памяти корневыми группами минус неактивный файловый кеш / буферы, аналогично вычислению free для удаления файлового кэша

Узел, находящийся под давлением памяти, не будет иметь запланированных модулей и будет активно пытаться удалять существующие модули до тех пор, пока состояние нагрузки памяти не будет разрешено.

Вы можете установить пороговое значение для вытеснения памяти, которую кубелет будет поддерживать доступной, с помощью флага --eviction-hard=[memory.available<500Mi].Запросы и использование памяти для модулей могут помочь в процессе выселения.

kubectl top node предоставит вам статистику существующей памяти для каждого узла (если у вас запущена служба метрик).

$ kubectl top node
NAME                 CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
node01               141m         7%     865Mi           22%       

Если вы не использовали cgroups-per-qos и несколько модулей без ограничений ресурсов или количество системных демонов, то у кластера, вероятно, возникнут некоторые проблемы с планированием в системе с ограниченным объемом памяти, так как allocatable будетбыть высоким, но фактическое значение может быть очень низким.

Расчет давления памяти

Kubernetes Вне обработки ресурсов docco включает в себя скрипт , который эмулирует процесс мониторинга памяти kubelets:

# This script reproduces what the kubelet does
# to calculate memory.available relative to root cgroup.

# current memory usage
memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}')
memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024))
memory_usage_in_bytes=$(cat /sys/fs/cgroup/memory/memory.usage_in_bytes)
memory_total_inactive_file=$(cat /sys/fs/cgroup/memory/memory.stat | grep total_inactive_file | awk '{print $2}')

memory_working_set=${memory_usage_in_bytes}
if [ "$memory_working_set" -lt "$memory_total_inactive_file" ];
then
    memory_working_set=0
else
    memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file))
fi

memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set))
memory_available_in_kb=$((memory_available_in_bytes / 1024))
memory_available_in_mb=$((memory_available_in_kb / 1024))

echo "memory.capacity_in_bytes $memory_capacity_in_bytes"
echo "memory.usage_in_bytes $memory_usage_in_bytes"
echo "memory.total_inactive_file $memory_total_inactive_file"
echo "memory.working_set $memory_working_set"
echo "memory.available_in_bytes $memory_available_in_bytes"
echo "memory.available_in_kb $memory_available_in_kb"
echo "memory.available_in_mb $memory_available_in_mb"
0 голосов
/ 07 июня 2019

Да, Kubernetes будет учитывать текущее использование памяти при планировании модулей (не просто requests), поэтому ваш новый модуль не будет запланирован на полном узле. Конечно, есть и ряд других факторов .

(FWIW, когда дело доходит до resources, request помогает планировщику путем объявления базового значения, а limit убивает модуль, когда ресурсы превышают это значение, что помогает при планировании / оценке емкости.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...