WEBVTT

00:00:00.180 --> 00:00:04.360
Сьогодні ми поговоримо про те, про що майже всі чули, але ніхто не може пояснити, кубанітаз.

00:00:04.460 --> 00:00:08.300
Це заплутано, тому що він вирішує проблему, яку більшість людей не бачить, поки з нею не зіткнеться.

00:00:08.420 --> 00:00:12.020
Усі знають, що це важливо, але запитайте, для чого він, і у відповідь отримаєте лише подив.

00:00:12.160 --> 00:00:15.760
Це не заміна дока і не хмарна операційна система, хоча люди часто так думають.

00:00:15.860 --> 00:00:20.540
Така плутанина зрозуміла, бо кубанітаз вирішує проблему, про існування якої ви не знаєте, доки не зустрінетеся з нею.

00:00:20.540 --> 00:00:24.820
Це інструмент, який стає необхідним, щойно у вас з'являється більше, ніж кілька контейнерів для керування.

00:00:24.980 --> 00:00:29.740
Наприкінці цього епізоду ви зрозумієте, що таке кубанітаз насправді, як він працює з контейнерами,

00:00:29.800 --> 00:00:34.540
та чому ажур кубанітаз сервіс робить його практичним для команд, які не хочуть створювати все з нуля.

00:00:34.700 --> 00:00:36.140
Беріть каву і починаємо.

00:00:36.320 --> 00:00:37.980
Проблема до появи контейнерів.

00:00:38.180 --> 00:00:39.660
Повернімося до цієї проблеми.

00:00:39.760 --> 00:00:41.900
Уявіть собі софтверну компанію 10 років тому.

00:00:41.900 --> 00:00:46.600
У вас є кілька застосунків, тому ви купуєте сервери, встановлюєте операційні системи та розгортаєте все вручну.

00:00:46.720 --> 00:00:49.980
Кожен застосунк отримує власну машину, і ви не можете ділити ресурси між ними.

00:00:50.160 --> 00:00:54.800
Якщо одному застосунку потрібно багато пам'яті, а інший майже нічого не споживає, вони все одно отримують кожен свій сервер.

00:00:55.100 --> 00:00:56.420
Марнотратство було величезним.

00:00:56.620 --> 00:01:02.480
Сервери працювали на 20% потужності, але їх не можна було об'єднати, бо застосунки конфліктували через залежності.

00:01:02.480 --> 00:01:09.200
Ви отримували кімнату повну серверів, кожен з яких майже нічого не робив, споживав електроенергію, потребував охолодження та постійного обслуговування.

00:01:09.340 --> 00:01:12.500
Один застосунок потребує Python 3.7, іншому потрібен Python 3.8.

00:01:12.700 --> 00:01:14.960
Один потребує стару бібліотеку, інший – найновішу.

00:01:15.080 --> 00:01:20.400
Ви не можете запустити їх на одній машині, нічого не зламавши, тому купуєте більше серверів і платите за обладнання, яке здебільшого простоює.

00:01:20.400 --> 00:01:30.540
Віртуальні машини трохи допомогли, дозволивши розбити фізичний сервер на менші частини, кожна з яких запускала власну ОС, але кожна ВМ – це важка система з повноцінною ОС, що займає місце на диску, пам'ять і потребує хвилин на запуск.

00:01:30.660 --> 00:01:33.940
І вам доводилося налаштовувати кожну окремо, що вимагало багато зусиль.

00:01:34.080 --> 00:01:38.540
Ви все ще керуєте всіма цими операційними системами, оновлюєте їх і дбаєте про безпеку.

00:01:38.540 --> 00:01:47.940
Командам потрібно було щось легше та мобільніше, спосіб запакувати застосунок з усім необхідним для запуску безнакладних витрат повної віртуальної машини, який можна легко переносити між пристроями.

00:01:48.160 --> 00:01:49.800
Саме тут з'явилися контейнери.

00:01:50.040 --> 00:01:51.600
Що таке контейнери насправді?

