Поделиться через

Использование службы Управления API Azure с микрослужбами, развернутыми в службе Kubernetes Azure

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни Управление API

Микрослужбы идеально подходят для создания интерфейсов программирования приложений. С помощью службы Azure Kubernetes Service (AKS) можно быстро развернуть и использовать архитектуру на основе микрослужб в облаке. Затем можно использовать службу управления API Azure (управления API) для публикации микрослужб как API для внутреннего и внешнего потребления. В этой статье описываются варианты развертывания управления API с помощью AKS. В ней предполагается наличие базовых знаний о Kubernetes, управлении API и сети Azure.

Общие сведения

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

Шаблон шлюза API предназначен для решения этих задач. Шлюз API выступает в качестве точки входа микрослужб, отделяет клиентов от микрослужб, добавляет дополнительный уровень безопасности и уменьшает сложность микрослужб за счет устранения проблем, связанных с обработкой перекрестных задач.

Управление API Azure — это готовое решение для решения ваших потребностей для шлюза API. Вы можете быстро создать единообразный и современный шлюз для микрослужб и опубликовать их в качестве интерфейса API. Будучи решением для управления API в полном жизненном цикле, оно также предоставляет дополнительные возможности, включая портал самообслуживания для разработчика для обнаружения API, управления жизненным циклом API и аналитики API.

При совместном использовании AKS и служба управления API предоставляют платформу для развертывания, публикации, защиты, мониторинга и управления интерфейсами API на основе микрослужб. В этой статье мы рассмотрим несколько вариантов развертывания AKS в сочетании с Управление API.

Службы Kubernetes и API

В кластере Kubernetes контейнеры развертываются в объекты pod, которые являются временными и имеют жизненный цикл. Когда рабочий узел выходит из строя, все объекты pod, работающие на узле, теряются. Таким образом, IP-адрес объекта pod может измениться в любое время. Мы не можем полагаться на него, чтобы взаимодействовать с модулем pod.

Чтобы решить эту проблему, Kubernetes представил концепцию служб. Служба Kubernetes — это уровень абстракции, который определяет группу логических модулей pod и обеспечивает для них возможность внешнего трафика, балансировку нагрузки и обнаружение служб.

Когда мы готовы опубликовать микрослужбы в качестве API-интерфейсов с помощью службы управления API, необходимо подумать о том, как сопоставлять наши службы в Kubernetes с API-интерфейсами в службе управления API. Не существует каких-либо установленных правил. Все зависит от конкретного изначального дизайна и способа разбиения ваших бизнес-возможностей или доменов на микрослужбы. Например, если модули pod, которые находятся за службой, отвечают за все операции с заданным ресурсом (например, customer), служба может быть сопоставлена с одним API. Если операции с ресурсом секционируются на несколько микрослужб (например, GetOrder, PlaceOrder), то несколько служб могут быть логически агрегированы в один API в управлении API (см. рис. 1).

Сопоставления также могут развиваться. Так как Управление API создает фасад перед микрослужбами, он позволяет нам рефакторинг и правильный размер наших микрослужб с течением времени.

Сопоставление служб и API

Развертывание службы управления API на фронте AKS

Существует несколько вариантов развертывания службы управления API на фронте кластера AKS.

Хотя кластер AKS всегда развертывается в виртуальной сети, Управление API экземпляр не требуется развертывать в виртуальной сети. Если Управление API не находится в виртуальной сети кластера, кластер AKS должен публиковать общедоступные конечные точки для Управление API подключения. В этом случае необходимо защитить подключение между Управление API и AKS. Другими словами, необходимо обеспечить доступ к кластеру только через службу управления API. Давайте перейдем к вариантам.

Вариант 1: сделать службы общедоступными

Службы в кластере AKS можно предоставлять в общий доступ, используя типы служб NodePort, LoadBalancer и ExternalName. В данном случае доступ к службам можно получить напрямую из Интернета. После развертывания службы управления API на фронте кластера необходимо убедиться, что весь входящий трафик проходит через службу управления API, применяя проверку подлинности в микрослужбах. Например, служба управления API может включать маркер доступа в каждый запрос к кластеру. Каждая микрослужба отвечает за проверку маркера перед обработкой запроса.

Это может быть самым простым способом развертывания службы управления API на фронте AKS, особенно если логика аутентификации уже реализована в микрослужбах.

Непосредственная публикация служб

Преимущества.

  • Простая настройка на стороне Управление API, так как она не требуется внедрять в виртуальную сеть кластера
  • Отсутствие изменений на стороне AKS, если службы уже в общем доступе части, а логика проверки подлинности уже существует в микрослужбах

Недостатки.

  • Потенциальная угроза безопасности из-за общедоступных конечных точек
  • Нет точки с одним входом для входящего трафика кластера
  • Усложняет микрослужбы из-за дублирующейся логики проверки подлинности

Вариант 2: установка контроллера объекта ingress

