Как настроить динамическую маршрутизацию запросов gRPC с envoy, nomad и консулом
Мы используем Nomad для развертывания наших приложений - которые предоставляют конечные точки gRPC - в качестве задач. Затем задачи регистрируются в Консуле, используя служебную строю кочевника.
Маршрутизация для наших приложений достигается с помощью прокси-сервера. У нас работают центральные инстансы с нагрузкой на IP 10.1.2.2
,
Решение о том, какую конечную точку / задачу направить в настоящее время, основано на host
заголовок и каждая задача регистрируется в качестве службы под <$JOB>.our.cloud
, Это приводит к двум проблемам.
При доступе к услуге DNS-имя должно быть зарегистрировано для IP-адреса loadbalancer, что приводит к
/etc/hosts
записи как10.1.2.2 serviceA.our.cloud serviceB.our.cloud serviceC.our.cloud
Эта проблема частично смягчается с помощью
dnsmasq
, но это все же немного раздражает, когда мы добавляем новые услугиНевозможно одновременно запустить несколько служб, которые предоставляют одну и ту же услугу gRPC. Если, например, мы решили протестировать новую реализацию службы, нам нужно запустить ее в том же
job
под тем же именем и все службы, которые определены в файле службы gRPC, должны быть реализованы.
Возможное решение, которое мы обсуждали, заключается в использовании tags
из service
раздел для добавления тегов, которые определяют предоставляемые услуги gRPC, например:
service {
tags = ["grpc-my.company.firstpackage/ServiceA", "grpc-my.company.secondpackage/ServiceB"]
}
Но это не рекомендуется Консулом:
Dots are not supported because Consul internally uses them to delimit service tags.
Теперь мы думали сделать это с помощью тегов, таких как grpc-my-company-firstpackage__ServiceA
... Это выглядит действительно отвратительно, хотя:-(
) Итак, мой вопрос:
- Кто-нибудь когда-нибудь делал что-то подобное?
- Если да, то каковы рекомендации о том, как направить сервисы gRPC, которые автоматически обнаружены Консулом?
- У кого-нибудь есть другие идеи или идеи по этому поводу?
- Как это достигается, например, в istio?