Статьи

Spring Cloud Kubernetes для архитектуры гибридных микросервисов

Весна (облако) взошла!

Вы можете использовать Spring Cloud Kubernetes для создания приложений, работающих как внутри, так и вне кластера Kubernetes. Единственная проблема с запуском приложений вне Kubernetes состоит в том, что нет автоматически настроенного механизма регистрации.

Spring Cloud Kubernetes делегирует регистрацию платформе, что является очевидным поведением, если вы развертываете свое приложение изнутри, используя объекты Kubernetes. С внешним приложением ситуация иная. Вы должны гарантировать регистрацию самостоятельно на стороне приложения.

Вам также может понравиться: Краткое руководство по микросервисам с Kubernetes, Spring Boot 2.0 и Docker

Эта статья объясняет мотивацию добавления механизмов автоматической регистрации в проект Spring Cloud Kubernetes только для внешних приложений. Давайте рассмотрим архитектуру, в которой некоторые микросервисы работают вне кластера Kubernetes, а некоторые другие работают внутри него. Там может быть много объяснений такой ситуации. Наиболее очевидным объяснением является миграция ваших микросервисов из более старой инфраструктуры в Kubernetes.

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

Конечно, есть разные подходы к этому вопросу. Например, вы можете поддерживать две независимые архитектуры на основе микросервисов с различными источниками реестра и конфигурацией обнаружения. Но вы также можете подключить внешние микросервисы через API Kubernetes к кластеру для загрузки конфигурации из ConfigMapили Secretи зарегистрировать их там, чтобы обеспечить межсервисную связь с Spring Cloud Kubernetes Ribbon.

Пример исходного кода приложения доступен на GitHub в гибридном филиале в репозитории sample-spring-microservices-Kubernetes : https://github.com/piomin/sample-spring-microservices-kubernetes/tree/hybrid .

Архитектура

Мы перемещаем один из примеров микросервисов сотрудник-сервис , описанный в упомянутой статье, за пределы кластера Kubernetes. Теперь приложения, которые обмениваются данными с сотрудником-службой, должны использовать адреса вне кластера.

Кроме того, они должны иметь возможность обрабатывать номер порта, динамически генерируемый приложением во время запуска ( server.port=0). Наши приложения по-прежнему распределены по разным пространствам имен, поэтому важно включить функции обнаружения в нескольких пространствах имен, также описанные в моей предыдущей статье. Приложение employee-service подключается к MongoDB , которая все еще развернута в Kubernetes. В этом случае интеграция осуществляется через сервис Kubernetes. Следующая картина иллюстрирует нашу текущую архитектуру.

Kubernetes PropertySource

Ситуация с распределенной конфигурацией понятна. Нам не нужно реализовывать дополнительный код, чтобы иметь возможность использовать его извне. Просто, прежде чем запускать клиентское приложение, мы должны установить переменную окружения KUBERNETES_NAMESPACE. Так как мы установили его на внешний, нам сначала нужно создать такое пространство имен.

Затем мы можем применить некоторые источники свойств к этому пространству имен. Конфигурация состоит из Kubernetes ConfigMapи Secret. Мы храним там монго, учетные данные и некоторые другие свойства. Вот наша ConfigMapдекларация.


Джава