Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Примечание.
Планы "Базовый", "Стандартный" и "Корпоративный" вступили в пенсионный период 17 марта 2025 года. Дополнительные сведения см. в объявлении о выходе на пенсию в Azure Spring 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 и состоит из нескольких ресурсов в AKS. Ingress управляет внешним доступом к службам и задает правила маршрутизации трафика в разные службы. Служба абстрагирует доступ к набору модулей pod. Можно выполнить переключение сине-зеленого развертывания, обновив службу, чтобы указать на другую версию развертывания с помощью меток. |
| Развертывание — это версия приложения. Приложение может иметь одно рабочее развертывание и одно промежуточное развертывание. | Развертывание управляет развертыванием и жизненным циклом определенного приложения или службы. Кроме того, он позволяет проводить постепенные обновления и откаты, обеспечивая контролируемые, плавные изменения приложений без простоя. |
| Экземпляр приложения — это минимальная единица выполнения, управляемая службой. | Модуль Pod представляет один или несколько тесно связанных контейнеров и размещает один экземпляр работающего приложения или рабочей нагрузки. |
Рекомендации по сети
Перед подготовкой кластера AKS важно тщательно рассмотреть параметры сети. Эти решения могут значительно повлиять на производительность, масштабируемость и безопасность приложений.
AKS использует плагины интерфейса контейнерных сетей (CNI) для организации сетей в своих кластерах. Эти подключаемые модули обрабатывают критически важные задачи, такие как назначение IP-адресов подам, маршрутизация трафика между ними и обеспечение связи через службы Kubernetes. AKS поддерживает несколько подключаемых модулей CNI, адаптированных к различным сетевым потребностям, обеспечивая гибкость в проектировании кластера.
AKS предлагает две основные сетевые модели: наложенные сети и плоские сети. Наложенные сети назначают частные IP-адреса Pods, отдельно от подсети виртуальной сети Azure узлов AKS. Эта модель масштабируется и сохраняет IP-адреса виртуальной сети, но использует преобразование сетевых адресов (NAT) для трафика, покидающего кластер. В отличие от этого, плоские сети назначают IP-адреса непосредственно из той же подсети виртуальной сети Azure, что и узлы, что позволяет внешним службам получать доступ к модулям без NAT. Хотя плоские сети обеспечивают прямую связь между pod, им нужно больше адресного пространства для IP-адресов виртуальной сети.
Надлежащее планирование IP-адресов является важным для гладкой операции AKS. Важно убедиться, что подсети имеют достаточно IP-адресов для всех ресурсов, избегайте перекрывающихся диапазонов и оставляйте место для будущего роста, чтобы предотвратить проблемы с подключением и нарушения. Для получения дополнительной информации см. обзор сети CNI в службе Azure Kubernetes.
Для обработки входящего трафика в AKS можно использовать подсистемы балансировки нагрузки или контроллеры входящего трафика. Подсистемы балансировки нагрузки работают на уровне 4, распределяя трафик на основе протоколов и портов, а контроллеры входящего трафика работают на уровне 7, предлагая дополнительные функции, такие как маршрутизация на основе URL-адресов и завершение TLS/SSL. Контроллеры входящего трафика сокращают потребность в нескольких общедоступных IP-адресах, управляя трафиком в несколько приложений через один IP-адрес. Для веб-приложений контроллеры входящего трафика предпочтительнее, так как они обеспечивают более эффективное управление трафиком и интеграцию с ресурсами Kubernetes. Дополнительные сведения см. в разделе "Управляемый входящий трафик NGINX" с надстройкой маршрутизации приложений.
Чтобы защитить сетевой трафик в AKS, используйте Брандмауэр веб-приложений (WAF), такие как Шлюз приложений Azure для защиты от атак, таких как межсайтовый скрипт и отравление файлов cookie, а также управление маршрутизацией трафика и завершением TLS/SSL. Кроме того, реализуйте политики сети для управления обменом данными между pod путем определения правил в манифестах YAML на основе меток, пространств имен или портов. Эти политики, доступные только для узлов под управлением 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 интегрируется с внешними поставщиками удостоверений через федерацию OpenID Connect (OIDC), используя собственные функции Kubernetes. В нем используется проекция тома маркера учетной записи службы для назначения удостоверений Kubernetes подам посредством аннотированных служебных учетных записей. С помощью этих маркеров приложения Kubernetes могут безопасно проходить проверку подлинности и получать доступ к ресурсам Azure с помощью идентификатора Microsoft Entra. Эта настройка легко работает с такими библиотеками, как клиентские библиотеки удостоверений Azure (Azure.Identity) или библиотека аутентификации Microsoft (MSAL), чтобы упростить проверку подлинности для рабочих нагрузок. Чтобы узнать, как настроить кластер и настроить pod вашего приложения с использованием идентификации рабочей нагрузки, см. в разделе Развертывание и настройка удостоверения рабочей нагрузки.
Контейнеризация приложений
Контейнеризация приложений в образы контейнеров необходима для развертывания в AKS. Это гарантирует, что развертывания являются согласованными, переносимыми и масштабируемыми. Использование образов контейнеров обеспечивает гибкость в управлении различными версиями приложений. Это упрощает обновление и откат и повышает эффективность использования ресурсов, позволяя нескольким контейнерам работать на одном хосте.
Azure Spring Apps помогает пользователям создавать образы контейнеров и развертывать приложения разными способами. Вы можете развернуть из исходного кода, из собранных артефактов, таких как JAR и WAR-файлы, или непосредственно из образа контейнера. Сведения о том, как развертывать из JAR-файла или WAR, см. в разделе «Создание образа контейнера из JAR или WAR». Сведения о развертывании из исходного кода см. в статье "Контейнеризация приложения с помощью paketo Buildpacks".
Чтобы отслеживать производительность приложений, развернутых в AKS, можно интегрировать агент мониторинга производительности приложений (APM) во время процесса контейнеризации. Дополнительные сведения см. в разделе "Интеграция мониторинга производительности приложений" в образы контейнеров.
Развертывание приложений и компонентов Spring Cloud
Для развертывания приложений в AKS можно использовать Deployments, которые применяются в Azure Spring Apps, или StatefulSets в зависимости от потребностей вашего приложения. Для приложений без отслеживания состояния, таких как микрослужбы, обычно используется развертывание, которое управляет репликами приложения и гарантирует, что они работают гладко. Этот тип используется Azure Spring Apps. С другой стороны, StatefulSets идеально подходят для приложений, требующих постоянного хранения или стабильных идентификаторов, таких как базы данных или службы с необходимостью в отслеживании состояния.
Наряду с развертыванием приложения необходимо также определить службу для открытия доступа к подам бэкенда. Служба — это абстракция, которая позволяет определить логический набор pod и обеспечивает сетевой доступ к ним. Эта возможность имеет решающее значение для балансировки нагрузки и обмена данными между Pod'ами.
При развертывании компонентов Spring Cloud, таких как Spring Cloud Config или Spring Cloud Gateway, обычно используются развертывания для служб без отслеживания состояния. Для внутренних служб, которым требуется стабильное хранилище или состояние, можно выбрать StatefulSets.
По следующим ссылкам приведены справочные примеры по настройке проектов компонентов Java на основе библиотек с открытым исходным кодом, сборке образов контейнеров и развертыванию компонентов в AKS:
Монитор
Мониторинг является важной частью управления приложениями, развернутыми в AKS. AKS предоставляет ряд средств для отслеживания и анализа состояния кластера и рабочих нагрузок, включая интегрированные решения, такие как Azure Monitor, Azure Log Analytics и Prometheus. Дополнительные сведения см. в следующих статьях:
- Управляемый Prometheus для сбора метрик.
- Аналитическая информация о контейнерах для сбора журналов
- Azure Managed Grafana для визуализации.
Помимо Azure Monitor и Prometheus, вы также можете использовать другие решения мониторинга, такие как Datadog, New Relic или Elastic Stack (ELK). Эти средства можно интегрировать в AKS для сбора журналов, метрик и трассировок, предлагая различные аналитические сведения о производительности кластера.
Туториал
Мы предоставляем следующие учебники, демонстрирующие комплексный опыт выполнения приложений в AKS. Эти учебники предназначены для справки, а так как AKS обладает высокой гибкостью, необходимо выбирать конфигурации и настройки в зависимости от конкретных требований.
- Приложение ACME Fitness Store: Это учебное пособие предлагает практическое руководство по запуску приложения ACME Fitness Store на AKS. Для получения дополнительной информации см. acme-fitness-store/azure-kubernetes-service.
- Микросервисы Spring PetClinic: В этом учебнике демонстрируется распределенная версия приложения Spring PetClinic, созданного с помощью Spring Cloud. Дополнительные сведения см. в статье spring-petclinic-microservices/azure-kubernetes-service.