Модуль 0.1: Огляд та стратегія CKAD

Складність: [ШВИДКИЙ] — орієнтація та стратегія

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

Передумови: пройдений навчальний план CKA (рекомендовано) або основи Kubernetes

---

Навчальні результати

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

• Порівняти обов’язки CKAD і CKA через екзаменаційні домени, їхні ваги та патерни ресурсів, орієнтовані на розробника.
• Спроєктувати зважений план підготовки, який надає пріоритет середовищу, конфігурації, безпеці, розгортанню, мережі, спостережуваності та практиці проєктування й збирання застосунків.
• Впровадити практичне середовище Kubernetes 1.35+ із kind, маніфестами kubectl у режимі dry-run, Jobs, CronJobs, пробами та перевірками контексту.
• Діагностувати пастки екзаменаційного робочого процесу, пов’язані з перемиканням контексту, сортуванням завдань, пробами, багатоконтейнерними подами, логами та прибиранням ресурсів.

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

Гіпотетичний сценарій: ви приєднуєтеся до команди, яка вже керує кластерами Kubernetes, але кожен реліз досі залежить від платформного інженера, який перетворює намір застосунку на маніфести. Розробник просить фоновий воркер, перевірку готовності, невеликий Secret і план відкату, а потім чекає, поки хтось інший переведе ці потреби на Pods, Deployments, Services, Jobs та об’єкти конфігурації. Екзамен CKAD існує тому, що така передача завдань занадто повільна для команд, які очікують, що інженери застосунків безпечно постачатимуть код усередині Kubernetes, не стаючи повноцінними адміністраторами кластера.

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

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

CKAD і CKA ділять кластер, але не роботу

Найшвидший спосіб неправильно зрозуміти CKAD — сприймати його як ще один екзамен з операцій над кластером. Якщо ви вже вивчали CKA, це припущення спокусливе, бо Pods, Deployments, Services, ConfigMaps, Secrets, томи, Helm, Kustomize та NetworkPolicies з’являються в обох напрямках. Різниця в тому, що CKAD оцінює, як розробник застосунків використовує ці примітиви, тоді як CKA оцінює, чи може адміністратор підтримувати платформу доступною та коректно налаштованою для багатьох команд. Спільна назва ресурсу не означає спільну ментальну модель.

Початкове порівняння й досі є правильною відправною точкою, бо воно розділяє обсяг ще до того, як розділяє команди. CKA і CKAD обидва тривають дві години, обидва використовують завдання, орієнтовані на практику, і обидва очікують вільного володіння кількома контекстами Kubernetes. Завдання CKAD зазвичай починається ближче до наміру застосунку, як-от «зробіть так, щоб цей вебзастосунок відкривав порт 8080 і не проходив перевірку готовності, доки не запрацює /ready», тоді як завдання CKA зазвичай починається ближче до наміру кластера, як-от «полагодьте цю ноду, клас сховища або компонент площини управління». Ця різниця змінює те, як ви розподіляєте час на підготовку.

Аспект	CKA	CKAD
Фокус	Адміністрування кластера	Розробка застосунків
Перспектива	Команда Ops/Platform	Команда Dev/Application
Тривалість екзамену	2 години	2 години
Прохідний бал	66%	66%
Питання	~15–20 завдань	~15–20 завдань
Кластери	Кілька контекстів	Кілька контекстів

Якщо ви нещодавно склали CKA, то можете перенести значну базу. Не варто витрачати перший тиждень підготовки до CKAD на повторне вивчення того, що таке Pod, як мітки з’єднують Service з ендпоінтами або як Deployment створює ReplicaSets. Натомість варто перетворити ці знання на робочі процеси зі швидкістю розробника: швидко згенерувати маніфест, відредагувати поля, що мають значення, застосувати його, перевірити стан, прочитати логи та прибрати ресурси. CKA дає вам словник; CKAD винагороджує те, наскільки швидко ви можете перетворити цей словник на робочі ресурси застосунку.

Спільна частина охоплює Pods, Deployments, ReplicaSets, Services, ConfigMaps, Secrets, PersistentVolumes, PersistentVolumeClaims, базову мережу, NetworkPolicies, основи Helm, основи Kustomize та засади RBAC. Сприймайте їх радше як обов’язкові м’язи, ніж як увесь план тренувань. Коли екзаменаційне завдання каже «налаштуйте под на споживання ConfigMap», воно не просить лекції про API-сервер. Воно запитує, чи можете ви створити об’єкт, правильно змонтувати або спроєктувати дані, перезапустити чи поспостерігати за навантаженням за потреби та довести, що застосунок бачить те, що ви задумали.

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

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

