Модуль 1.1: Що таке Kubernetes?

Складність: [ШВИДКИЙ] — основоположні поняття. Час на проходження: 35–45 хвилин. Передумови: відсутні, хоча базове знайомство із серверами, застосунками та контейнерами полегшить зв’язування прикладів із реальною роботою.

Результати навчання

Після завершення цього модуля ви зможете:

Порівняти оркестрацію Kubernetes із моделями розгортання на одному сервері, на базі віртуальних машин та лише з контейнерним середовищем виконання, оцінюючи платформу для застосунків.
Діагностувати, як бажаний стан, поточний стан та узгодження пояснюють поведінку самовідновлення, масштабування, розгортань і виявлення сервісів у Kubernetes.
Оцінити, чи має сценарій робочого навантаження використовувати Kubernetes, простіший платформний сервіс, віртуальну машину чи безсерверну інфраструктуру.
Спроєктувати першу робочу ментальну модель Kubernetes 1.35+, яка включає декларативну конфігурацію, незмінну інфраструктуру та обов’язки Day 2.

Чому цей модуль важливий

Коли у 2016 році вийшла гра Pokemon GO, Niantic зіткнулася не просто з насиченими першими вихідними: гра отримала трафік, що значно перевищив рівень, на який команда розраховувала, — пізніше Google описала попит, який сягнув 50-кратного очікуваного максимуму. Гравці стикалися з проблемами входу та регіональною нестабільністю, але важливіший інженерний урок полягав у тому, що глобальний продукт може стати залежним від інфраструктури ще до того, як бізнес встигне перебудуватися. Традиційне адміністрування серверів вимагало б, щоб люди вручну виділяли машини, налаштовували балансувальники навантаження, копіювали конфігурацію та сподівалися, що кожен ручний крок виконано правильно, поки інцидент уже був публічним.

Причина, чому цей випадок досі з’являється у навчанні з Kubernetes, не в тому, що Kubernetes робить кожен запуск безтурботним. Він важливий тому, що показує тип проблеми, яку оркестрація покликана вирішувати: багато ідентичних екземплярів застосунку, мінливий попит, відмова як звичайна подія та потреба платформи постійно узгоджувати дійсність із заявленим наміром. У популярному сервісі навіть кілька хвилин зайвого простою можуть означати втрачений дохід, розлючених клієнтів і виснажених операторів, тож платформа має зменшувати кількість рішень, які люди мусять ухвалювати під тиском.

Цей перший модуль KCNA дає вам словник для оцінювання Kubernetes без сприйняття його як магії. Ви пов’яжете практичні проблеми розгортання, масштабування, відновлення після відмов, мережевої взаємодії, конфігурації, переносності та поточної експлуатації в єдину цілісну модель. Наприкінці назва «Kubernetes» має означати для вас більше, ніж просто «те, що запускає контейнери»: вона має означати декларативну систему керування, призначену для управління контейнеризованими застосунками на цілому пулі машин.

Яку проблему вирішує Kubernetes

До Kubernetes багато команд експлуатували сервери як окремо керовані активи. Вебсервер міг мати особливе ім’я хоста, вручну налаштовані пакети, скопійовану власноруч конфігурацію та рунбук, повний кроків, які спрацьовували лише тоді, коли оператор пам’ятав той самий порядок, що й під час минулого інциденту. Такий стиль може бути прийнятним, коли застосунок малий, але він стає крихким, коли трафік зростає, розгортання частішають, а командам потрібно, щоб той самий сервіс однаково працював у розробці, тестуванні, staging-середовищі та продакшені.

Стара аналогія «домашні улюбленці проти худоби» добре передає цей зсув, хоча реальні системи нюансованіші. Сервер-улюбленець має ім’я, про нього дбають, його ремонтують на місці та сприймають як унікальний; екземпляр у стилі худоби — це один замінний член більшого стада. Kubernetes підштовхує команди до другого мислення, пропонуючи їм пакувати застосунки в контейнери, описувати бажаний результат і дозволяти контролерам створювати, замінювати та видаляти екземпляри, доки спостережувана система не збігатиметься з цією декларацією.

┌─────────────────────────────────────────────────────────────┐
│              BEFORE KUBERNETES                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Traditional Deployment:                                   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Server 1         Server 2         Server 3         │   │
│  │  ┌─────────┐     ┌─────────┐     ┌─────────┐       │   │
│  │  │  App A  │     │  App B  │     │  App C  │       │   │
│  │  └─────────┘     └─────────┘     └─────────┘       │   │
│  │  ┌─────────┐     ┌─────────┐     ┌─────────┐       │   │
│  │  │   OS    │     │   OS    │     │   OS    │       │   │
│  │  └─────────┘     └─────────┘     └─────────┘       │   │
│  │  ┌─────────┐     ┌─────────┐     ┌─────────┐       │   │
│  │  │Hardware │     │Hardware │     │Hardware │       │   │
│  │  └─────────┘     └─────────┘     └─────────┘       │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Problems:                                                 │
│  • One app per server = waste                              │
│  • Server dies = app dies                                  │
│  • Manual scaling                                          │
│  • Deployment is risky                                     │
│  • No standard way to manage                               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Діаграма показує основний експлуатаційний біль: кожен сервер несе забагато ідентичності. Якщо Server 2 відмовляє, App B відмовляє разом із ним, якщо хтось заздалегідь не спроєктував резервну потужність, відновлення стану, балансування навантаження, автоматизацію розгортання та моніторинг. Kubernetes не усуває потреби в цих дисциплінах, але дає їм спільний API та набір контролерів, щоб система могла виконувати рутинні коригувальні дії автоматично.

Корисний спосіб осмислити Kubernetes — запитати, що залишається невирішеним після появи контейнерів. Образ контейнера дає вам переносний пакет, але він не вирішує, де запускатися, скільки копій має існувати, як замінювати відмовлені копії, як трафік має знаходити справні копії, як впроваджувати конфігурацію та як призупиняти розгортання, коли нова версія ламається. Kubernetes існує тому, що продакшен-системам потрібно, щоб ці рішення оброблялися повторювано й послідовно.

Зробіть паузу й спробуйте передбачити: якщо команда вже може зібрати образ контейнера й запустити його однією командою на ноутбуку, що ж усе одно ламається тоді, коли той самий застосунок мусить пережити відмову ноди, регіональний сплеск трафіку та невдале розгортання — і все це одночасно? Саме це питання є серцевиною цього модуля, адже Kubernetes виправдовує свою складність лише тоді, коли проблема оркестрації стає більшою, ніж один окремий процес на одній окремій машині.

