GG
траефик например при рпс больше 5к по памяти течет дико
Как именно ?
Size: a a a
2021 January 04
G
у меня нет возможности сделать натив роутинг к сожалению
Проверт с Geneve
DS
Проверт с Geneve
проверю. Но меня пока интересует ingress controller
DZ
Привет, возможно ли в configMap передать ссылку на конфиг lua (prosody.cfg.lua), вместо вставки целого кода из файла?
G
Вообще, если очень часто обновляются эндпоинты, силиум агент намного меньше куб прокси потребляет цпу
DS
cilium c vxlan?
А ты наверное уже это изучал? Почему в случае vxlan он так потребляет? Если поднять vxlan руками в линуксе, и кинуть трафик, ядро же так не будет потреблять CPU. У cilium какой-то особый vxlan?
GG
Видимо, не весь vxlan одинаково полезен
DS
Вообще, если очень часто обновляются эндпоинты, силиум агент намного меньше куб прокси потребляет цпу
да это так, но в данном случае endpoints вообще не менялись никак - все статично. То есть CPU уходило на что-то другое
DS
А ты наверное уже это изучал? Почему в случае vxlan он так потребляет? Если поднять vxlan руками в линуксе, и кинуть трафик, ядро же так не будет потреблять CPU. У cilium какой-то особый vxlan?
по идее это можно проверить 🤔. Какой-нибудь flannel задеплоить для vxlan, а cilium для всего остального
DS
Или скрестить cilium с kube-router 🤔
СГ
а какие конкретно? Я сразу могу сказать какие - растет counter запросов =)
го-шные как минимум, сборку мусора, работа с памятью. Может это не сам nginx тормозит, а вся обёртка контейнеровская. upstream_latency, process_connections (с разными статусами), request_size (может там с апстримами мелкими блоками работает), response_duration (может апстримы "тормозят")
SM
А ты наверное уже это изучал? Почему в случае vxlan он так потребляет? Если поднять vxlan руками в линуксе, и кинуть трафик, ядро же так не будет потреблять CPU. У cilium какой-то особый vxlan?
Я бы отправился в strace
GG
Я бы отправился в strace
В метрики го сервисов
DS
го-шные как минимум, сборку мусора, работа с памятью. Может это не сам nginx тормозит, а вся обёртка контейнеровская. upstream_latency, process_connections (с разными статусами), request_size (может там с апстримами мелкими блоками работает), response_duration (может апстримы "тормозят")
апстримы не тормозят. Трафик проксировался на одни и те же бэкенды в обоих случаях. 95 перцентиль времени ответа от бэкенда 0.005s (nginx_ingress_controller_request_duration_seconds)
nginx_ingress_controller_nginx_process_connections - 30 коннектов с одного хоста, так как тест был в 30 тредов
request_size - маленький, там чутка заголовков и это просто GET запрос на /ready. Бэкенд на этот запрос отвечает двумя байтами ("ok"), то есть и response_size тоже маленький.
upstream_latency - нет смысла смотреть, так как по nginx_ingress_controller_request_duration_seconds видно что бэкенды отвечают быстро
nginx_ingress_controller_nginx_process_connections - 30 коннектов с одного хоста, так как тест был в 30 тредов
request_size - маленький, там чутка заголовков и это просто GET запрос на /ready. Бэкенд на этот запрос отвечает двумя байтами ("ok"), то есть и response_size тоже маленький.
upstream_latency - нет смысла смотреть, так как по nginx_ingress_controller_request_duration_seconds видно что бэкенды отвечают быстро
GG
Они очевидно экспозят всю фигню про гоу раунтайм
GG
Или скрестить cilium с kube-router 🤔
Можно
G
А ты наверное уже это изучал? Почему в случае vxlan он так потребляет? Если поднять vxlan руками в линуксе, и кинуть трафик, ядро же так не будет потреблять CPU. У cilium какой-то особый vxlan?
Силиум агент за маршрутизацию не отвечает, но при vxlan агент инкапусулирует идентити
DS
Я бы отправился в strace
да я чет столько проблем с cilium огребаю, что похоже мне проще остаться на kube-router
k
народ, а кто-нибудь некстклауд в кубе гоняет?