Хотя вариант 1 может быть проще, он имеет значительные недостатки, как упоминалось выше. Если экземпляр Управление API не находится в виртуальной сети кластера, взаимная проверка подлинности TLS (mTLS) — это надежный способ обеспечения безопасности и доверия трафика в обоих направлениях между экземпляром Управление API и кластером AKS.

Взаимная проверка подлинности TLS поддерживается нативно службой управления API и может быть включена в Kubernetes путем установки контроллера объекта ingress (рис. 3). В результате проверка подлинности будет выполняться в контроллере объекта ingress, что упрощает микрослужбы. Кроме того, можно добавить IP-адреса службы управления API в список разрешенных данных объекта ingress, чтобы обеспечить доступ к кластеру только для службы управления API. Если используется Управление API уровень "Премиум" или "Стандартный" уровня "Стандартный", изоляция на уровне сети может быть достигнута.

Публикация через контроллер объекта ingress

Преимущества.

  • Простая конфигурация на стороне Управление API, так как она не требуется внедрять в виртуальную сеть кластера и mTLS изначально поддерживается.
  • Централизует защиту входящего трафика кластера на уровне контроллера объекта ingress
  • Уменьшение угроз безопасности за счет минимизации общедоступных конечных точек кластера

Недостатки.

  • Повышает сложность конфигурации кластера из-за дополнительной работы по установке, настройке и обслуживанию контроллера объекта ingress и управлению сертификатами, используемыми для mTLS
  • Риск безопасности из-за общедоступной видимости конечных точек контроллера входящего трафика, если не используется Управление API уровень "Стандартный" версии 2 или "Премиум".

При публикации API в Управлении API использование ключей подписки является самым простым способом защитить доступ к этим интерфейсам API. Разработчики, которым требуется использовать опубликованные API, должны включать действительный ключ подписки в HTTP-запросах при выполнении вызовов к этим API. Иначе все вызовы немедленно игнорируются шлюзом Управления API. Они не передаются в серверные службы.

Чтобы получить ключ подписки для доступа к API, нужна подписка. Подписка по сути является именованным контейнером для пары ключей подписки. Разработчики, которым требуется доступ к опубликованным API, могут получить подписки. Им не требуется согласие издателей API. Издатели API могут самостоятельно создавать подписки напрямую для пользователей API.

Вариант 3: развертывание управления API в виртуальной сети кластера

В некоторых случаях клиенты с ограничениями на соблюдение нормативных требований или строгими требованиями к безопасности могут найти вариант 1 и 2 неприемлемыми решениями из-за наличия общедоступных конечных точек. В других службах кластер AKS и приложения, использующие микрослужбы, могут находиться в одной виртуальной сети, поэтому нет причин для общедоступного предоставления кластера, так как весь трафик API останется в виртуальной сети. Для таких сценариев можно развернуть службу управления API в виртуальной сети кластера. Уровни Developer и Premium для службы управления API поддерживают развертывание в виртуальной сети.

Существует два режима развертывания службы управления API в виртуальной сети (внешний и внутренний).

Если потребители API не находятся в виртуальной сети кластера, следует использовать внешний режим (рис. 4). В этом режиме шлюз службы управления API внедряется в виртуальную сеть кластера, но становится доступным из Интернета через внешний балансировщик нагрузки. Это позволяет полностью скрыть кластер, в то же время позволяя внешним клиентам использовать микрослужбы. Кроме того, можно использовать сетевые возможности Azure, такие как группы безопасности сети (NSG), чтобы ограничить сетевой трафик.

Внешний режим для виртуальной сети

Если все потребители API находятся в виртуальной сети кластера, можно использовать внутренний режим (рис. 5). В этом режиме шлюз службы управления API внедряется в виртуальную сеть кластера и доступен только в пределах этой виртуальной сети с помощью внутреннего балансировщика нагрузки. Нет способа связаться с шлюзом Управление API или кластером AKS из общедоступного Интернета.

Внутренний режим для виртуальной сети

В обоих случаях кластер AKS не отображается публично. По сравнению с вариантом 2, контроллер объекта ingress может не потребоваться. В зависимости от сценария и конфигурации проверка подлинности между службой управления API и микрослужбами все равно может оказаться необходимой. Например, при внедрении сетки служб всегда требуется взаимная проверка подлинности по протоколу TLS.

Преимущества.

  • Наиболее безопасный вариант, так как у кластера AKS нет общедоступной конечной точки
  • Упрощает настройку кластера, так как в нем нет общедоступной конечной точки
  • У внутреннего режима есть возможность инкапсулировать службу управления API и AKS в виртуальной сети
  • Возможность управления сетевым трафиком с помощью сетевых возможностей Azure, таких как группы безопасности сети (NSG)

Недостатки.

  • Повышает сложность развертывания и настройки службы управления API для работы в виртуальной сети

Следующие шаги