Тема	Покриття в CKA	Покриття в CKAD
Багатоконтейнерні поди	Згадуються	Глибокий фокус
Init-контейнери	Згадуються	Базова навичка
Проби (liveness/readiness/startup)	Базово	Детально
Jobs і CronJobs	Охоплено	Фокус розробника
Збирання образів контейнерів	Не охоплено	Важливо
Застарілі версії API	Не охоплено	Екзаменаційна тема
Налагодження застосунків	З погляду адміністратора	З погляду розробника
Стратегії розгортання	Поетапні оновлення	Blue/green, canary

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

Є один практичний наслідок для ваших нотаток. Не створюйте зошит CKAD, упорядкований лише за типом об’єкта, як-от «Pods», «Services» та «ConfigMaps». Упорядкуйте його за завданням розробника: «запустити вебпроцес», «впровадити конфігурацію», «пропускати трафік за готовністю», «запустити одноразове завдання», «надсилати логи з сайдкара» та «відкрити застосунок». Об’єкти Kubernetes — це словник; результати застосунку — це речення, які вам треба писати під тиском часу.

Екзаменаційні домени та зважене планування підготовки

Офіційний навчальний план CKAD поділено на п’ять зважених доменів. Ці ваги — не дрібниця; вони є вхідними даними для планування. Учень, який витрачає більшу частину тижня на зручні команди для Deployment, нехтуючи середовищем, конфігурацією та безпекою, тихо обирає недостатню підготовку до найбільшого домену. Учень, який практикує лише найновіші чи найцікавіші теми, може припуститися протилежної помилки, залишивши на столі легкі бали за Services, Jobs або ConfigMap.

┌──────────────────────────────────────────────────────────────────┐
│                    CKAD Exam Breakdown                           │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │ Application Environment, Configuration & Security   25%  │   │
│  └──────────────────────────────────────────────────────────┘   │
│                                                                  │
│  ┌────────────────────────────┐ ┌───────────────────────────┐   │
│  │ Application Design & Build │ │ Application Deployment    │   │
│  │            20%             │ │           20%             │   │
│  └────────────────────────────┘ └───────────────────────────┘   │
│                                                                  │
│  ┌────────────────────────────┐ ┌───────────────────────────┐   │
│  │ Services & Networking      │ │ Observability/Maintenance │   │
│  │            20%             │ │           15%             │   │
│  └────────────────────────────┘ └───────────────────────────┘   │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Application Design and Build несе двадцять відсотків екзамену. На практиці цей домен запитує, чи можете ви визначати, збирати та змінювати образи контейнерів на рівні, потрібному розробнику застосунків; створювати Jobs і CronJobs; проєктувати багатоконтейнерні патерни подів; та використовувати персистентні чи ефемерні томи там, де навантаження їх потребує. Цей домен варто практикувати, починаючи з наміру застосунку, а не з шаблону об’єкта. Наприклад, «запустити резервне копіювання один раз і зберегти його логи» природно стає Job, тоді як «підготувати конфігурацію до запуску застосунку» природно стає init-контейнером.

Application Deployment також несе двадцять відсотків. Цей домен зосереджується на Deployments, поетапних оновленнях, відкатах, Helm, Kustomize та стратегіях релізу, як-от blue-green чи canary. Важлива навичка CKAD — не просто створення Deployment з пам’яті. Корисна навичка — знати, коли зміна належить до тегу образу, команди kubectl set image, оверлею Kustomize, значення Helm чи відкату. Це рішення потребує і швидкості команд, і судження щодо релізів.

Application Observability and Maintenance несе п’ятнадцять відсотків, але його легко недооцінити, бо він з’являється всередині багатьох завдань. Проби, логи, події, kubectl describe та налагодження на рівні застосунку виникають щоразу, коли маніфест синтаксично коректний, але навантаження все одно поводиться неправильно. Обізнаність щодо застарілих версій API також належить сюди, бо маніфест, який використовує стару версію API, може дати збій ще до того, як застосунок узагалі запуститься. Цей домен менший за вагою, проте він захищає бали в кожному іншому домені.