Та сама проблема виникає й у менших компаніях, лише з менш драматичними заголовками. Інженер підтримки може помітити, що сервіс зупинився після перезавантаження хоста; розробник може виявити, що staging використовує іншу версію пакета, ніж продакшен; а керівник експлуатації може усвідомити, що інструкції з розгортання існують лише в пам’яті однієї людини. Кожен симптом виглядає локальним, але спільна причина в тому, що стан застосунку, стан сервера й експлуатаційний намір переплетені разом. Kubernetes розділяє ці аспекти достатньо, щоб платформа могла міркувати про них.

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

Саме тому Kubernetes став важливим і поза вебзастосунками. Пакетні обробники, API-сервіси, внутрішні інструменти, обробники потоків та допоміжні сервіси машинного навчання — усі вони можуть виграти, коли їх пакують послідовно й керують ними спільні контролери. Робочі навантаження різняться, але питання платформи повторюються: де це має запускатися, скільки ресурсів має запитувати, що має статися в разі відмови, як інші компоненти мають його знаходити та як наступна версія має замінити поточну, не дивуючи користувачів?

Чим є Kubernetes

Kubernetes, який часто скорочують до K8s, — це відкрита платформа оркестрації контейнерів, що автоматизує розгортання, масштабування й управління контейнеризованими застосунками. «Відкрита» має значення, бо основний проєкт розробляється публічно під егідою Cloud Native Computing Foundation, а не контролюється як пропрієтарний сервіс одного хмарного провайдера. «Оркестрація контейнерів» має значення, бо Kubernetes опікується групами контейнерів та інфраструктурними зв’язками навколо них, а не лише запуском одного процесу.

Аналогія з диригентом оркестру досі корисна, якщо тримати її приземленою. Музикант уміє грати на інструменті, так само як образ контейнера вміє запускати процес вашого застосунку. Диригент не переписує музику під час виконання; диригент координує темп, заміну, гучність і взаємодію, щоб увесь виступ тримався купи. Kubernetes виконує цю координаційну роль для контейнерів, плануючи робочі навантаження, підтримуючи кількість реплік, з’єднуючи сервіси, розгортаючи зміни й реагуючи, коли частини відмовляють.

Термін	Значення
Відкритий код	Безкоштовний, керований спільнотою, без прив’язки до постачальника
Оркестрація контейнерів	Управління багатьма контейнерами як системою
Платформа	Основа для побудови, а не просто інструмент
Автоматизує	Зменшує ручну роботу та людські помилки

Скорочення також розповідає невелику історію про проєкт. Kubernetes грецькою означає «керманич» або «лоцман», а K8s утворено з першої літери, восьми літер посередині та останньої літери. Google створив Kubernetes на основі уроків, отриманих під час внутрішньої експлуатації Borg та Omega, а потім передав Kubernetes до CNCF у 2015 році, щоб ширша екосистема могла будуватися навколо нейтрального до постачальника рівня управління.

Іспит KCNA очікує, що ви чітко відрізнятимете Kubernetes від суміжних рівнів стека. Kubernetes — це не формат образу контейнера, це не середовище виконання контейнерів, це не керована база даних і це не гарантія того, що погано спроєктовані застосунки масштабуватимуться чисто й без проблем. Це передусім платформний API та система контролерів, яка використовує середовища виконання на кшталт containerd для фактичного створення контейнерів на нодах, а потім безперервно продовжує працювати, щоб привести кластер до того стану, який користувачі задекларували через об’єкти Kubernetes.

Коли ви почнете користуватися командним рядком далі в цьому напрямку, стандарт проєкту — один раз визначити скорочення оболонки alias k=kubectl, а потім використовувати k у прикладах. Це означає, що команда на кшталт k get pods запитує в Kubernetes API, які Pod’и існують, тоді як псевдонім просто заощаджує набирання тексту. Псевдонім не є новим інструментом, і пам’ятання про цю відмінність позбавляє несподівано великої кількості плутанини для початківців під час читання реальних рунбуків.

Слово «платформа» заслуговує на додаткову увагу, бо воно змінює те, як команди мають оцінювати Kubernetes. Інструмент зазвичай вирішує одну вузьку проблему, як-от запуск процесу чи копіювання файлу. Платформа створює місце, де багато команд можуть будувати повторювані робочі процеси на спільних примітивах. Kubernetes дає командам примітиви на кшталт Pod’ів, Деплойментів, Сервісів, ConfigMap’ів, Secret’ів, Просторів імен, міток та контролерів, а потім дозволяє організаціям компонувати їх у системи доставки, межі безпеки та експлуатаційні практики.

Саме ця платформна властивість пояснює, чому Kubernetes може здаватися водночас і таким, що розширює можливості, і приголомшливим. Початківець може попросити «команду Kubernetes для розгортання застосунку» і швидко зіткнутися з образами, маніфестами, мітками, Сервісами, пробами, запитами ресурсів та просторами імен. Складність реальна, але вона не випадкова. Кожне поняття відповідає на експлуатаційне питання, яке раніше вирішували через shell-скрипти, тікети, угоди про іменування серверів, правки балансувальників навантаження чи племінні знання. Kubernetes робить ці питання явними через об’єкти API.

Площина управління — це частина Kubernetes, яка зберігає ці об’єкти й діє на їх основі. API-сервер приймає запити, etcd зберігає стан кластера, планувальник обирає ноди для Pod’ів, а контролери стежать за відмінностями, що потребують виправлення. Робочі вузли запускають kubelet, мережеві компоненти та середовище виконання контейнерів. Вам не потрібно запам’ятовувати кожен компонент у цьому першому модулі, але ви вже маєте побачити поділ: користувачі декларують намір через API, а компоненти кластера співпрацюють, щоб втілити цей намір на нодах.

Що робить Kubernetes

Kubernetes надає набір платформних поведінок, які ззовні здаються простими й стають потужними в поєднанні. Розгортання означає, що він може створювати правильні об’єкти робочих навантажень із задекларованої конфігурації. Масштабування означає, що він може змінювати кількість запущених копій або співпрацювати з автомасштабувальниками, коли метрики це виправдовують. Відновлення означає, що контролери помічають відсутні або несправні екземпляри й замінюють їх. Виявлення сервісів означає, що застосунки можуть використовувати стабільні імена замість гонитви за мінливими адресами Pod’ів.

