Разработка в Kubernetes - подмена контейнеров для отдельных Dev/QA
1,00
р.
Мы используем Kubernetes для развертывания тестовых окружений. Само окружение - это примерно 40-50 микросервисов + nginx для роутинга входящего траффика. Вызовы к микросервисам есть как внешние (через nginx), так и внутренние (обычный http).
Сейчас каждое тестовое окружение - отдельный namespace, в который задеплоен полный набор микросервисов. Это требует достаточно много памяти, и требует периодического редеплоя каждого тестового окружения (все автоматизировано, но тем не менее). Кроме того, есть накладывает жесткое ограничение на общее количество микросервисов из-за проблем с DSR на windows-нодах - около 300 сервисов в кластере для них предел, это 8 тестовых окружений.
При этом основной кейс тестирования у QA - это master всех микросервисов + 1 измененный.
Вопрос: есть ли более-менее стандартный способ организовать деплоймент так, чтобы экземпляры всех микросервисов, кроме тестируемого, были общими для всех QA окружений.
Конкретные проблемы:
вызовы к микросервиса должны уходить в на переопределенный в данном тестовом окружении, если он есть. В противном случае - уходить в общий. роутинг вызовов должен работать даже для непрямых вызовов - т.е. срабатывать посреди цепочки микросервисов, а не только для первого запроса через nginx (иначе все решалось бы через ingress)
Похожую проблему решал Azure DevSpaces, но его по неопределенным причинам решили закрыть.
Вот примерная схема того, что хотелось бы получить (и что позволял делать Azure DevSpaces):
Приложение уже multi-tenant, и умеет изолировать данные для jonh.s.dev.myapp / dev.myapp по входящему URL.
Проблемные места:
как изолировать два разных деплоймента / сервиса Reservations (по namespace, как это делали DevSpaces)? как перенаправить вызов Bikes -> Reservations без дописывания DNS проверок вида reservations.john.svc.cluster.local ?? reservations.dev.svc.cluster.local в каждый микросервис. Прокидывать информацию вида "top-level вызов был для jonh.s.dev.myapp" приложение уже умеет.
Если коротко: есть ли готовые альтернативы закрытому Azure DevSpaces? Общие для k8s или специфические для Azure - не принципиально.
Ответ
Если можно изменить сервисы, чтоб имя тенанта передавалось как поддомен, т.е. tenantX.serviceY, то можно легко реализовать все в DNS.
Нужно переключиться на использование CoreDNS. Там включить плагин для, собственно, kubernetes и rewrite. Rewrite позволяет изменить входящий DNS запрос по правилам. Добавляем его первым, чтоб он работал до kubernetes.
Дальше добавляем статические правила типа *.serviceY -> serviceY.master.cluster.local в самом конце. А при деплое вначале добавляем правила типа tenantX.serviceY -> serviceY.tenantX.cluster.local, если serviceY заменен в окружении tenantX.
Сейчас каждое тестовое окружение - отдельный namespace, в который задеплоен полный набор микросервисов. Это требует достаточно много памяти, и требует периодического редеплоя каждого тестового окружения (все автоматизировано, но тем не менее). Кроме того, есть накладывает жесткое ограничение на общее количество микросервисов из-за проблем с DSR на windows-нодах - около 300 сервисов в кластере для них предел, это 8 тестовых окружений.
При этом основной кейс тестирования у QA - это master всех микросервисов + 1 измененный.
Вопрос: есть ли более-менее стандартный способ организовать деплоймент так, чтобы экземпляры всех микросервисов, кроме тестируемого, были общими для всех QA окружений.
Конкретные проблемы:
вызовы к микросервиса должны уходить в на переопределенный в данном тестовом окружении, если он есть. В противном случае - уходить в общий. роутинг вызовов должен работать даже для непрямых вызовов - т.е. срабатывать посреди цепочки микросервисов, а не только для первого запроса через nginx (иначе все решалось бы через ingress)
Похожую проблему решал Azure DevSpaces, но его по неопределенным причинам решили закрыть.
Вот примерная схема того, что хотелось бы получить (и что позволял делать Azure DevSpaces):
Приложение уже multi-tenant, и умеет изолировать данные для jonh.s.dev.myapp / dev.myapp по входящему URL.
Проблемные места:
как изолировать два разных деплоймента / сервиса Reservations (по namespace, как это делали DevSpaces)? как перенаправить вызов Bikes -> Reservations без дописывания DNS проверок вида reservations.john.svc.cluster.local ?? reservations.dev.svc.cluster.local в каждый микросервис. Прокидывать информацию вида "top-level вызов был для jonh.s.dev.myapp" приложение уже умеет.
Если коротко: есть ли готовые альтернативы закрытому Azure DevSpaces? Общие для k8s или специфические для Azure - не принципиально.
Ответ
Если можно изменить сервисы, чтоб имя тенанта передавалось как поддомен, т.е. tenantX.serviceY, то можно легко реализовать все в DNS.
Нужно переключиться на использование CoreDNS. Там включить плагин для, собственно, kubernetes и rewrite. Rewrite позволяет изменить входящий DNS запрос по правилам. Добавляем его первым, чтоб он работал до kubernetes.
Дальше добавляем статические правила типа *.serviceY -> serviceY.master.cluster.local в самом конце. А при деплое вначале добавляем правила типа tenantX.serviceY -> serviceY.tenantX.cluster.local, если serviceY заменен в окружении tenantX.
