Comments 7
Внимательный читатель сразу заметить странность в том что как это так получается что в одном случае нам рекомендуют, что в кластере с максимальным количеством узлов 5000, у нас может быть не более 150 000 подов, то есть в среднем 300 подов на узел (150 000 / 5000), но в первой рекомендации нам говорят что не более 110 подов на узел?
ну только не 300, а 30.
А так, интересное исследование
Вах, респект, ну наконец-то кто-то решился испачкать руки, а не верить на слово лекторам, читающим с бумажки
А без мостов значит сеть в подах не поднять?
А разве что то такое же как bridge в ядро завезли?
cilium cni решает все эти проблемы.
Но делать больше чем 110 все еще не нужно. Тут вступают в силу другие ограничения, например то, что context switch будет сжирать больше чем приложение работает.
Под это не 1 процесс, там их много. и когда у вас в системе 100500*100500 процессов - грустно
Спасибо за комментарий!
CNI плагинов много (и они по моему мнению больше про кластеры с больше чем одним worker'ом) и исследование их возможностей, плюсов и минусов это тема для отдельной статьи, которая я надеюсь будет. В данном случае как раз было интересно посмотреть ситуацию без них.
Про переключение контекста и возрастающие "сопутствующие" системные нагрузки при увеличении количества подов - в целом согласен, я тут как раз о возрастающем сетевом оверхеде и пытался разобраться и рассказать (остальные оверхеды решил оставить за рамками, что бы статья не разрасталась). Но эти оверхеды появляются при любом увеличении подов или процессов. Идея в том что если вдруг нужно запустить больше 110 подов, например 111 - то это можно сделать и ни чего плохого не будет. А вот если хочется запустить 1000 тут нужно все оценить и протестировать на реальных приложениях, нагрузках и кейсах.
K8s best practices или что будет если их не соблюдать?