┌─────────────────────────────────────────────────────────────┐
│              KUBERNETES CAPABILITIES                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. DEPLOYMENT                                             │
│     "Run my app"                                           │
│     ├── Deploy containers                                  │
│     ├── Rolling updates                                    │
│     └── Rollback if needed                                 │
│                                                             │
│  2. SCALING                                                │
│     "Handle more traffic"                                  │
│     ├── Scale up (more replicas)                          │
│     ├── Scale down (fewer replicas)                       │
│     └── Autoscale based on metrics                        │
│                                                             │
│  3. HEALING                                                │
│     "Keep it running"                                      │
│     ├── Restart failed containers                          │
│     ├── Replace unhealthy nodes                           │
│     └── Reschedule if node dies                           │
│                                                             │
│  4. SERVICE DISCOVERY                                      │
│     "Let apps find each other"                            │
│     ├── DNS-based discovery                               │
│     ├── Load balancing                                    │
│     └── Internal networking                               │
│                                                             │
│  5. CONFIGURATION                                          │
│     "Manage settings"                                      │
│     ├── ConfigMaps for config                             │
│     ├── Secrets for sensitive data                        │
│     └── Environment injection                             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Важлива частина полягає в тому, що ці можливості не є ізольованими функціями, прикрученими до запускача контейнерів. Вони підсилюють одна одну через ту саму модель бажаного стану. Деплоймент декларує кількість реплік та шаблон Pod’а. Сервіс надає цим мінливим Pod’ам стабільну мережеву ідентичність. ConfigMap’и та Secret’и відокремлюють налаштування від образів. Історія розгортань дозволяє команді рухатися вперед і назад, не заходячи на окремі машини.

Розгляньмо для прикладу сервіс кошика покупок під час інтенсивного розпродажу. Якщо трафік раптово зростає, команда може вручну збільшити кількість реплік або ж дозволити автомасштабувальнику зробити це автоматично на основі метрик; якщо одна з нод відмовляє, замінні Pod’и можуть бути заплановані деінде на іншій ноді; якщо ж версія 2 починає провалювати перевірки справності, розгортання можна зупинити ще до того, як постраждає кожен користувач. Жодна з цих дій не вимагає, щоб Kubernetes розумів справжнє бізнесове значення кошика покупок. Платформі потрібні лише чіткі декларації, сигнали справності, запити ресурсів та контролери, які невпинно продовжують узгоджувати стан кластера.

Перш ніж запускати це в майбутній практичній роботі, який вивід ви очікували б від k get pods одразу після того, як одна репліка впаде, але до того, як її заміна стане готовою? Сильна відповідь згадує, що ви можете на короткий час побачити Pod, який завершується, новий Pod у стані pending або running та загальний стан, який збігається, а не миттєво ідеальний. Kubernetes швидкий, але це все одно цикл керування, що працює над реальними машинами, образами, мережами та перевірками справності.

Kubernetes також стандартизує те, як команди говорять про відмови. Замість того щоб казати «вебсервер зламаний», оператори можуть запитати, чи Pod перебуває у стані pending, чи контейнер циклічно падає (crash-looping), чи проба готовності провалюється, чи селектор Сервісу не збігається з мітками, чи розгортання застрягло. Цей словник — одна з причин, чому Kubernetes став галузевим стандартом: він перетворює безладні інфраструктурні симптоми на стани об’єктів, які команди, інструменти та автоматизація можуть послідовно перевіряти.

Поведінка розгортання — гарний приклад того, як цей словник стає дією. Розгортання — це не просто людина, яка копіює новий бінарник на сервер. Це контрольований перехід від одного задекларованого шаблону Pod’а до іншого, зі статусом, який можна спостерігати, та політиками, які можуть обмежувати, скільки змін відбувається за раз. Якщо нові Pod’и провалюють перевірки готовності, Kubernetes може залишати старі Pod’и обслуговувати запити, поки команда розслідує. Платформа не може вирішити, чи правильний новий код, але вона може запобігти тому, щоб зміна стала за замовчуванням принципом «усе або нічого».

Масштабування також має дві сторони. Ручне масштабування корисне, коли оператор навмисно змінює кількість реплік, можливо, перед запланованою подією. Автомасштабування корисне, коли система змінює кількість реплік на основі метрик, як-от завантаження процесора чи власних сигналів застосунку. Обидва залежать від однієї основи: застосунок має витримувати кілька копій, запити мають балансуватися між цими копіями, а стійкий стан має зберігатися десь у безпечному місці. Kubernetes надає механіку, але архітектура застосунку все одно визначає, чи дає масштабування справну потужність.

Виявлення сервісів так само практичне. Pod’и навмисно замінні, тож їхні окремі мережеві адреси недостатньо стабільні, щоб інші застосунки на них покладалися. Сервіс Kubernetes дає клієнтам стабільне ім’я та віртуальну адресу, обираючи відповідні Pod’и за ним. Це різниця між запитанням «який саме екземпляр живий просто зараз?» і запитанням «де сервіс кошика покупок?». Друге питання — це те, яке зазвичай мають ставити розробники застосунків.

Управління конфігурацією доповнює базову модель, відокремлюючи код, придатний для розгортання, від налаштувань, специфічних для середовища. Образ контейнера не має потребувати повторного збирання лише тому, що змінився перемикач функції чи відрізняється кінцева точка сервісу між staging та продакшеном. ConfigMap’и та Secret’и дозволяють специфікації Pod’а посилатися на зовнішні значення, хоча Secret’и все одно потребують обережного поводження, вибору шифрування, контролю доступу та ротації. Kubernetes дає стандартний шлях доставки конфігурації; він не усуває потреби добре керувати чутливими даними.

Kubernetes проти альтернатив

Kubernetes найлегше зрозуміти у порівнянні з інструментами, які він не замінює. Віртуальна машина забезпечує апаратну віртуалізацію та повну гостьову операційну систему; середовище виконання контейнерів запускає контейнери на хості; платформа як сервіс (PaaS) приховує більшість інфраструктурних рішень за простішим контрактом розгортання; безсерверні функції виконують код, керований подіями, без довготривалого серверного процесу. Kubernetes посідає інше місце: він оркеструє контейнеризовані робочі навантаження в кластері, залишаючи команду відповідальною за багато платформних виборів.

Аспект	Віртуальні машини	Kubernetes + Контейнери
Час запуску	Хвилини	Секунди
Використання ресурсів	Важке (повна ОС)	Легке (спільне ядро)
Щільність	~десятки на хост	~сотні на хост
Переносність	Обмежена	Висока
Масштабування	Повільне	Швидке

