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


Повторное создание веб-приложения AWS EKS для службы Azure Kubernetes (AKS)

Теперь, когда у вас есть лучшее представление о различиях платформ между AWS и Azure, давайте рассмотрим архитектуру веб-приложений в AWS и изменения, необходимые для обеспечения его совместимости со службой Azure Kubernetes (AKS).

Архитектура приложения Yelb

Пример веб-приложения Yelb состоит из фронтэнд-компонента, именуемого yelb-ui, и компонента приложения, именуемого yelb-appserver.

Схема архитектуры веб-приложения Yelb.

yelb-ui передает JavaScript-код браузеру. Этот код компилируется из приложения Angular . Компонент yelb-ui также может включать nginx прокси-сервер в зависимости от модели развертывания. Это yelb-appserver приложение Sinatra , взаимодействующее с сервером кэша (redis-server) и серверной базой данных Postgres (yelb-db). Кэш Redis хранит количество просмотров страниц, а PostgreSQL сохраняет голоса. Обе службы развертываются в Kubernetes без использования управляемой службы для хранения данных в AWS или Azure.

Исходное приложение Yelb является автономным и не зависит от внешних служб, поэтому его можно перенести из AWS в Azure без каких-либо изменений кода. В Azure можно использовать кэш Azure для Redis и Базу данных Azure для PostgreSQL в качестве замены для служб Кэша Redis и PostgreSQL, развернутых в AKS.

Пример приложения Yelb позволяет пользователям голосовать по набору альтернативных вариантов (ресторанов) и динамически обновляет круговые диаграммы на основе количества полученных голосов. Приложение также отслеживает число просмотров страниц и отображает имя хоста экземпляра yelb-appserver, который обрабатывает запрос API при голосовании или обновлении страницы. Эта функция позволяет демонстрировать приложение самостоятельно или вместе с другими.

Снимок экрана: интерфейс службы Yelb.

Архитектура в AWS

Чтобы защитить веб-приложения и API от распространенных веб-эксплойтов, AWS предлагает брандмауэр веб-приложений AWS (WAF) и диспетчер брандмауэра AWS.

Сопоставление служб AWS со службами Azure

Чтобы повторно создать рабочую нагрузку AWS в Azure с минимальными изменениями, используйте эквивалент Azure для каждой службы AWS. В следующей таблице приведены сопоставления служб.

Сопоставление служб Служба AWS Служба Azure
Брандмауэр веб-доступа Брандмауэр веб-приложений AWS (WAF) Azure Брандмауэр веб-приложений (WAF)
Балансировка нагрузки приложений Подсистема балансировки нагрузки приложения (ALB) Шлюз приложений AzureШлюз приложений для контейнеров (AGC)
Сеть доставки содержимого Amazon CloudFront Azure Front Door (AFD)
Оркестрация Служба Elastic Kubernetes (EKS) Служба Azure Kubernetes (AKS)
Хранилище секретов Служба управления ключами AWS (KMS) Azure Key Vault
Реестр контейнеров Реестр эластичных контейнеров Amazon (ECR) Реестр контейнеров Azure (ACR)
Система доменных имен (DNS) Amazon Route 53 Azure DNS
Кэширование Amazon ElastiCache Кэш Azure для Redis
NoSQL Amazon DynamoDB База данных Azure для PostgreSQL

Полное сравнение служб Azure и AWS см. в сравнении aws с службами Azure.

Архитектура в Azure

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

Этот пример поддерживает установку управляемого контроллера входящего трафика NGINX с надстройкой маршрутизации приложений или неуправляемым контроллером входящего трафика NGINX с помощью диаграммы Helm. Надстройка маршрутизации приложений с контроллером входящего трафика NGINX предоставляет следующие функции:

Сведения о других конфигурациях см. в следующих статьях:

Приложение Yelb защищено с помощью ресурса Шлюза приложений Azure , развернутого в выделенной подсети в той же виртуальной сети, что и кластер AKS или в одноранговой виртуальной сети. Вы можете защитить доступ к приложению Yelb с помощью брандмауэра веб-приложений Azure (WAF), который обеспечивает централизованную защиту веб-приложений от распространенных эксплойтов и уязвимостей.

