--kube-api-qps/--kube-api-burst у kube-controller-manager однажды могут вас укусить. Вот как это выглядело у нас: тихий инцидент, без отказа сервисов, но поучительно.Симптом: завершённые поды перестали убираться. Число объектов-подов в etcd поползло вверх - с ~30 700 до ~33 500. Ноды здоровы, пользователи ничего не заметили. Ломается не «под не создаётся», а «под не удаляется» - значит смотрим не на scheduler, а на garbage collector внутри kube-controller-manager.
Что случилось: около 19:35 переехал лидер kube-controller-manager. И у нового лидера очередь GC
attempt_to_delete стартовала не с нуля, а сразу с ~72 000 объектов (очередь формируется через 30 секунд после старта Garbage Collector. На самом деле объектов больше, но мначие успевают разобраться за первые 30 секунл и это происходит "незаметно"). Дальше он разгребал её строго линейно - ~20 удалений/с. Почти идеальная прямая на графике.При этом apiserver здоров: p99
DELETE pods 0.1-0.5s, ответов 429 - ноль. Раз API не тормозит и не режет запросы - значит потолок 20/с задаёт сам клиент. А клиент тут - kube-controller-manager с его --kube-api-qps.И вот главное. Дефолт у контроллер-менеджера -
qps=20 / burst=30. Для маленького кластера норм, там очередь GC вечно у нуля и эти 20/с в глаза не бросаются. Но когда объектов десятки тысяч, любое событие, наполнившее очередь (смена лидера, всплеск удалений, рестарт kube-controller-manager), превращает эти 20/с в бутылочное горлышко. Считаем: 72000 / 20 ≈ 58 минут - ровно столько чистка и заняла.У нас на здоровых мастерах qps был поднят до 100, а на одном - не применился конфиг, и он откатился к дефолту. Но суть не в кривом конфиге на одном узле. Суть в том, что на нагруженном кластере сама по себе дефолтная планка слишком низкая - и рано или поздно совпадёт с моментом, когда очередь большая.
Фикс - крутить строго в паре:
-
--concurrent-gc-syncs: 200 - параллелизм самого GC,-
--kube-api-qps: 200 / --kube-api-burst: 300 - чтобы 200 воркеров GC не встали в очередь на клиентском лимите.Поднимешь одно без другого - это педаль газа в пол при зажатом ручнике.
Мораль: если у вас крупный кластер - не оставляйте
--kube-api-qps/--kube-api-burst на дефолтах. Они рассчитаны на маленькие инсталляции и молчат ровно до того дня, когда очередь GC вырастет. Проверьте, с какими лимитами реально запущены ваши controller-manager'ы на КАЖДОМ мастере. Не в шаблоне - в живом процессе.Про то, как работает Garbage Collector в Kubernetes я уже рассказывал вот тут
#Kubernetes #garbage_collector #sre
