Модуль 0.5: Стратегія іспиту — метод трьох проходів

Складність: [ШВИДКИЙ] — стратегія, дисципліна часу та звички виконання іспиту

Час на проходження: 20–30 хвилин на вивчення, повторювана практика з таймером для закріплення

Передумови: модулі 0.1–0.4, робочий shell та базова впевненість у запуску команд kubectl

Цільова версія Kubernetes: 1.35+

---

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

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

• Застосовувати метод трьох проходів, щоб розставляти пріоритети завдань CKA за балами, складністю та часом, що залишився.
• Сортувати питання іспиту на швидку, середню та складну роботу ще до того, як ви оберете шлях розв’язання.
• Оцінювати компроміси «бали за хвилину», коли кілька незавершених питань конкурують за обмежений час.
• Розробити повторюваний ритуал початку питання, який захищає від помилок із неправильним контекстом і неправильним простором імен.
• Відновлюватися після завдань із діагностики, де ви застрягли, зберігаючи часткові бали й переходячи до роботи з вищою впевненістю.

---

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

Гіпотетичний сценарій: ви починаєте CKA з достатнім знанням Kubernetes, щоб створювати Деплойменти, лагодити зламаний образ, перевіряти RBAC і читати офіційну документацію без паніки. Перше питання — це шумне завдання з діагностики ноди, тож ви витрачаєте початковий відрізок на пошук симптомів kubelet, поки таймер невпинно рухається. Коли ви нарешті заглядаєте вперед, на вас чекає кілька дрібніших питань: простір імен, ConfigMap, відкриття Сервісу та файл виводу. Ви провалилися не тому, що вам бракувало навичок Kubernetes; ви провалилися тому, що іспит змусив вас до операційної пріоритизації раніше, ніж ви мали для неї план.

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

Цей модуль навчає методу трьох проходів як повторюваної системи керування цим тиском. Прохід 1 накопичує швидку, знайому, перевірювану роботу. Прохід 2 опрацьовує стандартні багатокрокові завдання, які потребують маніфестів, документації або перевірок зв’язків. Прохід 3 витрачає час, що залишився, на діагностику та складний ремонт, де невизначеність вища, але часткові бали все одно можуть бути цінними. Ви відпрацюєте стратегію на тих самих матеріалах, які цей модуль використовував завжди: перевірки контексту, дисципліна простору імен, завдання з файлами виводу, RBAC, NetworkPolicy, PVC, діагностика Деплойментів і невеликий навчальний іспит на час.

Частина 1: застосуйте метод трьох проходів, перш ніж годинник почне думати за вас

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

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

+----------------------+------------------------+-------------------------+
| Linear Exam Thinking | What Actually Happens  | Strategic Correction    |
+----------------------+------------------------+-------------------------+
| Start at Question 1  | Early hard task stalls | Scan all questions      |
| Finish before moving | One bug eats minutes   | Time-box aggressively   |
| Treat tasks equally  | Points are uneven      | Compare point return    |
| Perfect each answer  | Optional polish grows  | Meet requirements only  |
| Review at the end    | No time remains        | Verify during each task |
+----------------------+------------------------+-------------------------+

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

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

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

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

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

Частина 2: сортуйте питання іспиту на швидку, середню та складну роботу

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

Мітки [QUICK], [MEDIUM] та [COMPLEX] — це не судження про те, наскільки добре ви знаєте Kubernetes. Це категорії планування саме для цієї спроби іспиту. Кандидат із сильним володінням RBAC може вважати RoleBinding середнім завданням і впоратися з ним швидко, тоді як інший кандидат потребуватиме документації щоразу. Стратегія лишається тією самою: не дозволяйте невизначеній роботі блокувати передбачувану роботу, якщо тільки бал і ваша впевненість не виправдовують цей компроміс.

Категорія	Типовий час	Поширені ознаки	Форма перевірки
[QUICK]	1–3 хвилини	Створити, масштабувати, додати мітку чи анотацію, відкрити знайомий об’єкт	Один kubectl get чи kubectl describe підтверджує результат
[MEDIUM]	4–6 хвилин	RBAC, PVC, NetworkPolicy, використання ConfigMap, просте правило планування	Маніфест плюс перевірка об’єкта підтверджують результат
[COMPLEX]	8–15 хвилин	Діагностувати, лагодити, налагоджувати, розслідувати, проблема ноди чи площини управління	Кілька діагностичних команд звужують збій, перш ніж виправлення спрацює

