Лучший способ межкластерной связи между микросервисами в Kubernetes? - PullRequest
0 голосов
/ 09 апреля 2020

Я новичок в микросервисах и хочу понять, как лучше всего реализовать описанное ниже поведение в микросервисах, развернутых в Kubernetes:

Существует 2 разных кластера K8s. Микросервис B развернут в обоих кластерах.

Теперь, если микросервис A вызывает микросервис B, а модули B недоступны в кластере 1, то вызов должен go к B кластера 2.

Я мог бы представить, как реализовать эту функцию с помощью Netflix OSS, но здесь я ее не использую.

Кроме того, на секунду оставив в стороне межкластерную связь, как я должен общаться между микросервисами?

Один из известных мне способов заключается в создании службы Kubernetes типа NodePort для каждого микросервиса и использовании IP-адреса и nodePort в вызывающем микросервисе.

Вопрос: Что если кто-то удалит службу K8s целевого микросервиса ? Новый nodePort будет случайным образом назначаться K8s при воссоздании службы K8s, а затем мне снова придется go вернуться к моему вызывающему микросервису и изменить nodePort целевого микросервиса. Как я могу отделиться от nodePort?

Я исследовал kubedns, но похоже, что он работает только внутри кластера.

У меня очень ограниченные знания об Istio и Kubernetes Ingress. Предоставляет ли что-нибудь из этого то, что я ищу?

Извините за длинный вопрос. Любое руководство будет очень полезным.

Ответы [ 3 ]

2 голосов
/ 09 апреля 2020

Вы можете выставить свое приложение, используя службы, есть некоторые виды услуг, которые вы можете использовать:

  • ClusterIP: Предоставляет Службу по внутреннему IP-адресу кластера. Выбор этого значения делает Сервис доступным только из кластера. Это значение по умолчанию ServiceType.

  • NodePort. Предоставляет Сервис для каждого IP-адреса узла в порту c (NodePort). , Служба ClusterIP, к которой NodePort Служба направляет, создается автоматически. Вы сможете связаться со службой NodePort из-за пределов кластера, запросив <NodeIP>:<NodePort>.

  • LoadBalancer: извлекает службу извне используя балансировщик нагрузки облачного провайдера. NodePort и ClusterIP Службы, для которых автоматически создаются внешние маршруты балансировки нагрузки.

  • ExternalName: сопоставляет службу с содержимым externalName поле (например, foo.bar.example.com), возвращая CNAME запись

Для внутренней связи вы используете тип услуги ClusterIP, и вы можете настроить служба днс для ваших приложений вместо IP. То есть: служба с именем my-app-1 может быть достигнута внутри организации с использованием dns http://my-app-1 или с помощью fqdn http://my-app-1.<namespace>.svc.cluster.local.

. Для внешней связи можно использовать NodePort или * 1053. *.

NodePort хорошо, когда у вас мало узлов и вы знаете ip всех из них. И да, с помощью сервисной документации вы можете указать указанный c номер порта:

Если вы хотите указать c номер порта, вы можете указать значение в поле nodePort. Плоскость управления либо выделит вам этот порт, либо сообщит о сбое транзакции API. Это означает, что вам нужно позаботиться о возможных конфликтах портов самостоятельно. Вы также должны использовать действительный номер порта, который находится внутри диапазона, настроенного для использования NodePort.

LoadBalancer дает вам больше гибкости, потому что вам не нужно знать все ips узла, вы Просто необходимо знать IP-адрес службы и порт. Но LoadBalancer поддерживается только в облачных провайдерах, если вы хотите внедрить их в кластер с голым металлом, я рекомендую вам взглянуть на MetalLB .

Finnaly, есть еще один вариант, который используйте ingress, на мой взгляд, это лучший способ выставлять HTTP-приложения извне, потому что вы можете создавать правила по пути и хосту, и это дает вам гораздо большую гибкость, чем услуги. Но поддерживается только HTTP / HTTPS, если вам нужен TCP, то go to Services

Я бы порекомендовал вам взглянуть по этим ссылкам, чтобы глубже понять, как работает сервис и вход :

Услуги Kubernetes

Вход Kubernetes

NGINX Вход

1 голос
/ 09 апреля 2020

Использовать вход для межкластерной связи и использовать кластерную службу типа ip для внутрикластерной связи между двумя микросервисами.

0 голосов
/ 15 апреля 2020

Ваш дизайн очень близок к примеру Istio Multicluster .

Выполнив шаги в мультикластерной лаборатории Istio , вы получите два кластера с одной плоскостью управления Istio, которые балансируют трафик c между двумя ClusterIP Services, расположенными в двух независимых кластерах Kubernetes.

Лабораторная конфигурация следит за загрузкой traffi c, но, переписав код Controller Pod, вы можете настроить его для переключения traffi c на Второй кластер, если служба первого кластера имеет нет конечных точек (все модули определенного типа не находятся в состоянии готовности).

Это всего лишь пример, вы можете изменить istiowatcher.go код для реализации любой логики c, которую вы хотите.


Существует более продвинутое решение с использованием Admiral в качестве средства автоматизации управления Istio Multicluster.

Admiral обеспечивает автоматизацию c конфигурация для Istio me sh, охватывающая несколько кластеров для работы в качестве одного me sh на основе уникального идентификатора службы, который связывает рабочие нагрузки, выполняющиеся в нескольких кластерах, со службой. Он также обеспечивает автоматическую c настройку и синхронизацию конфигурации Istio между кластерами. Это устраняет нагрузку на разработчиков и меня sh операторов, что помогает масштабировать их за пределы нескольких кластеров.

Это решение решает следующие ключевые требования для современной инфраструктуры Kubernetes:

  • Создание записей DNS службы, отделенных от пространства имен, как описано в разделе Особенности развертываний multi-me sh.
  • Обнаружение служб во многих кластерах.
  • Поддержка активно-активных развертываний и HA / DR , Мы также должны были поддерживать эти важнейшие шаблоны устойчивости, поскольку службы развертываются в глобально уникальных пространствах имен в отдельных кластерах.

Это решение может стать очень полезным в полном масштабе.

...