Большой профессионал - это прием данных.Если у вас есть кластер ES внутри кластера k8s, загрузка данных будет быстрее.
Однако большая проблема заключается в ресурсах.ES поглотит ваши ресурсы хуже, чем Google-Chrome съест вашего барана.И я имею в виду, много.
И поддерживать его может быть довольно громоздким.Не уверен насчет вашего варианта использования, но если он регистрирует (как в большинстве случаев), обычно облачные провайдеры имеют для этого свое собственное решение.
Если нет, то:
Я бы рекомендовал выделитьузлы для ES в вашем кластере, иначе это может повлиять на другие модули, если есть пики, и начинает использовать много ресурсов узла.
Также обязательно ознакомьтесь и оптимизируйте свои холодные и горячие данные, это сэкономит вам много времени и ресурсов.
РЕДАКТИРОВАТЬ
Я не подчеркивал, насколько важно это более быстрое поглощение данных, поэтому может показаться, что это недостаточно веская причина для его развертывания внутри кластера.Итог довольно очевиден: Сетевая задержка и пропускная способность .
Эти вещи могут действительно сложить (собирая все эти журналы со всех этих модулей, затем масштабируя те же самые модули, затем расширяя кластер, затем снова ...), так что каждый юнитна счет.Если ваши виртуальные машины не пострадают от этих двух (имеется в виду, что они имеют такую же задержку, как и любой другой узел кластера), я думаю, что не будет иметь большого значения .
НаС другой стороны, я не вижу большой выгоды в отделении их от кластера.В любом случае, это часть вашей инфраструктуры.
Что если завтра вы решите перейти на AWS или GKE?Вы должны были бы изменить свои развертывания, настроить все заново.С другой стороны, если это уже часть вашего кластера, просто kubectl apply и ?
Я также могу догадаться, что вы попытаетесь настроить стек ELK.Если время и добрая воля позволяют, дайте шанс fluentd (он на 100% совместим со всеми клиентами logstash, но гораздо более легок).