Частина 0. Підсумковий тест: середовище та техніка складання іспиту

Lab Progress 0/5 completed

Складність: [СЕРЕДНЯ]

Час на проходження: 45–60 хвилин

Передумови: Частина 0.1 Налаштування кластера, Частина 0.2 Майстерність оболонки, Частина 0.3 Vim для YAML, Частина 0.4 Навігація документацією, Частина 0.5 Стратегія іспиту

Версія Kubernetes: 1.35+

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

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

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

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

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

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

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

Кандидат може досконало розуміти Pod’и, Deployment’и, Service’и та планування — і все одно провалити іспит у перші кілька хвилин лише через те, що робочий контекст виявився неправильним. Один інженер у навчальній групі під час пробного іспиту створив усі свої ресурси не в тому кластері просто тому, що запрошення термінала виглядало знайомо, а перше завдання здалося легким. Команди були синтаксично правильні, YAML був цілком коректний, а діагностика — компетентна, проте вся ця робота не дала жодного бала, бо потрапила не туди, куди мала.

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

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

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

Основний матеріал: цикл іспиту — це система керування

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

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

+-------------------+     +-------------------+     +-------------------+
|  1. Target Check  | --> |  2. Method Choice | --> |  3. Change State  |
|  context, ns, ask |     |  command, YAML,   |     |  create, patch,   |
|  scoring object   |     |  docs, explain    |     |  edit, delete     |
+-------------------+     +-------------------+     +-------------------+
          ^                         |                         |
          |                         v                         v
+-------------------+     +-------------------+     +-------------------+
|  5. Confidence    | <-- |  4. Verification  | <-- |  System Response  |
|  done, defer, or  |     |  get, describe,   |     |  events, status,  |
|  revisit later    |     |  logs, explain    |     |  errors, output   |
+-------------------+     +-------------------+     +-------------------+

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

Протягом Частини 0 ви вивчили окремі інструменти: kubeadm, kind, аліас kubectl, змінні оболонки, налаштування Vim, kubectl explain, документацію Kubernetes та триетапний метод. У цьому підсумковому модулі ці інструменти стають одним робочим процесом. Інструмент готовий до іспиту лише тоді, коли ви знаєте, де його місце у циклі та якій помилці він запобігає.

Перша професійна звичка — відокремлювати команди дії від команд-доказів. Команди дії змінюють кластер: create, apply, patch, delete, scale, cordon або редагування маніфеста статичного Pod’а. Команди-докази зменшують невизначеність: get, describe, logs, events, auth can-i, explain та пошук у документації. Кандидати під тиском часто виконують команди дії, коли мали б збирати докази, що породжує нові симптоми, які приховують початкову проблему.

Друга професійна звичка — тримати перевірку близько до формулювання завдання. Якщо запитання вимагає три репліки, перевірка має містити лічильники READY або вивід JSONPath, що доводить число. Якщо запитання вимагає селектор міток, перевірка має довести, що вибрані Pod’и відповідають Service’у або робочому навантаженню. Якщо запитання вимагає ремонт статичного Pod’а, перевірка має оглянути дзеркальний Pod, керований kubelet, а не лише файл, який ви відредагували.

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

Запит на активне навчання: Уявіть, що перше екзаменаційне завдання просить вас створити Deployment у просторі імен app-prod, але ваш поточний контекст указує на інший кластер, а ваш типовий простір імен — default. Які дві команди зловили б обидві небезпеки, перш ніж ви щось створите, і чому перевірка лише однієї з них усе одно залишить ризик?

Практична відповідь почалася б із видимості контексту та простору імен, а не зі створення ресурсу. k config current-context ловить ціль кластера, тоді як k config view --minify --output 'jsonpath={..namespace}{"\n"}' або явний -n app-prod ловить дрейф простору імен. Перевірка лише контексту доводить кластер, але не простір імен; перевірка лише простору імен усе одно може помістити об’єкт у неправильний кластер.

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

alias k=kubectl
complete -o default -F __start_kubectl k

Хороший цикл також має схильність до оборотних операцій. Генерування YAML за допомогою --dry-run=client -o yaml є безпечнішим за ручне набирання цілого об’єкта з пам’яті. Застосувати сфокусований маніфест легше перевірити, ніж великий вставлений блок. Видалення зламаного об’єкта може бути правильним у деяких завданнях, але воно має відбуватися тому, що завдання чи діагноз це виправдовують, а не тому, що термінал став заплутаним.

Цикл достатньо простий, щоб його запам’ятати, але дисципліна полягає у його застосуванні тоді, коли запитання здається легким. Легкі запитання — це там, де багато кандидатів пропускають ворота цілі. Складні запитання — це там, де багато кандидатів пропускають ворота впевненості й витрачають забагато часу на гонитву за одним непевним симптомом.

Основний матеріал: безпека цілі перед швидкістю

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

