Сьогодні ми поговоримо про те, про що майже всі чули, але ніхто не може пояснити, кубанітаз. Це заплутано, тому що він вирішує проблему, яку більшість людей не бачить, поки з нею не зіткнеться. Усі знають, що це важливо, але запитайте, для чого він, і у відповідь отримаєте лише подив. Це не заміна дока і не хмарна операційна система, хоча люди часто так думають. Така плутанина зрозуміла, бо кубанітаз вирішує проблему, про існування якої ви не знаєте, доки не зустрінетеся з нею. Це інструмент, який стає необхідним, щойно у вас з'являється більше, ніж кілька контейнерів для керування. Наприкінці цього епізоду ви зрозумієте, що таке кубанітаз насправді, як він працює з контейнерами, та чому ажур кубанітаз сервіс робить його практичним для команд, які не хочуть створювати все з нуля. Беріть каву і починаємо. Проблема до появи контейнерів. Повернімося до цієї проблеми. Уявіть собі софтверну компанію 10 років тому.

У вас є кілька застосунків, тому ви купуєте сервери, встановлюєте операційні системи та розгортаєте все вручну. Кожен застосунк отримує власну машину, і ви не можете ділити ресурси між ними. Якщо одному застосунку потрібно багато пам'яті, а інший майже нічого не споживає, вони все одно отримують кожен свій сервер. Марнотратство було величезним. Сервери працювали на 20% потужності, але їх не можна було об'єднати, бо застосунки конфліктували через залежності. Ви отримували кімнату повну серверів, кожен з яких майже нічого не робив, споживав електроенергію, потребував охолодження та постійного обслуговування. Один застосунок потребує Python 3.7, іншому потрібен Python 3.8. Один потребує стару бібліотеку, інший – найновішу. Ви не можете запустити їх на одній машині, нічого не зламавши, тому купуєте більше серверів і платите за обладнання, яке здебільшого простоює. Віртуальні машини трохи допомогли, дозволивши розбити фізичний сервер на менші частини, кожна з яких запускала власну ОС, але кожна ВМ – це важка система з повноцінною ОС, що займає місце на диску, пам'ять і потребує хвилин на запуск.

І вам доводилося налаштовувати кожну окремо, що вимагало багато зусиль. Ви все ще керуєте всіма цими операційними системами, оновлюєте їх і дбаєте про безпеку. Командам потрібно було щось легше та мобільніше, спосіб запакувати застосунок з усім необхідним для запуску безнакладних витрат повної віртуальної машини, який можна легко переносити між пристроями. Саме тут з'явилися контейнери. Що таке контейнери насправді? Контейнер – це невеликий пакет, який включає ваш застосунок і все, що потрібно для його роботи. Це означає, що код «Середовище виконання», «Бібліотеки» та «Конфігураційні файли» зібрані разом в одну одиницю. Уявіть це як вантажний контейнер для програмного забезпечення. Транспортний контейнер можна вести вантажівкою, потягом чи кораблем, і сам контейнер при цьому залишається незмінним. Ваш програмний контейнер працює так само. Ви створюєте його один раз, і він однаково працює на вашому ноутбуці, тестовому сервері та в робочому середовищі.

Ключова відмінність між контейнерами та віртуальними машинами полягає в їхній ефективності. Віртуальна машина запускає власну повну операційну систему, тому кожна VM має власне ядро, системні файли та все інше. Контейнер використовує спільну операційну систему ГОСТа. Це лише процес із власним ізольованим баченням світу. Це означає, що контейнери запускаються за секунди, а не хвилини. Вони споживають менше пам'яті, і ви можете розмістити їх більше на одному комп'ютері. Дока зробив контейнери популярними, надавши розробникам простий спосіб створювати та запускати їх однією командою. Раптом проблема на моєму комп'ютері працює, почала зникати. Якщо ваш додаток працює в контейнері на ноутбуці, він так само працюватиме і на сервері. Середовище є стабільним усюди. Але контейнери вирішують одну проблему і створюють іншу. З кількома контейнерами ручне керування працює добре. Ви можете запускати їх, зупиняти та відстежувати самостійно.

