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

Перенос Azure Spring Apps на службу Azure Kubernetes

  • Статья

Примечание.

The Basic, Standard, and Enterprise plans entered a retirement period on March 17, 2025. Дополнительные сведения см. в объявлении о выходе на пенсию в Azure Spring Apps.

The Standard consumption and dedicated plan entered a retirement period on September 30, 2024, with a complete shutdown by the end of March 2025. For more information, see Migrate Azure Spring Apps Standard consumption and dedicated plan to Azure Container Apps.

Эта статья относится к:✅ Basic/Standard ✅ Enterprise

В этой статье представлен обзор миграции из Azure Spring Apps в Служба Azure Kubernetes (AKS).

Azure Spring Apps — это решение для платформы как службы (PaaS), разработанное специально для приложений Spring Boot. Это упрощает развертывание, запуск и управление этими приложениями. Azure Spring Apps заботится о инфраструктуре, масштабировании и мониторинге, чтобы разработчики могли сосредоточиться на своем коде.

AKS — это предложение инфраструктуры как службы (IaaS), которое предоставляет полностью управляемую среду Kubernetes. AKS обеспечивает более полный контроль над развертыванием и управлением приложениями. Он поддерживает широкий спектр контейнерных приложений и обеспечивает настройку в соответствии с конкретными потребностями.

Перенос приложений из Azure Spring Apps в AKS означает переход из управляемой среды в одну, которая обеспечивает большую гибкость. Для этого процесса требуются новые инструменты и методики для достижения одинаковых результатов в AKS, как и в Azure Spring Apps.

Сопоставление концепций

Так как Azure Spring Apps и AKS являются различными типами предложений облачных служб, это не совсем точно для сопоставления концепций Azure Spring Apps непосредственно с AKS. Кроме того, Azure Spring Apps зависит от многих внутренних компонентов при использовании в рабочих средах, которые здесь не перечислены. На следующей схеме и таблице представлено простое сопоставление концепций из Azure Spring Apps с AKS, которые помогут вам понять основы. В реальной рабочей среде следует рассмотреть более безопасные и надежные решения.

Схема сопоставления концепции между Azure Spring Apps и Служба Azure Kubernetes.

Служба Azure Spring Apps Служба Azure Kubernetes
Экземпляр службы хранит и обеспечивает границу для приложений и других ресурсов, а также поддерживает пользовательскую виртуальную сеть. Кластер — это базовая единица развертывания. В кластере пространство имен — это виртуальное подразделение, используемое для организации и изоляции ресурсов. Он использует ту же базовую сетевую инфраструктуру, определенную виртуальной сетью кластера. Выбор между выделенным кластером или общим кластером с пространствами имен зависит от потребностей бизнеса.
An App is one business app that serves as a child resource within a service instance. Приложение — это виртуальная концепция в Azure Spring Apps и состоит из нескольких ресурсов в AKS. Ingress управляет внешним доступом к службам и задает правила маршрутизации трафика в разные службы. A Service abstracts access to a set of pods. You can perform a blue-green deployment switch by updating a service to point to a different version of a deployment using labels.
Развертывание — это версия приложения. Приложение может иметь одно рабочее развертывание и одно промежуточное развертывание. Развертывание управляет развертыванием и жизненным циклом определенного приложения или службы. Кроме того, он позволяет проводить постепенные обновления и откаты, обеспечивая контролируемые, плавные изменения приложений без простоя.
Экземпляр приложения — это минимальная единица выполнения, управляемая службой. Модуль Pod представляет один или несколько тесно связанных контейнеров и размещает один экземпляр работающего приложения или рабочей нагрузки.

Рекомендации по сети

Перед подготовкой кластера AKS важно тщательно рассмотреть параметры сети. Эти решения могут значительно повлиять на производительность, масштабируемость и безопасность приложений.

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

AKS предлагает две основные сетевые модели: наложенные сети и плоские сети. Overlay networks assign private IP addresses to pods, separate from the Azure Virtual Network subnet of the AKS nodes. Эта модель масштабируется и сохраняет IP-адреса виртуальной сети, но использует преобразование сетевых адресов (NAT) для трафика, покидающего кластер. В отличие от этого, плоские сети назначают IP-адреса непосредственно из той же подсети виртуальной сети Azure, что и узлы, что позволяет внешним службам получать доступ к модулям без NAT. While flat networks enable direct pod communication, they require more extensive virtual network IP address space.

Надлежащее планирование IP-адресов является важным для гладкой операции AKS. Важно убедиться, что подсети имеют достаточно IP-адресов для всех ресурсов, избегайте перекрывающихся диапазонов и оставляйте место для будущего роста, чтобы предотвратить проблемы с подключением и нарушения. Для получения дополнительной информации см. обзор сети CNI в службе Azure Kubernetes.

Для обработки входящего трафика в AKS можно использовать подсистемы балансировки нагрузки или контроллеры входящего трафика. Подсистемы балансировки нагрузки работают на уровне 4, распределяя трафик на основе протоколов и портов, а контроллеры входящего трафика работают на уровне 7, предлагая дополнительные функции, такие как маршрутизация на основе URL-адресов и завершение TLS/SSL. Контроллеры входящего трафика сокращают потребность в нескольких общедоступных IP-адресах, управляя трафиком в несколько приложений через один IP-адрес. Для веб-приложений контроллеры входящего трафика предпочтительнее, так как они обеспечивают более эффективное управление трафиком и интеграцию с ресурсами Kubernetes. Дополнительные сведения см. в разделе "Управляемый входящий трафик NGINX" с надстройкой маршрутизации приложений.