Швидке завдання зазвичай має прямий імперативний шлях. Створення Пода, масштабування Деплойменту, додавання мітки до об’єкта, відкриття Деплойменту або запис вибраних імен об’єктів у файл повинні мати короткий цикл зворотного зв’язку. Цей цикл цінний, бо закриває питання, поки вимога ще свіжа у вашій робочій пам’яті. Щойно вам знадобиться кілька сторінок документації або кілька діагностичних гілок, питання перестало поводитися як робота Проходу 1.

Середнє завдання зазвичай має більше ніж одну рухому частину. RBAC вимагає, щоб суб’єкт, Роль, RoleBinding, дієслова, ресурси та простір імен узгоджувалися. NetworkPolicy вимагає відрізнити захищені Поди від дозволених джерел. PVC вимагає правильних режимів доступу та запитів сховища в потрібному об’єкті. Жодне з цих завдань не є саме по собі загадковим, але кожне містить достатньо структури, щоб набирання з пам’яті могло створити дрібні помилки.

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

+-------------------+       +----------------------+       +--------------------+
| Read Question     | ----> | Estimate Work Type   | ----> | Choose Pass        |
+-------------------+       +----------------------+       +--------------------+
        |                              |                              |
        v                              v                              v
+-------------------+       +----------------------+       +--------------------+
| Context Required  |       | Predictable Command  |       | Pass 1: Quick      |
| Namespace Needed  |       | Documented Manifest  |       | Pass 2: Medium     |
| Output File Path  |       | Diagnostic Unknown   |       | Pass 3: Complex    |
+-------------------+       +----------------------+       +--------------------+

Перш ніж запускати це, який вивід ви очікуєте від власної категоризації? Візьміть три приклади завдань: створити Secret і змонтувати його в Под, полагодити kubelet, який не запускається, та записати у файл усі імена Подів із міткою tier=frontend. Завдання із Secret зазвичай середнє, бо поєднує створення об’єкта з конфігурацією Пода. Завдання з kubelet складне, бо причина невідома. Завдання з файлом виводу швидке, бо команда й перевірка прямі.

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

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

Частина 3: захистіть передбачувані бали за допомогою Проходу 1

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

Хороше завдання Проходу 1 має короткий шлях команди й короткий шлях перевірки. Завдання може просити простір імен, Под, зміну масштабу Деплойменту, мітку, анотацію, ConfigMap, Secret чи відкриття Сервісу. Такі завдання привабливі на початку, бо їх можна завершити повними командами, одразу перевірити, а тоді подумки закрити. Ви не повинні нести їх як незавершений фоновий шум, поки налагоджуєте складнішу проблему.

# Quick example: create a namespace, then verify it exists.
kubectl create namespace production
kubectl get namespace production

Цей приклад навмисно простий, бо команди іспиту мають бути придатними до копіювання й запуску у звичайних shell. Багато інженерів інтерактивно використовують короткий псевдонім для kubectl, але псевдоніми не розкриваються в неінтерактивних shell-скриптах і їх легко забути під тиском. У цьому курсі придатні до запуску shell-блоки використовують повне ім’я бінарного файлу kubectl. Це робить команду довшою, проте робить приклад однозначним і безпечнішим для учнів, які вставляють блоки у практичні скрипти.

# Quick example: create a Pod in a specified namespace, then verify readiness.
kubectl run web --image=nginx:1.25 -n production
kubectl get pod web -n production

# Quick example: scale a Deployment and confirm the desired replica count.
kubectl scale deployment api --replicas=3 -n production
kubectl get deployment api -n production

# Quick example: expose a Deployment and inspect the Service object.
kubectl expose deployment api --port=8080 --target-port=8080 -n production
kubectl get service api -n production

Перевірка — це частина відповіді, а не окрема фаза перегляду. Якщо перевіряльник очікує Под у production, а ви створили його в default, швидкий kubectl get ловить помилку, поки питання ще завантажене у вашій голові. Негайна перевірка також зменшує тиск фінального перегляду, бо ви можете довіряти завершеній роботі замість того, щоб наприкінці заново відкривати кожне питання.

