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