Мінімальний безпечний старт для кожного запитання — прочитати запитуваний контекст із завдання та свідомо перемкнутися. Не покладайтеся на попереднє запитання, на запрошення оболонки чи на м’язову пам’ять. Команда коротка, а ціна її пропуску висока.

k config use-context <context-from-question>
k config current-context

Після контексту ставтеся до простору імен як до частини цілі. Деякі завдання називають простір імен явно, деякі очікують типовий простір імен, а деякі надають наявний об’єкт, який підказує вам, де має бути робота. Безпечна команда використовує -n <namespace>, коли завдання його називає, бо явні прапорці простору імен зменшують залежність від прихованого стану термінала.

k get ns
k get all -n <namespace-from-question>

Коли завдання стосується наявного об’єкта, огляньте цей об’єкт, перш ніж його змінювати. Наприклад, якщо завдання каже, що Deployment не працює, не починайте з видалення Pod’ів. Почніть із get, describe, а можливо, й logs, бо вони зберігають докази. Мета — визначити, чи є збій проблемою образа, проблемою планування, проблемою проб, проблемою селектора, проблемою прав доступу чи проблемою конфігурації.

k get deploy -n <namespace>
k describe deploy <name> -n <namespace>
k get pods -n <namespace> -o wide

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

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

sudo ls /etc/kubernetes/manifests/
k get pods -n kube-system
k describe pod <control-plane-pod-name> -n kube-system

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

Поширена помилка початківця — плутати інструменти створення кластера з інструментами його експлуатації. kubeadm init створює площину управління на вузлі; kubectl спілкується із сервером API, описаним у kubeconfig; kind створює локальні кластери в контейнерах; Vim редагує файли. Під час іспиту ви зазвичай експлуатуєте наявний кластер, а не завантажуєте його з нуля, тож знання про налаштування кластера здебільшого корисні для діагностики того, як поєднуються частини площини управління.

Наступне порівняння менше про запам’ятовування інструментів і більше про вибір правильного рівня під час діагностики проблеми. Якщо сервер API недосяжний, команд kubectl може бути недостатньо. Якщо Deployment неправильно налаштований, перезапуск kubelet — майже напевно неправильний рівень. Хороші оператори обирають рівень, що відповідає симптому.

Ситуація	Найкращий стартовий рівень	Чому цей рівень підходить	Перша команда-доказ
Нові Pod’и залишаються в стані Pending, тоді як наявні Pod’и працюють	Планувальник та обмеження Pod’а	API працює, але розміщення не відбувається або не може відбутися	`k describe pod <pod> -n <ns>`
Сервер API недосяжний з kubectl	Kubeconfig, сервер API або служба вузла	Клієнтські команди не можуть підтвердити стан навантаження, поки не відновиться зв’язок	`k cluster-info`
Статичний Pod площини управління зникає	Каталог маніфестів kubelet	Життєвий цикл статичного Pod’а залежить від локальних файлів, за якими стежить kubelet	`sudo ls /etc/kubernetes/manifests/`
Service не має ендпоінтів	Мітки та селектори	Service існує, але може не відповідати потрібним Pod’ам	`k get endpoints -n <ns>`
Застосування YAML зазнає невдачі з помилкою схеми	Структура маніфеста та поля API	Кластер відхилив об’єкт ще до того, як поведінка під час виконання матиме значення	`k explain <resource>.<field>`

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

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

Надійне формулювання цілі може звучати так: «У контексті cluster-a, простір імен web, Deployment frontend має запускати три готові репліки з образом nginx:1.35 та надавати порт вісімдесят через Service типу ClusterIP.» Це речення дає вам достатньо інформації, щоб обрати команди, згенерувати YAML та перевірити готовність, не перечитуючи раз за разом увесь запит.

Основний матеріал: генерування команд, редагування YAML та документація

Швидка робота з Kubernetes залежить від використання командного рядка для створення правильних відправних точок. Генерування YAML за допомогою --dry-run=client -o yaml дає змогу уникнути багатьох помилок відступу та форми API, особливо для поширених об’єктів, як-от Pod’и, Deployment’и, Service’и, Job’и, ConfigMap’и та Secret’и. Згенерований маніфест не завжди є остаточною відповіддю, але це безпечніший скелет, ніж писання кожного поля вручну.

Багато хто з тих, хто вчиться, визначає помічник оболонки на ім’я do для виводу dry-run під час практики. Якщо ваша оболонка це підтримує, змінна на кшталт do="--dry-run=client -o yaml" може пришвидшити генерування, але ви маєте розуміти розгорнуту команду, перш ніж на неї покладатися. На іспиті помічник, який ви не можете пояснити, стає ще одним джерелом ризику.

do="--dry-run=client -o yaml"
k create deploy web --image=nginx:1.35 --replicas=3 $do > web-deploy.yaml

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

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