Звичка Проходу 1	Чому це важливо	Приклад перевірки
Перемикайте контекст перед кожним питанням	Правильне розв’язання в неправильному кластері не дає балів за потрібне завдання	kubectl config current-context
Підтверджуйте простір імен перед створенням ресурсів	Багато завдань іспиту прив’язані до простору імен і тихо різняться за розташуванням	kubectl get ns target-ns
Віддавайте перевагу імперативним командам для простих об’єктів	Імперативні команди зменшують набір YAML і ризик синтаксису	kubectl get pod web -n production
Перевіряйте одразу після кожної зміни	Негайні перевірки ловлять помилки, поки вони ще дешеві	kubectl describe deployment api -n production

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

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

Частина 4: використовуйте Прохід 2 для стандартної багатокрокової роботи з Kubernetes

Прохід 2 — це місце, де задокументована механіка Kubernetes має найбільше значення. Ці завдання зазвичай не загадкові, але містять достатньо полів, щоб покладатися лише на пам’ять було ризиковано. Ви можете створити Роль і RoleBinding, змонтувати Secret, написати PVC, застосувати NetworkPolicy, налаштувати пробу або під’єднати ConfigMap до Пода. Екзаменаційна навичка — обрати шлях побудови з найнижчим ризиком, а потім перевірити саме той зв’язок, який цікавить перевіряльника.

Сильний робочий процес Проходу 2 починається з надійного шаблону, а не з порожнього файлу. Для RBAC імперативні команди часто зменшують набір тексту й роблять зв’язок суб’єкта явним. Для PVC і NetworkPolicy компактні маніфести можуть бути безпечнішими, бо вкладені поля мають значення. Найкращий вибір не завжди найкоротша команда; це шлях, який мінімізує помилки для об’єкта перед вами.

# Worked example setup: create a namespace and a service account for an RBAC task.
kubectl create namespace secure
kubectl create serviceaccount app-sa -n secure

# Worked example: create a Role and bind it to the ServiceAccount.
kubectl create role pod-reader --verb=get,list,watch --resource=pods -n secure
kubectl create rolebinding app-sa-pod-reader --role=pod-reader --serviceaccount=secure:app-sa -n secure

# Worked example verification: prove the binding grants the intended access.
kubectl auth can-i list pods --as=system:serviceaccount:secure:app-sa -n secure
kubectl get role,rolebinding,serviceaccount -n secure

Цей приклад RBAC демонструє повний цикл: створити об’єкти, з’єднати суб’єкт із дозволом і перевірити результат авторизації. Те, що API-сервер прийняв об’єкт, не означає, що завдання виконане правильно. RoleBinding може існувати, вказуючи на неправильний простір імен ServiceAccount, використовуючи неправильне ім’я Ролі або перебуваючи в неправильному просторі імен. Дисципліна Проходу 2 означає перевірку зв’язку, а не лише кількості об’єктів.

NetworkPolicy — класична тема Проходу 2, бо дійсний YAML усе одно може виражати протилежне до того, що ви мали на меті. Політика нижче захищає Поди, вибрані spec.podSelector, а потім дозволяє вхідний трафік від Подів, вибраних під ingress.from. Якщо ви поміняєте ці селектори місцями, маніфест усе одно застосується, але поведінка не відповідатиме вимозі. Прочитайте зв’язок трафіку звичайними словами, перш ніж застосувати файл.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: web
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

# Apply and inspect the NetworkPolicy after saving it as netpol.yaml.
kubectl create namespace web
kubectl apply -f netpol.yaml
kubectl describe networkpolicy allow-frontend-to-backend -n web

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

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

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

Частина 5: відновлюйтеся після застряглої діагностики за допомогою Проходу 3

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

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

+-------------------+      +-------------------+      +-------------------+
| Observe Symptoms  | ---> | Form Hypothesis   | ---> | Make Small Change |
+-------------------+      +-------------------+      +-------------------+
         ^                                                   |
         |                                                   v
+-------------------+      +-------------------+      +-------------------+
| Decide Next Step  | <--- | Verify Result     | <--- | Inspect New State |
+-------------------+      +-------------------+      +-------------------+

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