00:01:51.720 --> 00:01:56.000
Контейнер – це невеликий пакет, який включає ваш застосунок і все, що потрібно для його роботи.

00:01:56.120 --> 00:02:00.760
Це означає, що код «Середовище виконання», «Бібліотеки» та «Конфігураційні файли» зібрані разом в одну одиницю.

00:02:00.760 --> 00:02:03.500
Уявіть це як вантажний контейнер для програмного забезпечення.

00:02:03.660 --> 00:02:08.500
Транспортний контейнер можна вести вантажівкою, потягом чи кораблем, і сам контейнер при цьому залишається незмінним.

00:02:08.680 --> 00:02:10.640
Ваш програмний контейнер працює так само.

00:02:10.840 --> 00:02:15.580
Ви створюєте його один раз, і він однаково працює на вашому ноутбуці, тестовому сервері та в робочому середовищі.

00:02:15.720 --> 00:02:19.400
Ключова відмінність між контейнерами та віртуальними машинами полягає в їхній ефективності.

00:02:19.400 --> 00:02:24.740
Віртуальна машина запускає власну повну операційну систему, тому кожна VM має власне ядро, системні файли та все інше.

00:02:24.880 --> 00:02:27.480
Контейнер використовує спільну операційну систему ГОСТа.

00:02:27.580 --> 00:02:30.120
Це лише процес із власним ізольованим баченням світу.

00:02:30.280 --> 00:02:33.240
Це означає, що контейнери запускаються за секунди, а не хвилини.

00:02:33.380 --> 00:02:36.900
Вони споживають менше пам'яті, і ви можете розмістити їх більше на одному комп'ютері.

00:02:37.040 --> 00:02:42.100
Дока зробив контейнери популярними, надавши розробникам простий спосіб створювати та запускати їх однією командою.

00:02:42.100 --> 00:02:45.400
Раптом проблема на моєму комп'ютері працює, почала зникати.

00:02:45.580 --> 00:02:49.640
Якщо ваш додаток працює в контейнері на ноутбуці, він так само працюватиме і на сервері.

00:02:49.900 --> 00:02:51.540
Середовище є стабільним усюди.

00:02:51.660 --> 00:02:54.440
Але контейнери вирішують одну проблему і створюють іншу.

00:02:54.580 --> 00:02:57.180
З кількома контейнерами ручне керування працює добре.

00:02:57.300 --> 00:03:00.100
Ви можете запускати їх, зупиняти та відстежувати самостійно.

00:03:00.200 --> 00:03:02.120
Але що станеться, коли їх будуть сотні?

00:03:02.260 --> 00:03:05.560
Вам потрібно вирішити, який сервер запускає який контейнер, перезапускати збої,

00:03:05.560 --> 00:03:08.140
з'єднувати їх між собою та масштабувати при сплесках трафіку.

00:03:08.300 --> 00:03:11.160
Це новий виклик, і саме тут на допомогу приходить Кубанітас.

00:03:11.340 --> 00:03:12.560
Проблема оркестрації.

00:03:12.760 --> 00:03:17.140
Отже, у вас працюють контейнери, ви запакували додаток, він стабільно працює всюди і життя прекрасне.

00:03:17.260 --> 00:03:18.460
Але лише на деякий час.

00:03:18.660 --> 00:03:21.540
З 10 або 20 контейнерами ви можете керувати процесами вручну.

00:03:21.700 --> 00:03:23.740
Ви знаєте, який сервер запускає який контейнер,

00:03:23.860 --> 00:03:26.720
можете перезапустити щось у разі збою та оновити окремі компоненти.

00:03:26.900 --> 00:03:27.700
Це керовано.

00:03:27.700 --> 00:03:29.500
Але потім ваш додаток зростає.

00:03:29.500 --> 00:03:34.420
Ви переходите на мікросервіси, тож замість одного великого додатка у вас 20 менших.

00:03:34.580 --> 00:03:38.780
Кожному потрібно кілька копій для надійності, і тепер у вас уже 200 контейнерів.

00:03:38.940 --> 00:03:40.780
Ручне керування більше не працює.