cat > ~/.vimrc <<'EOF'
set tabstop=2
set shiftwidth=2
set expandtab
set number
set ruler
EOF

Найважливіша навичка у Vim — не якесь маловідоме скорочення. Це здатність робити невеликі, контрольовані правки, зберігаючи відступи. Вам потрібно вставляти поля на правильному рівні, безпечно дублювати сусідні рядки, видаляти неправильні розділи та швидко зберігати. Команди на кшталт dd, yy, p, u, :w та :q! мають значення, бо тримають вашу увагу на маніфесті, а не на редакторі.

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

:set paste
:set nopaste

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

k explain deployment.spec.strategy
k explain pod.spec.containers.readinessProbe

Для невизначеності на рівні поля kubectl explain зазвичай швидший за відкривання браузера. Він дає шлях ресурсу, тип поля та опис зі схеми OpenAPI кластера. Для багатоетапних завдань, як-от налаштування проби, створення NetworkPolicy або перевірка прикладів Gateway API, сайт документації часто надає кращі придатні для виконання приклади.

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

Запит на активне навчання: Вам потрібно додати пробу готовності до Deployment’а, але ви пам’ятаєте лише, що поле належить десь під containers. Чи скористалися б ви k explain, документацією чи обома? Спочатку вирішіть, а потім порівняйте свій вибір із міркуваннями в наступному абзаці.

Хороший вибір — почати з k explain pod.spec.containers.readinessProbe або еквівалентного шляху шаблону Deployment’а, якщо вам швидко потрібна структура поля. Якщо вам також потрібен повний приклад зі шляхом і портом HTTP, офіційна документація стає в пригоді після підтвердження шляху поля. Цей двокроковий підхід запобігає й нечіткому переглядові, й сліпому редагуванню YAML.

Конкретний приклад робить патерн наочним. Припустімо, завдання каже: «У просторі імен web створіть Deployment на ім’я portal із трьома репліками, що використовує образ nginx:1.35, потім надайте його на порту вісімдесят усередині кластера.» Поспішний кандидат може набрати кілька команд із пам’яті й припустити успіх. Контрольований кандидат генерує, застосовує, надає та перевіряє селектори й ендпоінти.

k config use-context <task-context>
k create ns web
k create deploy portal --image=nginx:1.35 --replicas=3 -n web
k expose deploy portal --port=80 --target-port=80 -n web
k rollout status deploy/portal -n web
k get deploy,svc,endpoints -n web

Перевірка не є декоративною. rollout status доводить, що контролер Deployment’а досяг бажаного стану, тоді як get deploy,svc,endpoints показує, чи має Service ендпоінти. Якщо ендпоінти порожні, Service може мати неправильний селектор, Pod’и можуть бути не Ready, або Pod’ів може не бути у просторі імен, який ви очікували.

Тепер розгляньте схоже завдання, що потребує мітки tier=frontend на шаблоні Pod’а та Service’у, який вибирає цю мітку. У цьому випадку негайного надання Deployment’а може бути недостатньо, бо згенерований селектор може слідувати типовим міткам Deployment’а, а не запитуваному завданням селектору. Ви згенерували б або відредагували б YAML, підтвердили мітки і під spec.selector.matchLabels, і під spec.template.metadata.labels, а потім застосували й перевірили ендпоінти.

Звичка рівня досвідченого фахівця — поєднувати кожну згенеровану команду з моделлю ресурсів. Deployment володіє ReplicaSet’ами, ReplicaSet’и створюють Pod’и, Service’и вибирають Pod’и через мітки, а готовність впливає на те, чи заповнено ендпоінти. Коли перевірка зазнає невдачі, ця модель підказує, де шукати далі.

+---------------------+       owns        +---------------------+       creates      +---------------------+
| Deployment portal   | ----------------> | ReplicaSet revision | ----------------> | Pods with labels    |
| desired replicas=3  |                   | selector matches    |                   | app=portal          |
+---------------------+                   +---------------------+                   +---------------------+
                                                                                              |
                                                                                              | selected by labels
                                                                                              v
                                                                                  +---------------------+
                                                                                  | Service portal      |
                                                                                  | endpoints populated |
                                                                                  +---------------------+

Якщо Service не має ендпоінтів, не перестворюйте кластер і не перезапускайте випадкові Pod’и. Порівняйте селектор Service’у з мітками Pod’ів. Це діагностичний крок рівня 4, бо він аналізує відношення між ресурсами, а не пригадує команду.

k get svc portal -n web -o yaml
k get pods -n web --show-labels
k get endpoints portal -n web -o wide

Це також місце, де документація може запобігти надмірному виправленню. Селектор Service’у не є мовою довільних запитів; це відображення ключів та значень міток, які мають збігатися з мітками Pod’ів. Якщо селектор каже tier: frontend, Pod має нести tier=frontend на рівні шаблону Pod’а, а не лише в метаданих Deployment’а.

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