# Worked troubleshooting example: inspect the Deployment, Pod state, and recent events.
kubectl get deployment critical-app -n production
kubectl get pods -l app=critical-app -n production
kubectl describe pod -l app=critical-app -n production
kubectl get events -n production --sort-by='.lastTimestamp'

# If events show a bad image reference, update the image and watch the rollout.
kubectl set image deployment/critical-app critical-app=nginx:1.25 -n production
kubectl rollout status deployment/critical-app -n production
kubectl get pods -l app=critical-app -n production

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

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

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

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

Частина 6: розробіть ритуал початку питання для контексту, простору імен і файлів виводу

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

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

# Question-start routine: replace the context and namespace with the values from the task.
kubectl config use-context exam-cluster-a
kubectl config current-context
kubectl get namespace production

+------------------------+
| Every Question Starts  |
+------------------------+
| 1. Read context        |
| 2. Switch context      |
| 3. Confirm context     |
| 4. Check namespace     |
| 5. Solve requirement   |
| 6. Verify result       |
+------------------------+

Простори імен заслуговують на ту саму дисципліну. Багато об’єктів Kubernetes прив’язані до простору імен, і default рідко є безпечним припущенням для іспиту. Под на ім’я web у default не задовольняє завдання, яке просило web у production. Якщо ви створили об’єкт у неправильному просторі імен, спершу створіть його правильно. Видаляйте випадковий об’єкт лише тоді, коли прибирання безпечне й не краде час у потрібної роботи.

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

# Example: output Pod names with a label selector to an exact file path.
kubectl get pods -l tier=frontend -o custom-columns=NAME:.metadata.name --no-headers > /tmp/frontend-pods.txt
cat /tmp/frontend-pods.txt

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

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

Частина 7: оцінюйте компроміси «бали за хвилину»

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

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

+------------------+----------------------+-----------------------------+
| Time Remaining   | Best Use             | Usually Avoid               |
+------------------+----------------------+-----------------------------+
| 90+ minutes      | Finish quick tasks   | Deep troubleshooting first   |
| 45-90 minutes    | Medium tasks         | Optional polish             |
| 15-45 minutes    | Complex or leftovers | Starting vague rabbit holes  |
| 0-15 minutes     | Verify and quick fix | New multi-branch diagnosis   |
+------------------+----------------------+-----------------------------+

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

Зупиніться й вирішіть: у вас лишилося 18 хвилин, одне незаймане завдання з діагностики на 9 балів, одне незаймане завдання з PVC на 5 балів та одне незаймане завдання з файлом виводу на 4 бали. Запишіть свій порядок, перш ніж читати далі. Сильний порядок — файл виводу, PVC, потім діагностика, бо перші два завдання дуже придатні до перевірки й разом дорівнюють цінності невизначеного завдання. Якщо завдання з діагностики виявиться простим, ви все одно дійдете до нього з накопиченими балами за плечима.

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

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

Частина 8: «виконано за вимогою» — це достатньо добре

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

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

# Requirement-complete answer: create a Deployment with three replicas using the requested image.
kubectl create deployment web --image=nginx:1.25
kubectl scale deployment web --replicas=3
kubectl rollout status deployment/web

# Verification focuses on the stated requirement, not on cosmetic YAML quality.
kubectl get deployment web -o jsonpath='{.spec.replicas}{"\n"}'
kubectl get deployment web -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

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

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

Відповідям «виконано за вимогою» легше довіряти, коли ви перевіряєте саме те поле, яке назвала умова. Якщо умова просить три репліки, прочитайте .spec.replicas; якщо просить образ, прочитайте образ контейнера; якщо просить порт Сервісу, огляньте порт Сервісу та targetPort. Широкі команди на кшталт kubectl get all можуть бути корисними для орієнтації, але вони рідко є найсильнішим доказом. Точна перевірка прив’язує вашу впевненість до вимоги, а не до загального відчуття, що об’єкт виглядає нормально.

Частина 9: відпрацьоване міні-сортування на маленькому іспиті

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