00:03:40.960 --> 00:03:43.740
Вам потрібно вирішувати, який сервер запускає кожен контейнер,

00:03:43.860 --> 00:03:46.640
перезапускати їх у разі збою та з'єднувати для комунікації.

00:03:46.800 --> 00:03:49.240
Також потрібно масштабувати систему при сплесках трафіку,

00:03:49.240 --> 00:03:53.380
наприклад, під час розпродажу чи запуску продукту, і зменшувати, коли навантаження падає.

00:03:53.540 --> 00:03:56.180
І вам потрібно впроваджувати оновлення без простоїв,

00:03:56.180 --> 00:04:00.460
Тобто замінювати старі контейнери на нові по черзі, обережно, нічого не ламаючи.

00:04:00.620 --> 00:04:04.480
Це проблеми оркестрації, і саме для їх вирішення було створено Кубанітаз.

00:04:04.620 --> 00:04:07.660
Кубанітаз – це платформа з відкритим кодом, що автоматизує розгортання,

00:04:07.800 --> 00:04:10.020
масштабування та керування контейнеризованими програмами.

00:04:10.180 --> 00:04:12.820
Уявіть це як операційну систему для вашого дата-центру.

00:04:12.980 --> 00:04:16.220
Подібно до того, як Windows або Linux керують ресурсами одного комп'ютера,

00:04:16.220 --> 00:04:20.340
як от процесором, пам'яттю та диском, Кубанітаз керує ресурсами на всіх ваших серверах.

00:04:20.340 --> 00:04:23.860
Він розглядає всі ваші машини як один великий пол обчислювальної потужності.

00:04:24.020 --> 00:04:27.180
Ви кажете йому, що хочете запустити, а він визначає, куди це розмістити,

00:04:27.320 --> 00:04:29.680
як підтримувати роботу та як під'єднати до решти системи.

00:04:29.760 --> 00:04:32.100
Основні поняття – поди, ноди та кластери.

00:04:32.340 --> 00:04:34.520
Розгляньмо, як насправді працює Кубанітаз.

00:04:34.660 --> 00:04:36.960
Найменша одиниця в Кубанітаз називається под.

00:04:37.060 --> 00:04:38.980
Под містить один або кілька контейнерів.

00:04:38.980 --> 00:04:41.460
Контейнери в одному поді спільно використовують сховище та мережу,

00:04:41.500 --> 00:04:43.360
тому вони можуть спілкуватися через Localhost.

00:04:43.540 --> 00:04:45.920
Ви можете сприймати под як єдину одиницю розгортання.

00:04:46.080 --> 00:04:48.360
Ви не розгортаєте контейнери безпосередньо в Кубанітаз.

00:04:48.500 --> 00:04:49.620
Ви розгортаєте поди.

00:04:49.760 --> 00:04:52.220
Поди не працюють самі по собі, вони запускаються на нодах.

00:04:52.360 --> 00:04:56.080
Нода – це фізичний або віртуальний сервер, що є частиною вашого кластера Кубанітаз.

00:04:56.220 --> 00:04:58.780
Кожна нода запускає програмне забезпечення, необхідне для роботи подів,

00:04:58.840 --> 00:05:00.560
а також дещо інше, про що ми згадаємо згодом.

00:05:00.560 --> 00:05:03.980
Кластер – це сукупність усіх нод, якими керують як єдиною системою.

00:05:03.980 --> 00:05:07.520
Простими словами, под – це ваша програма, нода – місце, де вона працює,

00:05:07.600 --> 00:05:09.220
а кластер – все середовище загалом.

00:05:09.360 --> 00:05:10.420
Поди є ефемерними.

00:05:10.600 --> 00:05:12.700
Їх можна створювати, видаляти або переміщувати в будь-який момент.

00:05:12.880 --> 00:05:14.020
Це закладено в архітектурі.

00:05:14.160 --> 00:05:16.400
Якщо нода виходить з ладу, Кубанітаз переміщує поди на іншу.