Але що станеться, коли їх будуть сотні? Вам потрібно вирішити, який сервер запускає який контейнер, перезапускати збої, з'єднувати їх між собою та масштабувати при сплесках трафіку. Це новий виклик, і саме тут на допомогу приходить Кубанітас. Проблема оркестрації. Отже, у вас працюють контейнери, ви запакували додаток, він стабільно працює всюди і життя прекрасне. Але лише на деякий час. З 10 або 20 контейнерами ви можете керувати процесами вручну. Ви знаєте, який сервер запускає який контейнер, можете перезапустити щось у разі збою та оновити окремі компоненти. Це керовано. Але потім ваш додаток зростає. Ви переходите на мікросервіси, тож замість одного великого додатка у вас 20 менших. Кожному потрібно кілька копій для надійності, і тепер у вас уже 200 контейнерів. Ручне керування більше не працює. Вам потрібно вирішувати, який сервер запускає кожен контейнер, перезапускати їх у разі збою та з'єднувати для комунікації.

Також потрібно масштабувати систему при сплесках трафіку, наприклад, під час розпродажу чи запуску продукту, і зменшувати, коли навантаження падає. І вам потрібно впроваджувати оновлення без простоїв, Тобто замінювати старі контейнери на нові по черзі, обережно, нічого не ламаючи. Це проблеми оркестрації, і саме для їх вирішення було створено Кубанітаз. Кубанітаз – це платформа з відкритим кодом, що автоматизує розгортання, масштабування та керування контейнеризованими програмами. Уявіть це як операційну систему для вашого дата-центру. Подібно до того, як Windows або Linux керують ресурсами одного комп'ютера, як от процесором, пам'яттю та диском, Кубанітаз керує ресурсами на всіх ваших серверах. Він розглядає всі ваші машини як один великий пол обчислювальної потужності. Ви кажете йому, що хочете запустити, а він визначає, куди це розмістити, як підтримувати роботу та як під'єднати до решти системи.

Основні поняття – поди, ноди та кластери. Розгляньмо, як насправді працює Кубанітаз. Найменша одиниця в Кубанітаз називається под. Под містить один або кілька контейнерів. Контейнери в одному поді спільно використовують сховище та мережу, тому вони можуть спілкуватися через Localhost. Ви можете сприймати под як єдину одиницю розгортання. Ви не розгортаєте контейнери безпосередньо в Кубанітаз. Ви розгортаєте поди. Поди не працюють самі по собі, вони запускаються на нодах. Нода – це фізичний або віртуальний сервер, що є частиною вашого кластера Кубанітаз. Кожна нода запускає програмне забезпечення, необхідне для роботи подів, а також дещо інше, про що ми згадаємо згодом. Кластер – це сукупність усіх нод, якими керують як єдиною системою. Простими словами, под – це ваша програма, нода – місце, де вона працює, а кластер – все середовище загалом. Поди є ефемерними. Їх можна створювати, видаляти або переміщувати в будь-який момент.

Це закладено в архітектурі. Якщо нода виходить з ладу, Кубанітаз переміщує поди на іншу. Для масштабування він створює нові поди. А коли под завершується помилкою, він автоматично замінюється. Уся система розглядає поди як тимчасові об'єкти. Але якщо поди постійно з'являються і зникають, вам потрібен спосіб взаємодії з ними. Замість того, щоб звертатися до пода напряму, ви звертаєтеся до сервісу. Сервіс надає стабільну мережеву адресу, яка спрямовує трафік до потрібних подів, навіть якщо вони змінюються. Уявіть готель. Номер телефону готелю – це сервіс. Гості в номерах постійно змінюються, але номер телефону залишається незмінним. Ви дзвоните на стійку реєстрації, і вас перемикають на потрібний номер. Саме це робить сервіс у Кубанітаз.

Виникає питання, хто вирішує, що іде запускати. Це завдання для Control Plane. Він є в кожному кластері Кубанітаз, і це мозок усієї системи. Саме тут ухвалюються всі рішення. Control Plane складається з кількох компонентів. Перший із них – це ARRI сервер, який слугує входом до вашого кластера. Будь-яка команда, яку ви надсилаєте в Кубанітаз, чи то з командного рядка, через дашборд або автоматизований скрипт, проходить через ARRI сервер. Він автентифікує ваш запит, перевіряє, чи маєте ви дозвіл на ці дії, а потім передає його за призначенням. У Кубанітаз нічого не відбувається без попереднього проходження через ARRI сервер. Далі йде планувальник Schedule, який вирішує, на якому вузлі запускати кожен под. Коли ви кажете «Я хочу, щоб цей застосунок працював», планувальник переглядає всі доступні вузли, перевіряє ресурси, як от CPU, пам'ять і місце на диску, та обирає найкращий для цього завдання.