Порівняння з ВМ не слід читати як «ВМ — це погано». Багато кластерів Kubernetes працюють на ВМ, особливо у публічних хмарних середовищах, де ноди є хмарними екземплярами. Різниця в тому, що Kubernetes розглядає ці ноди як потужність для робочих навантажень, замість того щоб очікувати, що кожна ВМ буде керованим вручну домом одного застосунку. ВМ залишаються корисними одиницями ізоляції та інфраструктури, тоді як Kubernetes керує рівнем застосунків над ними.

Docker та Kubernetes плутають навіть частіше, бо початківці стикаються з обома через контейнери. Docker допоміг популяризувати зручний для розробників робочий процес побудови та запуску контейнерів, тоді як Kubernetes зосереджується на плануванні та експлуатації багатьох контейнерів на багатьох машинах. У сучасних кластерах Kubernetes containerd зазвичай є середовищем виконання, що виконує низькорівневу контейнерну роботу, тоді як Kubernetes надає вищерівневу площину управління та API.

┌─────────────────────────────────────────────────────────────┐
│              DOCKER vs KUBERNETES                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  DOCKER:                                                   │
│  "Run this container on this machine"                      │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  docker run nginx                                   │   │
│  │  → Runs ONE container on ONE machine                │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  KUBERNETES:                                               │
│  "Run 3 copies, keep them healthy, balance traffic"        │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Deployment: nginx, replicas: 3                     │   │
│  │  → Runs across cluster                              │   │
│  │  → Self-heals if one dies                           │   │
│  │  → Load balances traffic                            │   │
│  │  → Scales up/down automatically                     │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Docker = Container runtime                                │
│  Kubernetes = Container orchestrator                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Практичне рішення часто починається з експлуатаційного володіння. Якщо команда хоче найпростіший спосіб розмістити маркетинговий сайт із низьким трафіком, керована платформа застосунків може підійти краще, ніж кластер Kubernetes. Якщо команда має багато сервісів, потребує переносних маніфестів, хоче зрілих засобів контролю розгортання та може вкладатися в платформну експлуатацію, Kubernetes починає мати більше сенсу. Вибір інструмента має слідувати за робочим навантаженням і командою, а не навпаки.

Гіпотетичний сценарій: невелика SaaS-команда якось перенесла застосунок із двох сервісів із ВМ на Kubernetes, бо клієнт запитав, чи вони «cloud native». Перший місяць не приніс жодної помітної для користувача користі, але приніс налаштування ingress, автоматизацію сертифікатів, сканування образів, визначення розміру ресурсів, рішення щодо логування та планування оновлень. Міграція стала цінною лише після того, як продукт виріс у багато сервісів із незалежними циклами випуску; до цього простіша ВМ була легшою для осмислення.

Платформний сервіс може бути протилежним компромісом. Він може приховувати сервери, балансування навантаження, TLS та масштабування за коротким конфігураційним файлом чи вебконсоллю. Це чудово, коли команда хоче випускати функції продукту, а припущення провайдера відповідають робочому навантаженню. Компроміс у тому, що глибше налаштування може бути обмежене, переносність може бути нижчою, а складніші мережеві вимоги чи вимоги до політик можуть не вписуватися. Kubernetes привабливий, коли командам потрібен спільний субстрат для багатьох робочих навантажень, а не просто тому, що вони хочуть вишуканіший цільовий об’єкт для розгортання.

Безсерверні функції пропонують ще один корисний контраст. Вони добре працюють для завдань, керованих подіями, обробників запитів із коротким часом виконання та команд, які хочуть платити близько до використання, не керуючи довготривалими екземплярами. Вони менш природні для систем, яким потрібні власні sidecar-контейнери, довготривалі мережеві з’єднання, спеціалізоване планування чи спільна service mesh. Kubernetes та безсерверні рішення можуть співіснувати в одній організації. Питання дизайну полягає в тому, яка модель виконання робить експлуатаційний тягар меншим для конкретного робочого навантаження.

Найкращі інженери уникають перетворення цих порівнянь на суперечки про ідентичність. Вони не запитують «Ми Kubernetes-команда?», ніби це має вирішувати кожне платформне рішення. Вони запитують, які режими відмов мають значення, який ритм випуску очікується, яка переносність потрібна, хто експлуатуватиме систему та які обмеження накладаються станом, мережею, безпекою та вартістю. Kubernetes — це один сильний варіант у цьому просторі рішень, і він стає сильнішим, коли ці питання вказують у бік оркестрації.

Ключові поняття Kubernetes

Kubernetes є декларативним, що означає: ви описуєте результат, якого хочете, а не скриптуєте кожну дію, яку платформа має виконати. Імперативний підхід каже: «запусти цей процес, потім скопіюй цей файл, потім перезапусти цей сервіс, потім додай ще один екземпляр». Декларативний підхід каже: «бажаний стан — це три репліки цього шаблону Pod’а», і площина управління продовжує перевіряти, чи збігається поточний стан із цим бажаним станом.

# You declare: "I want 3 nginx replicas"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3  # Desired state
  ...

Приклад YAML навмисно невеликий, але він містить центральну ідею. apiVersion та kind повідомляють Kubernetes, який тип об’єкта ви декларуєте. Метадані дають об’єкту ім’я. Специфікація несе бажаний стан, включно з кількістю реплік. У реальних маніфестах пропущений шаблон Pod’а визначав би образ контейнера, мітки, порти, проби, запити ресурсів та інші деталі, які роблять декларацію придатною до експлуатації.

Бажаний стан має таке велике значення саме тому, що продакшен-системи постійно дрейфують. Нода може зненацька відмовити, контейнер може несподівано завершитися, розгортання може створити нові репліки ще до того, як старі повністю завершаться, а оператор може внести ручну зміну, яка конфліктує із задекларованим об’єктом. Контролери Kubernetes уважно стежать за всіма цими відмінностями та самостійно вживають заходів. Саме тому Деплоймент із трьома бажаними репліками не просто створює три Pod’и один-єдиний раз; він безперервно продовжує забезпечувати дотримання цієї цілі в міру того, як кластер змінюється з часом.

┌─────────────────────────────────────────────────────────────┐
│              DESIRED STATE RECONCILIATION                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  You declare:     "I want 3 replicas"                      │
│                         │                                   │
│                         ▼                                   │
│  Kubernetes:      Checks current state                     │
│                         │                                   │
│           ┌─────────────┴─────────────┐                    │
│           │                           │                     │
│           ▼                           ▼                     │
│     If 2 running:              If 4 running:               │
│     "Create 1 more"            "Terminate 1"               │
│                                                             │
│  This loop runs CONTINUOUSLY                               │
│  Kubernetes never stops trying to match desired state      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Зупиніться на мить і подумайте: якщо бажаний стан каже, що має бути три репліки, то що саме має статися тоді, коли одна репліка раптом падає о 3-й годині ночі й при цьому ніхто з команди не на зв’язку? Відповідь зовсім не в тому, що Kubernetes має якийсь календар чи вроджений інстинкт реагування на інциденти. Відповідь у тому, що контролер просто спостерігає дві доступні репліки там, де було задекларовано три, а потім створює замінну роботу доти, доки спостережуваний стан не зійдеться назад до специфікації.

