Я пытаюсь отладить проблему, которая решается с помощью hostNetwork: true.Установка k8s использует kubenet, а версия k8s 1.9.8.
Установка выполняется с помощью kops на AWS с использованием экземпляров m4.xlarge и c4.xlarge.
Проблема заключается в том, чтоследующее:
Когда мы перенесли это приложение в kubernetes, время отклика (процентиль 95) для определенной конечной точки увеличилось примерно на 20-30%.
Однако эта проблема решается при использованииhostNetwork: true в ямле.Производительность такая же, как на виртуальных машинах для этой конечной точки, т. Е. Процентиль 95 для времени отклика одинакова для этой конечной точки.
Я спрашивал об этом в рабочие часы офиса в Куберне 18 июля (да, некоторое время назад!) и обходной путь hostNetwork: true.
Пожалуйста, обратите внимание, что все вещи с kube-прокси могут быть отброшены, так как это увеличенное время отклика видно при измерении в самом приложении.Я имею в виду, что приложение ruby измеряет время, которое требуется, и отправляет его сборщику журналов.На этот раз, то есть, поскольку запрос начинает обрабатываться приложением до его завершения, он уже показывает снижение производительности.Таким образом, kube-proxy и все такое выходит за пределы уравнения.
В модуле есть 3 контейнера:
- Nginx
- Сборщик журналов
- Приложение (приложение ruby, работающее с единорогом)
Эти приложения также находятся в режиме виртуальных машин
Что я пробовал:
- Найден способВоспроизвести с помощью ab (тест Apache)
ab -c 1 -n 1000 'https://...- То же самое происходит с http, а не https
- Я попытался удалить контейнер nginx,но это ничего не меняет.Сборщик журналов используется поверх localhost, и то же самое делается на виртуальных машинах, которые не вызывают проблемы
- Я пытался использовать unix-сокеты между nginx и приложением вместо localhost, но это не таклибо измените что-либо.
- Пробовал использовать те же экземпляры (m4.xlarge) с EKS: то же самое происходит.Хотя затраты на производительность без использования
hostNetwork: true меньше, около 10%.Обратите внимание, что EKS не использует kubenet и использует свое собственное сетевое наложение на основе какого-либо открытого источника. - Попытка с использованием другой конечной точки, которая просто возвращает строку (помещает «Ok»), и проблема не возникает
- Попытка с использованием конечной точки, которая возвращает несколько МБ (например,
"Die" * 10 * 1024 * 1024), и проблема также не возникает - Пробовала ту же конечную точку, которая имеет проблему с различными параметрами строки запроса, поэтому ответбольшой (9 МБ) или короткий (130 КБ) и оба надежно воспроизводят проблему
- Пробовал приложение nodejs, которое возвращает похожие jsons из аналогичных источников, и проблема отсутствует (ни с короткими / длинными ответами) Что можетсделайте следующее:
Итак, я пытаюсь отладить эту проблему, чтобы понять, что это такое, и, надеюсь, прекратить использование hostNetwork: true.Кажется, есть путь, чтобы копать дальше:
Попробуйте другие CNI (EKS показал меньшее снижение производительности), чтобы увидеть, изменяется ли производительность
Посмотрите, чтоэта конечная точка делает или как она взаимодействует с единорогом и всем стеком.Одно большое отличие состоит в том, что единорог - это один процесс на запрос (синхронный), а nodejs - нет.
Попробуйте использовать более новые машины (m5 / c5), чтобы увидеть, снижают ли они снижение производительности,Но, поскольку эта проблема не существует с текущими экземплярами, использующими их в качестве виртуальных машин, кажется, что, если это поможет, будет только скрыть проблему
Эта конечная точка, которая имеет проблему перфорации, являетсяконечная точка в ruby, которая читает базу данных и возвращает json.С базой данных, хостом, сетью все выглядит нормально (мониторинг CPU, дисковый ввод-вывод, подкачка и т. Д. С помощью vmstat, наших обычных инструментов, консоли AWS, проверка kern.log, sysloca и тому подобного)
Случайно, у вас был подобный опыт?Или у вас есть другие идеи о том, как продолжить устранение этой проблемы?
Любые идеи или любая помощь более чем приветствуются!
Родриго