Динамическое связывание поддоменов клиентов Kubernetes - PullRequest
Новая
       15

Динамическое связывание поддоменов клиентов Kubernetes

0 голосов
/ 21 декабря 2018

У меня есть следующий вариант использования:

  1. Наши клиенты часто выпускают новые услуги в своих кластерах K8s.Эти новые службы доступны из внешнего мира с помощью балансировки нагрузки и Ingress для динамической настройки балансировки нагрузки после развертывания службы.Это действительно облегчает работу групп разработчиков наших клиентов, поскольку им не нужно ждать, пока кто-нибудь не настроит балансировку нагрузки вручную.Они могут просто создать свой собственный ресурс Ingress рядом со своим развертыванием службы, и услуга будет доступна.

  2. Заказчик спросил, можем ли мы также включить, чтобы каждая из его служб могла иметь свой собственный поддомен.автоматически.Таким образом, после развертывания нового приложения оно должно быть доступно как поддомен домена кластера (например, https://helloworld.cyvh5.k8s.ginger.aws.gigantic.io), а также на собственном поддомене (например, helloworld.awesome-customer.com).

Я нашел этот ресурс в качестве отправной точки.

Мои вопросы:

  1. Могу ли я достичь динамическое связывание поддомена клиента каким-либо другим (лучшим) способом?

  2. Каковы возможные ограничения / ловушки для предлагаемого решения?

Спасибо!

1 Ответ

0 голосов
/ 21 декабря 2018

Да, для 1 входа звучит замечательно.

Для 2 это звучит для меня так, будто вам нужен только подстановочный DNS, указывающий на входной контроллер.DNS-запись с подстановочными знаками должна указывать, что * .domain.com должен указывать на внешний IP-адрес входного контроллера.Затем могут быть развернуты основанные на хосте правила / ресурсы Ingress, и трафик может быть перенаправлен в соответствующую Службу на основе хоста, указанного в запросе.Таким образом, не имеет значения, что находится в подстановочной части DNS-запроса, поскольку abdomain.com переходит к входному контроллеру, и тогда это будет зависеть от того, какие правила находятся в ресурсах Ingress относительно того, где он заканчивается.,

Это не будет «автоматическим» в том смысле, что клиенту придется развернуть одно или два правила Ingress, если они хотят, чтобы сервис предоставлялся на двух хостах.Но если клиент доволен развертыванием ресурсов Ingress, он должен быть доволен и этим.

Я не думаю, что вам нужно что-то более динамичное, потому что в 'helloworld.awesome-customer.com' кажется, что 'helloworld' - это служба, которая заполняет ваш хост, поэтому в подстановочном знаке нет необходимостиСамо правило входа.Что может быть более динамичным и более похожим на пример, на который вы указываете, если бы они запрашивали v1.helloworld.awesome-customer.com и v2.helloworld.awesome-customer.com и чтобы оба были охвачены однимВходная запись, содержащая подстановочный знак (а не две записи, по одной на версию).Но, похоже, они этого не просят.

Так я вижу часть домена клиента.Я не совсем уверен, что вы имеете в виду под частью домена кластера - для этого мне нужно лучше понять, как к этому обращаться.Предположительно, это снова подстановочный DNS, указывающий на что-то, выполняющее маршрутизацию, но я не настолько уверен в том, что делает маршрутизацию там.Если дело в том, что вы хотите достичь этого, то это может быть просто другая подстановочная DNS-запись, указывающая на тот же входной контроллер с развернутыми дополнительными входными ресурсами.

...