Незмінна інфраструктура — це супутня ідея. Замість того щоб заходити в запущений контейнер і змінювати код на місці, команди збирають новий образ, оновлюють декларацію й дозволяють Kubernetes замінити старі Pod’и новими. Це зменшує дрейф конфігурації, бо запущений екземпляр не є джерелом істини. Джерело істини — це задекларований об’єкт плюс образ і посилання на конфігурацію, на які він вказує.

Ця модель робить відкати та аудити надійнішими, але вона також просить команди змінити звички. Швидке виправлення через SSH може здаватися швидшим під час збою, проте воно створює невидиму відмінність, яку наступне розгортання може стерти чи непередбачувано відтворити. Kubernetes працює найкраще, коли команди розглядають запущені контейнери як одноразові результати, тримають маніфести під рецензуванням і вносять зміни через повторювані декларації, а не через аварійні ручні правки.

Для Kubernetes 1.35 і пізніших версій та сама концептуальна модель залишається відправною точкою, навіть коли окремі функції дозрівають. Ви вивчите типи об’єктів у наступних модулях, але ментальний патерн стабільний: декларуйте намір, спостерігайте статус, дозволяйте контролерам узгоджувати та налагоджуйте, порівнюючи те, що ви попросили, з тим, що повідомляє кластер. Цей патерн — найпростіший спосіб уникнути запам’ятовування розрізнених команд.

Мітки та селектори — ще одне раннє поняття, яке варто пов’язати з оркестрацією. Kubernetes рідко керує об’єктами лише за жорстко закодованими іменами. Натомість Сервіс може обирати Pod’и з певною міткою, Деплоймент може керувати ReplicaSet’ами, якими володіє, а експлуатаційні інструменти можуть фільтрувати об’єкти за середовищем, командою чи застосунком. Це дозволяє системі керувати групами, що змінюються з часом. Мітка невелика, але здатність платформи діяти на марковані набори — одна з причин, чому API масштабується до реальних середовищ.

Перевірки справності поглиблюють модель бажаного стану, бо Kubernetes потрібні сигнали, перш ніж він зможе ухвалювати добрі рішення про заміну та маршрутизацію. Проба життєздатності (liveness) може вказувати, що контейнер слід перезапустити, тоді як проба готовності (readiness) може вказувати, чи має Pod отримувати трафік. Без цих сигналів платформа може продовжувати надсилати користувачів до процесу, який технічно запущений, але насправді не готовий. Kubernetes може автоматизувати відновлення лише настільки, наскільки застосунки виставляють осмислену справність.

Запити та ліміти ресурсів створюють ще один міст між наміром застосунку та поведінкою кластера. Планувальнику потрібно знати, скільки процесора та пам’яті очікує Pod, перш ніж він зможе відповідально розмістити роботу. Якщо запити надто низькі, ноди можуть перевантажитися, а продуктивність — стати непередбачуваною. Якщо запити надто високі, кластер може виглядати заповненим, тоді як реальне завантаження залишається низьким. Kubernetes дає планувальнику мову для потужності, але команди мають надавати чесні числа й переглядати їх на основі спостережень.

Простори імен допомагають командам організовувати та ізолювати роботу, але їх не слід плутати з повноцінною межею безпеки самих по собі. Простір імен може розділяти імена, квоти, політики та правила доступу, що корисно для розробки, staging, продакшену чи володіння командою. Сильна ізоляція все одно залежить від RBAC, мережевої політики, контролю допуску, посилення нод та конфігурації провайдера. Урок для початківця простий: Kubernetes надає будівельні блоки для врядування, а кластер потребує, щоб ці блоки були зібрані свідомо.

Ці поняття вказують на звичку налагодження, яку ви використовуватимете впродовж усього напрямку Kubernetes. Коли щось виглядає неправильно, порівняйте задекларований об’єкт, статус контролера, обрані Pod’и, події та базові умови ноди. Ця послідовність надійніша за вгадування за симптомами. Проблеми Kubernetes часто виглядають загадковими, коли їх розглядати як одну гігантську платформу, але вони стають розв’язними, коли ви простежуєте зв’язки між об’єктами.

Експлуатація Day 2 і де працює Kubernetes

Kubernetes може працювати в багатьох місцях, і ця переносність — одна з його найсильніших переваг. Керований сервіс на кшталт Amazon EKS, Google Kubernetes Engine чи Azure Kubernetes Service зменшує тягар експлуатації площини управління, тоді як самокеровані кластери дають командам більше контролю та більше відповідальності. Локальні інструменти розробки на кшталт kind, minikube та Docker Desktop надають невеликі кластери для навчання й тестування, але їх не слід плутати з продакшен-експлуатацією.

Середовище	Приклади
Публічна хмара	EKS (AWS), GKE (Google), AKS (Azure)
Приватна хмара	OpenStack, VMware
On-Premises	Bare metal, центри обробки даних
Edge	Роздрібні магазини, заводи
Розробка	minikube, kind, Docker Desktop

Ця гнучкість допомагає з переносністю, але вона не означає, що кожен кластер поводиться однаково. Класи зберігання, інтеграції балансувальників навантаження, системи ідентифікації, образи нод, канали оновлень та мережеві плагіни різняться між середовищами. API Kubernetes дає командам спільну модель для робочих навантажень, проте реальна експлуатація все одно вимагає розуміння провайдера під кластером. Переносність зменшує прив’язку до постачальника; вона не стирає інфраструктуру.

Експлуатація Day 2 починається після того, як кластер існує і розгорнуто перший застосунок. Командам потрібні моніторинг та оповіщення, щоб вони знали, коли Pod’и несправні, ноди під тиском чи розгортання застрягли. Їм потрібні засоби контролю безпеки, як-от RBAC, політики допуску, сканування образів та мережева політика. Їм потрібні плани оновлень, бо Kubernetes випускається з регулярним ритмом, а вікна підтримуваних версій з часом закриваються.