Application Environment, Configuration and Security — найбільший домен із двадцятьма п’ятьма відсотками. Він охоплює ConfigMaps, Secrets, ServiceAccounts, запити та ліміти ресурсів, SecurityContexts і роботу з кастомними ресурсами. Це найближче, до чого CKAD підходить до політики платформи, але погляд розробника лишається чітким: зробити застосунок налаштовуваним, дати йому лише ту ідентичність і привілеї, яких він потребує, обмежити його поведінку щодо ресурсів та виявляти розширювальні API без припущення про доступ рівня cluster-admin. Якщо у вашому плані підготовки є лише один збільшений блок, поставте його сюди.

Services and Networking несе двадцять відсотків. CKAD очікує, що ви відкриватимете застосунки через Services, використовуватимете правила Ingress там, де вони доступні, і міркуватимете про NetworkPolicies з погляду застосунку. Поширена помилка розробника — сприймати мережу як фінальну обгортку навколо завершеного Pod. У Kubernetes селектор Service, мітка Pod, порт контейнера та проба готовності утворюють один шлях трафіку. Вам треба налагоджувати цей шлях як систему, а не як чотири окремі фрагменти YAML.

Домен	Вага	Зміщення практики	Докази, що ви готові
Application Design and Build	20%	Jobs, CronJobs, init-контейнери, сайдкари, томи	Ви можете вибрати правильну форму навантаження зі сценарію та швидко згенерувати чистий стартовий маніфест.
Application Deployment	20%	Deployments, команди викочування, Helm, Kustomize, стратегії релізу	Ви можете оновити, поспостерігати та відкотити застосунок, не загубивши мітки чи селектори.
Observability and Maintenance	15%	Проби, логи, події, команди налагодження, застарілі API	Ви можете пояснити, чи збій спричинений плануванням, запуском контейнера, готовністю, живучістю чи маршрутизацією сервісу.
Environment, Configuration and Security	25%	ConfigMaps, Secrets, ServiceAccounts, ресурси, SecurityContexts, CRD	Ви можете впровадити конфігурацію та обмежити поведінку під час виконання без повторної збірки образу.
Services and Networking	20%	Services, Ingress, NetworkPolicies, перевірки ендпоінтів	Ви можете довести, які поди отримують трафік і чому інший под заблоковано чи дозволено.

Проєктуйте свій план підготовки і з ваги, і зі слабких місць. Якщо ви вже склали CKA, виділіть менше часу на просте створення Pod і більше — на специфічні для розробника варіації, які CKA не змусив увійти у м’язову пам’ять. Якщо ви писали Deployments на роботі, але ніколи не створювали CronJobs чи init-контейнери вручну, не дозволяйте робочій звичності обманути себе й пропустити ці теми. Готовність до екзамену — це не те саме, що досвід у продакшені, бо екзамен забирає вашу IDE, вашого колегу та ваш повільний цикл рев’ю.

Корисний план із чотирьох блоків на два тижні використовує ваги радше як орієнтири, ніж як жорсткий календар. Витратьте перший блок на підтвердження того, що ваші основи CKA достатньо швидкі: Pods, Deployments, Services, ConfigMaps, Secrets та контекст простору імен. Витратьте другий блок на найбільший домен, особливо на вимоги до ресурсів, SecurityContexts, ServiceAccounts та впровадження конфігурації. Використайте третій блок для Jobs, CronJobs, проб, багатоконтейнерних патернів і налагодження. Використайте останній блок для змішаних завдань на час, де ви вирішуєте, що пропустити, що завершити, а до чого повернутися пізніше.

Практичне середовище та робочий процес із командами

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

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

# Create a multi-node CKAD practice cluster
cat <<EOF > ckad-cluster.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
EOF
kind create cluster --config ckad-cluster.yaml --name ckad-prep

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

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

kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml

Перш ніж запустити це, який вивід ви очікуєте побачити в pod.yaml? Ви маєте очікувати повний маніфест Pod із apiVersion, kind, metadata та одним контейнером, що використовує образ nginx, але вам не варто очікувати проб, томів, SecurityContexts чи кастомних міток, доки ви їх не додасте. Це передбачення має значення, бо наступний крок — редагування згенерованої форми. Якщо ви не можете передбачити, що дає генерація, ви не помітите, коли потрібне поле все ще відсутнє.

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

# Jobs and CronJobs
kubectl create job myjob --image=busybox -- echo "hello"
kubectl create cronjob mycron --schedule="* * * * *" --image=busybox -- date

# Generate multi-container pod YAML
kubectl run multi --image=nginx --dry-run=client -o yaml > multi.yaml
# Then edit to add sidecar

# Debugging
kubectl logs pod-name -c container-name
kubectl exec -it pod-name -c container-name -- sh
kubectl debug pod-name --image=busybox --target=container-name

# Quick testing
kubectl run test --image=busybox --rm -it --restart=Never -- wget -qO- http://service  # replace 'service' with your Service name

Синтаксис проб заслуговує на окреме місце в пам’яті, бо він поширений, точний і легкий для друкарської помилки. Проба живучості (liveness) відповідає на питання, чи має Kubernetes перезапустити контейнер. Проба готовності (readiness) відповідає, чи має Pod отримувати трафік Service. Проба запуску (startup) дає застосункам із повільним стартом час до початку перевірок живучості. Змішування цих призначень — один із найшвидших способів створити навантаження, яке виглядає керованим, але поводиться погано.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

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

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

# List available contexts
kubectl config get-contexts

# Switch context (to the practice cluster created earlier)
kubectl config use-context kind-ckad-prep

# Verify current context
kubectl config current-context

# Quick shortcut: set namespace for context
kubectl config set-context --current --namespace=default

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

Трипрохідна екзаменаційна стратегія та швидкісні вправи

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

┌─────────────────────────────────────────────────────────────────┐
│                    CKAD Three-Pass Method                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Pass 1: Quick Wins (40-50 min)                                │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ • Create pod/deployment/service (imperative commands)   │   │
│  │ • Add labels, annotations                               │   │
│  │ • Expose a deployment                                   │   │
│  │ • Simple ConfigMap/Secret creation                      │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  Pass 2: Medium Tasks (40-50 min)                              │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ • Add probes to pods                                    │   │
│  │ • Create multi-container pods                           │   │
│  │ • Jobs and CronJobs                                     │   │
│  │ • Network policies                                      │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  Pass 3: Complex Tasks (20-30 min)                             │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ • Debugging failing applications                        │   │
│  │ • Complex multi-container patterns                      │   │
│  │ • Helm charts with values                               │   │
│  │ • Troubleshooting scenarios                             │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

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

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

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

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

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

# These should be muscle memory
kubectl run nginx --image=nginx
kubectl create deployment web --image=nginx --replicas=3
kubectl expose deployment web --port=80 --target-port=80
kubectl create job backup --image=busybox -- /bin/sh -c "echo done"
kubectl create cronjob cleanup --image=busybox --schedule="*/5 * * * *" -- /bin/sh -c "echo cleanup"

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

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

# 1. Pod named 'web' with nginx image
kubectl run web --image=nginx

# 2. Deployment named 'api' with 2 replicas of httpd
kubectl create deployment api --image=httpd --replicas=2

# 3. Service exposing the api deployment on port 8080
kubectl expose deployment api --port=8080 --target-port=80

# 4. Job named 'backup' that runs busybox and echoes "done"
kubectl create job backup --image=busybox -- echo "done"

# 5. CronJob named 'hourly' running every hour
kubectl create cronjob hourly --image=busybox --schedule="0 * * * *" -- date

# Verify
kubectl get pod,deploy,svc,job,cronjob

# Cleanup
kubectl delete pod web
kubectl delete deployment api
kubectl delete service api
kubectl delete job backup
kubectl delete cronjob hourly

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

# Generate pod YAML
kubectl run nginx --image=nginx --dry-run=client -o yaml > /tmp/pod.yaml

# Generate deployment YAML
kubectl create deployment web --image=nginx --dry-run=client -o yaml > /tmp/deploy.yaml

# Generate service YAML
kubectl create service clusterip mysvc --tcp=80:80 --dry-run=client -o yaml > /tmp/svc.yaml

# Verify files exist and are valid
head -10 /tmp/pod.yaml
head -10 /tmp/deploy.yaml

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

# List available contexts
kubectl config get-contexts

# Switch context (to the practice cluster created earlier)
kubectl config use-context kind-ckad-prep

# Verify current context
kubectl config current-context

# Quick shortcut: set namespace for context
kubectl config set-context --current --namespace=default

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

# Create a pod YAML with all three probe types
cat << 'EOF' > /tmp/probed-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: probed-app
spec:
  containers:
  - name: app
    image: nginx
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 5
    startupProbe:
      httpGet:
        path: /
        port: 80
      failureThreshold: 30
      periodSeconds: 10
EOF

# Apply and verify
kubectl apply -f /tmp/probed-pod.yaml
kubectl describe pod probed-app | grep -A5 "Liveness\\|Readiness\\|Startup"

# Cleanup
kubectl delete pod probed-app

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

Scenario 1: Download config before app starts
Answer: Init container

Scenario 2: Ship logs to Elasticsearch alongside main app
Answer: Sidecar

Scenario 3: Wait for database to be ready
Answer: Init container

Scenario 4: Proxy database connections through localhost
Answer: Ambassador

Scenario 5: Monitor and reload config on change
Answer: Sidecar

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

1. Application Design and Build - 20%
2. Application Deployment - 20%
3. Application Observability and Maintenance - 15%
4. Application Environment, Configuration and Security - 25%
5. Services and Networking - 20%

Фінальна екзаменаційна стратегія — поєднати ці вправи у змішані набори. Десятихвилинний набір може створити Deployment, відкрити його, додати ConfigMap і перевірити трафік. П’ятнадцятихвилинний набір може додати Job, CronJob, пробу готовності та крок прибирання. Довший набір має містити навмисне перемикання контексту та один зламаний ресурс. Ви тренуєте ухвалення рішень під тиском часу, тож кожна вправа має закінчуватися доказом, а не просто запрошенням командного рядка.

Розбір прикладу: перетворіть завдання CKAD на докази

Сценарій вправи: пробне завдання каже вам перемкнутися на контекст kind-ckad-prep, працювати у просторі імен apps, створити Deployment orders із трьома репліками з nginx, відкрити його на порту 80, додати значення ConfigMap із назвою MODE=practice та довести, що застосунок досяжний з тимчасового пода BusyBox. Завдання виглядає простим, але воно перетинає чотири поширені межі збоїв: контекст, простір імен, створення навантаження та вибір сервісу. Учень, який одразу кидається друкувати, може швидко завершити — або може створити ідеальні ресурси не в тому просторі імен і витратити кілька хвилин на налагодження проблеми, яка насправді взагалі не про Kubernetes.

Перший крок — перекласти завдання на вимоги до доказів. Фінальна відповідь — не «я запустив команди». Фінальна відповідь — «потрібні ресурси існують у потрібному просторі імен, Deployment має запитану кількість реплік, Service вибирає очікувані поди, ConfigMap існує із запитаним ключем, а клієнт усередині кластера може досягти Service». Таке формулювання доказів змінює роботу. Ви більше не друкуєте лінійний рецепт; ви будуєте невеликий доказ для кожного твердження, яке робить завдання.

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

Далі виберіть шлях створення. Простий Deployment з образом і кількістю реплік — це завдання першого проходу, бо kubectl create deployment може виразити його напряму. Відкриття Deployment також завдання першого проходу, бо kubectl expose deployment створює Service із селектором, похідним від міток Deployment. Літерал ConfigMap достатньо простий для імперативної команди. Тимчасовий тестовий под BusyBox — теж імперативна команда, але він має запускатися після того, як Service існує, щоб його збій сказав вам щось про мережу, а не про відсутні ресурси.

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

Тепер інспектуйте мітки та селектори. Deployment створює поди з мітками, а Service маршрутизує до подів, чиї мітки відповідають його селектору. Якщо ви створили Service через kubectl expose deployment, селектор зазвичай коректний, але «зазвичай» — не доказ. Швидкий погляд на мітки Pod, селектор Service та ендпоінти підтверджує шлях трафіку. Якщо ендпоінти порожні, зміна порту Service без перевірки міток — це здогад. Якщо ендпоінти існують, наступний збій імовірніше пов’язаний із портом контейнера, відповіддю застосунку, DNS чи мережевою політикою.

Значення ConfigMap потребує власного доказу. Завдання може лише вимагати створення ConfigMap, і в такому разі kubectl get configmap orders-config -o yaml достатньо. Якщо завдання вимагає, щоб Deployment споживав ConfigMap, існування недостатньо; ви маєте інспектувати специфікацію Pod або виконати команду всередині контейнера, щоб перевірити змінну середовища чи змонтований файл. Завдання CKAD часто використовують точне формулювання. «Створіть ConfigMap» і «налаштуйте застосунок на використання ConfigMap» — це різні роботи, і сприйняття їх як однієї роботи створює ризик мовчазного часткового заліку.

Тест досяжності має йти зсередини кластера, бо Service типу ClusterIP не призначений для прямого доступу з вашого ноутбука. Тимчасовий под BusyBox, що використовує wget чи схожий клієнт, тестує той самий шлях DNS і маршрутизації Service, який використовував би інший Pod. Якщо цей тест дає збій, розбийте проблему. Спочатку підтвердьте DNS-ім’я Service та простір імен. Потім підтвердьте ендпоінти. Потім підтвердьте цільовий порт та відповідь контейнера. Цей шаруватий підхід запобігає поширеній звичці редагувати той маніфест, якого ви торкалися найостаннішим.

Припустімо, тест дає збій із помилкою DNS. Це вказує на ім’я, простір імен або кластерний DNS, а не на образ Deployment. Якщо тимчасовий Pod працює в default, поки Service живе в apps, коротке ім’я orders може не розв’язатися так, як очікувалося. Використайте повністю кваліфіковане ім’я сервісу або запустіть тестовий Pod у тому самому просторі імен. Це мережева проблема з боку розробника, і вона видається простою лише після того, як ви натренували себе розділяти DNS, вибір, готовність та відповідь застосунку.

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

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

Цей розбір прикладу також показує, чому план підготовки має містити змішані вправи. Якщо ви практикуєте лише створення Deployment, селектор Service видається окремою темою. Якщо ви практикуєте лише Services, помилки простору імен видаються фоновим шумом. Якщо ви практикуєте лише ConfigMaps, ви можете забути довести споживання. Змішане завдання змушує вас зберігати зв’язки між об’єктами, і це справжня навичка CKAD за багатьма завданнями, що виглядають простими.

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

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

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

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

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

Патерн	Коли його використовувати	Чому він працює
Спочатку згенеруй, потім редагуй	Ресурс має поширену стартову форму, але потребує кастомних полів	kubectl --dry-run=client -o yaml запобігає помилкам YAML з чистого аркуша, лишаючи місце для проб, env, томів та полів безпеки.
Перевір шлях трафіку	Задіяні Service, Ingress, NetworkPolicy чи проба готовності	Перевірка міток, селекторів, ендпоінтів та стану готовності знаходить справжній злам, замість припущення, що найновіший об’єкт неправильний.
Практикуй за сценаріями	Ви обираєте серед Pod, Deployment, Job, CronJob, init, сайдкара та Service	Формулювання за сценарієм тренує ту саму навичку вибору ресурсу, яку використовує екзамен, тоді як нотатки лише за об’єктами заохочують пригадування без судження.

Найсильніший антипатерн — вивчати CKAD як список ізольованих маніфестів об’єктів. Ізольовані маніфести виглядають продуктивними, бо створюють багато сторінок нотаток, але приховують зв’язки, які роблять Kubernetes корисним. Deployment потребує міток, які може вибрати Service. На Secret треба посилатися за коректним ключем. Проба готовності змінює маршрутизацію ендпоінтів. NetworkPolicy залежить від селекторів з обох боків з’єднання. Якщо ваш метод навчання не змушує ці зв’язки потрапити в поле зору, він не підготує вас до налагодження.

Антипатерн	Що йде не так	Краща альтернатива
Спочатку перевчати адміністрування кластера	Час іде на ноди та механіку площини управління замість завдань розробника	Коротко повторіть основи CKA, потім перейдіть до ресурсів та робочих процесів застосунків.
Копіювати аліаси в робочі приклади	Команди дають збій у скриптах чи вставлених оболонках, де аліаси не розгортаються	Набирайте повні команди kubectl у навчальних матеріалах і автоматизуйте лише після того, як звичка сформувалася.
Сприймати фольклор про прохідність як дані для планування	Зусилля на підготовку йдуть за анекдотами, а не за офіційною вагою доменів і особистою слабкістю	Використовуйте ваги доменів, вправи на час та журнали невдалих завдань, щоб вирішити, що практикувати далі.

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

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

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

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

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

Чи знали ви?

• CKA запустили у 2017 році, а CKAD з’явився у травні 2018 року. CKAD створили для розробників, які проєктують, збирають, налаштовують і відкривають застосунки на Kubernetes, не обов’язково керуючи самим кластером.
• Поточна сторінка CNCF CKAD перелічує п’ять доменів із вагами 20%, 20%, 15%, 25% та 20%. Ці числа є інструментом планування, бо найбільший домен — це середовище, конфігурація та безпека.
• Екзамен CKAD орієнтований на практику й триває приблизно дві години. Цей формат винагороджує виконання в командному рядку та перевірку, а не лише знання визначень ресурсів у теорії.
• CNCF заявляє, що заплановано щоквартальні оновлення екзамену для відповідності релізам Kubernetes. Для цього навчального плану практикуйте з Kubernetes 1.35 або новішим, щоб ваші команди та версії API лишалися актуальними.

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

Помилка	Чому вона виникає	Як її виправити
Занадто велика зосередженість на адмініструванні кластера	Звички CKA роблять ноди, ремонт площини управління та внутрішні механізми сховища важливішими за прикладні завдання CKAD	Коротко повторіть спільні основи, потім витрачайте більшість часу практики на робочі процеси розробника, проби, конфігурацію, Jobs, Services та налагодження.
Ігнорування init-контейнерів	Вони виглядають як невелика функція Pod, доки завдання не вимагає впорядкування налаштування до запуску основного контейнера	Практикуйте сценарії, де init-контейнер завантажує конфігурацію, чекає на залежність чи готує спільний том.
Незнання синтаксису проб	Поля проб точні, і учні часто плутають обов’язки живучості, готовності та запуску	Запам’ятайте одну мінімальну форму проби, потім відпрацюйте, який тип проби відповідає кожному режиму збою.
Пропускання Jobs і CronJobs	Довготривалі вебзастосунки видаються звичнішими, тож скінченні та заплановані навантаження отримують менше повторень	Створюйте один Job і один CronJob у кожній змішаній вправі, доки генерація команд і перевірка не стануть автоматичними.
Використання лише kubectl apply	Декларативні звички хороші в продакшені, але можуть бути повільними, коли екзамен просить простий об’єкт	Використовуйте імперативне створення та dry-run генерацію для стартових маніфестів, потім редагуйте лише ті поля, які вимагає завдання.
Забування перевірок контексту й простору імен	Кілька контекстів роблять можливим застосування коректного YAML до неправильної цілі	Починайте кожне завдання з підтвердження контексту та простору імен, потім перевіряйте ресурси в тій самій цілі, перш ніж рухатися далі.
Вивчення типів об’єктів без зв’язків між ресурсами	Окремі нотатки приховують, як взаємодіють мітки, селектори, проби, ендпоінти та політики	Будуйте малі сценарії, що змушують один зв’язок за раз, потім інспектуйте доказ через kubectl get, describe та логи.

Тест

Питання 1: Ви склали CKA минулого місяця й маєте десять вечорів для підготовки до CKAD. Ви вже вмієте створювати Pods, Deployments та Services, але повільні з ConfigMaps, Secrets, пробами, Jobs та CronJobs. Як вам спроєктувати план підготовки?

Надайте пріоритет слабким областям, орієнтованим на розробника, замість того щоб витрачати більшість вечорів на повторення основ CKA. Офіційні ваги роблять середовище, конфігурацію та безпеку найбільшим доменом, тож ConfigMaps, Secrets, налаштування ресурсів, ServiceAccounts та SecurityContexts заслуговують на великий блок. Jobs, CronJobs, проби та багатоконтейнерні патерни мають іти далі, бо саме вони найчастіше відрізняють CKAD від CKA. Залиште одну-дві змішані сесії для Pods, Deployments та Services, щоб основи лишалися швидкими, але не дозволяйте звичній роботі поглинути розклад.

Питання 2: Під час пробного екзамену на час ви починаєте зі складного багатоконтейнерного Pod, що потребує init-контейнера, сайдкара, спільного тому та перевірки логів. Через десять хвилин він усе ще дає збій. Що вам робити далі?

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

Питання 3: Об'єкт Service існує, але ваш тестовий Pod не може досягти вебзастосунку через ім'я Service. Поди Deployment працюють. Що ви інспектуєте, перш ніж змінювати образ застосунку?

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

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

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

Питання 5: Ви успішно застосовуєте маніфест, але `kubectl get pods` показує Pod у неправильному просторі імен. Завдання називало простір імен у першому реченні. Яка помилка робочого процесу це спричинила і як ви її запобігаєте?

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

Питання 6: Ваш Pod багаторазово перезапускається після додавання проби живучості, але застосунок зазвичай завантажується довго. Яку стратегію проб вам варто розглянути?