Основний матеріал: розібраний приклад діагностики

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

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

k get pods -n <namespace> -o wide

Якщо Pod у стані Pending, наступна команда — зазвичай describe pod, бо збої планування з’являються як події. Якщо Pod у стані Running, але не Ready, огляньте проби готовності, стани контейнерів та логи. Якщо Pod у стані CrashLoopBackOff, мають значення логи та попередні логи. Якщо Pod’а не існує, огляньте контролер, який мав його створити.

k describe pod <pod-name> -n <namespace>
k logs <pod-name> -n <namespace>
k logs <pod-name> -n <namespace> --previous

Ось розібраний приклад. Завдання каже: «У просторі імен orders полагодьте Deployment api, щоб він став доступним. Не змінюйте запитуваний образ, якщо тільки образ не є причиною.» Кандидат спочатку підтверджує ціль, потім оглядає Deployment та Pod’и.

k config use-context <task-context>
k get deploy api -n orders
k get pods -n orders -o wide
k describe pod <api-pod-name> -n orders

Подія Pod’а показує Readiness probe failed: HTTP probe failed with statuscode: 404. Це означає, що контейнер працює, планування вдалося, а образ, імовірно, не є першим підозрюваним. Збій — у шляху, порту проби готовності або поведінці застосунку. Необачне виправлення видалило б Deployment або змінило б образ. Сфокусоване виправлення перевіряє поля проби.

k get deploy api -n orders -o yaml > api.yaml

Припустімо, маніфест містить такий відповідний розділ. Шлях — /healthz, але застосунок надає /ready згідно з приміткою до завдання або логами. Правильна правка вузька: оновити шлях проби готовності й застосувати повторно.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: orders
spec:
  template:
    spec:
      containers:
        - name: api
          image: registry.k8s.io/e2e-test-images/agnhost:2.55
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080

Після редагування перевірка має довести, що Deployment стає доступним, а не лише те, що kubectl apply спрацював. Застосування маніфеста доводить тільки те, що сервер API прийняв об’єкт. Контролеру ще треба розгорнути Pod’и, пробам ще треба пройти, а статусу ще треба зійтися.

k apply -f api.yaml
k rollout status deploy/api -n orders
k get deploy api -n orders
k get pods -n orders

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

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

k get pods -n kube-system
sudo ls /etc/kubernetes/manifests/
sudo sed -n '1,160p' /etc/kubernetes/manifests/kube-scheduler.yaml

Якщо маніфест планувальника відсутній, kubelet не може створити статичний Pod планувальника з цього файлу. У навчальному кластері відновлення маніфеста з резервної копії або виправлення його імені може відновити планування. У екзаменаційному завданні уважно дотримуйтеся наданого середовища та обмежень завдання, бо запитання про ремонт площини управління можуть мати вузький очікуваний набір змін.

Практичне діагностичне запитання: «Який контролер чи агент відповідає за відсутню поведінку?» Якщо Pod’и не розміщуються на вузлах, причетний планувальник. Якщо Deployment не створює Pod’ів, причетні контролер Deployment’а та ланцюжок ReplicaSet. Якщо статичний Pod не з’являється, причетні kubelet та каталог маніфестів. Якщо трафік Service’у не проходить, причетні селектори, ендпоінти, готовність та мережа.

Запит на активне навчання: Pod у стані Running, але Service не має ендпоінтів. Перш ніж читати відповідь, оберіть перші два відношення, які ви б оглянули. Уникайте вибору команд із пам’яті; оберіть відношення ресурсів, які могли б пояснити симптом.

Перше відношення — селектор Service’у до міток Pod’а, бо ендпоінти залежать від відповідних Pod’ів у стані Ready. Друге відношення — готовність Pod’а до публікації ендпоінта, бо відповідний Pod усе одно може бути виключений, якщо він не Ready. Команди випливають із цих відношень: огляньте svc -o yaml, pods --show-labels, endpoints та деталі готовності Pod’а.

k get svc <service> -n <namespace> -o yaml
k get pods -n <namespace> --show-labels
k get endpoints <service> -n <namespace> -o wide
k describe pod <pod> -n <namespace>

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

Основний матеріал: стратегія іспиту під тиском часу

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

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

Другий етап — для завдань, які потребують редагування, звернення до документації або двох-трьох пов’язаних ресурсів. Приклади — додавання проб, створення Job’а з конкретною командою, налаштування тома ConfigMap або корегування міток і селекторів. Ці завдання все ще керовані, але вони потребують уважнішого читання та перевірки.

Третій етап — для завдань із відкритою діагностикою, симптомами площини управління, роботою на рівні вузла або непевними режимами збою. Запитання, що каже «продіагностуйте, чому Pod’и не запускаються», може стати простим після збору доказів, але починається з невідомого обсягу. Позначення його для третього етапу — не уникання; це керування часом.

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

