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

2025-04-07

Теперь, когда у вас есть лучшее представление о различиях платформ между 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 предоставляет следующие функции:

Простая настройка управляемых контроллеров входящего трафика NGINX на основе контроллера входящего трафика Kubernetes NGINX.
Интеграция с Azure DNS для управления общедоступными и частными зонами.
Завершение SSL с сертификатами, хранящимися в Azure Key Vault.

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

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

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

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

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

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

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

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

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

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

Контроллер входящего трафика выполняется в собственном модуле 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, чтобы избежать проблем с зависимостью от одного поставщика.

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

Недостатки

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

* Единый облачный подход: AGIC в основном используется клиентами, которые принимают единый облачный подход. Это может быть не лучший выбор, если требуется многооблачная архитектура, где развертывание на разных облачных платформах является обязательным. В этом случае может потребоваться использовать облаконезависимый контроллер входящего трафика, например NGINX, Traefik или HAProxy, чтобы избежать проблем с зависимостью от одного поставщика.

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

Шлюз приложений Azure для контейнеров обеспечивает балансировку нагрузки и динамическое управление трафиком для приложений в кластерах Kubernetes.

Ключевые функции

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

Балансировка нагрузки. Эффективно распределяет входящий трафик между несколькими контейнерами для оптимальной производительности и масштабируемости.
Реализация API шлюза: поддерживает API шлюза, что позволяет определять правила маршрутизации и политики в нативном для Kubernetes стиле.
Пользовательские пробы работоспособности. Определите пользовательские пробы работоспособности для отслеживания работоспособности контейнера и автоматического перенаправления трафика из неработоспособных экземпляров.
Сходство сеансов: обеспечивает сходство сеансов, маршрутизацию последующих запросов от одного клиента к одному контейнеру для согласованного взаимодействия с пользователем.
Политика TLS: поддерживает прерывание TLS, позволяя шифрование SSL/TLS и расшифровку переноситься на шлюз.
Перезаписи заголовков: перезаписывайте заголовки HTTP клиентских запросов и ответов от целевых сервисов с помощью пользовательского определения ресурсов IngressExtension. Дополнительные сведения см. в разделе API входящего трафика и API шлюза.
Перезаписи URL-адресов: измените URL-адрес клиентских запросов, включая имя узла и (или) путь, и включите новый URL-адрес перезаписи при инициировании запросов к целевым объектам серверной части. Дополнительные сведения см. в разделе API входящего трафика и API шлюза.

Ограничения

В настоящее время шлюз приложений Azure для контейнеров не поддерживает следующие функции:

Дополнительные сведения см. в статье о развертывании кластера Службы Azure Kubernetes (AKS) с помощью шлюза приложений для контейнеров.

Azure Front Door — это глобальный балансировщик нагрузки уровня 7, который безопасно предоставляет и защищает рабочие нагрузки, выполняемые в AKS, с брандмауэром веб-приложений Azure и службой Azure Private Link.

Это решение использует azure Front Door Premium, сквозное шифрование TLS, брандмауэр веб-приложений Azure и службу приватного канала для безопасного предоставления и защиты рабочей нагрузки, работающей в AKS.

Возможность разгрузки TLS и SSL в Azure Front Door для завершения подключений TLS и расшифровки входящего трафика на уровне Front Door. Azure Front Door повторно расшифровывает входящий трафик перед пересылкой его в веб-приложение, размещенное в AKS. Эта практика применяет сквозное шифрование TLS для всего процесса запроса от клиента к источнику. Дополнительные сведения см. в статье Secure your origin with Private Link in Azure Front Door Premium.

Контроллер входного трафика NGINX обеспечивает доступ к веб-приложению, размещенному в AKS. Он настроен на использование частного IP-адреса в качестве интерфейсной IP-конфигурации внутренней kubernetes-internal подсистемы балансировки нагрузки, и он использует HTTPS в качестве транспортного протокола для предоставления веб-приложения. Дополнительные сведения см. в разделе "Создание контроллера входящего трафика" с помощью внутреннего IP-адреса.

Мы рекомендуем это решение для сценариев, в которых вы развертываете одно и то же веб-приложение в нескольких региональных кластерах AKS для обеспечения непрерывности бизнес-процессов и аварийного восстановления, или даже на нескольких облачных платформах или локальных установках. В этом случае Front Door может перенаправлять входящие вызовы к одному из внутренних серверов (также известных как источники) с помощью одного из следующих методов маршрутизации:

Задержка. Маршрутизация на основе задержки гарантирует, что запросы отправляются в самые низкие источники задержки, допустимые в диапазоне конфиденциальности. Другими словами, запросы отправляются к ближайшему набору точек происхождения с учетом задержки сети.
Приоритет. Вы можете задать приоритеты для источников, если требуется настроить основной источник для обслуживания всего трафика. Вторичный источник может быть резервной копией в случае, если основной источник становится недоступным.
Взвешанный: вы можете назначить вес источникам, если вы хотите распределять трафик по набору источников равномерно или в соответствии с коэффициентами веса. Трафик распределяется по весовому значению, если задержки источников находятся в пределах допустимого диапазона чувствительности к задержке в группе источников.
Сходство сеансов. Вы можете настроить сходство сеансов для внешних узлов или доменов, чтобы обеспечить отправку запросов от одного и того же пользователя в тот же источник.

Дополнительные сведения см. в статье "Использование Azure Front Door для защиты рабочих нагрузок AKS".

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