Переход с Azure Kubernetes Service на Container Apps: рекомендации и особенности

Введение

«Рамешвар, это уже второй раз, когда у нас возникли проблемы с обновлением кластера и почти случился простой приложения. Мы живем в эпоху облака, и мне не очень приятно слышать, что у нас могут возникнуть вопросы с приложением из-за проблем с обновлением кластера AKS; и зачем такие частые обновления? Мы обновляли кластер только в прошлом квартале. Не можешь ли ты просто выбрать стабильную версию, чтобы нам не нужно было планировать обновления по крайней мере в течение года?» — именно этот комментарий моего руководителя дал старт нашей работе с контейнерными приложениями.

Как выбрать оркестратор контейнеров

Проблемы, связанные с использованием AKS

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

Требования к оркестратору контейнеров

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

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

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

Сравнение оркестраторов контейнеров

Я начал с изучения доступных оркестраторов контейнеров. Помимо AKS, я рассмотрел Service Fabric и Azure Container Apps (ACA). ACA был запущен компанией Microsoft в мае 2022 года как полностью управляемый оркестратор контейнеров.

Ниже приведено сравнение факторов, важных для нас.

Поскольку мы уже использовали Kubernetes (AKS), а команда хорошо его знала и имела опыт работы с ним, мы приняли решение в пользу Azure Container Apps; это платформа Kubernetes, а значит требовались минимальные усилия по изучению и переходу.

Прежде чем рассматривать проект и архитектуру перехода, давайте коротко поговорим об архитектуре контейнерных приложений, а также некоторых ее ключевых особенностях и компонентах.

Обзор контейнерных приложений Azure

ACA, как и AKS, является бессерверной платформой оркестрации контейнеров. В отличие от AKS, она полностью управляема. В случае с AKS за контроль и обслуживание области управления отвечает Microsoft, а пользователи отвечают за рабочие узлы. В ACA области управления и данных контролирует Microsoft. ACA — это та же AKS, но управляемая Microsoft.

Источник изображения: https://learn.microsoft.com/en-us/azure/architecture/example-scenario/serverless/microservices-with-container-apps

Ключевые особенности замены инфраструктуры AKS: 

• IaC-поддержка
• Обеспечение доступа по HTTPS или TCP без необходимости управления внутренней инфраструктурой
• Возможность выбора специализированного оборудования
• Запуск нескольких ревизий контейнеров
• Автомасштабирование
• Внутренний доступ и обнаружение служб
• Встроенная поддержка сине-зеленых развертываний
• Поддержка интеграции VNet
• Мониторинг журналов
• Щедрые квоты
• Отсутствие изменений кода или незначительные изменения

Доступные планы ACA

ACA можно развернуть по одному из двух планов:

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

Среда ACA

Несмотря на то, что это бессерверная платформа, и у нас нет доступа к базовому кластеру k8s, одной из важнейших особенностей ACA является интеграция VNet в среду ACA.

Среда Azure Container Apps — это безопасная граница вокруг одного или нескольких контейнерных приложений и заданий. Среда выполнения Container Apps управляет всеми средами, выполняя обновление ОС, операции масштабирования, процедуры обхода отказа и балансировку ресурсов.

Существует два типа сред Container Apps:

• Среды профилей рабочей нагрузки — поддерживают как план потребления, так и «выделенный» план.
• Среды только для потребления — поддерживают только план потребления.

Источник изображения: https://learn.microsoft.com/en-us/azure/container-apps/environment

Сравнение характеристик ACA и AKS

Наш кластер AKS был интегрирован с VNet, и весь трафик к службам AKS контролировался через подсети и NSG. Мы хотели и дальше использовать этот подход. Мы решили развернуть среду профилей рабочей нагрузки в нашей VNet, и это позволило нам протестировать профили как рабочей нагрузки потребления, так и «выделенной» рабочей нагрузки.

Терминология ACA

• Container App — контейнерное приложение в ACA, эквивалент службы в Kubernetes.
• Контейнер — в ACA вы запускаете не модули pod, а контейнеры.
• Ревизия — это снимок версии контейнерного приложения. Вы можете одновременно запускать несколько ревизий одного и того же контейнерного приложения.