Управління вартістю — це також турбота Day 2. Kubernetes може ефективно пакувати робочі навантаження, але лише якщо команди встановлюють реалістичні запити процесора та пам’яті, стежать за невикористаною потужністю та розуміють, як автомасштабування взаємодіє із хмарними групами нод. Без цієї дисципліни кластер може стати дорогим місцем для приховування марнотратства. Платформа дає вам ручки керування; вона не знає автоматично бізнесову цінність кожного робочого навантаження.

Який підхід ви обрали б тут і чому: керований сервіс Kubernetes для команди з багатьма мікросервісами, але обмеженою експертизою щодо площини управління, чи самокерований кластер, бо команда хоче кожну деталь конфігурації? Зріла відповідь зважує експлуатаційний тягар проти контролю. Багато організацій обирають керований Kubernetes спочатку, бо вивчення оркестрації застосунків уже є достатньою роботою без додаткового володіння кожним режимом відмови площини управління.

Керований Kubernetes не означає «жодної експлуатації»; це означає, що провайдер бере на себе відповідальність за обрані завдання площини управління та інфраструктури. Команда застосунку все одно володіє визначеннями робочих навантажень, визначенням розміру ресурсів, виборами RBAC, мережевим виставленням, спостережуваністю, реагуванням на інциденти та тестуванням оновлень. Ця відмінність має значення під час планування, бо керований сервіс може зменшити недиференційовану експлуатаційну роботу, залишивши платформній команді чимало рішень щодо дизайну, які впливають на надійність і безпеку.

On-premises та edge-кластери додають інший набір обмежень. У центрі обробки даних команди можуть дбати про життєвий цикл обладнання, фізичну мережу, масиви зберігання та наявні системи ідентифікації. На межі (edge) командам можуть знадобитися невеликі кластери в магазинах, на заводах, у клініках чи віддалених майданчиках, де мережеве з’єднання обмежене. Kubernetes може підтримувати ці середовища, але експлуатаційна модель має враховувати оновлення, розповсюдження образів, прогалини у спостережуваності та локальне відновлення, коли центральна команда не присутня.

Кластери для розробки мають власне призначення. Інструменти на кшталт kind та minikube чудово підходять для вивчення поведінки об’єктів, тестування маніфестів та відтворення простих взаємодій контролерів на ноутбуку. Вони не є доказом того, що продакшен буде легким, бо продакшен додає реальний трафік, стійкі дані, перевірку безпеки, багатокористувацький доступ, хмарні інтеграції, резервні копії та координацію оновлень. Розглядайте локальні кластери як навчальні полігони та цикли зворотного зв’язку, а не як мініатюрний доказ того, що кожну продакшен-турботу вирішено.

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

Коли це не застосовується

Kubernetes потужний, але він не є відповіддю за замовчуванням для кожного застосунку. Якщо у вас простий вебзастосунок із низьким трафіком та однією одиницею розгортання, платформний сервіс на кшталт Heroku, Vercel, Cloud Run чи AWS App Runner може дати той самий результат для користувача зі значно меншою експлуатаційною поверхнею. Якщо ваш застосунок сильно залежить від локальної файлової системи однієї машини, ручного стану сервера чи неконтейнеризованих припущень, Kubernetes може виявити проблеми дизайну, перш ніж надасть переваги.

Заплановані скрипти — ще одна поширена невідповідність. Один нічний звіт може належати до cron, керованого планувальника чи безсерверної функції, а не до кластера з нодами, ingress, політиками, оновленнями та спостережуваністю. Стейтфул-бази даних також заслуговують на обережність. Kubernetes може запускати стейтфул-навантаження, і багато команд успішно це роблять, але керовані бази даних часто надають резервні копії, патчинг, реплікацію та експлуатаційну експертизу, яку було б дорого відтворити всередині кластера для початківців.

Антипатерн — це не «використання Kubernetes»; антипатерн — це використання Kubernetes для уникнення простіших рішень. Якщо команда не може пояснити, яку проблему оркестрації вона має, хто експлуатуватиме кластер, як спостерігатимуться застосунки та як оброблятимуться інциденти, міграція може лише перемістити складність у YAML. Kubernetes слід обирати тому, що він підходить робочому навантаженню та організації, а не тому, що він звучить як сучасна відповідь.

Застарілі моноліти заслуговують на особливу увагу в цьому оцінюванні. Моноліт може працювати в Kubernetes, якщо він контейнеризований, придатний для перевірок справності та здатний витримувати модель заміни платформи. Проблеми виникають, коли застосунок припускає постійне ім’я хоста, записує важливий стан лише на локальний диск, вимагає ручного патчингу всередині запущеного екземпляра чи довго запускається, не повідомляючи готовність точно. У таких випадках команді може знадобитися модернізація застосунку, перш ніж Kubernetes зможе надати очікувані переваги.

Малі команди також мають бути чесними щодо когнітивного навантаження. Kubernetes додає поняття, API, дозволи, контролери, мережеві рівні та експлуатаційні дашборди. Команда може зменшити це навантаження за допомогою керованого сервісу та сильних шаблонів, але хтось усе одно має розуміти достатньо, щоб діагностувати інциденти. Якщо ті самі два інженери будують функції продукту, обробляють підтримку, керують базами даних і вивчають Kubernetes з нуля, простіша платформа може захистити і надійність, і фокус команди.

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

Коли використовувати це проти альтернатив

Використовуйте ВМ, коли вам потрібна невелика кількість довготривалих серверів, сильний контроль на рівні машини та команда, яка може безпосередньо керувати патчингом і резервними копіями. Використовуйте керовану платформу застосунків, коли продукт потребує швидкого розгортання, а команда радше проміняє контроль над інфраструктурою на простоту. Використовуйте безсерверні функції, коли робочі навантаження керовані подіями, короткотривалі та вписуються в модель виконання провайдера. Використовуйте Kubernetes, коли багато контейнеризованих сервісів потребують скоординованого планування, контролю розгортання, виявлення сервісів, політик та переносної експлуатації.

Компроміс у тому, що Kubernetes перетворює інфраструктуру на платформний продукт. Хтось має визначити стандарти кластера, керувати доступом, встановити політики ресурсів, спроєктувати мережу, обрати інструменти спостережуваності, спланувати оновлення та допомогти командам застосунків правильно користуватися платформою. Натомість команди застосунків отримують узгоджений API для розгортання та експлуатації сервісів у різних середовищах. Цей обмін може бути чудовим, але лише тоді, коли організація готова володіти платформою як реальною системою.