Тиск балів може спокусити кандидатів на часткову роботу. Часткова робота іноді не дає балів, якщо очікуваний стан ресурсу відсутній, тож перевірка — це діяльність із набирання балів, а не діяльність із наведення лиску. Завершене завдання має докази, що відповідають інструкції. Лише спроба завдання має команди в історії оболонки.

Тримайте чернеткові нотатки мінімальними та структурованими. Під час іспиту вам не потрібні абзаци; вам потрібна черга відкладених завдань і причина, чому їх відкладено. Корисна нотатка може бути такою: «Q6 етап3: pod’и Pending у payments; перевірити планувальник/події після швидких перемог.» Ця нотатка зберігає контекст, не крадучи час.

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

Досвідчений оператор також знає, коли припинити вдосконалення розв’язку. Якщо завдання просить Service типу ClusterIP, а ендпоінти заповнено, не витрачайте додатковий час на те, щоб зробити YAML красивішим. Якщо завдання просить оновлення образа Deployment’а, а rollout status успішний, не оглядайте кожен непов’язаний Pod у просторі імен. Завершення означає відповідність вимозі, а не вичерпання цікавості.

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

Сигнал у завданні	Імовірний етап	Патерн міркування	Прив’язка перевірки
«Створіть простір імен» або «масштабуйте цей Deployment»	Етап 1	Пряма команда, низька неоднозначність, короткий цикл зворотного зв’язку	`k get` для точного стану об’єкта
«Створіть із YAML із цими полями»	Етап 2	Генерування плюс правка, розташування поля має значення	`k apply`, `k get -o yaml`, статус
«Додайте пробу, том або змінну середовища»	Етап 2	Потребує правильного шляху API під шаблоном Pod’а	`k explain`, статус розгортання, describe
«Продіагностуйте, чому Pod’и не запускаються»	Етап 3	Невідомий рівень збою, доки не оглянуто події та стани	`describe`, логи, події
«Компонент площини управління відсутній»	Етап 3	Ремонт на рівні вузла чи статичного Pod’а може вплинути на здоров’я кластера	Pod’и kube-system, маніфести, події
«Скористайтеся документацією, щоб налаштувати можливість»	Етап 2	Імовірно потрібне обмежене звернення для точного синтаксису	Офіційний приклад плюс статус кластера

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

Основний матеріал: підсумковий огляд готовності

Готовність до Частини 0 вимірюється не тим, чи можете ви повторити двадцять фактів. Вона вимірюється тим, чи можете ви працювати в терміналі Kubernetes, не втрачаючи цілі, структури чи доказів. Наступний огляд поєднує попередні модулі в єдину модель готовності.

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

Із майстерності оболонки вам потрібне виконання команд із низьким тертям. Аліас k, доповнення, генерування dry-run та форматування виводу заощаджують час лише тоді, коли залишаються прозорими. Якщо помічник приховує забагато, сповільніться й розгорніть його. Іспит винагороджує плавність, а не таємничість.

Із Vim вам потрібне надійне редагування маніфестів. Коректність YAML — це не візуальна охайність; це структурне значення. Двопробільний відступ, пробіли замість табуляцій, режим вставлення за потреби та невеликі правки запобігають помилкам, які важко побачити під тиском.

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

Зі стратегії іспиту вам потрібна пріоритизація за етапами. Триетапний метод — це стратегія набирання балів, але це також стратегія керування когнітивним навантаженням. Вона не дає одній непевній проблемі поглинути увагу, потрібну для кількох простих завдань.

Сильний учень Частини 0 може пояснити, чому кожна звичка існує. Перевірки контексту запобігають роботі над неправильною ціллю. Dry-run YAML запобігає структурним помилкам. Налаштування Vim захищають відступи. Документація запобігає вигадуванню полів. Перевірка перетворює зроблену спробу на оцінену роботу. Стратегія етапів захищає час.

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

Перш ніж складати підсумковий тест, зробіть паузу й подумки відрепетируйте цей компактний робочий процес: контекст, простір імен, ресурс, метод, правка, застосування, перевірка, рішення. Це речення — не гасло й не мнемонічна примовка; це конкретний порядок виконання. Якщо ви можете застосувати його до незнайомих запитань, які бачите вперше, то Частина 0 зробила свою справу.

Чи знали ви?

Факт 1: kubectl explain читає інформацію про схему, яку надає сервер API Kubernetes, а це означає, що він може відображати поля ресурсу, доступні в кластері, який ви насправді використовуєте, а не випадковий приклад із пам’яті.
Факт 2: Статичні Pod’и керуються kubelet із файлів на вузлі, тож зламаний маніфест може вплинути на компонент площини управління навіть тоді, коли API Kubernetes іще достатньо справний, щоб показувати дзеркальні Pod’и.
Факт 3: Service із дійсним ClusterIP усе одно може надсилати трафік у нікуди, якщо його селектор не відповідає жодному Pod’у у стані Ready, і саме тому ендпоінти часто є кращим доказом перевірки, ніж сам об’єкт Service.
Факт 4: Тиск часу на іспиті робить перевірку важливішою, а не менш важливою, бо швидке неперевірене завдання може мовчки не дати балів і водночас дати вам хибну впевненість.

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

