Почему модули не могут планироваться из-за ресурсов, когда на узле достаточно свободного места?
Модули в моем приложении масштабируются с 1 модулем на пользователя (каждый пользователь получает свой собственный модуль). У меня есть ограничения для контейнера приложения, настроенные следующим образом:
resources:
limits:
cpu: 250m
memory: 768Mi
requests:
cpu: 100m
memory: 512Mi
Узлы в моем пуле узлов имеют 8 ГБ памяти каждый. Я запустил несколько пользовательских экземпляров, чтобы начать тестирование, и наблюдал, как мои показатели ресурсов увеличиваются при запуске каждого из них:
ЦП:
Память:
В 15:40 я увидел это в журналах событий. ошибка (примечание: первый узел исключен с помощью заражения):
0/2 nodes are available: 1 Insufficient memory, 1 node(s) didn't match node selector.
Почему это произошло, когда количество запросов к памяти / процессору все еще было значительно ниже общей емкости (~ 50% для процессора, ~ 60% памяти)?
Вот некоторая важная информация из kubectl description node :
Non-terminated Pods: (12 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
ide theia-deployment--ac031811--football-6b6d54ddbb-txsd4 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 13m
ide theia-deployment--ac031811--footballteam-6fb7b68794-cv4c9 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 12m
ide theia-deployment--ac031811--how-to-play-football-669ddf7c8cjrzl 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 14m
ide theia-deployment--ac031811--packkide-7bff98d8b6-5twkf 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 9m54s
ide theia-deployment--ac032611--static-website-8569dd795d-ljsdr 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 16m
ide theia-deployment--aj090111--spiderboy-6867b46c7d-ntnsb 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 2m36s
ide theia-deployment--ar041311--tower-defenders-cf8c5dd58-tl4j9 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 14m
ide theia-deployment--np091707--my-friends-suck-at-coding-fd48ljs7z 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 4m14s
ide theia-deployment--np091707--topgaming-76b98dbd94-fgdz6 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 5m17s
kube-system csi-azurefile-node-nhbpg 30m (1%) 400m (21%) 60Mi (1%) 400Mi (7%) 12d
kube-system kube-proxy-knq65 100m (5%) 0 (0%) 0 (0%) 0 (0%) 12d
lens-metrics node-exporter-57zp4 10m (0%) 200m (10%) 24Mi (0%) 100Mi (1%) 6d20h
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 1130m (59%) 3750m (197%)
memory 4836Mi (90%) 7988Mi (148%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-1Gi 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
attachable-volumes-azure-disk 0 0
Я обнаружил, что при просмотре доступной емкости нужно обращать внимание на Allocatable , а не на Capacity . Служба поддержки Azure:
Пожалуйста, ознакомьтесь с этим документом «Резервирование ресурсов», если мы следуйте примеру в этом документе (используя округленное число до 8 ГБ на узел):
0,75 + (0,25 * 4) + (0,20 * 3) = 0,75 ГБ + 1 ГБ + 0,6 ГБ = 2,35 ГБ / 8 ГБ = 29,37% зарезервированоДля сервера 8 ГБ зарезервированная сумма составляет около 29,37 %, что означает:
Объем памяти, зарезервированной узлом =
29,37% * 8000 = 2349. Распределяемый оставшаяся память =5651Первые 9 модулей будут использовать =9 * 528 = 4752Распределяемая оставшаяся память после первых пакетов =899(выделяемая память, показанная в узле описания kubectl, должна быть номером доступно после резервирования ОС)В последнем числе мы должны учитывать оговорку ОС, что она необходимо запустить, поэтому, вероятно, после того, как ОС заберет зарезервированную память, там недостаточно места для дополнительных модулей на узле, отсюда и сообщения.
Это приведет к ожидаемому поведению с учетом вычислений.
Согласно документации kubernetes :
Планирование модулей с запросами ресурсов
Когда вы создаете модуль, планировщик Kubernetes выбирает узел для Под для бега. Каждый узел имеет максимальную емкость для каждого из типы ресурсов: объем ЦП и памяти, которые он может предоставить для модулей. Планировщик гарантирует, что для каждого типа ресурса сумма запросов ресурсов запланированных Контейнеров меньше, чем мощность узла. Обратите внимание, что хотя фактическая память или ресурсы ЦП использование на узлах очень низкое, планировщик по-прежнему отказывается размещать под на узле, если проверка емкости не удалась. Это защищает от нехватка ресурсов на узле, когда использование ресурсов позже увеличивается, для Например, во время дневного пика частоты запросов.
Дополнительную информацию о том, как используются ограничения для пакетов, можно найти здесь .
Обновление:
Можно оптимизировать потребление ресурсов путем перенастройки ограничение памяти и добавление политики выселения, которая соответствует вашим предпочтениям. Вы можете найти более подробную информацию в документации kubernetes здесь и здесь .
Обновление 2:
Чтобы лучше понять, почему планировщик отказывается размещать Pod на узле, я предлагаю включить журналы ресурсов в вашем кластере AKS. Взгляните на это руководство из документации AKS . В общих журналах найдите журналы kube-scheduler , чтобы увидеть более подробную информацию.