Проектирование архитектуры решения

На следующей схеме показана рекомендуемая архитектура в Azure:

Схема решения на основе контроллера входящего трафика шлюза приложений WAFv2 и NGINX.

Архитектура решения состоит из следующих элементов:

  1. Шлюз приложений обрабатывает завершение TLS и взаимодействует с серверным приложением по протоколу HTTPS.
  2. Прослушиватель шлюза приложений использует SSL-сертификат, полученный из Azure Key Vault.
  3. Политика WAF Azure, связанная с прослушивателем, запускает правила OWASP и настраиваемые правила для входящих запросов и блокирует вредоносные атаки.
  4. Параметры HTTP серверной части шлюза приложений вызывают приложение Yelb через HTTPS через порт 443.
  5. Серверный пул шлюза приложений и проба работоспособности вызывают контроллер входящего трафика NGINX через внутреннюю подсистему балансировки нагрузки AKS с помощью HTTPS.
  6. Контроллер входящего трафика NGINX использует внутреннюю подсистему балансировки нагрузки AKS.
  7. Кластер AKS настроен с использованием поставщика Azure Key Vault, предназначенного для надстройки Secrets Store CSI Driver, чтобы получать секреты, сертификаты и ключи из Azure Key Vault через том CSI.
  8. SecretProviderClass получает тот же сертификат, который используется шлюзом приложений из Azure Key Vault.
  9. Объект Ingress Kubernetes использует контроллер NGINX Ingress для открытия доступа к приложению через HTTPS через внутренний балансировщик нагрузки AKS.
  10. Служба Yelb имеет тип ClusterIP и предоставляется через контроллер входящего трафика NGINX.

Подробные инструкции по развертыванию приложения Yelb в AKS с помощью этой архитектуры см. в сопровождающем примере.

Альтернативные решения

Azure предлагает несколько вариантов развертывания веб-приложения в кластере AKS и защиты его с помощью брандмауэра веб-приложения:

Контроллер входящего трафика шлюза приложений (AGIC) — это приложение Kubernetes, поэтому вы можете использовать собственный балансировщик нагрузки шлюза приложений Azure L7 для предоставления облачного программного обеспечения в Интернете для рабочих нагрузок Службы Azure Kubernetes (AKS). AGIC отслеживает кластер Kubernetes, в котором он размещен, и постоянно обновляет шлюз приложений, чтобы выбранные службы предоставлялись в Интернете.

Схема решения на основе контроллера входящего трафика шлюза приложений Azure.

Контроллер входящего трафика выполняется в собственном модуле pod в кластере AKS. AGIC отслеживает подмножество ресурсов Kubernetes для изменений, преобразует состояние кластера в определенную конфигурацию шлюза приложений и применяет его к Azure Resource Manager (ARM). Дополнительные сведения см. в разделе "Что такое контроллер входящего трафика шлюза приложений?".

В следующей таблице описаны преимущества и недостатки контроллера входящего трафика шлюза приложений (AGIC):

Преимущества Недостатки
* Встроенная интеграция: AGIC обеспечивает встроенную интеграцию со службами Azure, в частности с Шлюзом приложений Azure, что позволяет легко и эффективно маршрутизации трафика в службы, работающие в AKS.
* Упрощенное развертывание: Развертывание AGIC как надстройки для AKS отличается простотой и легкостью по сравнению с другими методами. Она обеспечивает быструю и простую настройку шлюза приложений и кластера AKS с поддержкой AGIC.
* Полностью управляемая служба: AGIC как надстройка является полностью управляемой службой, предоставляя такие преимущества, как автоматические обновления и повышенная поддержка от Майкрософт. Он гарантирует, что контроллер входящего трафика остается up-to-date и добавляет дополнительный уровень поддержки.
* Единый облачный подход: AGIC в основном используется клиентами, которые принимают единый облачный подход. Это может быть не лучший выбор, если требуется многооблачная архитектура, где развертывание на разных облачных платформах является обязательным. В этом случае может потребоваться использовать облаконезависимый контроллер входящего трафика, например NGINX, Traefik или HAProxy, чтобы избежать проблем с зависимостью от одного поставщика.

Дополнительные сведения см. в следующих ресурсах: