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

Складність: [QUICK] — Стратегія, а не технічні навички

Час на виконання: 15-20 хвилин на читання, все життя на оволодіння

Передумови: Модулі 0.1-0.4

Що ви зможете робити

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

Застосувати метод трьох проходів для максимізації балу в умовах обмеженого часу
Класифікувати питання іспиту за складністю та оцінкою часу (спочатку легкі, складні — наприкінці)
Керувати часом на іспиті за правилом 2 хвилин (якщо застрягли на 2 хвилини — позначити та рухатися далі)
Уникати головної причини провалу на іспиті: витрачати 15 хвилин на 4-бальне питання, пропускаючи три 7-бальних

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

Ви можете знати Kubernetes ідеально і все одно провалити CKA.

Як? Час.

16 запитань. 120 хвилин. Це в середньому 7,5 хвилин на запитання. Але запитання не рівноцінні — деякі займають 2 хвилини, інші — 15. Якщо ви витратите 15 хвилин на складне запитання першим і не встигнете виконати легкі, ви втратите бали.

Метод трьох проходів — це стратегія, яка максимізує ваш результат незалежно від складності запитань.

Проблема: Лінійне мислення

Більшість людей підходять до іспитів лінійно:

Запитання 1 → Запитання 2 → Запитання 3 → ... → Запитання 16

Це не працює, коли:

Запитання 3 — це 15-хвилинний кошмар з діагностики
Ви витрачаєте на нього 20 хвилин (перфекціонізм)
Ви поспішаєте з запитаннями 14-16
Ви втрачаєте легкі бали, які могли б отримати

Прохідний бал CKA — 66%. Вам не потрібна досконалість — вам потрібна ефективність.

Рішення: Метод трьох проходів

Замість лінійного підходу, працюйте проходами:

┌─────────────────────────────────────────────────────────────────┐
│                     МЕТОД ТРЬОХ ПРОХОДІВ                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ПРОХІД 1: ШВИДКІ ПЕРЕМОГИ (1-3 хвилини кожне)                  │
│  ├── Перегляньте ВСІ 16 запитань спочатку                       │
│  ├── Виконайте кожне завдання, яке можете зробити швидко        │
│  ├── Пропустіть все, що виглядає складним                       │
│  └── Мета: Забезпечити легкі бали, зекономити час               │
│                                                                  │
│  ПРОХІД 2: СЕРЕДНІ ЗАВДАННЯ (4-6 хвилин кожне)                  │
│  ├── Поверніться до пропущених запитань                          │
│  ├── Виконайте завдання, що потребують помірних зусиль           │
│  ├── Пропустіть, якщо застрягли після 5-6 хвилин                │
│  └── Мета: Стабільний прогрес                                   │
│                                                                  │
│  ПРОХІД 3: СКЛАДНІ ЗАВДАННЯ (залишок часу)                      │
│  ├── Беріться за найскладніші запитання останніми                │
│  ├── Використовуйте ВЕСЬ залишок часу                           │
│  ├── Часткові рішення дають часткові бали                        │
│  └── Мета: Максимізувати залишкові бали                          │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Частина 1: Розпізнавання складності завдань

Перш ніж використовувати метод трьох проходів, вам потрібно миттєво категоризувати запитання.

Швидкі перемоги (1-3 хвилини)

Індикатори:

“Створіть Под/Деплоймент/Сервіс”
“Додайте мітку до…”
“Масштабуйте деплоймент до…”
“Відкрийте сервіс на порту…”
Одноетапні операції
Ресурси, які ви створюєте часто

Приклади:

Створити Під nginx
Додати мітку env=prod до всіх подів у просторі імен
Масштабувати деплоймент web до 5 реплік
Створити NodePort сервіс для деплойменту api

Середні завдання (4-6 хвилин)

Індикатори:

“Налаштуйте RBAC…”
“Створіть NetworkPolicy…”
“Налаштуйте PersistentVolumeClaim…”
“Створіть ConfigMap і використайте його в…”
Багатоетапні, але прямолінійні
Потребують пошуку синтаксису

Приклади:

Створити Role та RoleBinding для користувача для перегляду подів
Створити NetworkPolicy, що дозволяє лише frontend подам доступ до backend
Створити PVC та змонтувати його в поді
Створити ConfigMap та вставити як змінні середовища

Складні завдання (8-15 хвилин)

Індикатори:

“Знайдіть причину, чому…”
“Виправте зламаний…”
“Кластер не…”
“Діагностуйте та вирішіть…”
Мультикластерні або багатоетапні
Потребують дослідження

Приклади:

Знайти причину, чому поди не плануються
Виправити зламаний деплоймент (щось не так, з’ясуйте що)
Вузол NotReady, знайдіть і виправте проблему
Застосунок не може з’єднатися з базою даних, вирішіть

Частина 2: Прохід 1 — Швидкі перемоги

Що робити

Початок іспиту: Прочитайте ВСІ 16 запитань швидко (5 хвилин)
Визначте швидкі перемоги: Позначте їх подумки або на чернетці
Виконайте швидкі перемоги: Зробіть усі легкі запитання першими
Не відволікайтесь: Якщо щось займає більше часу, ніж очікувалось, пропустіть

Бюджет часу

Перегляд усіх запитань: 5 хвилин
Швидкі перемоги (припустимо 4-6 запитань): 15-20 хвилин
Прохід 1 загалом: ~25 хвилин

Приклади швидких перемог

# Запитання: Створіть под з іменем 'web', що запускає nginx у просторі імен 'production'
# Час: <1 хвилина

kubectl run web --image=nginx -n production

# Готово. Наступне запитання.

# Запитання: Масштабуйте деплоймент 'api' до 3 реплік
# Час: <30 секунд

kubectl scale deploy api --replicas=3

# Готово. Наступне запитання.

# Запитання: Створіть ClusterIP сервіс для деплойменту 'backend' на порту 8080
# Час: <1 хвилина

kubectl expose deploy backend --port=8080

# Готово. Наступне запитання.

Психологія

Швидкі перемоги формують впевненість. Після Проходу 1 ви вже відповіли на 4-6 запитань правильно. Це потенційно 25-35% іспиту за 25 хвилин. Тиск спадає.

Частина 3: Прохід 2 — Середні завдання

Що робити

Поверніться до пропущених запитань: Починайте з найменш складних
Використовуйте документацію: Саме тут допомагає kubernetes.io
Обмежуйте себе в часі: Якщо застрягли після 5-6 хвилин, рухайтесь далі
Прийміть “достатньо добре”: Часткові рішення > нічого

Бюджет часу

Середні завдання (припустимо 6-8 запитань): 50-60 хвилин
Прохід 2 загалом: ~55 хвилин
Сукупно: ~80 хвилин (залишається 40 хвилин)

Приклади середніх завдань

# Запитання: Створіть NetworkPolicy, що дозволяє подам з міткою 'role=frontend'
#           доступ до подів з міткою 'role=backend' на порту 3306

# Час: 4-5 хвилин
# Стратегія: Знайти шаблон NetworkPolicy, модифікувати

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - port: 3306

# Запитання: Створіть ServiceAccount 'app-sa', Role, що може переглядати поди,
#           та зв'яжіть їх разом

# Час: 5-6 хвилин
# Стратегія: команди kubectl create + YAML для binding

kubectl create serviceaccount app-sa
kubectl create role pod-reader --verb=get,list,watch --resource=pods
kubectl create rolebinding app-sa-binding --role=pod-reader --serviceaccount=default:app-sa

Частина 4: Прохід 3 — Складні завдання

Що робити

Використовуйте ВЕСЬ залишок часу: Немає потреби поспішати
Методична діагностика: Збір інформації → гіпотеза → перевірка
Часткові бали: Виправити ЧАСТИНУ проблеми краще, ніж нічого
Не панікуйте: Ви вже забезпечили більшість своїх балів

Бюджет часу

Складні завдання (припустимо 2-4 запитання): 40 хвилин
Прохід 3 загалом: ~40 хвилин
Буфер: 0 хвилин (ви використали весь час стратегічно)

Приклад складного завдання

Запитання: Деплоймент 'critical-app' у просторі імен 'production' не
працює коректно. Поди в стані CrashLoopBackOff. Діагностуйте та виправте.

Підхід до діагностики:

# Крок 1: Збір інформації (2 хвилини)
kubectl get pods -n production
kubectl describe pod critical-app-xxx -n production
kubectl logs critical-app-xxx -n production
kubectl get events -n production --sort-by='.lastTimestamp'

# Крок 2: Визначення проблеми (з логів/подій)
# Приклад: ConfigMap 'app-config' не знайдено

# Крок 3: Виправлення
kubectl get cm -n production  # Підтвердити відсутність
kubectl create configmap app-config --from-literal=KEY=value -n production

# Крок 4: Перевірка
kubectl get pods -n production -w  # Спостерігати, поки не буде Running

Стратегія часткових балів

Якщо ви не можете повністю розв’язати складне завдання:

Виправте, що можете: Якщо зламано 3 речі, виправте 2
Задокументуйте свій прогрес: Перевіряючий може побачити часткову роботу
Не залишайте порожнім: Будь-який прогрес краще, ніж нічого

Частина 5: Дисципліна перемикання контексту

Кожне запитання CKA вказує контекст кластера. Це критично важливо.

Помилка №1 на іспиті

Розв’язання задачі в неправильному кластері. Ви все робите правильно, але в неправильному контексті. Нуль балів.

Правило

КОЖНЕ запитання, ПЕРША дія: Перемкнути контекст.

# На початку КОЖНОГО запитання
kubectl config use-context <context-from-question>

Зробіть це м’язовою пам’яттю. Прочитати запитання → перемкнути контекст → потім розв’язувати.

Перевірка

Після перемикання:

kubectl config current-context

Це займає 2 секунди. Це може зберегти 7 хвилин даремної роботи.

Частина 6: Мислення “Достатньо добре”

Перфекціоністи провалюють CKA. Ось чому.

Пастка перфекціонізму

Запитання: Створіть деплоймент з 3 репліками, лімітами ресурсів,
          перевірками стану та томом ConfigMap

Перфекціоніст:
- Витрачає 10 хвилин на ідеальний YAML
- Перевіряє кожне поле двічі
- Додає необов'язкові найкращі практики
- Не встигає з іншими запитаннями

Підхід “Достатньо добре”

Достатньо добре:
- Створює робочий деплоймент (3 хвилини)
- Додає лише обов'язкові поля
- Перевіряє, що працює
- Рухається далі

Результат: Ті ж бали, зекономлено 7 хвилин

Правило 80%

Якщо ваше рішення працює і відповідає вимогам, воно завершене. Не:

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

Частина 7: Контрольні точки часу

Встановіть ментальні контрольні точки під час іспиту:

Минуло часу	Контрольна точка	Перевірка стану
30 хвилин	Кінець Проходу 1	Має бути виконано 4-6 запитань
80 хвилин	Кінець Проходу 2	Має бути виконано 10-12 запитань
110 хвилин	Прохід 3 в процесі	Робота над складними завданнями
120 хвилин	Іспит завершено	Здати

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

Історія успіху: Від провалу до 89%

Кандидат провалив свою першу спробу CKA з результатом 58%. Він витратив 18 хвилин на запитання з діагностики в першому проході, а потім поспішав з усім іншим. На другій спробі він неухильно використовував метод трьох проходів. Прохід 1: 6 запитань за 22 хвилини. Прохід 2: 7 запитань за 50 хвилин. Прохід 3: 3 складних запитання з 48 хвилинами, що залишились. Фінальний бал: 89%. Ті ж знання, інша стратегія, абсолютно інший результат.

Частина 8: Передіспитова рутина

За 5 хвилин до

Середовище готове: Вода, тихе місце, документ
Ментальний стан: Спокій, зосередженість, впевненість
Пам’ятайте: Метод трьох проходів. Швидкі перемоги першими.

Перші 5 хвилин іспиту

Прочитайте ВСІ запитання: Не починайте розв’язувати ще
Категоризуйте подумки: Швидке / Середнє / Складне
Сплануйте свої проходи: Знайте, які запитання ви візьмете першими
Налаштуйте аліаси: Якщо не передналаштовані

Останні 5 хвилин іспиту

Не починайте нових складних завдань: Недостатньо часу
Перевірте критичні відповіді: Швидкі перевірки на здоровий глузд
Здайте будь-яку часткову роботу: Щось > нічого
Дихайте: Ви зробили все можливе

Чи знали ви?

66% — це прохідний бал. Це означає, що ви можете повністю провалити 5-6 запитань і все одно скласти іспит. Метод трьох проходів забезпечує, що ви не залишите легкі бали на столі.
Часткові бали існують. Якщо запитання коштує 7 балів і ви виконали 4 речі правильно, ви можете отримати 4 бали. Завжди намагайтесь щось зробити.
Іспит розроблений, щоб бути складним. Linux Foundation очікує, що багато людей не встигнуть вчасно. Ваша стратегія важить стільки ж, скільки й ваші знання.
Другі спроби дозволені. Якщо ви провалитесь, ви отримуєте одну безкоштовну перездачу з покупкою іспиту. Це не кінець світу.

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

Помилка	Проблема	Рішення
Починати з Запитання 1	Може бути складним	Спершу перегляньте все, оберіть легкі
Перфекціонізм	Витрата часу	Мислення “достатньо добре”
Неправильний контекст	Нуль балів	Завжди перемикайте контекст першим
Застрягли на складному запитанні	Витрата часу	Пропустіть після 5-6 хвилин, поверніться пізніше
Невикористання залишку часу	Залишення балів	Використовуйте ВЕСЬ час на складні завдання
Паніка	Погані рішення	Довіряйте своїй підготовці

Тест

Минуло 30 хвилин, і ви виконали лише 2 запитання. Що робити?

Відповідь
Ви відстаєте. Негайно перейдіть до легших запитань (Прохід 1). Пропускайте все, що займає надто довго. Відновіть час, зосередившись лише на швидких перемогах.
Запитання просить вас діагностувати зламаний деплоймент. Як ви його категоризуєте?

Відповідь
Складне (Прохід 3). Запитання з "діагностикою" потребують дослідження і непередбачувані за часом. Залиште на кінець, коли у вас буде залишок часу.
Що ПЕРШЕ ви робите, починаючи будь-яке запитання?

Відповідь
Перемикаєте на правильний контекст. `kubectl config use-context `. Це запобігає розв'язуванню задач у неправильному кластері.
Ви частково розв’язали складне запитання, але час закінчується. Що робити?

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

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

Завдання: Практикуйте категоризацію запитань та контроль часу.

Вправа 1: Категоризація запитань

Категоризуйте ці зразкові запитання CKA як [QUICK], [MEDIUM] або [COMPLEX]:

Створіть под з іменем nginx, що запускає образ nginx:1.25
Деплоймент web-app не запускається. Поди показують CrashLoopBackOff. Знайдіть і виправте проблему.
Масштабуйте деплоймент api до 5 реплік
Створіть NetworkPolicy, що дозволяє подам з міткою role=frontend доступ до подів з міткою role=db на порту 3306
Створіть ClusterRole, що дозволяє переглядати та отримувати поди, і прив’яжіть до користувача developer
Вузол worker-02 у стані NotReady. Діагностуйте та виправте.
Додайте мітку env=production до всіх подів у просторі імен app
Створіть PersistentVolumeClaim із запитом на 5Gi сховища з режимом доступу ReadWriteOnce

Відповіді

[QUICK] — Одна команда kubectl
[COMPLEX] — Потребує дослідження
[QUICK] — Одна команда kubectl
[MEDIUM] — Потребує YAML, але прямолінійно
[MEDIUM] — Багатоетапне, але задокументоване
[COMPLEX] — Потрібна діагностика
[QUICK] — Одна команда kubectl з селектором
[MEDIUM] — Потребує шаблон YAML

Вправа 2: Практика з таймером

Встановіть таймер і практикуйте:

2 хвилини: Створіть деплоймент з 3 репліками та відкрийте його
5 хвилин: Створіть повне налаштування RBAC (Role, RoleBinding, ServiceAccount)
3 хвилини: Створіть NetworkPolicy з документації

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

Можете категоризувати складність запитання за <10 секунд
Розумієте, до якого проходу належить кожне запитання
Можете виконувати швидкі перемоги без вагань

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

Вправа 1: Тест на швидкість категоризації запитань (Ціль: 2 хвилини)

Категоризуйте всі 10 запитань як QUICK / MEDIUM / COMPLEX. Засікайте час.

Створіть простір імен production
Діагностуйте, чому поди деплойменту api в стані CrashLoopBackOff
Створіть ConfigMap з іменем app-config з ключем LOG_LEVEL=debug
Масштабуйте StatefulSet database до 5 реплік
Створіть NetworkPolicy, що дозволяє frontend подам доступ до backend на порту 443
Вузол worker-03 показує NotReady. Знайдіть і виправте проблему.
Створіть ClusterRole, що дозволяє get/list для secrets, прив’яжіть до користувача auditor
Додайте анотацію owner=team-a до деплойменту web
Створіть PVC з 10Gi сховища, ReadWriteOnce, StorageClass fast
Діагностика: Сервіс api-svc не маршрутизує трафік до подів. Виправте.

Відповіді

QUICK — одна команда
COMPLEX — потребує дослідження
QUICK — одна команда
QUICK — одна команда
MEDIUM — потребує YAML
COMPLEX — діагностика
MEDIUM — багатоетапне, але задокументоване
QUICK — одна команда
MEDIUM — потребує YAML
COMPLEX — діагностика

Вправа 2: Пробний іспит — Лише Прохід 1 (Ціль: 15 хвилин)

Виконайте ЛИШЕ швидкі перемоги з Вправи 1. Пропустіть усі MEDIUM та COMPLEX.

# Запустіть таймер

# 1. Створити простір імен
kubectl create ns production

# 3. Створити ConfigMap
kubectl create cm app-config --from-literal=LOG_LEVEL=debug

# 4. Масштабувати StatefulSet
kubectl scale sts database --replicas=5

# 8. Додати анотацію
kubectl annotate deploy web owner=team-a

# Зупиніть таймер. Ціль: <5 хвилин на 4 запитання
# Ви щойно забезпечили ~25% балів менш ніж за 5 хвилин

Вправа 3: Перемикання контексту під тиском (Ціль: 3 хвилини)

Симулюйте перемикання контексту на іспиті. Створіть тестові контексти та практикуйте:

# Налаштування
kubectl config set-context exam-cluster-1 --cluster=kubernetes --user=kubernetes-admin
kubectl config set-context exam-cluster-2 --cluster=kubernetes --user=kubernetes-admin
kubectl config set-context exam-cluster-3 --cluster=kubernetes --user=kubernetes-admin

# ВПРАВА: Прочитайте запитання, перемкніть контекст, перевірте, потім розв'яжіть
# Таймер починається ЗАРАЗ

# Запитання 1: На кластері exam-cluster-1 створіть под nginx
kubectl config use-context exam-cluster-1
kubectl config current-context  # Перевірка!
kubectl run nginx --image=nginx

# Запитання 2: На кластері exam-cluster-2 створіть простір імен dev
kubectl config use-context exam-cluster-2
kubectl config current-context  # Перевірка!
kubectl create ns dev

