Комментарии 5
Спасибо за статью!
В одном кластере, где был запущен Istio и количество пакетов и одновременных TCP-соединений зашкаливало, мы столкнулись с сильно завышенным потреблением CPU cilium-agent’ом. (Хотя документация обещает накладные расходы в объеме не более 1–15%.)
Я тоже с этим сталкивался. Но это еще было в версии 1.8, надеялся что исправили уже. Но я также заметил нюанс: что прям много CPU потребляется именно в туннельном режиме с включенным hubble. Если использовать native routing, то потребление CPU агентами падает (также с включенным hubble). Вы аналогичное наблюдали?
Благодарю.
Ситуация была с native routing'ом. Хотел бы дать больше информации, но, к сожалению, не углублялись ещё в это.
Примечательно (а может и очевидно), что агенты потребляют еще больше CPU, в случае если открыть в браузере страницу с визуализацией hubble.
Провели тест на кластере из двух воркер нод 4/8, находящихся физически на двух разных гипервизорах, запуская iperf между подами двух нод. Ключи iperf - bidirectional dualtest в 100 потоков, полоса ограничена физической картой хост машины в 1 Гбит.
Порядок значений потребления cpu агентами с хабблом
Hubble отключен в агентах - 0.5 ядра
Hubble включён в агентах - 4-5 ядер
Hubble включён и в браузере открыт дашборд с неймспейсом iperf, где 2 пода передают друг другу данные (выглядит как квадрат и одна стрелочка) - 7-8 ядер
Почему именно cilium а не к calico к примеру?
Отвечали в статье с анонсом поддержки.
Тернистый путь к eBPF, или Как мы Cilium в Deckhouse внедряли