Помилка	Чому це шкодить	Краща практика
Початок завдання без перемикання контексту	Правильні ресурси, створені в неправильному кластері, зазвичай не оцінюються й можуть ввести в оману подальшу діагностику	Виконайте `k config use-context <context>` і підтвердьте `k config current-context` перед оцінюваними змінами
Припущення, що простір імен із попереднього запитання все ще діє	Ресурси з простором імен можуть виглядати відсутніми чи зламаними, коли їх створено в іншому просторі імен	Використовуйте явні прапорці `-n <namespace>` щоразу, коли завдання називає простір імен
Писання великого YAML вручну з пам’яті	Невеликі помилки відступу чи шляху поля можуть змарнувати більше часу, ніж зайняло б генерування	Згенеруйте скелет із виводом dry-run, потім редагуйте лише ті поля, яких вимагає завдання
Ставлення до `kubectl apply` як до перевірки	Apply доводить тільки те, що API прийняв об’єкт, а не те, що контролери зійшлися чи трафік працює	Перевіряйте за допомогою статусу розгортання, стану ресурсу, подій, міток, ендпоінтів або логів, як доречно
Використання документації без конкретного запитання	Широкий перегляд палить час і збільшує шанс скопіювати недоречні приклади	Спершу визначте відсутнє поле чи патерн, знайдіть його, застосуйте, потім поверніться до перевірки
Видалення Pod’ів до збору доказів	Видалення може стерти корисний стан і може просто відтворити той самий збій під контролером	Огляньте статус, події, логи та контролери-власники перед руйнівними діями
Недбале редагування маніфестів статичних Pod’ів	Некоректний маніфест площини управління може прибрати критичний компонент, доки kubelet не прийме виправлений файл	Уважно огляньте файл, збережіть відступи й перевірте дзеркальний Pod у `kube-system`
Витрачання надто довгого часу на невідомий збій	Одне відкрите завдання може поглинути час, потрібний для кількох прямих завдань	Класифікуйте непевну діагностику як третій етап, запишіть нотатку й поверніться після швидких перемог

Тест

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

1. Запобігання неправильній цілі

Ви відкриваєте нове екзаменаційне запитання, що каже: «Використовуйте контекст cluster-b та простір імен payments.» Ваше запрошення все ще показує знайому назву кластера з попереднього завдання, і ви впевнені, що знаєте команду для ресурсу. Що ви маєте зробити, перш ніж щось створювати, і який ризик залишиться, якщо ви перевірите лише контекст?

Відповідь

Спершу перемкніть і підтвердьте контекст, потім або встановіть, або явно використовуйте простір імен у подальших командах. Безпечний старт — k config use-context cluster-b, k config current-context, а потім команди з -n payments або перевіреним налаштуванням простору імен. Перевірка лише контексту все одно залишає ризик простору імен, бо ресурси з простором імен, створені в default, не задовольнять завдання, що вимагає payments.

2. Вибір генерування замість пам’яті

Завдання просить вас створити Deployment на ім’я worker з двома репліками, образом busybox:1.36 та командою sleep 3600, потім зберегти маніфест перед застосуванням. Ви пам’ятаєте більшість структури Deployment’а, але не впевнені, де належать аргументи команди. Який підхід найкраще збалансовує швидкість і коректність?

Відповідь

Згенеруйте скелет Deployment’а з виводом dry-run, потім відредагуйте поля команди контейнера у збереженому маніфесті та застосуйте його. Наприклад, скористайтеся k create deploy worker --image=busybox:1.36 --replicas=2 --dry-run=client -o yaml > worker.yaml, потім відредагуйте spec.template.spec.containers[0].command та args за потреби. Якщо ви не впевнені у точній формі поля, скористайтеся k explain pod.spec.containers.command та k explain pod.spec.containers.args перед застосуванням.

3. Діагностика Pod’ів у стані Pending

Ваша команда успішно створила Deployment, але всі нові Pod’и залишаються в стані Pending. Наявні Pod’и в інших просторах імен усе ще працюють, а сервер API відповідає нормально. Які докази вам слід зібрати першими й чому зміна образа є слабким першим кроком?

Відповідь

Почніть із k get pods -n <namespace> -o wide та k describe pod <pod> -n <namespace>, щоб прочитати події планування. Pending зазвичай означає, що Pod не призначено вузлу або його не можна запланувати через обмеження, відсутні ресурси, taints чи проблеми планувальника. Зміна образа спрямована на запуск контейнера після планування, тож це слабкий перший крок, якщо тільки події справді не згадують завантаження образа або створення контейнера.

