MM
все локально
Size: a a a
2020 March 17
EG
Да, попробуй ограничить на сетевых железках до мастера общение с kubelet-ами (всеми) и мастером
MM
Предположение - кто то дергает API.
netstat -ntpa и попробовать поблочить внешние коннекты к APIда, у нас сверху к api кубов обращаются наши сервисы
MM
но не так часто
MM
по крону раз в 10 минут список деплойментов запрашивает и все
L
но это не нормально. обычно когда API жрет cpu, то и памяти он потребляет гигами. а тут у тебя mem совсем небольшой.
это когда в кластере десятки тысяч объектов наплодилось
это когда в кластере десятки тысяч объектов наплодилось
MM
kubelet_status_update_frequency: 10s
kube_controller_node_monitor_grace_period: 40s
kube_controller_node_monitor_period: 5s
kube_controller_node_monitor_grace_period: 40s
kube_controller_node_monitor_period: 5s
MM
вот такие настройки стоят
MM
мб в них дело?
EG
Угу. Чего от стандартных отошёл?
MM
но это не нормально. обычно когда API жрет cpu, то и памяти он потребляет гигами. а тут у тебя mem совсем небольшой.
это когда в кластере десятки тысяч объектов наплодилось
это когда в кластере десятки тысяч объектов наплодилось
ща гляну другие ресурсы, может там всякие конфигмапы и тд
MM
Угу. Чего от стандартных отошёл?
ну кластер небольшой, а нам хочется чтобы в случае падения ноды она быстро кордонилась
L
Угу. Чего от стандартных отошёл?
дыкэто ж дефолты
EG
kubelet_status_update_frequency дорогая по ресурсам, kubelet свой стэйт сверяет полностью, если память не изменяет
MM
дыкэто ж дефолты
упс, я не в тот конфиг вроде заглянул
EG
дыкэто ж дефолты
Не, 30 секунд дефолт на фул синк
MM
MM
это действительно деф настройки
EG
Не, 30 секунд дефолт на фул синк
Был на ~1.11-1.13 примерно
EG
Дальше уже не слежу