Ось практичне оцінювальне питання: чи буде відмова одного екземпляра рутинною чи винятковою? Якщо рутинною, модель самовідновлення та реплік Kubernetes може допомогти. Чи виграв би застосунок від незалежних розгортань та горизонтального масштабування? Якщо так, Kubernetes стає привабливішим. Чи розв’язали б проблему керована база даних, сервіс статичного хостингу чи проста ВМ із меншою кількістю рухомих частин? Якщо так, вибір простішого варіанта зазвичай є сильнішим інженерним рішенням.

Інше оцінювальне питання — як часто система змінюється. Kubernetes сяє, коли багато команд часто розгортають і потребують узгодженої поведінки розгортання, відкату, політик та виявлення. Якщо робоче навантаження змінюється двічі на рік і безпечно працює на одній добре керованій ВМ, експлуатаційна віддача може бути слабкою. Платформа має зменшувати тертя в роботі, яка насправді відбувається. Якщо робота рідкісна й проста, платформа може стати головним джерелом тертя.

Вимоги безпеки можуть підштовхнути рішення в будь-який бік. Kubernetes пропонує багаті механізми для ідентифікації, контролю допуску, мережевої сегментації, доставки секретів та забезпечення дотримання політик, але ці механізми мають бути спроєктовані та протестовані. Малий застосунок із базовими потребами може бути безпечнішим на керованій платформі з меншою кількістю виставлених засобів контролю. Більша організація з багатьма сервісами може бути безпечнішою на Kubernetes, бо вона може централізувати обмежувальні рамки та зробити безпечні патерни придатними для повторного використання. Той самий набір функцій може бути перевагою чи тягарем залежно від експлуатаційної зрілості.

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

Нарешті, розгляньте організаційне навчання. Kubernetes вводить мову, яку багато постачальників, інструментів та інженерів уже поділяють. Ця екосистема може пришвидшити найм, інтеграцію та документування, бо поняття широко відомі. Вона також може спокушати команди копіювати патерни, не розуміючи, чому вони існують. Правильна навчальна мета для KCNA — не запам’ятати модні терміни, а напрацювати достатньо суджень, щоб пояснити, чому патерн Kubernetes підходить сценарію.

Чи знали ви?

Kubernetes походить від Borg компанії Google — Google експлуатував Borg внутрішньо понад 10 років, перш ніж Kubernetes привніс багато з тих уроків оркестрації у проєкт з відкритим кодом.
K8s справляється з величезним масштабом — висхідні пороги масштабованості включають кластери з 5000 нодами та 150 000 Pod’ів, що значно більше, ніж потрібно більшості команд, але доводить, що архітектуру протестовано на великому розмірі.
Більшість проєктів CNCF інтегруються з K8s — Kubernetes став спільною основою для cloud native інструментів мережі, спостережуваності, політик, доставки та безпеки, бо API дає цим проєктам спільне місце для приєднання.
Цикл випуску передбачуваний — Kubernetes зазвичай випускає три мінорні релізи на рік, а проєкт документує вікно підтримки, щоб оператори могли планувати оновлення, а не сприймати зміни версій як несподіванки.

Типові помилки

Помилка	Чому вона трапляється	Як її виправити
«K8s — це просто Docker»	Той, хто навчається, бачить обидва інструменти через контейнери й припускає, що вони займають той самий рівень.	Відокремте середовище виконання від оркестрації: Docker чи containerd запускають контейнери, тоді як Kubernetes планує, відновлює, з’єднує та масштабує їх у кластері.
«K8s замінює ВМ»	Маркетингові діаграми часто показують контейнери замість машин, приховуючи ноди під ними.	Пам’ятайте, що Kubernetes зазвичай працює на нодах ВМ чи bare metal і керує робочими навантаженнями застосунків над цим інфраструктурним рівнем.
«K8s лише для великих компаній»	Великі публічні кейси змушують платформу звучати корисною лише в інтернет-масштабі.	Оцінюйте проблему оркестрації, а не розмір компанії; менші команди можуть виграти, коли мають багато сервісів, повторювані розгортання та підтримку керованого кластера.
«K8s — це середовище виконання контейнерів»	Команди на кшталт `k get pods` показують контейнери опосередковано, тож початківці приписують поведінку середовища виконання API-серверу.	Вивчіть рівні: Kubernetes спілкується з агентами нод, агенти нод використовують середовище виконання контейнерів, а середовище виконання виконує низькорівневі операції з контейнерами.
«K8s робить застосунки миттєво масштабованими»	Кількість реплік легко змінити, тож команди ігнорують обмеження дизайну застосунку.	Проєктуйте для горизонтального масштабу зі stateless-обробкою запитів, винесеним назовні стійким станом, реалістичними запитами ресурсів та навантажувальними тестами, які доводять, що сервіс може безпечно додавати репліки.
«K8s — це керована база даних»	StatefulSet’и та персистентні томи роблять бази даних можливими, що можна сплутати з тим, що це робить їх простими.	Використовуйте керовані бази даних, якщо тільки ви не маєте експертизи та експлуатаційної причини володіти резервними копіями, реплікацією, оновленнями та відновленням усередині кластера.
«Розгортання K8s означає кінець експлуатації»	Автоматизація приховує рутинну роботу, створюючи враження, що платформа експлуатує себе сама.	Плануйте роботу Day 2 від самого початку: моніторинг, RBAC, політики, оновлення, реагування на інциденти, планування потужності та перегляди вартості залишаються необхідними.

Тест

Ваша команда запускає єдиний сервіс оформлення замовлень на одній ВМ. Трафік зростає, а розгортання спричиняють короткі простої. Що Kubernetes вирішив би, а що не вирішив би автоматично?

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

Колега каже: «Ми вже використовуємо Docker, тож Kubernetes був би зайвим». Як ви відповісте на огляді дизайну?

Docker чи інше середовище виконання контейнерів може запустити контейнер на одній машині, що необхідно, але недостатньо для експлуатації продакшен-сервісу в кластері. Kubernetes вирішує розміщення, підтримує бажану кількість реплік, налаштовує виявлення сервісів, виконує розгортання та реагує, коли ноди чи контейнери відмовляють. Краща відповідь — не відкидати колегу, а визначити невирішені проблеми: багатонодове планування, заміну на основі справності, маршрутизацію трафіку та повторювані декларації. Якщо цих проблем ще не існує, Kubernetes усе одно може бути непотрібним.

Деплоймент декларує три репліки, але кластер наразі показує два справні Pod'и й одну заміну, що ще запускається. Чи провалює Kubernetes модель бажаного стану?

