Перехід з 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 пропонує цікаву альтернативу для зниження операційної складності, а також переваги орієнтованого на хмару контейнерного середовища. Оскільки хмарний ландшафт продовжує розвиватися, ці рекомендації закладають основу для впевненого й гнучкого підходу до використання оркестрації контейнерів у майбутньому.