Azure App Service, Container Apps или AKS: выбор по модели ответственности

Azure App Service, Azure Container Apps и Azure Kubernetes Service способны запустить веб-API, упакованный в контейнер. Для выбора это почти ничего не объясняет. Существенная разница состоит в модели эксплуатации: какие заботы об инфраструктуре берет на себя Azure, какими средствами управления располагает команда приложения и какие постоянные обязанности возникают вместе с этими средствами.

Начните с досье нагрузки. Опишите составляющие, протоколы, единицы развертывания, состояние, распределение запросов, задержку, потребление процессора и памяти, фоновые задания, источники событий, зависимости, регионы, цели восстановления, изоляцию клиентов, нормативные требования, сеть, частоту поставки и возможности команды. Жесткие требования отделите от пожеланий и предположений об отдаленном будущем. Необходимый уже сегодня оператор Kubernetes — это доказательство; рассуждение «возможно, когда-нибудь понадобится гибкость» — нет.

Выбирайте самую простую службу, которая удовлетворяет подтвержденные ограничения и проходит испытания, приближенные к рабочим условиям. Для обычных веб-приложений и API ответственным исходным выбором часто служит App Service. Container Apps подходит контейнерным API, обработчикам, заданиям и связанным службам, когда команда не хочет напрямую управлять Kubernetes. Затраты на AKS оправданы, если измеримую пользу дают API Kubernetes, специальное планирование, операторы, подробные правила, собственная сеть, разнообразные нагрузки или уже созданная внутренняя платформа кластеров.

Изменить решение можно, но переход никогда не бывает бесплатным. Контейнеры упрощают упаковку; идентификация, прием входящих запросов, проверка состояния, хранилище, обнаружение служб, масштабирование, постепенный выпуск, правила, телеметрия и восстановление все равно зависят от платформы. Запишите решение, отклоненные варианты, доказательства, ответственных и условия повторного рассмотрения. В наших проектах по разработке приложений для Azure этот подход помогает выбрать и внедрить наименьшую платформу, достаточную для реальных требований.

Сначала сравните модели обслуживания

App Service — управляемая веб-платформа для программного кода или веб-контейнера. Azure отвечает за базовую операционную систему и инфраструктуру размещения, а команда нагрузки — за настройки приложения, зависимости, идентификацию, данные, правила масштабирования, выпуски, наблюдение и восстановление. Планы App Service определяют вычислительную мощность. Тесно связанные приложения могут пользоваться одним планом, если согласуются их жизненные циклы, уровни доверия и риск взаимного влияния через общие ресурсы. Ячейки развертывания делают обычный веб-выпуск и возврат к прежней версии сравнительно простыми.

Container Apps — управляемая платформа контейнерных приложений, построенная на родственных Kubernetes технологиях, но без доступа к API Kubernetes и эксплуатации кластера. Среда образует важную границу сети и безопасности. Приложения получают неизменяемые редакции, распределение запросов по весам, обнаружение служб, задания и масштабирование по HTTP либо правилам KEDA; подходящие нагрузки можно уменьшать до нуля. Этот вариант подходит командам, которым нужны современные контейнерные подходы, а управление узлами и плоскостью управления они готовы поручить Azure.

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

Согласуйте масштабирование с характером нагрузки и пределами зависимостей

Масштабирование начинается с характера нагрузки, а не с переключателя в настройках. Измерьте постоянную и пиковую частоту запросов, одновременность, затраты процессора и памяти на запрос, время запуска и прогрева, продолжительность заданий, скорость поступления в очередь, срок соединений, состояние сеансов и пропускную способность зависимых систем. Установите цель задержки и выясните, как быстро новая мощность должна начать приносить пользу. Добавление экземпляров без состояния не устранит блокировки базы данных, ограничения поставщика, последовательные деловые правила или исчерпанный пул соединений.

App Service масштабирует приложения в пределах мощности плана App Service. Общий план может улучшить использование ресурсов, но одновременно привязывает приложения к одной выделенной мощности и общей области отказа или перегрузки. Постоянно прогретые экземпляры и простое увеличение их числа хорошо соответствуют предсказуемым HTTP-службам. Обязательно проверьте сигналы автоматического масштабирования, прогрев, направление запросов по состоянию, пределы плана, распределение по зонам и способность одного чрезмерно активного приложения исчерпать общие ресурсы.