# Запитання 3: На кластері exam-cluster-3 масштабуйте деплоймент web до 3
kubectl config use-context exam-cluster-3
kubectl config current-context  # Перевірка!
kubectl scale deploy web --replicas=3 2>/dev/null || echo "deploy not found - expected in drill"

# Таймер стоп. Чи перевіряли ви контекст КОЖНОГО разу?

Вправа 4: Симуляція тиску часу (Ціль: 7 хвилин)

Симулюйте запитання середньої складності під тиском часу:

# ЗАПУСК ТАЙМЕРА: У вас рівно 7 хвилин

# ЗАПИТАННЯ:
# Створіть ServiceAccount з іменем 'app-sa' у просторі імен 'secure'
# Створіть Role з іменем 'secret-reader', що може get та list secrets
# Прив'яжіть роль до service account
# Створіть под 'test-pod', що використовує цей service account

# ВПЕРЕД!

kubectl create ns secure
kubectl create sa app-sa -n secure
kubectl create role secret-reader --verb=get,list --resource=secrets -n secure
kubectl create rolebinding app-sa-binding --role=secret-reader --serviceaccount=secure:app-sa -n secure
kubectl run test-pod --image=nginx --serviceaccount=app-sa -n secure

# ПЕРЕВІРКА
kubectl get sa,role,rolebinding,pod -n secure

# ЗУПИНКА ТАЙМЕРА
# <5 хв: Відмінно
# 5-7 хв: Добре
# >7 хв: Практикуйте ще

# Очищення
kubectl delete ns secure

Вправа 5: Практика часткових балів

Сценарій: Ви застрягли на складному запитанні з 3 хвилинами залишку. Практикуйте отримання часткових балів.

# ЗАПИТАННЯ: Деплоймент 'web-app' не працює. Поди в стані
# ImagePullBackOff. Діагностуйте та виправте. Також переконайтесь, що деплоймент
# має встановлені ліміти ресурсів.

# У вас 3 хвилини. Ви не встигнете все. Отримайте часткові бали.

# Крок 1: Діагностика (30 секунд)
kubectl describe pod -l app=web-app | grep -A5 "Events"
# Бачимо: Failed to pull image "nginx:nonexistent"

# Крок 2: Виправити очевидну проблему (30 секунд)
kubectl set image deploy web-app web-app=nginx:1.25

# Крок 3: Перевірити, чи працює (30 секунд)
kubectl get pods -l app=web-app
# Running? Добре!

# Час вийшов! Ви не додали ліміти ресурсів, але отримали часткові бали
# за виправлення проблеми з образом.

Вправа 6: Повний міні-іспит (Ціль: 20 хвилин)

Виконайте цей міні-іспит з 4 запитань, використовуючи метод трьох проходів:

Запитання 1 (3%): Створіть под q1-pod, що запускає nginx

Запитання 2 (7%): Створіть NetworkPolicy q2-netpol у просторі імен web, що:

Застосовується до подів з міткою app=backend
Дозволяє вхідний трафік лише від подів з міткою app=frontend
Дозволяє вхідний трафік лише на порту 8080

Запитання 3 (5%): Створіть PVC q3-pvc із запитом на 5Gi з ReadWriteOnce

Запитання 4 (10%): Діагностика: Деплоймент q4-broken існує, але поди не запускаються. Виправте.

# Налаштування для Q4
kubectl create deploy q4-broken --image=nginx:doesnotexist

Інструкції:

Прочитайте всі 4 запитання (1 хвилина)
Прохід 1: Лише швидкі перемоги
Прохід 2: Середні завдання
Прохід 3: Складні (Q4)

Рішення

# Прохід 1: Швидкі перемоги
# Q1 (QUICK)
kubectl run q1-pod --image=nginx

# Прохід 2: Середні
# Q3 (MEDIUM)
cat << 'EOF' | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: q3-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
EOF