4. Ремонт Service’у без ендпоінтів

Service існує й має ClusterIP, але трафік не проходить, а k get endpoints не показує адрес. Pod’и застосунку в стані Running. Які відношення вам слід оглянути й який результат підтвердить виправлення?

Відповідь

Огляньте селектор Service’у, мітки Pod’ів та готовність Pod’ів. Скористайтеся k get svc <name> -n <ns> -o yaml, k get pods -n <ns> --show-labels, k describe pod <pod> -n <ns> та k get endpoints <name> -n <ns> -o wide. Виправлення підтверджено, коли селектор Service’у відповідає Pod’ам у стані Ready, а об’єкт ендпоінтів містить очікувані IP-адреси та порти Pod’ів.

5. Робота зі зламаним статичним Pod’ом

На вузлі площини управління відсутній Pod планувальника, а новостворені Pod’и не призначаються вузлам. Ви маєте доступ до вузла. Яке розташування файлу та який простір імен Kubernetes найдоречніші й як вам слід перевірити відновлення?

Відповідь

Перевірте /etc/kubernetes/manifests/ на вузлі площини управління, бо kubelet керує статичними Pod’ами площини управління з цього каталогу. Дзеркальний Pod планувальника має з’явитися у просторі імен kube-system, коли маніфест присутній і дійсний. Перевірте за допомогою sudo ls /etc/kubernetes/manifests/, огляньте чи відновіть маніфест планувальника згідно із завданням, потім виконайте k get pods -n kube-system та зробіть describe Pod’а планувальника, якщо він не стає справним.

6. Рішення, коли використовувати документацію

Запитання просить вас додати пробу готовності HTTP до наявного Deployment’а. Ви знаєте концепцію, але не впевнені щодо точного шляху YAML під шаблоном Pod’а. Яка найшвидша безпечна стратегія звернення?

Відповідь

Скористайтеся kubectl explain для точного шляху API, потім використовуйте офіційну документацію лише тоді, коли вам потрібен повніший приклад. Команди на кшталт k explain deployment.spec.template.spec.containers.readinessProbe та пов’язаних підполів можуть підтвердити, де належить проба. Це безпечніше за вгадування відступу й швидше за широкий перегляд, бо звернення прив’язане до конкретного відсутнього поля.

7. Застосування триетапного методу

Ви оглядаєте пробний іспит і бачите три завдання: створити простір імен, додати том ConfigMap до Deployment’а та продіагностувати, чому кілька Pod’ів не запускаються. Як вам слід їх упорядкувати й які докази свідчать, що перше завдання завершене?

Відповідь

Спершу створіть простір імен як швидку перемогу першого етапу, обробіть том ConfigMap як завдання другого етапу з правкою маніфеста й відкладіть відкрите діагностичне завдання до третього етапу, якщо тільки симптом не стане очевидним швидко. Завдання зі створення простору імен завершене, коли k get ns <name> показує, що простір імен існує у правильному контексті. Упорядкування захищає бали, завершуючи роботу з низькою невизначеністю перед витрачанням часу на ширшу діагностику.

8. Перевірка розгортання замість припущення про нього

Ви оновлюєте образ Deployment’а, і kubectl apply повідомляє, що об’єкт налаштовано. Запитання вимагає, щоб Deployment успішно запускав новий образ. Які додаткові перевірки вам слід виконати, перш ніж позначити завдання виконаним?

Відповідь

Виконайте k rollout status deploy/<name> -n <ns> й огляньте Deployment та Pod’и, щоб підтвердити готовність і стан образа. Корисні перевірки — k get deploy <name> -n <ns>, k get pods -n <ns> та k describe pod <pod> -n <ns>, якщо розгортання застрягає. apply лише підтверджує, що API прийняв оновлений об’єкт; перевірка розгортання доводить, що контролер та Pod’и досягли запитуваного стану.

Практична вправа

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

Скористайтеся наявним локальним навчальним кластером Kubernetes, як-от kind, minikube чи іншим одноразовим середовищем. Не виконуйте ці кроки проти спільного робочого кластера. Якщо ваше навчальне середовище не використовує таку саму назву контексту, як у прикладах, свідомо підставте власний контекст і перевірте його, перш ніж продовжувати.

Крок 1. Установіть безпеку цілі

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

k config current-context
k create ns part0-review
k get ns part0-review

Крок 2. Створіть Deployment зі згенерованого скелета

Згенеруйте або безпосередньо створіть Deployment на ім’я portal із трьома репліками та образом nginx:1.35 у просторі імен вправи. Якщо ви спершу генеруєте YAML, огляньте його перед застосуванням, щоб ви могли поєднати команду зі структурою маніфеста.

k create deploy portal --image=nginx:1.35 --replicas=3 -n part0-review
k rollout status deploy/portal -n part0-review

Крок 3. Надайте Deployment і перевірте ендпоінти

