Как выбрать API-шлюз в Kubernetes? - PullRequest
0 голосов
/ 07 апреля 2019

Мы некоторое время использовали Zuul в качестве шлюза API на сцене Microservices, недавно мы решили перейти в Kubernetes и выбрать более облачный нативный способ.

После некоторого изучения и изучения документов Istio у нас есть несколько вопросов по выбору шлюза API в Кубернетесе:

  • Какие аспекты следует учитывать при выборе шлюза API в Kubernetes?
  • Нужен ли нам еще Зуул, если мы используем Istio?

1 Ответ

1 голос
/ 10 апреля 2019

Я предполагаю, что Zuul предлагает множество функций в качестве пограничного сервиса для функций управления трафиком, маршрутизации и безопасности. Он должен объявить API-шлюз основной точкой доступа к микросервисам со стороны внешних клиентов в соответствии с шаблоном архитектуры микросервиса Дизайн . Однако Zuul необходимо каким-то образом обнаружить базовые микросервисы, а для Kubernetes вам может понадобиться адаптировать клиент обнаружения Kubernetes, который определяет правила, по которым API-шлюз будет обнаруживать маршруты и передавать сетевой трафик во вложенные сервисы.

В соответствии с проектом Istio представляет сервисную сетку с архитектурой и становится ориентированным на Kubernetes решением с плавной интеграцией. Основной концепцией здесь является использование расширенной версии прокси Envoy путем внедрения колясок в модули Kubernetes без необходимости изменять или переписывать существующее развертывание или использовать любые другие методы для целей обнаружения служб. Zuul API Gateway может быть полностью заменен ресурсом Istio Gateway в качестве балансировщика граничной нагрузки для входящих или исходящих соединений HTTP (S) / TCP. Istio содержит набор функций управления трафиком , которые могут быть включены в общую конфигурацию.

Вас могут заинтересовать другие фундаментальные концепции функциональных возможностей Istio, такие как:

...