Це схоже на готельєра, який розподіляє номери залежно від потреб кожного гостя. Гість із великою кількістю багажу отримує більший номер, тоді як легкий застосунок, менший вузол із вільними ресурсами. Потім є Controller Manager, Controller Manager. Цей компонент стежить за кластером і переконується, що фактичний стан відповідає оголошеному вами. Ви сказали, що хочете запустити три копії свого веб-застосунку. Controller Manager перевіряє, чи дійсно працюють три копії. Якщо одна з них виходить із ладу, він помічається і запускає заміну. Якщо хтось випадково видаляє под, він створює новий. Це компонент, який підтримує ваш кластер у належному стані. І, нарешті, є Ed – база даних кластера. Вона зберігає все, що запущено, де воно працює і як налаштовано. Це єдине джерело істини для всього кластера. Якщо Arie Server – це вхідні двері, то Ed – це картотека в офісі, де зберігаються всі записи. Краса цього дизайну в тому, що ви описуєте бажаний стан, а Кубанітас сам вирішує, як його реалізувати.

Ви не кажете йому, як робити справи, ви кажете, як має виглядати кінцевий результат. Це декларативна модель і це основна ідея всього, що робить Кубанітас. Робочі навантаження, розгортання, сервіси та масштабування. Отже, давайте поговоримо про те, як запускати застосунки в Кубанітас. Ви не будете створювати поди безпосередньо. Натомість ви використовуватимете об'єкт вищого рівня, який називається deployment. Уявіть deployment як менеджера, який каже Кубанітас, скільки копій вашого пода має працювати, який образ контейнера використовувати і як оновлювати їх з виходом нової версії. Це стандартний спосіб запуску безстанних стейтлас застосунків. Коли ви оновлюєте deployment, скажімо, викладаєте нову версію застосунку, Кубанітас виконує плавне оновлення rolling update. Він замінює поди один за одним, гарантуючи, що принаймні одна копія завжди працює. Це означає відсутність простоїв і раптових перерв для ваших користувачів.

А якщо щось піде не так з новою версією, ви можете відкотитися до попередньої однією командою. Це потужна запобіжна мережа. Але ваші поди все одно повинні бути доступними. Ось тут на допомогу приходять сервіси. Сервіс надає стабільну мережеву адресу, яка спрямовує трафік на потрібні поди. Він також може відкривати ці поди для інших частин вашого застосунку або для зовнішнього світу. Сервіс може бути внутрішнім, доступним лише в межах кластера або зовнішнім, з публічною IP-адресою, до якої користувачі можуть звернутися з інтернету. Тепер щодо масштабування. Кубанітаз може автоматично збільшувати та зменшувати ваш застосунок залежно від попиту. Ви встановлюєте ціль, скажімо, 70% використання процесора, і Кубанітаз додає поди, коли навантаження перевищує поріг і видаляє їх, коли воно падає. Ваш застосунок масштабується під час піків трафіку і зменшується, коли активність спадає. Ручне втручання не потрібне, але вся ця потужність приходить зі складністю.

Керування власним кластером Кубанітаз означає, що ви відповідаєте за панель керування, Ви відповідаєте за все панель керування, оновлення, патчі безпеки та резервні копії. Вам потрібні глибокі знання для вирішення проблем з відмовами вузлів, налаштуванням мережі та масштабуванням кластера. Багато команд витрачають більше часу на керування кластером, ніж на розробку застосунків. І саме тут з'являється керований Кубанітаз. Самокерований проти керованого Кубанітаз. Отже, давайте поговоримо про реальність самостійного запуску Кубанітаз. Коли ви створюєте власний кластер, ви відповідаєте за все панель керування, оновлення, патчі безпеки та резервні копії ІТІСІДІ. Якщо АРІС-сервер виходить з ладу, це ваша проблема. Якщо у версії, яку ви використовуєте, виявлено вразливість, вам потрібно її виправити. Якщо ІТІСІД пошкоджено, вам потрібно відновити дані з резервної копії. Все це вимагає глибокої експертизи.