Надайте Deployment за допомогою Service’у типу ClusterIP на порту вісімдесят. Потім перевірте не лише те, що Service існує, але й те, що ендпоінти заповнено. Цей крок підтверджує, що мітки, селектори, готовність Pod’ів та з’єднання Service’у узгоджені.

k expose deploy portal --port=80 --target-port=80 -n part0-review
k get svc,endpoints -n part0-review
k get pods -n part0-review --show-labels

Крок 4. Скористайтеся пошуком полів перед редагуванням

Скористайтеся kubectl explain, щоб оглянути шлях поля проби готовності. Вам не потрібно запам’ятовувати всю схему; вам потрібно відпрацювати звичку запитувати у кластера точну форму поля перед редагуванням YAML.

k explain deployment.spec.template.spec.containers.readinessProbe
k explain pod.spec.containers.readinessProbe.httpGet

Крок 5. Експортуйте, відредагуйте та застосуйте сфокусовану зміну маніфеста

Експортуйте Deployment, додайте пробу готовності до контейнера й застосуйте маніфест повторно. Використовуйте Vim із пробілами та уважними відступами або інший редактор лише тоді, коли він надійно зберігає структуру YAML.

k get deploy portal -n part0-review -o yaml > portal.yaml

Додайте цю пробу під контейнером, що запускає nginx:1.35, зберігаючи двопробільний відступ YAML відносно сусідніх полів.

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 3
  periodSeconds: 5

Застосуйте відредагований маніфест і перевірте, що розгортання знову сходиться.

k apply -f portal.yaml
k rollout status deploy/portal -n part0-review
k get deploy,pods,endpoints -n part0-review

Крок 6. Відпрацюйте діагностику селектора

Огляньте селектор Service’у та мітки Pod’ів, потім поясніть собі, чому ендпоінти існують. Якщо хочете виклику, тимчасово змініть селектор Service’у на мітку, яка не збігається, поспостерігайте, як ендпоінти зникають, потім відновіть правильний селектор. Робіть це лише в одноразовому просторі імен вправи.

k get svc portal -n part0-review -o yaml
k get pods -n part0-review --show-labels
k get endpoints portal -n part0-review -o wide

Крок 7. Приберіть свідомо

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

k delete ns part0-review

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

Ви підтвердили контекст Kubernetes перед створенням ресурсів вправи.
Ви створили простір імен part0-review і перевірили, що він існує, перш ніж продовжувати.
Ви створили Deployment portal із трьома репліками, використовуючи образ nginx:1.35, у правильному просторі імен.
Ви надали Deployment за допомогою Service’у й перевірили, що ендпоінти заповнено.
Ви скористалися kubectl explain, щоб оглянути поля проби готовності перед редагуванням маніфеста.
Ви відредагували YAML із дійсним відступом і застосували пробу готовності, не зламавши розгортання.
Ви перевірили кінцевий стан за допомогою статусу розгортання, стану Pod’ів, стану Service’у та ендпоінтів, а не покладалися лише на apply.
Ви можете пояснити, чому невідповідність селектора Service’у дала б порожній об’єкт ендпоінтів навіть тоді, коли Pod’и в стані Running.

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

Перейдіть до Частини 1: Архітектура кластера

Джерела

docs.linuxfoundation.org: дозволені ресурси сертифікації — сторінка дозволених ресурсів від The Linux Foundation явно дозволяє доступ до документації Kubernetes та явно дозволяє пошук на самому сайті, водночас забороняючи зовнішні результати пошуку.
kubernetes.io: організація доступу до кластера через kubeconfig — документація kubeconfig прямо зазначає, що кожен контекст має параметри кластера, простору імен і користувача та що kubectl за замовчуванням використовує поточний контекст.
kubernetes.io: деталі реалізації — сторінка деталей реалізації kubeadm явно документує шлях маніфеста, поведінку відстеження kubelet та розміщення у просторі імен kube-system для статичних Pod’ів площини управління, керованих kubeadm.
kubernetes.io: статичний pod — сторінка завдання про статичні Pod’и явно каже, що статичні Pod’и керуються kubelet і що kubelet автоматично намагається створити дзеркальний Pod для кожного з них.
kubernetes.io: kubectl create deployment — довідник kubectl create deployment явно документує --dry-run=client як друк об’єкта, який було б надіслано, без його надсилання.
kubernetes.io: kubectl explain — офіційний довідник kubectl explain каже, що інформація про кожне поле отримується із сервера у форматі OpenAPI.
kubernetes.io: deployment — документація Deployment’а явно зазначає, що .spec.selector має збігатися з .spec.template.metadata.labels.
kubernetes.io: endpoint slices — документація EndpointSlice каже, що Service’и із селекторами отримують EndpointSlice’и, що містять відповідні Pod’и, і що готовність ендпоінтів на основі Pod’а відображає умову Ready Pod’а.