В Container Apps правила HTTP, TCP или KEDA отдельно определяют число экземпляров каждой редакции. Уменьшение до нуля экономит ресурсы для нагрузок, допускающих простой, однако холодный запуск, наименьшее число реплик, частота опроса, правила очереди и соединения с зависимостями остаются архитектурными решениями. В AKS спрос модулей отделен от наличия узлов: HPA или KEDA меняет число реплик нагрузки, а автоматическое масштабирование или подготовка узлов добавляет мощность. Запросы и ограничения ресурсов, бюджеты прерываний, планирование, служебные затраты, группы узлов и поведение ожидающих модулей дают больше контроля, но создают и больше взаимосвязанных способов отказа.

Опишите сеть от входа до каждой зависимости

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

В App Service частные конечные точки для входящего движения и присоединение к виртуальной сети для исходящего движения решают разные задачи. Проверьте частный DNS, исходящие маршруты, сетевые средства защиты, доступ к развертыванию и все зависимости; один переключатель не создает замкнутого периметра. App Service Environment может обеспечить более сильную изоляцию, однако его стоимость и объем сопровождения должны следовать из настоящего требования. Если несколько приложений используют один план, отдельно согласуйте приемлемость общей мощности и доверия.

Среда Container Apps является существенной границей сети и безопасности. Объединяйте в ней приложения, которым действительно можно совместно использовать эту границу, регион и возможности среды; разные области доверия разделяйте. Проверьте внутренний и внешний вход, частные соединения, DNS, исходящие ограничения, обнаружение служб, ответственность за сертификаты, доступ к реестру и место назначения телеметрии. В AKS команда получает самый богатый выбор для построения CNI, входа и выхода, сетевых правил, служебной сети и частного доступа к плоскости управления. Вместе с ним она берет на себя планирование адресов, обновление компонентов, совместимость правил, диагностику на уровне пакетов и многочисленные способы прервать движение небольшой ошибкой настройки.

Сопоставьте выпуск, восстановление и наблюдаемость

Проектирование выпуска и восстановления — это один разговор. Ячейка развертывания App Service позволяет прогреть кандидата, проверить его, перевести на него производственное имя узла и быстро поменять версии обратно. Надежность зависит от отдельных настроек ячеек, совместимости изменений базы данных, поведения кеша, фоновой работы и проверки состояния, которая подтверждает настоящую готовность, а не само существование процесса.

Редакции Container Apps сохраняют неизменяемые версии приложения и поддерживают веса распределения запросов, поэтому постепенное открытие доступа и возврат естественны. Определите, могут ли прежние редакции продолжать получать сообщения, как режимы одной или нескольких активных редакций влияют на обработчики, какое изменение настроек создает новую редакцию и как долго возврат остается возможным. AKS поддерживает последовательное, пробное и параллельное сине-зеленое внедрение через ресурсы Kubernetes и контроллеры поставки. Такая гибкость окупается лишь тогда, когда команда отвечает за правила допуска, проверки состояния, бюджеты прерываний, анализ внедрения, продвижение описаний развертывания, обновление контроллеров и восстановление после расхождения желаемого и фактического состояний.

Все три варианта являются региональными службами. Устойчивость в нескольких регионах требует еще одного развертывания, подходящего копирования данных, глобального направления запросов, резервной мощности, распределения секретов и настроек, наблюдаемости и испытанного решения о переключении. Схема не является проверкой восстановления. Отработайте неудачный выпуск, недоступность зависимости, исчерпание квоты, потерю зоны или региона, ошибку DNS и просроченный сертификат; измерьте время обнаружения, локализации, восстановления, потерю данных и влияние на клиентов.

Наблюдаемость должна сопровождать пользовательский сценарий через все управляемые границы. Начните с показателей уровня обслуживания для доступности, задержки, правильности и актуальности, а затем свяжите запросы, редакции, экземпляры, очереди, зависимости и события развертывания с помощью сквозных идентификаторов. App Service обычно открывает наименьшую поверхность платформы. Container Apps добавляет поведение редакций, реплик, среды и масштабирования по событиям. AKS добавляет узлы, модули, контроллеры, планирование, сеть, хранилища, правила и обновления кластера. Больше телеметрии полезно лишь тогда, когда панели, оповещения, сроки хранения, доступ и ответственные за реагирование остаются продуманными.

