Comments 9
Как они состояние шарят в Kubernetes?
Мучаю докеровский swarm mode, там удобств не предусмотрено на этот счёт.
Хороший перевод, спасибо!
Хотелось бы от себя добавить: возможно после прочтения статьи кто-то захочет выставить значение --iptables-sync-period
как можно меньше, скажем равным 1 сек, чтобы правила почаще обновлялись и не было задержки в случае случайного удаления правил iptables.
Так вот, тут нужно понимать что kube-proxy каждые 30 сек запрашивает у api список сервисов и запускает цикл в котором проверяет соответствие правил желаемому состоянию. И в случае большого количества сервисов этот цикл будет выполняться долго, плюс для каждого сервиса в NAT таблице создается не одно правило а несколько, в зависимости от кол-ва IP адресов у сервиса.
У этого дизайна (все правила на всех нодах) есть и побочная сторона — представьте что у вас кластер из 1000 нод (Kubernetes поддерживает до 5000), и у вас скажем 5000 сервисов, что не так уж много для такого кластера. Тогда во-первых на каждой ноде будут длинные портянки в NAT таблицах, а самое главное что kube-proxy просто сожрет весь CPU ресурс обходя бесконечно все сервисы. Вот здесь есть очень показательные графики поведения iptables и ipvs при возрастании количества сервисов.
habr.com/company/flant/blog/359120
но зачем в хаб «Системное администрирование» пихать статью про управление контейнерами?!
В
- habr.com/hub/cloud_computing Облачные вычисления
- habr.com/hub/virtualization Виртуализация
— не пустили что ли?!
Эксперименты с kube-proxy и недоступностью узла в Kubernetes