Ні. Узгодження бажаного стану — це цикл керування, а не обіцянка, що дійсність завжди ідеальна в кожну мить. Важливе питання — чи спостерігав контролер відмінність і чи вживає заходів, щоб зійтися назад до задекларованого стану. Під час завантаження образів, затримок планування чи запуску проби готовності поточний стан може відставати від бажаного. Ви налагоджуєте, перевіряючи події, статус Pod'а та статус розгортання, а не припускаючи, що будь-яка тимчасова невідповідність є відмовою платформи.

Ваш менеджер хоче перенести блог на WordPress із низьким трафіком на трьохнодовий кластер Kubernetes, щоб «забезпечити майбутнє». Яку оцінку ви дасте?

Найсильніша оцінка полягає в тому, що Kubernetes, імовірно, додасть більше експлуатаційної вартості, ніж користі для цього робочого навантаження. Простому блогу зазвичай потрібні резервні копії, патчинг, TLS та передбачуваний хостинг більше, ніж оркестрація реплік, виявлення сервісів та оновлення кластера. Керований хостинг WordPress, невелика ВМ чи платформний сервіс можуть задовольнити потребу користувача з меншою кількістю рухомих частин. Kubernetes стає переконливішим лише тоді, коли робоче навантаження перетворюється на кілька контейнеризованих сервісів із вимогами до масштабування, розгортання чи переносності.

Під час релізу розробник хоче зайти через SSH у запущений контейнер і виправити файл, бо повторне збирання образу здається повільним. Який принцип він збирається порушити?

Він порушує незмінну інфраструктуру й послаблює декларативну модель. Запущений контейнер слід розглядати як замінний результат образу та специфікації, а не як джерело істини. Ручне виправлення створює прихований дрейф, який може зникнути при перезапуску чи неузгоджено поширитися між репліками. Безпечніше виправлення — перезібрати образ, оновити декларацію Kubernetes і дозволити розгортанню створити нові Pod'и з повторюваного артефакту.

Команда хоче переносності між постачальниками й планує використовувати ті самі маніфести на EKS, GKE та on-premises кластері. Що має бути переносним, а що все одно потребує дизайну, специфічного для середовища?

Основні об'єкти робочих навантажень, як-от Деплойменти, Сервіси, ConfigMap'и та багато патернів політик, можуть бути переносними, бо вони використовують API Kubernetes. Команда все одно має очікувати відмінностей у наданні балансувальників навантаження, класах зберігання, інтеграції ідентифікації, керуванні нодами, мережі та робочих процесах оновлення. Kubernetes зменшує прив'язку до постачальника, надаючи спільну модель управління, але провайдери все одно реалізують інфраструктурні інтеграції по-різному. Гарний дизайн відокремлює переносні маніфести застосунків від платформної конфігурації, специфічної для середовища.

Ваша компанія розгорнула свій перший кластер, і керівництво припускає, що проєкт експлуатації завершено. Які обов'язки Day 2 ви маєте підняти негайно?

Ви маєте підняти моніторинг, оповіщення, контроль доступу, планування оновлень, резервне копіювання та відновлення, мережеву політику, безпеку образів, управління вартістю та реагування на інциденти. Kubernetes автоматизує рутинне узгодження, але він не вирішує, хто може розгортати, що має сповіщати команду, як версії оновлюватимуться чи чи марнують робочі навантаження потужність. Робота Day 2 — це постійна практика експлуатації кластера як платформи. Ігнорування її зазвичай перетворює ранній успіх на пізнішу нестабільність.

Практична вправа: мислити декларативно

Ця вправа не вимагає реального кластера. Мета — попрактикувати ментальну модель, яку використовує Kubernetes: порівняти бажаний стан із поточним станом, а потім вжити найменшу коригувальну дію, яка зрушує дійсність до декларації. Використовуйте папір, текстовий файл чи дошку й опирайтеся спокусі спершу написати покроковий скрипт.

Сценарій: Ви — площина управління Kubernetes для нового вебмагазину. Ваше завдання — змоделювати, як узгодження обробляє звичайні зміни, не сприймаючи кожну відмову як окрему аварію.

Крок 1: Задекларуйте свій стан. Запишіть цей бажаний стан: «3 екземпляри Web Frontend, 1 екземпляр Payment Processor та 2 екземпляри Cache».
Крок 2: Початкове розгортання. Намалюйте ці 6 екземплярів як прямокутники, потім підпишіть малюнок «поточний стан збігається з бажаним станом».
Крок 3: Обробіть відмову. Закресліть один екземпляр Web Frontend, щоб змоделювати збій, потім запишіть поточну кількість поряд із бажаною.
Крок 4: Узгодьте. Намалюйте замінний екземпляр Web Frontend і поясніть, чому ви замінили один екземпляр, а не перепроєктували весь застосунок.
Крок 5: Масштабуйте вгору. Настає Чорна п’ятниця, тож змініть лише бажаний стан на «10 екземплярів Web Frontend» і додайте 7 прямокутників, яких бракує.
Крок 6: Оцініть відповідність. Вирішіть, чи виграє цей вебмагазин від Kubernetes, чи простішої платформи було б достатньо за його поточного розміру.

Підказка до розв'язання

Правильна ментальна модель полягає в тому, що бажаний стан — це ціль, а поточний стан — це спостереження. Після змодельованого збою кількість Web Frontend нижча за задекларовану, тож узгодження створює одну заміну. Після запиту на масштабування вгору ви не записуєте сім окремих імперативних дій як джерело істини; ви змінюєте бажану загальну кількість на десять і дозволяєте циклу керування зійтися. Фінальна оцінка має згадувати обидві сторони: Kubernetes допомагає, якщо цей магазин потребує повторюваного масштабування та відновлення, але простіша платформа може бути кращою, якщо магазин малий, а команда поки не може експлуатувати кластер.

Критерії успіху:

Ви можете пояснити різницю між бажаним станом і поточним станом, не використовуючи завчене визначення.
Ви можете описати, чому впала репліка призводить до роботи із заміни, а не до ручного ремонту сервера.
Ви можете порівняти Kubernetes із ВМ, керованим платформним сервісом та середовищем виконання контейнерів у практичних термінах.
Ви можете визначити щонайменше три обов’язки Day 2, які все ще існують після успіху першого розгортання.
Ви можете оцінити, чи виправданий Kubernetes для робочого навантаження, замість того щоб припускати, що кожен контейнеризований застосунок належить кластеру.

Джерела

Наступний модуль

Модуль 1.2: Основи контейнерів добудовує відсутній нижній рівень, показуючи, як контейнери пакують процеси, файлові системи та налаштування середовища виконання, що значно полегшить осмислення Pod’ів та Деплойментів Kubernetes.