+------------+----------------------------------------------+------------+----------------+
| Question   | Requirement                                  | Category   | Planned Pass   |
+------------+----------------------------------------------+------------+----------------+
| Q1         | Create Pod q1-pod running nginx               | QUICK      | Pass 1         |
| Q2         | Create NetworkPolicy for backend traffic      | MEDIUM     | Pass 2         |
| Q3         | Create PVC requesting 5Gi ReadWriteOnce       | MEDIUM     | Pass 2         |
| Q4         | Debug broken Deployment q4-broken             | COMPLEX    | Pass 3         |
+------------+----------------------------------------------+------------+----------------+

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

kubectl run q1-pod --image=nginx:1.25
kubectl get pod q1-pod

Прохід 2 опрацьовує Q3 і Q2. PVC коротше за NetworkPolicy, тож багатьом кандидатам варто зробити PVC першим. NetworkPolicy йде наступним, щойно простір імен і селектори стануть зрозумілими. Цей порядок захищає легше середнє завдання перед завданням із багатьма селекторами, яке має більше способів бути дійсним YAML, але неправильною поведінкою.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: q3-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

kubectl apply -f q3-pvc.yaml
kubectl get pvc q3-pvc

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: q2-netpol
  namespace: web
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

kubectl create namespace web
kubectl apply -f q2-netpol.yaml
kubectl describe networkpolicy q2-netpol -n web

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

kubectl get deployment q4-broken
kubectl get pods -l app=q4-broken
kubectl describe pod -l app=q4-broken
kubectl get events --sort-by='.lastTimestamp'

kubectl set image deployment/q4-broken nginx=nginx:1.25
kubectl rollout status deployment/q4-broken
kubectl get pods -l app=q4-broken

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

Патерни та антипатерни

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

Патерн або антипатерн	Коли з’являється	Кращий хід на іспиті
Патерн: огляд перед розв’язанням	На початку іспиту чи будь-якого нового розділу завдань	Збудуйте приблизний порядок проходів, перш ніж братися за глибоку роботу
Патерн: негайна перевірка	Після кожної команди create, apply, scale чи ремонту	Доведіть саме потрібну вимогу, поки умова ще свіжа
Патерн: перекласифікація застряглої роботи	Коли швидке чи середнє завдання починає вимагати діагностики	Перенесіть його на пізніший прохід і захистіть роботу з вищою впевненістю
Антипатерн: тунельний зір на перше питання	Складне початкове завдання здається таким, що його треба завершити перед усім іншим	Пропустіть після огляду, якщо невизначеність висока, а легші завдання є
Антипатерн: необов’язкове шліфування	Робоча відповідь спокушає додати незазначені найкращі практики	Зупиніться на «виконано за вимогою» та перевіреному стані
Антипатерн: перегляд лише наприкінці	Перевірку відкладено до фінальних хвилин	Переглядайте під час кожного завдання, щоб фінальний прохід був для дрібних перевірок

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

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

Рамка прийняття рішень

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

Питання для рішення	Обрати раніше, коли	Обрати пізніше, коли
Чи можу я назвати форму команди або маніфесту до набирання?	Шлях команди знайомий, а простір імен/контекст зрозумілі	Вам потрібно кілька діагностичних кроків, перш ніж дізнатися виправлення
Чи можу я перевірити результат однією-двома перевірками?	kubectl get, describe, auth can-i чи вивід у файл доводять відповідь	Перевірка потребує тестів трафіку, логів, подій і кількох гіпотез
Чи конкурує робота з легшими незавершеними завданнями?	Завдання подібної цінності вже виконані або менш впевнені	Кілька передбачуваних завдань лишаються незайманими
Чи ймовірно, що часткові бали будуть видимими?	Застосування правильних частин покращує стан кластера навіть за незавершеності	Більшість поступу — це приватні міркування з малим придатним до огляду станом

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

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

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

Чи знали ви?

• CKA — це іспит на основі практики: Linux Foundation описує сертифікацію як практичний іспит, тож важливим артефактом є той живий стан кластера, який ви створюєте, а не пояснення того, що ви мали на меті.
• Поточний публічний прохідний бал — 66%: цей поріг змінює стратегію, бо повна досконалість менш важлива за достатню кількість перевіреної роботи в достатній кількості завдань.
• Іспит використовує кілька завдань на справжніх середовищах Kubernetes: помилки з контекстом і простором імен дорогі, бо правильні команди все одно можуть потрапити в неправильну ціль.
• Документація Kubernetes достатньо велика, щоб стати поглиначем часу: знання того, де шукати, корисне, але метод трьох проходів не дає звертанню до документації замінити виконання.

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