00:05:16.540 --> 00:05:18.220
Для масштабування він створює нові поди.

00:05:18.320 --> 00:05:20.860
А коли под завершується помилкою, він автоматично замінюється.

00:05:20.860 --> 00:05:23.080
Уся система розглядає поди як тимчасові об'єкти.

00:05:23.080 --> 00:05:25.840
Але якщо поди постійно з'являються і зникають, вам потрібен спосіб взаємодії з ними.

00:05:26.000 --> 00:05:28.740
Замість того, щоб звертатися до пода напряму, ви звертаєтеся до сервісу.

00:05:28.880 --> 00:05:33.180
Сервіс надає стабільну мережеву адресу, яка спрямовує трафік до потрібних подів, навіть якщо вони змінюються.

00:05:33.340 --> 00:05:34.200
Уявіть готель.

00:05:34.380 --> 00:05:36.040
Номер телефону готелю – це сервіс.

00:05:36.220 --> 00:05:39.220
Гості в номерах постійно змінюються, але номер телефону залишається незмінним.

00:05:39.220 --> 00:05:42.200
Ви дзвоните на стійку реєстрації, і вас перемикають на потрібний номер.

00:05:42.320 --> 00:05:44.140
Саме це робить сервіс у Кубанітаз.

00:05:53.080 --> 00:05:55.920
Виникає питання, хто вирішує, що іде запускати.

00:05:56.080 --> 00:05:57.540
Це завдання для Control Plane.

00:05:57.720 --> 00:06:00.520
Він є в кожному кластері Кубанітаз, і це мозок усієї системи.

00:06:00.680 --> 00:06:02.220
Саме тут ухвалюються всі рішення.

00:06:02.380 --> 00:06:04.380
Control Plane складається з кількох компонентів.

00:06:04.540 --> 00:06:07.400
Перший із них – це ARRI сервер, який слугує входом до вашого кластера.

00:06:07.400 --> 00:06:13.660
Будь-яка команда, яку ви надсилаєте в Кубанітаз, чи то з командного рядка, через дашборд або автоматизований скрипт, проходить через ARRI сервер.

00:06:13.660 --> 00:06:18.780
Він автентифікує ваш запит, перевіряє, чи маєте ви дозвіл на ці дії, а потім передає його за призначенням.

00:06:18.860 --> 00:06:22.440
У Кубанітаз нічого не відбувається без попереднього проходження через ARRI сервер.

00:06:22.580 --> 00:06:26.240
Далі йде планувальник Schedule, який вирішує, на якому вузлі запускати кожен под.

00:06:26.240 --> 00:06:35.220
Коли ви кажете «Я хочу, щоб цей застосунок працював», планувальник переглядає всі доступні вузли, перевіряє ресурси, як от CPU, пам'ять і місце на диску, та обирає найкращий для цього завдання.

00:06:35.220 --> 00:06:38.820
Це схоже на готельєра, який розподіляє номери залежно від потреб кожного гостя.

00:06:39.000 --> 00:06:43.760
Гість із великою кількістю багажу отримує більший номер, тоді як легкий застосунок, менший вузол із вільними ресурсами.

00:06:43.880 --> 00:06:45.840
Потім є Controller Manager, Controller Manager.

00:06:45.840 --> 00:06:49.820
Цей компонент стежить за кластером і переконується, що фактичний стан відповідає оголошеному вами.

00:06:49.980 --> 00:06:52.700
Ви сказали, що хочете запустити три копії свого веб-застосунку.

00:06:52.860 --> 00:06:55.580
Controller Manager перевіряє, чи дійсно працюють три копії.

00:06:55.740 --> 00:06:58.740
Якщо одна з них виходить із ладу, він помічається і запускає заміну.

00:06:58.740 --> 00:07:01.500
Якщо хтось випадково видаляє под, він створює новий.

00:07:01.640 --> 00:07:04.540
Це компонент, який підтримує ваш кластер у належному стані.

00:07:04.680 --> 00:07:07.180
І, нарешті, є Ed – база даних кластера.