Чтобы защитить сетевой трафик в AKS, используйте Брандмауэр веб-приложений (WAF), такие как Шлюз приложений Azure для защиты от атак, таких как межсайтовый скрипт и отравление файлов cookie, а также управление маршрутизацией трафика и завершением TLS/SSL. Additionally, implement network policies to control pod-to-pod communication by defining rules in YAML manifests, based on labels, namespaces, or ports. Эти политики, доступные только для узлов под управлением Linux, обеспечивают более эффективное управление трафиком и безопасность в кластере. Для получения более подробной информации см. "Защита трафика между подами с помощью сетевых политик в AKS".

Обеспечение

Для подготовки кластера AKS можно использовать портал Azure, шаблоны Azure CLI или ARM. Процесс обычно включает выбор требуемого региона, определение размера и типа пула узлов и выбор сетевой модели — Azure CNI или Kubenet. Кроме того, необходимо настроить параметры проверки подлинности, такие как интеграция идентификатора Microsoft Entra для управления доступом пользователей. Для мониторинга и масштабирования можно включить Azure Monitor и настроить автомасштабирование на основе использования ресурсов. После подготовки кластер можно управлять с помощью kubectl или Azure CLI. Подробные инструкции по подготовке AKS см. в статье "Создание кластера AKS".

Параметры доступа и идентификации

AKS предлагает несколько способов управления проверкой подлинности, авторизацией и доступом для кластеров Kubernetes. Вы можете использовать управление доступом на основе ролей Kubernetes (RBAC), чтобы предоставить пользователям, группам и учетным записям служб доступ только к нужным ресурсам. Дополнительные сведения см. в статье об Использовании авторизации RBAC. AKS также поддерживает идентификатор Microsoft Entra и Azure RBAC для повышения безопасности и контроля, что позволяет назначать разрешения и управлять ими более упрощенным способом.

Для обеспечения оптимальной безопасности рекомендуется интегрировать AKS с идентификатором Microsoft Entra. Эта интеграция использует протоколы OpenID Connect и OAuth 2.0 для проверки подлинности. Пользователи проходят проверку подлинности с помощью учетных данных Microsoft Entra при взаимодействии с кластером AKS с разрешениями на доступ, управляемыми администратором кластера. Дополнительные сведения см. в статье "Включение проверки подлинности управляемого удостоверения Azure для кластеров Kubernetes с помощью kubelogin"

Microsoft Entra Workload ID integrates Kubernetes' native features with external identity providers through OpenID Connect (OIDC) federation. It uses Service Account Token Volume Projection to assign Kubernetes identities to pods via annotated service accounts. С помощью этих маркеров приложения Kubernetes могут безопасно проходить проверку подлинности и получать доступ к ресурсам Azure с помощью идентификатора Microsoft Entra. This setup works seamlessly with libraries like Azure Identity client libraries (Azure.Identity) or the Microsoft Authentication Library (MSAL) to streamline authentication for your workloads. To learn how to set up a cluster and configure your application pod with workloads identify, see Deploy and configure workload identity.

Контейнеризация приложений

Containerizing applications into container images is essential for deployment on AKS. Это гарантирует, что развертывания являются согласованными, переносимыми и масштабируемыми. Использование образов контейнеров обеспечивает гибкость в управлении различными версиями приложений. Это упрощает обновление и откат и повышает эффективность использования ресурсов, позволяя нескольким контейнерам работать на одном хосте.

Azure Spring Apps помогает пользователям создавать образы контейнеров и развертывать приложения разными способами. You can deploy from source code, from built artifacts like JAR or WAR files, or directly from a container image. Сведения о том, как развертывать из JAR-файла или WAR, см. в разделе «Создание образа контейнера из JAR или WAR». Сведения о развертывании из исходного кода см. в статье "Контейнеризация приложения с помощью paketo Buildpacks".

Чтобы отслеживать производительность приложений, развернутых в AKS, можно интегрировать агент мониторинга производительности приложений (APM) во время процесса контейнеризации. Дополнительные сведения см. в разделе "Интеграция мониторинга производительности приложений" в образы контейнеров.

Развертывание приложений и компонентов Spring Cloud

Для развертывания приложений в AKS можно использовать Deployments, которые применяются в Azure Spring Apps, или StatefulSets в зависимости от потребностей вашего приложения. For stateless applications, such as microservices, you would typically use a Deployment, which manages replicas of your application and ensures they're running smoothly. Этот тип используется Azure Spring Apps. С другой стороны, StatefulSets идеально подходят для приложений, требующих постоянного хранения или стабильных идентификаторов, таких как базы данных или службы с необходимостью в отслеживании состояния.

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

When deploying Spring Cloud components, such as Spring Cloud Config or Spring Cloud Gateway, you would generally use Deployments for stateless services. Для внутренних служб, которым требуется стабильное хранилище или состояние, можно выбрать StatefulSets.

Следующие ссылки содержат справочные примеры образов контейнеров и файлов манифеста для компонентов Spring Cloud:

Монитор

Мониторинг является важной частью управления приложениями, развернутыми в AKS. AKS предоставляет ряд средств для отслеживания и анализа состояния кластера и рабочих нагрузок, включая интегрированные решения, такие как Azure Monitor, Azure Log Analytics и Prometheus. Дополнительные сведения см. в следующих статьях:

Помимо Azure Monitor и Prometheus, вы также можете использовать другие решения мониторинга, такие как Datadog, New Relic или Elastic Stack (ELK). Эти средства можно интегрировать в AKS для сбора журналов, метрик и трассировок, предлагая различные аналитические сведения о производительности кластера.

Tutorial

We provide the following tutorials to demonstrate the end-to-end experience of running applications on AKS. These tutorials are meant for reference, and because AKS is highly flexible, you need to choose configurations and customizations based on your specific requirements.