Помилка	Чому це стається	Як це виправити
Починати одразу з першого питання	Перше питання здається авторитетним, бо стоїть першим, навіть якщо воно повільне чи неоднозначне	Спершу огляньте всі питання й збудуйте порядок проходів за впевненістю, цінністю та вартістю перевірки
Сприймати кожне завдання як рівне	Двохвилинне створення об’єкта й тривале діагностичне завдання обидва виглядають як окремі питання в інтерфейсі	Порівнюйте передбачуваність, бал і очікуваний час перевірки, перш ніж обирати наступне завдання
Забувати перемкнути контекст	Правильна робота в неправильному кластері все одно виглядає правильною в терміналі, що її створив	Зробіть kubectl config use-context і kubectl config current-context частиною кожного ритуалу початку питання
Ігнорувати простори імен	Об’єкти, прив’язані до простору імен, можуть бути правильними в одному просторі імен і невидимими для перевіряльника в іншому	Прочитайте простір імен з умови й перевірте через kubectl get перед створенням ресурсів
Перебудовувати маніфести	Реальні найкращі практики спокушають кандидатів додавати поля, яких умова не просила	Реалізуйте запитаний стан, перевірте його й винесіть необов’язкові покращення за межі екзаменаційного мислення
Лишатися застряглим без контрольної точки	Завдання, яке мало бути середнім, поступово стає діагностикою без рішення	Перекласифікуйте застряглу роботу, збережіть корисний стан і поверніться після завершення завдань із вищою впевненістю
Пропускати негайну перевірку	Фінальний перегляд здається слушним моментом усе перевірити, але час часто зникає	Перевіряйте після кожної зміни найменшою командою, що доводить вимогу

Тест

1. Ви починаєте іспит, і перше питання просить діагностувати ноду, що в стані NotReady, тоді як друге просить створити простір імен і ConfigMap, які коштують трохи менше балів. Як ви застосуєте метод трьох проходів, щоб розставити пріоритети цих завдань CKA за балами, складністю та часом, що залишився?

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

2. Ви вже шість хвилин у завданні з NetworkPolicy, і YAML застосовується, але трафік усе одно поводиться не так, як очікувалося. Як вам відсортувати це питання іспиту на швидку, середню чи складну роботу, перш ніж вкладати більше часу?

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

3. Ви виконали завдання RBAC, але `kubectl auth can-i` показує, що ServiceAccount не може перелічити Поди. Що вам оглянути, перш ніж переписувати все?

Огляньте суб’єкт, простір імен і посилання на роль у RoleBinding, перш ніж видаляти чи перестворювати всю відповідь. Поширені збої — прив’язка до неправильного простору імен ServiceAccount, використання неправильного імені Ролі або створення прив’язки в іншому просторі імен, ніж Роль. Цілеспрямований огляд дотримується діагностичного циклу й зберігає роботу, яка вже правильна. Переписування всього марнує час і може внести нову помилку.

4. У вас лишилося 14 хвилин. Одне незаймане питання просить процедуру відновлення високої цінності, а інше просить вивід команди у вказаний файл плюс просту зміну масштабу Деплойменту. Як ви оціните компроміс «бали за хвилину»?

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

5. Ви усвідомлюєте, що розв'язали питання про Сервіс у неправильному контексті. Історія команд доступна, і лишається п'ять хвилин. Як ви побудуєте відновлення навколо ритуалу початку питання?

Одразу перемкніться на потрібний контекст, підтвердіть його й перестворіть або повторно застосуйте потрібний Сервіс у правильному просторі імен. Перевірте Сервіс у правильному контексті, перш ніж робити будь-що інше. Якщо час лишається й прибирання безпечне, видаліть випадковий об’єкт із неправильного контексту, але це другорядне. Пріоритет — створити перевірений стан там, де його очікує перевіряльник.

6. Завдання просить Деплоймент із трьома репліками й певним образом, і вас спокушає додати проби та обмеження ресурсів, бо це найкраща практика. Що має сказати вам стратегія іспиту?

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

7. Під час Проходу 3 питання про зламане робоче навантаження просить вас полагодити і помилку образа, і відсутні обмеження ресурсів. У вас лишилося три хвилини, і події чітко показують, що образ недійсний. Як ви відновитеся після застряглого завдання з діагностики, зберігаючи часткові бали?

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

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

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

Підготовка

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

kubectl create namespace exam-strategy-practice
kubectl create deployment q4-broken --image=nginx:doesnotexist -n exam-strategy-practice

Питання навчального іспиту

1. Створіть Под на ім’я q1-pod, що запускає nginx:1.25 у просторі імен exam-strategy-practice.
2. Створіть ConfigMap на ім’я q2-config з ключем LOG_LEVEL=debug у просторі імен exam-strategy-practice.
3. Створіть PVC на ім’я q3-pvc, що запитує 5Gi з режимом доступу ReadWriteOnce у просторі імен exam-strategy-practice.
4. Продіагностуйте Деплоймент q4-broken у просторі імен exam-strategy-practice, щоб його Поди змогли запуститися.
5. Запишіть імена всіх Подів у просторі імен exam-strategy-practice у файл /tmp/exam-strategy-pods.txt без рядка заголовка.
6. Створіть Роль на ім’я pod-reader, що може get, list та watch Поди, потім прив’яжіть її до ServiceAccount на ім’я app-sa у просторі імен exam-strategy-practice.

Крок 1: огляньте й категоризуйте

Перш ніж запускати будь-яку команду розв’язання, огляньте всі шість завдань і запишіть кожне як [QUICK], [MEDIUM] чи [COMPLEX]. Ваша категоризація має відображати ваш поточний рівень, а не чийсь чужий. Якщо RBAC для вас автоматичний, він усе одно може бути середнім, бо має кілька пов’язаних об’єктів. Якщо завдання з файлом виводу здається незнайомим, позначте його швидким лише після того, як знатимете точну команду форматування, яку плануєте використати.

• Я оглянув усі питання перед розв’язанням.
• Я визначив простір імен для кожного завдання.
• Я відсортував питання іспиту на швидку, середню та складну роботу перед набиранням команд розв’язання.
• Я обрав порядок Проходу 1, Проходу 2 і Проходу 3 перед набиранням команд розв’язання.
• Я записав принаймні одне завдання, яке пропущу, якщо воно перевищить свій ліміт часу.

Запропонована категоризація

Q1, Q2 і Q5 зазвичай швидкі, бо їхні шляхи команд і перевірки короткі. Q3 і Q6 зазвичай середні, бо об’єкти PVC і RBAC потребують ретельних перевірок полів і зв’язків. Q4 складне, бо починається зі зламаного робочого навантаження й потребує доказів перед виправленням. Якщо ваш особистий рівень змінює ці оцінки, задокументуйте чому й збережіть ту саму логіку проходів.

Крок 2: швидкі перемоги Проходу 1

Спершу виконайте лише швидкі завдання. Для багатьох учнів Q1, Q2 і Q5 швидкі. Не починайте зламаний Деплоймент поки що, навіть якщо він спокусливий, бо мета — захистити передбачувані бали. Перевіряйте кожен результат одразу, щоб не створити заборгованість фінального перегляду.

kubectl run q1-pod --image=nginx:1.25 -n exam-strategy-practice
kubectl create configmap q2-config --from-literal=LOG_LEVEL=debug -n exam-strategy-practice
kubectl get pods -n exam-strategy-practice -o custom-columns=NAME:.metadata.name --no-headers > /tmp/exam-strategy-pods.txt

kubectl get pod q1-pod -n exam-strategy-practice
kubectl get configmap q2-config -n exam-strategy-practice
cat /tmp/exam-strategy-pods.txt

• Я виконав швидкі завдання перед початком діагностики.
• Я перевірив кожне швидке завдання одразу після створення потрібного стану.
• Я не додавав необов’язкових полів і не витрачав час на шліфування завершених відповідей.

Нотатки до розв'язання Проходу 1

Команди для Пода й ConfigMap створюють прямо запитані об’єкти, тож вони хороші кандидати на Прохід 1. Команда для файлу виводу використовує --no-headers, бо умова просить лише імена. Друк файлу через cat — це не зайве шліфування; це перевірка того, що завдання просить точний вміст файлу, а не лише стан кластера.

Крок 3: середні завдання Проходу 2

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

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: q3-pvc
  namespace: exam-strategy-practice
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

kubectl apply -f q3-pvc.yaml
kubectl create serviceaccount app-sa -n exam-strategy-practice
kubectl create role pod-reader --verb=get,list,watch --resource=pods -n exam-strategy-practice
kubectl create rolebinding app-sa-pod-reader --role=pod-reader --serviceaccount=exam-strategy-practice:app-sa -n exam-strategy-practice

kubectl get pvc q3-pvc -n exam-strategy-practice
kubectl auth can-i list pods --as=system:serviceaccount:exam-strategy-practice:app-sa -n exam-strategy-practice

• Я використав шаблон маніфесту чи команди, що відповідав завданню, замість того щоб покладатися лише на пам’ять.
• Я окремо перевірив об’єкт PVC і дозвіл RBAC.
• Я оцінив компроміси «бали за хвилину», перш ніж витрачати додатковий час на будь-яку помилку YAML.
• Я припинив додавати поля, щойно зазначені вимоги було задоволено.

Нотатки до розв'язання Проходу 2

Перевірка PVC доводить, що об’єкт існує в правильному просторі імен, хоча поведінка прив’язки може залежати від класів сховища у вашому практичному кластері. Перевірка RBAC доводить, що ServiceAccount може перелічувати Поди, а саме цей зв’язок цікавить завдання. Якщо kubectl auth can-i повертає no, огляньте суб’єкт і простір імен RoleBinding, перш ніж усе перестворювати.

Крок 4: складна діагностика Проходу 3

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

kubectl get deployment q4-broken -n exam-strategy-practice
kubectl get pods -l app=q4-broken -n exam-strategy-practice
kubectl describe pod -l app=q4-broken -n exam-strategy-practice
kubectl get events -n exam-strategy-practice --sort-by='.lastTimestamp'

kubectl set image deployment/q4-broken nginx=nginx:1.25 -n exam-strategy-practice
kubectl rollout status deployment/q4-broken -n exam-strategy-practice
kubectl get pods -l app=q4-broken -n exam-strategy-practice

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

Нотатки до розв'язання Проходу 3

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

Крок 5: перегляньте свою стратегію

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

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

kubectl delete namespace exam-strategy-practice
rm -f /tmp/exam-strategy-pods.txt

Настанова до перегляду

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

Джерела

• https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/
• https://docs.linuxfoundation.org/tc-docs/certification/lf-handbook2/exam-preparation-checklist
• https://docs.linuxfoundation.org/tc-docs/certification/lf-handbook2/exam-rules-and-policies
• https://kubernetes.io/docs/tasks/tools/
• https://kubernetes.io/docs/reference/kubectl/
• https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
• https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
• https://kubernetes.io/docs/reference/access-authn-authz/rbac/
• https://kubernetes.io/docs/concepts/services-networking/network-policies/
• https://kubernetes.io/docs/concepts/storage/persistent-volumes/
• https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/
• https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/
• training.linuxfoundation.org: certified kubernetes administrator cka — Офіційна сторінка сертифікації CKA прямо описує іспит як онлайновий, під наглядом проктора, на основі практики, з командного рядка та тривалістю 2 години.
• docs.linuxfoundation.org: faq cka ckad cks — FAQ сертифікації Linux Foundation явно зазначає, що для проходження CKA потрібен бал 66% або вище.
• docs.linuxfoundation.org: certification resources allowed — Офіційна сторінка дозволених ресурсів зазначає, що кандидати CKA можуть використовувати kubernetes.io/docs і його вбудований пошук, доки не відкривають зовнішні результати пошуку.
• kubernetes.io: organize cluster access kubeconfig — Документація kubeconfig пояснює, що контекст містить інформацію про кластер, простір імен і користувача, і що kubectl за замовчуванням використовує поточний контекст.
• kubernetes.io: namespaces — Документація про простори імен Kubernetes визначає їх як області для імен і показує, що прив’язані до простору імен ресурси розділені за простором імен.

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

Далі: Частина 1: Архітектура кластера, встановлення та конфігурація починає перший повний домен CKA, спрямовуючи цей екзаменаційний ритуал на завдання з архітектури, встановлення та конфігурації, які ви сортуватимете в реальній практиці.