Ви повинні розуміти, як виходять з ладу вузли, як працює мережа на рівні кластера і як масштабувати ресурси, не ламаючи систему. Ось що дивує багато команд. Багато організацій витрачають більше часу на керування кластером Кубанітаз, ніж на створення застосунків, що в ньому працюють. Вони постійно борються з оновленнями, усуненням мережевих проблем і відмовами вузлів. Кластер стає роботою на повний день. Це не те, заради чого ви впроваджували Кубанітаз. Саме тут на допомогу приходять керовані сервіси Кубанітаз.

Ви платите лише за робочі вузли, віртуальні машини, на яких безпосередньо працюють ваші навантаження. Панель керування є безкоштовною. Це кардинально змінює ситуацію. Замість того, щоб витрачати час на обслуговування кластера, ваша команда може зосередитися на головному додатках, які ви створюєте. Для більшості команд, особливо тих, хто тільки починає керований Кубанітаз, це правильний вибір. Ви отримуєте всю потужність Кубанітаз без операційних витрат на підтримку. AKS – це Кубанітаз, спрощений для Azure. Тож, що саме таке AKS? Це керований сервіс Кубанітаз Azure, який надає повнофункціональний кластер без необхідності створювати його з нуля. Панель керування безкоштовна, як ми вже згадували, тому ви платите лише за віртуальні машини, на яких працюють ваші навантаження. Це означає, що ви можете почати з малого, платити небагато і масштабуватися в міру зростання потреб. Azure бере на себе всю найскладнішу роботу.

Оновлення, виправлення та моніторинг стану панелі керування – все це вже враховано. Вам не потрібна окрема команда експертів з Кубанітаз лише для того, щоб усе працювало. А оскільки AKS є частиною екосистеми Azure, він інтегрується з інструментами, які ви, ймовірно, вже використовуєте. Azure Active Directory для автентифікації, Azure Monitor для журналів і метрик, а також Azure Policy для керування. Вони всі працюють разом з коробки. Жодних окремих складних налаштувань. Налаштування CI, CD-конвайерів за допомогою GitHub Actions або Azure DevOps займає всього кілька хвилин. Зробіть пуш-змін у свій репозиторі, і система автоматично створить новий образ контейнера, відправить його в Azure Container, registry та оновить розгортання в AKS. Жодних ручних дій чи підключення через SSH до серверів. Усе автоматизовано. Для початківців існує автоматичний режим AKS, створений для команд, які не хочуть ухвалювати кожне рішення щодо конфігурації кластера.

Він надає готові налаштування за замовчуванням для масштабування, мережі, безпеки та оновлень. Вам не потрібно бути експертом із Кубанітаз, щоб почати роботу. Просто опишіть свій додаток, а AKS подбає про все інше. Одна команда створює кластер, один файл маніфесту запускає ваш додаток. Навички, отримані в AKS, можна застосувати до будь-якого середовища Кубанітаз, оскільки в основі лежить стандартний Кубанітаз. Ви вивчаєте не пропріетарну систему, а справжню технологію, тоді як Azure бере на себе операційну складність. Отже, тепер ви маєте загальне уявлення. Контейнери пакують ваші додатки так, щоб вони працювали стабільно всюди, а Кубанітаз керує цими контейнерами в масштабі, автоматизуючи розгортання, масштабування та відновлення. AKS робить це керування зручним, беручи на себе турботу про панель керування та інтегруючись із інструментами Azure, які ви вже знаєте. Головна ідея в тому, що Кубанітаз – це не лише для великих технологічних компаній із величезними інженерними командами.

Завдяки керованим сервісам, як от AKS, він доступний будь-якій команді. Ваше домашнє завдання на цей тиждень просте. Створіть безкоштовний обліковий запис Azure, запустіть кластер AKS і розгорніть просту програму. Це займе хвилини, і ви побачите, наскільки розвинулася ця платформа. Готові заглибитися більше. У наступному епізоді ми розберемо, як створити перший образ контейнера та надіслати його до Azure Container Registry. Підписуйтесь на улюбленій подкаст-платформі та поділіться цим із тими, хто тільки починає свій шлях у Кубанітаз.