# Q2 (MEDIUM)
kubectl create ns web
cat << 'EOF' | kubectl apply -f -
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:
    - port: 8080
EOF

# Прохід 3: Складні
# Q4 (COMPLEX)
kubectl describe deploy q4-broken
kubectl get pods | grep q4-broken
kubectl describe pod q4-broken-xxx | grep -A5 Events
# Образ не існує — виправлення:
kubectl set image deploy q4-broken nginx=nginx:1.25

# Перевірка всього
kubectl get pod q1-pod
kubectl get netpol -n web
kubectl get pvc q3-pvc
kubectl get pods | grep q4-broken

Вправа 7: Виклик — 30-хвилинний інтенсив

Виділіть 30 безперервних хвилин. Виконайте якомога більше завдань:

Створіть простір імен exam-practice
Створіть ConfigMap cm-1 з 3 парами ключ-значення
Створіть Secret secret-1 з username та password
Створіть Деплоймент web з 3 репліками, що використовує nginx
Відкрийте деплоймент web на NodePort 30080
Створіть PVC data-pvc з 1Gi сховища
Створіть Під data-pod, що використовує PVC за шляхом /data
Створіть ServiceAccount app-sa
Створіть Role pod-reader (get, list, watch pods)
Прив’яжіть Role до ServiceAccount
Створіть NetworkPolicy, що дозволяє лише вхідний трафік на порту 80
Масштабуйте деплоймент web до 5 реплік
Створіть HPA для web (min 2, max 10, CPU 80%)
Створіть Job batch-job, що виконує echo "done" та завершується
Створіть CronJob cron-job, що запускається кожні 5 хвилин

Усе в просторі імен exam-practice. Відстежуйте свій результат:

15/15: Готові до іспиту
12-14: Майже готові
9-11: Продовжуйте практикувати
<9: Повторіть модулі 0.1-0.4

# Очищення
kubectl delete ns exam-practice

Підсумок: Картка-довідник методу трьох проходів

╔═══════════════════════════════════════════════════════════════╗
║             СТРАТЕГІЯ ІСПИТУ: ТРИ ПРОХОДИ                      ║
╠═══════════════════════════════════════════════════════════════╣
║                                                                ║
║  ПЕРЕД РОЗВ'ЯЗУВАННЯМ: Прочитайте ВСІ 16 запитань (5 хв)       ║
║                                                                ║
║  ПРОХІД 1: ШВИДКІ ПЕРЕМОГИ                                     ║
║  • Завдання на 1-3 хв                                          ║
║  • Створити, масштабувати, мітка, відкрити                     ║
║  • Ціль: ~25 хв на 4-6 запитань                                ║
║                                                                ║
║  ПРОХІД 2: СЕРЕДНІ ЗАВДАННЯ                                    ║
║  • Завдання на 4-6 хв                                          ║
║  • RBAC, NetworkPolicy, PVC, ConfigMap                         ║
║  • Ціль: ~55 хв на 6-8 запитань                                ║
║                                                                ║
║  ПРОХІД 3: СКЛАДНІ ЗАВДАННЯ                                    ║
║  • Завдання на 8-15 хв                                         ║
║  • Діагностика, багатоетапні, налагодження                     ║
║  • Ціль: ~40 хв на решту запитань                              ║
║                                                                ║
║  ЗАВЖДИ: Спершу перемкніть контекст. Достатньо > досконало.    ║
║                                                                ║
╚═══════════════════════════════════════════════════════════════╝

Наступні кроки

Вітаємо! Ви завершили Частину 0: Середовище та техніка іспиту.

Тепер у вас є:

Робочий багатовузловий кластер Kubernetes
Оптимізована оболонка з аліасами та автодоповненням
Vim, налаштований для редагування YAML
Знання, де швидко знайти документацію
Стратегія максимізації вашого балу на іспиті

Далі: Частина 1: Архітектура кластера, встановлення та конфігурація

Тут починається справжнє вивчення Kubernetes.