Просто не указывай в качестве externalip айпишник ноды.

А разве kubeadm последних версий по дефолту ipvs не катит?

У меня уже пару раз взбешивались cronjob ночью (насоздавалось пачками в статусе pending) и выбивают ноды. ContainerGCFailed trying to send message larger than max На скорую руку помогает только переустановка докера с нуля (меня путь до /var/lib/docker, чтобы быстрее переставить). Подскажите манее радикальные способы. Похоже какой-то компонент k8s пытается что-то сделать и фейлит из-за размеров пакета к apiserver. Но так догаться не могу.

Ребят, подскажите, а вы у себя ингресс контроллеры в кластере размещаете? Рассматриваю два варианта: 1 - поднять по ингресс контроллеру на каждом мастере, либо поднять отдельные ноды (2,3) для ингресс контроллеров

или может есть другой, более правильный вариант?

Поэтому я и хочу каждому деплойменту отдельный внешний ip давать. Очень хочется сделать без оверлейных сетей. Но я не знаю насколько это плохо.

ContainerGCFailed это в логах кублетов? Выглядит будто не может с докер демоном связаться , мол запрос слишком большой . Или у вас не докер?

Докер. Проблема явно из-за того. что “наспамили” контейнерами

А какое количество контейнеров пыталось запуститься на ноде?

штук 100, точно уже не скажу

Только лимиты и спасли думаю. Просто удалить pending не помогло

вопрос если в 2-х ingress описан один и тот же потдомен что будет происходить если они в одном namespace и если они в разных namespace

я думаю что контроллер применит конфигурацию и не будет парится насчет валидации. там уж как дальше ваш ингресс реализован, nginx дубль заигнорит просто

я если честно порофлил немножко, я конечно читал и смотрел очень много видосов от cncf по сети в k8s, даже проходил курс от linux foundation, но это было полтора года назад, а теперь вещи начали отваливаться и абстракции протекать, а память невечная.. думал что мб просто выключатель гдето не тот поставил, но видимо придется снова все разребать и заново учить

Может с сетью, но на бриджах? Тогда у каждого пода будет свой ИП, но не будет оверхедов от оборачивания пакетов в другие пакеты. У @kvaps так все настроено

вопрос если в 2-х ingress описан один и тот же потдомен что будет происходить если они в одном namespace и если они в разных namespace

А с такой схемой можно в случае падения пода в деплойменте, при стратегии Recreate привязать его ip-адрес к новому поду? (Сохранить исходный ip-адрес)

Падают контейнеры, а не поды. Если рестартуют контейнер, то он сохраняет ИП пода

Ну мне нужно чтобы при падении ноды поды перезапускались на другой машине с теми же ip-адресами, что непонятного-то?

Вы задавали другой вопрос. Я вам ничего не должен.

А с такой схемой можно в случае падения пода в деплойменте, при стратегии Recreate привязать его ip-адрес к новому поду? (Сохранить исходный ip-адрес)

я юзал, его надо уметь готовить

Буфер уходит вместе с удалением /var/lib/docker, но крайне печально так делать. Просто может у кого есть догадки

А на стороне докера есть какие-нибудь сообщения?

ну зависит от того умеешь ты его готовить или нет

т.е. маленькие запросы он принимает (== контейнеры стартуют нормально), а большие на удаление всех контейнеров разом - нет. Ну как теория, по хорошему надо б ошибку в коде кублета поискать

Поэтому я и хочу каждому деплойменту отдельный внешний ip давать. Очень хочется сделать без оверлейных сетей. Но я не знаю насколько это плохо.

Можешь пример кинуть как шарить порт без указания ip?

т.е. маленькие запросы он принимает (== контейнеры стартуют нормально), а большие на удаление всех контейнеров разом - нет. Ну как теория, по хорошему надо б ошибку в коде кублета поискать

getKubeletContainers failed: rpc error: code = ResourceExhausted desc = grpc: trying to send message larger than max (8389176 vs. 8388608) GenericPLEG: Unable to retrieve pods: rpc error: code = ResourceExhausted desc = grpc: tryi ng to send message larger than max (8389176 vs. 8388608) skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 4h56m17.800 У kubelet, пойду гуглить про PLEG Там вагон всякого про send messages larger

getKubeletContainers failed: rpc error: code = ResourceExhausted desc = grpc: trying to send message larger than max (8389176 vs. 8388608) GenericPLEG: Unable to retrieve pods: rpc error: code = ResourceExhausted desc = grpc: tryi ng to send message larger than max (8389176 vs. 8388608) skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 4h56m17.800 У kubelet, пойду гуглить про PLEG Там вагон всякого про send messages larger

у вас поди куча Exited контейнеров

у вас поди куча Exited контейнеров

докер сообщает о них кубелету, отчего он дохнет из-за ограничения на размер кубелета

ну да, cronjob вбесился ночью

а вот эти проблемы все с кучей контейнеров, в случае с containerd не лечатся ли случаем?

в общем посидев, покопавшись еще, попробовал вытащить в мир, в sg порты 30000 - 32767 на мастере, по ним приложухи доступны тупо не работает 80 порт Оо если я на мастере открою 80 порт, то сразу connection refused, а если удалю обратно, то connection timeout..... че за хрень???

NodePort? https://kubernetes.io/docs/concepts/services-networking/service

Скажите кто знает - у пода генерируется имя, а хочется делать вывод лога контейнера скриптом

Да, вроде так взлетело. Спасибо

@Rodgelius все, договорились?