Экспонирование микросервисов, работающих в AWS EKS, с помощью шлюза микросервисов / API, такого как Solo Gloo

Итак, вы решили запустить свою рабочую нагрузку в Kubernetes в AWS. Как мы уже видели, настройка AWS EKS требует большого терпения и головной боли. Вы можете быть в состоянии заставить это работать. Для других вы должны проверить инструмент eksctl от Weaveworks .

Теперь, когда у вас есть кластер Kubernetes, вы хотите начать развертывание на нем своих микросервисов и начать предоставлять и интегрировать API и сервисы для ваших клиентов и других частей вашей организации. На Solo.io мы открыли шлюз для микросервисов, построенный на основе Envoy Proxy с именем Gloo . Gloo является платформой независимого от платформы управления для Envoy, специально созданной для понимания вызовов на «функциональном» уровне (например, сочетания путей / методов / заголовков HTTP, вызовов gRPC или функций Lambda) в целях их составления и создания более богатых API-интерфейсов для обоих северных направлений. юг и восток-запад движение. Gloo также очень хорошо дополняет технологию сервис-сетки, такую ​​как Istio .

Функциональность Gloo включает в себя:

• Маршрутизация функций (методы REST, конечные точки gRPC, лямбда / облачные функции)
• Мелкозернистое переключение трафика (функция канарейка, функция взвешенной маршрутизации и т. Д.)
• Преобразования запроса / содержимого (неявные и явные)
• Авторизация / Аутентификация
• Ограничение скорости
• КПГР
• WebSockets
• SOAP / WSDL
• Коллекция глубоких метрик
• GraphQL Engine для API агрегированных данных
• мощные, независимые от платформы механизмы обнаружения

Gloo имеет очень глубокую нативную поддержку Kubernetes и может быть запущен как вход кластера для вашего кластера Kubernetes. В качестве дополнительного примечания, для некоторых столь необходимых разъяснений по Ingress API Gatweay, API Management (и даже сервисная сетка), посмотрите на сообщение в блоге «Шлюзы API переживают кризис идентичности»

Чтобы помочь людям использовать Gloo в AWS EKS, нам пришлось пройти через довольно сложные варианты выбора и демонстрации сервисов, работающих в Kubernetes. Эти параметры будут такими же для других входных, API-интерфейсов или функциональных шлюзов Kuberentes. Поскольку AWS EKS — это Kubernetes, мы можем предоставить шлюз для микросервисов / API, такой как Gloo, следующими способами:

• входной ресурс Kubernetes
• служба Kubernetes с типом LoadBalancer
• Сервис Kubernetes как NodePort (не рекомендуется для производства)

На Gloo мы также работаем над собственной поддержкой OpenShift, и вскоре она должна появиться.

В то же время, если вы работаете с рабочими нагрузками на AWS EKS, у вас могут возникнуть вопросы о том, как использовать шлюз микросервисов или просто использовать управляемый AWS шлюз AWS API ?

Давайте рассмотрим варианты здесь.

Использование AWS API Gateway с вашим кластером EKS

AWS EKS — это действительно управляемая плоскость управления для Kubernetes, и вы сами управляете своими рабочими узлами. Типичная установка состоит в том, чтобы ваши рабочие узлы (хосты EC2) находились в частном VPC и использовали все встроенные изоляцию VPC, группы безопасности, политики IAM и т. Д. Как только вы начнете развертывать рабочие нагрузки / микросервисы в своем кластере Kubernetes, вы можете пожелать выставлять их и / или предоставлять красиво отделенный API своим клиентам / клиентам / партнерам и т. д. Ваш первый вопрос, вероятно, в духе «хорошо, так как я использую AWS, использовать AWS должно быть очень просто API-шлюз перед моим кластером Kubernetes ».

Когда вы начинаете копать, вы понимаете, что подключить AWS API Gateway к вашему кластеру EKS не так уж и просто. Вы обнаружите, что AWS API Gateway работает в своем собственном VPC и полностью управляется, поэтому вы не можете видеть никаких подробностей о его инфраструктуре. К счастью, с AWS API Gateway вы можете выполнить «Частные интеграции» для подключения к конечным точкам HTTP, работающим в вашем собственном VPC .

Частные интеграции позволяют вам выставить балансировщик сетевой нагрузки (NLB) в вашем частном VPC, который может прервать трафик для интеграции вашего шлюза API в VPC. Таким образом, в основном AWS API Gateway будет создавать VpcLink для NLB, работающего в вашем VPC .

Ну и отлично! Балансировщик сетевой нагрузки является очень мощным балансировщиком нагрузки, но даже если он работает внутри вашего VPC, он не знает и не понимает рабочих нагрузок, работающих в вашем кластере Kubernetes (т. Е. Модулях Kubernetes). Давайте изменим это. На этом этапе нам необходимо развернуть некую конечную точку входа в Kubernetes, которая понимает, как проложить маршрут к стручкам. Некоторые люди могут предпочесть использовать нативный ресурс Kubernetes Ingress на этом этапе, или вы действительно можете просто использовать одну службу Kubernetes, представленную как «LoadBalancer». На самом деле, мы можем сделать еще один шаг вперед. Балансировщик нагрузки по умолчанию, созданный при указании LoadBalancer в сервисе Kubernetes в EKS, является классическим балансировщиком нагрузки . Проблема в том, что API-шлюз не может маршрутизировать к классическому балансировщику нагрузки. Нам нужен сервис Kubernetes, работающий внутри EKS, чтобы создать балансировщик сетевой нагрузки . Например, эта конфигурация создаст классический балансировщик нагрузки:

Добавление аннотации service.beta.kubernetes.io/aws-load-balancer-type: "nlb" приведет к тому, что AWS создаст балансировщик сетевой нагрузки при создании этой службы в EKS:

На данный момент правильно настроена комбинация балансировщика нагрузки (NLB в частном VPC) и шлюза API AWS. Мы даже можем включить брандмауэр веб-приложений AWS (WAF) на шлюзе API AWS. Единственная проблема заключается в том, что у нас есть возможности (и стоимость) AWS API Gateway на грани, но он по-прежнему не понимает рабочих нагрузок, которые мы выполняем в кластере Kubernetes.

Когда мы хотим делать такие вещи, как канареечные выпуски, агрегацию API, маршрутизацию функций и преобразование контента, мы должны делать это в кластере Kubernetes. Гло решает за это. Так вам действительно нужен API Gateway -> NLB -> API Gateway? В этом случае вы можете просто перевести балансировщик сетевой нагрузки в общедоступную подсеть, позволить Gloo обрабатывать всю маршрутизацию API-шлюза, формирование трафика, ограничение скорости и не терять ни одну из функций AWS API Gateway (лямбда-маршрутизация, AuthZ). / N, веб-сокеты и т. Д.).

Альтернативные настройки

Мы начали предыдущий раздел с предположения, что шлюз AWS API будет проще интегрировать с нашим кластером Kubernetes при использовании EKS, чем альтернативное решение. Мы обнаружили, что это не так. Однако у нас есть и другие варианты. Если вы используете EKS, вам понадобится некоторый шлюз API или шлюз микросервисов, который работает в Kubernetes . Но как мы получаем трафик в наш кластер EKS? А что, если мы хотим воспользоваться такими преимуществами, как брандмауэр веб-приложений AWS (WAF)?

Имеющиеся у нас варианты с учетом различных типов балансировщиков нагрузки и компромиссов при работе с шлюзом микросервисов / API в AWS EKS сводятся к следующему:

AWS API Gateway + частный VPC NLB + простой Kubernetes Ingress

Это похоже на предыдущий раздел, но вместо использования мощного шлюза микросервисов, такого как Gloo, вы предпочитаете использовать базовый входной контроллер в Kubernetes. В этом случае вы используете AWS API Gateay, у вас есть такие приятные вещи, как брандмауэр веб-приложений AWS, но вы теряете верность рабочих нагрузок, выполняемых в EKS (модулях).

AWS API Gateway + частный VPC NLB + мощный шлюз Kubernetes microservices, такой как Gloo

Это сценарий из предыдущего раздела. Теперь вы получили доступ к шлюзу микросервисов ближе к рабочим нагрузкам в EKS, но у вас есть избыточный и дорогой шлюз на вашем краю. Преимущество здесь в том, что вы все еще можете воспользоваться брандмауэром веб-приложений AWS (WAF).

Публичный NLB + мощный шлюз Kubernetes microservices, такой как Gloo

В этом случае мы отказались от AWS API Gateway и просто используем балансировщик сетевой нагрузки, находящийся в общедоступной подсети. Все возможности шлюза microservices / API теперь близки к вашим рабочим нагрузкам в EKS, но вы теряете брандмауэр веб-приложения (его нельзя применить к NLB). Если у вас есть свой собственный WAF, это может быть не плохой компромисс.

Публичный ALB + частный NLB + мощный шлюз Kubernetes microservices, такой как Gloo

Вы можете более точно контролировать общедоступные сетевые запросы с помощью Application Load Balancer (который вы можете применять AWS WAF) и при этом сохранять свой трафик EKS частным и контролировать его через частный NLB. При таком подходе вы также можете централизованно управлять всеми своими сертификатами для TLS через CloudFormation

Публичный ALB управляется как входной контроллер Kubernetes + шлюз API Kubernetes, частный для кластера Kuberentes

Вы можете использовать сторонний плагин Kubernetes Ingress with Application Load Balancer для управления ALB в Kubernetes. На этом этапе вы можете запускать свой API Gateweay локально и в частном порядке в своем кластере EKS и при этом использовать WAF, поскольку мы используем ALB. Недостатком является то, что эта функциональность обеспечивается сторонним плагином, и вы не можете централизованно управлять своими сертификатами с образованием облаков. То есть вы должны использовать аннотации Ingress для управления ими .

Вывод

Существует несколько вариантов запуска ваших микросервисных / API-шлюзов в AWS EKS. Каждая комбинация идет с компромиссами и должна быть тщательно продумана. Мы специально создали Gloo, чтобы стать мощным кроссплатформенным межсетевым API-интерфейсом для микросервисов. Это означает, что у вас есть еще больше возможностей при работе в AWS, локально или любом другом облаке. У каждой организации будут свои уникальные ограничения, мнения и варианты. Мы считаем, что есть хорошие варианты для успешного внедрения монолитного микропроцессора или локального гибридного развертывания в публичное облако. Если у вас есть альтернативное предложение для этого варианта использования, пожалуйста , свяжитесь со мной @christianposta в твиттере или в комментариях к этому блогу.