00:07:07.180 --> 00:07:11.060
Вона зберігає все, що запущено, де воно працює і як налаштовано.

00:07:11.220 --> 00:07:13.640
Це єдине джерело істини для всього кластера.

00:07:13.820 --> 00:07:18.900
Якщо Arie Server – це вхідні двері, то Ed – це картотека в офісі, де зберігаються всі записи.

00:07:19.040 --> 00:07:23.580
Краса цього дизайну в тому, що ви описуєте бажаний стан, а Кубанітас сам вирішує, як його реалізувати.

00:07:23.580 --> 00:07:27.300
Ви не кажете йому, як робити справи, ви кажете, як має виглядати кінцевий результат.

00:07:27.500 --> 00:07:31.040
Це декларативна модель і це основна ідея всього, що робить Кубанітас.

00:07:31.180 --> 00:07:34.080
Робочі навантаження, розгортання, сервіси та масштабування.

00:07:34.240 --> 00:07:37.260
Отже, давайте поговоримо про те, як запускати застосунки в Кубанітас.

00:07:37.380 --> 00:07:39.180
Ви не будете створювати поди безпосередньо.

00:07:39.300 --> 00:07:42.200
Натомість ви використовуватимете об'єкт вищого рівня, який називається deployment.

00:07:42.440 --> 00:07:46.220
Уявіть deployment як менеджера, який каже Кубанітас, скільки копій вашого пода має працювати,

00:07:46.220 --> 00:07:49.680
який образ контейнера використовувати і як оновлювати їх з виходом нової версії.

00:07:49.820 --> 00:07:52.600
Це стандартний спосіб запуску безстанних стейтлас застосунків.

00:07:52.720 --> 00:07:55.500
Коли ви оновлюєте deployment, скажімо, викладаєте нову версію застосунку,

00:07:55.580 --> 00:07:57.540
Кубанітас виконує плавне оновлення rolling update.

00:07:57.740 --> 00:08:01.100
Він замінює поди один за одним, гарантуючи, що принаймні одна копія завжди працює.

00:08:01.260 --> 00:08:04.340
Це означає відсутність простоїв і раптових перерв для ваших користувачів.

00:08:04.460 --> 00:08:08.620
А якщо щось піде не так з новою версією, ви можете відкотитися до попередньої однією командою.

00:08:08.620 --> 00:08:10.280
Це потужна запобіжна мережа.

00:08:10.420 --> 00:08:12.440
Але ваші поди все одно повинні бути доступними.

00:08:12.540 --> 00:08:14.200
Ось тут на допомогу приходять сервіси.

00:08:14.360 --> 00:08:17.820
Сервіс надає стабільну мережеву адресу, яка спрямовує трафік на потрібні поди.

00:08:17.980 --> 00:08:22.340
Він також може відкривати ці поди для інших частин вашого застосунку або для зовнішнього світу.

00:08:22.560 --> 00:08:25.900
Сервіс може бути внутрішнім, доступним лише в межах кластера або зовнішнім,

00:08:25.960 --> 00:08:29.480
з публічною IP-адресою, до якої користувачі можуть звернутися з інтернету.

00:08:29.600 --> 00:08:30.960
Тепер щодо масштабування.

00:08:30.960 --> 00:08:34.900
Кубанітаз може автоматично збільшувати та зменшувати ваш застосунок залежно від попиту.

00:08:35.060 --> 00:08:38.060
Ви встановлюєте ціль, скажімо, 70% використання процесора,

00:08:38.180 --> 00:08:42.160
і Кубанітаз додає поди, коли навантаження перевищує поріг і видаляє їх, коли воно падає.

00:08:42.320 --> 00:08:46.360
Ваш застосунок масштабується під час піків трафіку і зменшується, коли активність спадає.

00:08:46.520 --> 00:08:50.160
Ручне втручання не потрібне, але вся ця потужність приходить зі складністю.

00:08:50.320 --> 00:08:53.700
Керування власним кластером Кубанітаз означає, що ви відповідаєте за панель керування,