Оцените стоимость эксплуатации, а не только вычислений

Сравнивайте полную стоимость владения при одинаковых предположениях. Учтите вычисления, зарезервированную или наименьшую мощность, балансировку нагрузки, общедоступные адреса, NAT и исходящее движение, хранилище, реестр образов, DNS, сертификаты, шлюз или межсетевой экран веб-приложения, журналы, показатели, резервные копии, средства безопасности, поддержку и удвоенную мощность для аварийного восстановления. Рассчитайте постоянное движение, ожидаемый пик, отказ с уменьшенным запасом и правдоподобный рост. Используйте актуальные региональные цены и измеренный профиль ресурсов, поскольку общие месячные примеры быстро устаревают.

План App Service выделяет мощность независимо от того, заняты размещенные приложения или простаивают. Совместное использование бывает выгодным, но связывает масштабирование и создает риск взаимного влияния. Расходы Container Apps могут довольно точно соответствовать использованию реплик, а подходящие нагрузки — уменьшаться до нуля. Однако наименьшие реплики, выделенные профили, ресурсы среды, шлюзы, журналы и зависимые службы никуда не исчезают. Стоимость AKS охватывает узлы и запас мощности, балансировщики, диски, реестр, исходящее движение, наблюдение, правила и средства безопасности, обновления и труд специалистов, которые поддерживают надежность кластера. Низкая цена узла еще не делает службу дешевой.

Инженерное время оценивайте так же серьезно, как счет Azure: проектирование платформы, код инфраструктуры, проверки доступа, исправления безопасности, обновления версий, реагирование на уязвимости, сопровождение развертывания, планирование емкости, диагностику происшествий, обучение дежурных специалистов и упражнения по восстановлению. Оцените и цену задержки. Платформа с ценными средствами управления может ускорить зрелую организацию; та же платформа замедлит продуктовую команду, которой сначала придется построить вокруг нее собственную операционную систему.

Решение должно выдержать совместное рассмотрение ответственных за приложение, платформу, безопасность, финансы и эксплуатацию. Сформулируйте выбранную службу одним предложением, назовите удовлетворенные требования, количественно опишите главные предположения, перечислите принятые риски и установите условия повторной оценки. Возвращайтесь к выбору, когда существенно меняются протоколы, изоляция, региональные цели, характер запросов, нормативные требования, возможности команды или разнообразие нагрузок, а не просто из-за появления новых возможностей у другой платформы.

Подтвердите выбор испытанием в реальных условиях

• Выбирайте App Service, когда нагрузка в основном состоит из обычного HTTP-приложения или API, важна быстрая поставка, ячейки развертывания соответствуют способу выпуска, а команде полезна малая поверхность инфраструктуры. Проверьте размер плана, прогрев, направление по состоянию, частные соединения, изоляцию общего плана и региональное восстановление.
• Выбирайте Container Apps, когда действительно нужны независимо выпускаемые контейнеры, API, обработчики, задания, масштабирование по событиям, редакции или уменьшение до нуля, а прямой доступ к API Kubernetes не требуется. Проверьте границы среды, допустимость холодного запуска, поведение KEDA, правильность очередей, распределение запросов, исходящее движение и возврат версии.
• Выбирайте AKS, когда необходимые возможности зависят от API Kubernetes, операторов, специального оборудования или планирования, подробных кластерных правил, собственной сети, служебных сетей или зрелой внутренней платформы. Еще до создания кластера назовите команду, ответственную за обновления, защитные ограничения, дополнительные компоненты, емкость, безопасность, наблюдение и происшествия.
• Проведите одно испытание в условиях, близких к рабочим, для каждого реального претендента. Разверните настоящий образ и идентификацию, подключите частные зависимости, создайте постоянное и пиковое движение, прервите работу экземпляра, выпустите неисправную версию, вернитесь назад, замените секрет, просмотрите трассировку и оцените стоимость по фактическому потреблению.
• Оформите запись архитектурного решения с ограничениями, измеренными доказательствами, альтернативами, отклоненными предположениями, сценариями стоимости, испытаниями отказов, принятыми рисками, ответственными и условиями повторного рассмотрения. Четкая запись сдерживает случайное разрастание платформы и превращает будущую миграцию в обоснованное решение.