Переход с Azure Kubernetes Service на Container Apps: рекомендации и особенности
Автор статьи — EPAM Systems Architect Рамешвар Баноре.
Введение
«Рамешвар, это уже второй раз, когда у нас возникли проблемы с обновлением кластера и почти случился простой приложения. Мы живем в эпоху облака, и мне не очень приятно слышать, что у нас могут возникнуть вопросы с приложением из-за проблем с обновлением кластера 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 предлагает интересную альтернативу для снижения операционной сложности, а также преимущества ориентированной на облако контейнерной среды. Поскольку облачный ландшафт продолжает развиваться, эти рекомендации закладывают основу для уверенного и гибкого подхода к использованию оркестрации контейнеров в будущем.