00:08:53.700 --> 00:08:55.620
Ви відповідаєте за все панель керування, оновлення, патчі безпеки та резервні копії.

00:08:55.760 --> 00:08:58.340
Вам потрібні глибокі знання для вирішення проблем з відмовами вузлів,

00:08:58.460 --> 00:09:00.240
налаштуванням мережі та масштабуванням кластера.

00:09:00.400 --> 00:09:03.880
Багато команд витрачають більше часу на керування кластером, ніж на розробку застосунків.

00:09:04.000 --> 00:09:06.080
І саме тут з'являється керований Кубанітаз.

00:09:06.400 --> 00:09:08.300
Самокерований проти керованого Кубанітаз.

00:09:08.440 --> 00:09:11.500
Отже, давайте поговоримо про реальність самостійного запуску Кубанітаз.

00:09:11.500 --> 00:09:17.500
Коли ви створюєте власний кластер, ви відповідаєте за все панель керування, оновлення, патчі безпеки та резервні копії ІТІСІДІ.

00:09:17.640 --> 00:09:20.120
Якщо АРІС-сервер виходить з ладу, це ваша проблема.

00:09:20.340 --> 00:09:24.280
Якщо у версії, яку ви використовуєте, виявлено вразливість, вам потрібно її виправити.

00:09:24.460 --> 00:09:27.560
Якщо ІТІСІД пошкоджено, вам потрібно відновити дані з резервної копії.

00:09:27.720 --> 00:09:29.620
Все це вимагає глибокої експертизи.

00:09:29.620 --> 00:09:34.940
Ви повинні розуміти, як виходять з ладу вузли, як працює мережа на рівні кластера і як масштабувати ресурси, не ламаючи систему.

00:09:35.080 --> 00:09:36.560
Ось що дивує багато команд.

00:09:36.760 --> 00:09:42.140
Багато організацій витрачають більше часу на керування кластером Кубанітаз, ніж на створення застосунків, що в ньому працюють.

00:09:42.300 --> 00:09:46.260
Вони постійно борються з оновленнями, усуненням мережевих проблем і відмовами вузлів.

00:09:46.380 --> 00:09:48.180
Кластер стає роботою на повний день.

00:09:48.340 --> 00:09:50.680
Це не те, заради чого ви впроваджували Кубанітаз.

00:09:50.840 --> 00:09:53.380
Саме тут на допомогу приходять керовані сервіси Кубанітаз.

00:09:59.620 --> 00:10:08.340
Ви платите лише за робочі вузли, віртуальні машини, на яких безпосередньо працюють ваші навантаження.

00:10:08.460 --> 00:10:10.080
Панель керування є безкоштовною.

00:10:10.240 --> 00:10:11.940
Це кардинально змінює ситуацію.

00:10:12.120 --> 00:10:17.540
Замість того, щоб витрачати час на обслуговування кластера, ваша команда може зосередитися на головному додатках, які ви створюєте.

00:10:17.700 --> 00:10:21.660
Для більшості команд, особливо тих, хто тільки починає керований Кубанітаз, це правильний вибір.

00:10:21.660 --> 00:10:25.120
Ви отримуєте всю потужність Кубанітаз без операційних витрат на підтримку.

00:10:25.120 --> 00:10:27.560
AKS – це Кубанітаз, спрощений для Azure.

00:10:27.740 --> 00:10:29.220
Тож, що саме таке AKS?

00:10:29.340 --> 00:10:34.200
Це керований сервіс Кубанітаз Azure, який надає повнофункціональний кластер без необхідності створювати його з нуля.

00:10:34.360 --> 00:10:39.120
Панель керування безкоштовна, як ми вже згадували, тому ви платите лише за віртуальні машини, на яких працюють ваші навантаження.

00:10:39.280 --> 00:10:43.380
Це означає, що ви можете почати з малого, платити небагато і масштабуватися в міру зростання потреб.

00:10:43.380 --> 00:10:45.700
Azure бере на себе всю найскладнішу роботу.

