Недавно я построил несколько микросервисов в кластере k8s с контроллером входящего трафика Nginx, и они работают нормально.
Когда я имел дело с коммуникациями между микросервисами, я попытался использовать gRPC, и это сработало. Затем я обнаружил, что когда микросервис A - ›gRPC -› микросервис B, все запросы были выполнены только в 1 модуле микросервиса B (например, всего 10 модулей доступны для микросервиса B). Чтобы сбалансировать загрузку запросов ко всем модулям микросервиса B, я попытался выполнить компоновку, и это сработало. Однако я понял, что gRPC иногда вызывает внутреннюю ошибку (например, 1 ошибку из 100 запросов), заставляя меня использовать способ DNS k8s (например, my-svc.my-namespace.svc.cluster-domain.example). Тогда запросы никогда не заканчиваются. Я начал задерживать gRPC и linkerd.
Позже меня заинтересовал istio. Я успешно развернул его в кластере. Однако я заметил, что он всегда создает свой собственный балансировщик нагрузки, который не очень соответствует существующему контроллеру входящего трафика Nginx.
Кроме того, я попробовал прометей и графану, а также k9s. Эти инструменты позволили мне лучше понять использование ЦП и памяти модулями.
Здесь у меня есть несколько вопросов, которые я хочу понять: -
- Если мне нужно отслеживать ресурсы кластера, у нас есть прометей, графана и k9s. Выполняют ли они ту же роль мониторинга, что и сервисная сетка (например, linkerd, istio)?
- Если k8s DNS уже может обеспечить балансировку нагрузки, нужна ли нам сервисная сетка?
- если использовать k8s без служебной сетки, отстает ли это от обычной практики?
На самом деле я тоже хочу использовать сервисную сетку каждый день.