Особенности перехода и принципы проектирования

Самым важным аспектом перехода было плавное переключение с AKS на ACA без простоев. Наши точки принятия решений по пространству инфраструктуры/приложения были, в частности, такими:

Тип плана

Мы рассматривали план потребления и план потребления + «выделенный». Несмотря на высокую стоимость, план потребления + «выделенный» обеспечивает гибкость перехода между планом потребления и «выделенным» планом без необходимости пересоздания среды. Это позволяет существенно упростить конфигурацию. В конечном итоге выбор зависит от имеющейся инфраструктуры и стоимости. Если основной мотив — экономия средств, лучше выбрать план потребления.

Среды

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

Управляемое удостоверение / субъект-служба

Среда контейнерных приложений — это безопасная логическая граница. Контейнерные приложения, развернутые в ней, не могут взаимодействовать за пределами этой границы, если они явно не настроены на это. Чтобы минимизировать затраты на обслуживание, можно выбрать одну субъект-службу / управляемое удостоверение для среды, используемой всеми контейнерными приложениями.

VNet-интеграция и размеры подсети

Решение — использовать имеющуюся VNet с дополнительными подсетями или создать новую VNet зависит от доступных вам VNet-пространства и IP-адреса. Если вы можете использовать для среды имеющуюся VNet с дополнительной(ыми) подсетью(ями), переход пройдет гораздо более гладко.

Доступ

• Если вам нужно, чтобы приложение было доступно в Интернете, выберите «Принимать трафик из любого места».
• Если вы хотите, чтобы ваше приложение было доступно только через VNet, выберите «ограничить до VNet». Это ограничит доступ к VNet среды контейнерных приложений.
• Если вы не хотите, чтобы приложения были доступны за пределами среды контейнерных приложений, выберите «ограничить до среды контейнерных приложений».
• Кроме того, вы можете отключить любой доступ к вашим контейнерным приложениям.

Ревизии

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

DNS

Во все приложения, доступ к которым открыт через настройки, можно войти через конечную точку среды контейнерных приложений (unique_identifier.region_name.azurecontainerapps.io). Для этого нужно создать отдельную зону DNS, указать IP-адрес среды как конечную точку, а затем привязать эту зону DNS к другим подсетям/VNet для разрешения. Если вы используете пользовательский DNS, настройте переадресацию для разрешения FQDN с помощью отдельной зоны DNS.

Доступность

Чтобы минимизировать сбои в зонах, развертывайте каждое контейнерное приложение с минимум 3 репликами, которые будут распределены по 3 AZ.

Наблюдаемость / мониторинг

Среда контейнерных приложений может быть интегрирована с рабочей областью анализа журналов для отправки журналов. Эти журналы можно использовать для настройки оповещений и электронных писем на основе определенных условий.

Dapr

Dapr обеспечивает возможности сетки служб. Использовать ли его, зависит от ваших требований.

Секреты

Контейнерные приложения могут использовать секреты, находящиеся в хранилищах ключей. Используйте субъекты-службы / управляемые удостоверения для приложений и настройте соответствующие разрешения RBAC для хранилищ ключей, чтобы обеспечить интеграцию с хранилищем ключей.

Обслуживание

ACA — это полностью управляемый PaaS-сервис в Azure. Даже область управления контролируется Microsoft. Поэтому все расходы на обслуживание, такие как обновление узла OS и версии AKS, Microsoft берет на себя. Если вы используете специальные стратегии развертывания, например сине-зеленую, можно добиться практически полного отсутствия простоев в работе вашего приложения.

Особенности, связанные с затратами

• Счета за ACA выставляются на основе посекундного потребления ресурсов и запросов. Первые 1 80 000 vCPU-секунд, 3 60 000 GiB-секунд и 2 миллиона запросов в месяц предоставляются бесплатно. Далее вы платите за то, что используете, на посекундной основе, рассчитанной по количеству vCPU и GiB, потребляемых вашими приложениями.
• Также для каждой среды предоставляется один стандартный балансировщик нагрузки, стоимость которого составляет 0,025 долл./ч за первые 5 правил (мы будем использовать только 2 правила на один балансировщик), а плата за обработку данных — 0,005 долл./ГБ.

Выводы

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