00:10:45.860 --> 00:10:49.760
Оновлення, виправлення та моніторинг стану панелі керування – все це вже враховано.

00:10:49.760 --> 00:10:53.680
Вам не потрібна окрема команда експертів з Кубанітаз лише для того, щоб усе працювало.

00:10:53.840 --> 00:10:59.480
А оскільки AKS є частиною екосистеми Azure, він інтегрується з інструментами, які ви, ймовірно, вже використовуєте.

00:10:59.640 --> 00:11:05.460
Azure Active Directory для автентифікації, Azure Monitor для журналів і метрик, а також Azure Policy для керування.

00:11:05.660 --> 00:11:07.520
Вони всі працюють разом з коробки.

00:11:07.520 --> 00:11:09.500
Жодних окремих складних налаштувань.

00:11:09.620 --> 00:11:14.300
Налаштування CI, CD-конвайерів за допомогою GitHub Actions або Azure DevOps займає всього кілька хвилин.

00:11:14.300 --> 00:11:21.360
Зробіть пуш-змін у свій репозиторі, і система автоматично створить новий образ контейнера, відправить його в Azure Container, registry та оновить розгортання в AKS.

00:11:21.520 --> 00:11:24.320
Жодних ручних дій чи підключення через SSH до серверів.

00:11:24.460 --> 00:11:25.640
Усе автоматизовано.

00:11:25.800 --> 00:11:31.440
Для початківців існує автоматичний режим AKS, створений для команд, які не хочуть ухвалювати кожне рішення щодо конфігурації кластера.

00:11:31.440 --> 00:11:35.380
Він надає готові налаштування за замовчуванням для масштабування, мережі, безпеки та оновлень.

00:11:35.540 --> 00:11:38.260
Вам не потрібно бути експертом із Кубанітаз, щоб почати роботу.

00:11:38.260 --> 00:11:41.160
Просто опишіть свій додаток, а AKS подбає про все інше.

00:11:41.300 --> 00:11:44.780
Одна команда створює кластер, один файл маніфесту запускає ваш додаток.

00:11:44.920 --> 00:11:50.080
Навички, отримані в AKS, можна застосувати до будь-якого середовища Кубанітаз, оскільки в основі лежить стандартний Кубанітаз.

00:11:50.220 --> 00:11:55.740
Ви вивчаєте не пропріетарну систему, а справжню технологію, тоді як Azure бере на себе операційну складність.

00:11:55.860 --> 00:11:57.980
Отже, тепер ви маєте загальне уявлення.

00:11:58.140 --> 00:12:01.640
Контейнери пакують ваші додатки так, щоб вони працювали стабільно всюди,

00:12:01.640 --> 00:12:07.080
а Кубанітаз керує цими контейнерами в масштабі, автоматизуючи розгортання, масштабування та відновлення.

00:12:07.220 --> 00:12:13.320
AKS робить це керування зручним, беручи на себе турботу про панель керування та інтегруючись із інструментами Azure, які ви вже знаєте.

00:12:13.480 --> 00:12:18.060
Головна ідея в тому, що Кубанітаз – це не лише для великих технологічних компаній із величезними інженерними командами.

00:12:18.240 --> 00:12:21.520
Завдяки керованим сервісам, як от AKS, він доступний будь-якій команді.

00:12:21.680 --> 00:12:23.720
Ваше домашнє завдання на цей тиждень просте.

00:12:23.720 --> 00:12:28.500
Створіть безкоштовний обліковий запис Azure, запустіть кластер AKS і розгорніть просту програму.

00:12:28.620 --> 00:12:31.700
Це займе хвилини, і ви побачите, наскільки розвинулася ця платформа.

00:12:31.860 --> 00:12:33.240
Готові заглибитися більше.

00:12:33.420 --> 00:12:38.540
У наступному епізоді ми розберемо, як створити перший образ контейнера та надіслати його до Azure Container Registry.

00:12:38.720 --> 00:12:43.960
Підписуйтесь на улюбленій подкаст-платформі та поділіться цим із тими, хто тільки починає свій шлях у Кубанітаз.