V
4136562 последний есть
Size: a a a
2021 June 23
V
2083 тасков
V
какого-то ресурса не хватает видимо, но непонятно ошибки только то что не может стартануть под
V
еще на этой ноде maxPods: 180 увеличено вместо стандартных 110 и именно эта нода барахлит
SM
kubelet не течет? https://github.com/kubernetes/kubernetes/pull/100326
V
kubelet всего 200мб потребляет, а вот containerd пишет что 57гигов. наверное со всеми контейнерами, но почему то на других нодах всего 10гигов, подов немного меньше
GG
вариант что он протек
GG
либо это память ВСЕХ контейнеров - и тогда это похоже на правду
SM
над больше вводных, облако? хостовая ос/ версия ядра/ версия кубера/ версия контейнерд
V
железо свое, 3 мастера и 4 ноды виртуалки, а эта проблемная 5ая нода железная, kuber 1.19.8 containerd 1.4.4 рантайм, ubuntu 20.04 ядро 5.4.0-74
V
на другой ноде где по 8 и 10 гигов containerd , это число точно меньше чем сумма памяти контейнеров, почему-то
V
а на этой ноде да, похоже на сумму
V
pid_max
4194304
в ubuntu 20 стал
в 18 был 32768 , поэтому такие огромные
4194304
в ubuntu 20 стал
в 18 был 32768 , поэтому такие огромные
GG
я тебе говорил
V
что говорил, проблема не в этом, просто пидмакс большой
S
Похожая проблема была, и тоже после увеличения maxpods, вообще кол-во подов, когда новые перестают создаваться каждый раз разное и зависит от контейнеров (если например, только nginx пустой стартовать, то никогда проблем нет), мы долго проблему искали, но так и не нашли. Тоже вм, ubuntu 20.04.2, в итоге ноды уменьшили по ресурсам и сделали их больше по количеству
GG
решение, ага
GG
но вероятно какие-то переполнения или race condition под капотом
V
на другом большом кластере кубер 1.17 docker runtime с лимитом 180 хорошо работает, щас по 150+ подов запущено
S
Да, но по логам и ошибками вообще не понять, где проблема.. неделю крутили на тестовом стенде, так и не нашли где упирается