Розгляньте пробу запуску (startup), щоб Kubernetes дав застосунку з повільним стартом час до того, як почнуть діяти перезапуски за живучістю. Живучість має виявляти процес, який більше не здоровий після запуску, а не карати процес, який ще ініціалізується. Готовність також може бути потрібна, щоб тримати трафік подалі, доки застосунок не зможе обслуговувати запити. Ключ — зіставити тип проби з фазою життєвого циклу, а не збільшувати кожну затримку без розуміння симптому.

Питання 7: Колега каже, що CKAD має бути легким, бо він ділить Pods, Services, ConfigMaps, Secrets та NetworkPolicies з CKA. Чого бракує в цьому порівнянні?

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

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

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

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

# 1. Create a deployment with 3 replicas
kubectl create deployment ckad-test --image=nginx --replicas=3

# 2. Expose it as a ClusterIP service
kubectl expose deployment ckad-test --port=80

# 3. Create a ConfigMap
kubectl create configmap ckad-config --from-literal=env=production

# 4. Create a Secret with a training placeholder value
kubectl create secret generic ckad-secret --from-literal=password=your-password-here

# 5. Verify everything
kubectl get deploy,svc,cm,secret | grep ckad

Нотатки до розв'язання базової вправи

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

# Cleanup
kubectl delete deployment ckad-test
kubectl delete service ckad-test
kubectl delete configmap ckad-config
kubectl delete secret ckad-secret

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

• Впровадьте практичне середовище Kubernetes 1.35+ із kind і підтвердьте активний контекст kubectl.
• Створіть і відкрийте Deployment ckad-test, потім перевірте Service та вибрані поди.
• Згенеруйте dry-run YAML для Pod, Deployment та Service ClusterIP, потім інспектуйте згенеровані файли, перш ніж будь-що застосовувати.
• Створіть один Job і один CronJob, перевірте їхні ресурси та поясніть, чому жоден із них не має бути Deployment.
• Застосуйте маніфест пода з пробами зі швидкісної вправи, потім використайте kubectl describe, щоб довести наявність проб живучості, готовності та запуску.
• Приберіть усі ресурси з вправи та переконайтеся, що простір імен більше не містить названих практичних об’єктів.

Розширений посібник із розв'язання

Почніть зі створення кластера kind, якщо він ще не існує, потім виконайте kubectl config current-context і підтвердьте, що він указує на kind-ckad-prep. Створіть Deployment і Service базовими командами, потім інспектуйте kubectl get pods --show-labels, kubectl get service ckad-test та kubectl get endpoints ckad-test, щоб побачити зв’язок між мітками й селектором. Згенеруйте файли YAML за допомогою --dry-run=client -o yaml і прочитайте перші рядки, перш ніж застосовувати будь-який згенерований об’єкт. Для Job і CronJob використайте збережені команди швидкісної вправи та перевірте через kubectl get job,cronjob. Для пода з пробами застосуйте маніфест із вправи та використайте kubectl describe pod probed-app, щоб інспектувати розділи проб. Приберіть, видаливши кожен названий ресурс, і підтвердьте фінальним kubectl get pod,deploy,svc,job,cronjob,cm,secret.

Перевірка для учня

Перш ніж рухатися далі, переконайтеся, що можете пояснити, чому ця команда вправи тепер працює саме так, як написано — зокрема чому --target-port має збігатися з портом, який слухає контейнер (nginx обслуговує на 80), інакше Service залишиться з нульовою кількістю готових ендпоінтів:

kubectl expose deployment web —port=80 —target-port=80

Джерела

• https://www.cncf.io/training/certification/ckad/
• https://github.com/cncf/curriculum/blob/master/CKAD_Curriculum_v1.35.pdf
• https://docs.linuxfoundation.org/tc-docs/certification/lf-handbook2
• https://docs.linuxfoundation.org/tc-docs/certification/tips-cka-and-ckad
• https://v1-35.docs.kubernetes.io/docs/concepts/workloads/pods/
• https://v1-35.docs.kubernetes.io/docs/concepts/workloads/controllers/deployment/
• https://v1-35.docs.kubernetes.io/docs/concepts/workloads/controllers/job/
• https://v1-35.docs.kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
• https://v1-35.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
• https://v1-35.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/
• https://v1-35.docs.kubernetes.io/docs/concepts/services-networking/service/
• https://v1-35.docs.kubernetes.io/docs/reference/kubectl/generated/
• https://kind.sigs.k8s.io/docs/user/quick-start/

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

Модуль 0.2: Робочий процес розробника — оптимізуйте свої патерни kubectl для швидкості CKAD.