Модуль 1.3: Що ми не вивчаємо (і чому)

Складність: [ШВИДКО] - Встановлення очікувань

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

Передумови: Модуль 1, Модуль 2

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

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

Визначити, які теми Kubernetes є релевантними для іспиту, а які — цікавими, але поза його межами
Пріоритезувати свій час на навчання, знаючи правило 80/20 щодо того, що насправді перевіряється на іспитах
Пояснити, чому ми пропускаємо певні теми (наприклад, розробку власних CNI або внутрішню архітектуру etcd) і де їх вивчити, якщо вам цікаво
Спланувати ефективний шлях навчання, який дозволить уникнути пастки «100+ годин»

Чому це важливо

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

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

Наша філософія: Орієнтація на іспит, а не вичерпність

KubeDojo існує, щоб допомогти вам ефективно скласти сертифікації. Ми застосовуємо правило 80/20:

┌─────────────────────────────────────────────────────────────┐
│              ПРАВИЛО 80/20 ДЛЯ СЕРТИФІКАЦІЙ                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ████████████████████████████████████████ 80% питань       │
│  █ Основні теми, які ми вивчаємо глибоко █ іспиту          │
│  ████████████████████████████████████████                   │
│                                                             │
│  ████████████ 20% питань іспиту                            │
│  █ Граничні випадки, рідкісні, складні   █                  │
│  ████████████                                               │
│                                                             │
│  Результат: Максимальна ймовірність успіху при ефект. навч. │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Ми не намагаємося охопити все. Ми охоплюємо те, що важливо для успіху.

Що ми свідомо пропускаємо

1. Специфіка хмарних провайдерів

Тема	Чому ми пропускаємо	Де вивчити
Деталі AWS EKS	Іспит використовує загальний Kubernetes, не хмарний	Документація AWS, доки eksctl
Функції GKE	З тієї ж причини	Документація Google Cloud
Специфіка AKS	З тієї ж причини	Документація Azure
Інтеграція хмарного IAM	Специфічно для провайдера	Документація провайдера

Наш підхід: Ми навчаємо Kubernetes. Хмарні провайдери додають власні рівні. Вивчіть платформу, а потім вивчайте реалізацію вашого провайдера.

2. Експлуатація в продакшені в масштабі

Тема	Чому ми пропускаємо	Де вивчити
Федерація мультикластерів	Поза межами сертифікації	Документація Kubernetes, проєкт KubeFed
Автомасштабування кластера	Хмарні реалізації	Документація провайдера
Аварійне відновлення	Специфічно для організації	Книги про SRE, інструкції компанії
Оптимізація витрат	Специфічно для хмари	Ресурси з FinOps, калькулятори

Наш підхід: Сертифікації перевіряють фундаментальні знання. Експлуатація в продакшені потребує досвіду та контексту конкретної компанії.

3. Глибоке мережування

Тема	Чому ми пропускаємо	Де вивчити
Конфігурація BGP	CKA торкається лише основ	Ресурси з мережевої інженерії
Внутр. механізми Service mesh	Istio/Linkerd — це окремі домени	Документація проєктів
Внутр. механізми eBPF/Cilium	Складна мережева тема	Документація Cilium
Розробка власних CNI	Тема для розробників, не адміністраторів	Специфікація CNI

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

4. Конкретні інструменти/проєкти

Інструмент	Чому ми пропускаємо	Де вивчити
ArgoCD	Інструмент GitOps, немає на іспиті	Документація ArgoCD
Istio	Service mesh, окремий напрямок	Документація Istio
Terraform	Інструмент IaC, не специфічний для Kubernetes	HashiCorp Learn
Prometheus/Grafana	Інструменти спостережуваності, побіжно	Документація проєктів

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

Зупиніться та поміркуйте: Якщо ваша компанія активно використовує Istio, чи варто вам вивчати його для CKA? Як збалансувати підготовку до іспиту та корисність на роботі з першого дня?

Чому ми робимо такий вибір

Причина 1: Ефективність використання часу

Вивчення всього про Kubernetes: 6-12 місяців
Успішне складання CKA за умови зосередженого навчання: 4-8 тижнів

Різниця: Фокус

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

Причина 2: Релевантність іспиту

CKA, CKAD та CKS мають визначені навчальні програми. Ми орієнтуємося на ці програми. Додавання контенту поза межами іспиту:

Збільшує час на навчання
Додає плутанини
Не покращує показники успішності

Причина 3: Уникнення застарілого контенту

Kubernetes розвивається швидко. Чим більше тем ми охоплюємо, тим більше нам доводиться підтримувати. Зосереджуючись на релевантному для іспиту контенті:

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

Принцип “Якраз достатньо”

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

┌─────────────────────────────────────────────────────────────┐
│              РІВНІ ГЛИБИНИ ЗА ТЕМАМИ                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Тема               Потреби   Покриття   Рівень             │
│                     іспиту    KubeDojo   експерта           │
│  ──────────────────────────────────────────────────────    │
│  Pods               ████      ████       ████████████       │
│  Deployments        ████      ████       ██████████         │
│  Services           ████      ████       █████████████      │
│  NetworkPolicy      ███       ███        ████████████       │
│  RBAC               ███       ███        ██████████████     │
│  Helm               ██        ██         ████████████       │
│  etcd backup        █         █          ████████████████   │
│                                                             │
│  Ключ: █ = глибина покриття                                 │
│  Ми відповідаємо потребам іспиту, а не рівню експерта       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Зупиніться та подумайте: Подивіться на графік глибини вище. Чому, на вашу думку, «etcd backup» потребує дуже малої глибини для іспиту, але максимальної — для експерта? Що станеться в продакшені, якщо ви припуститеся помилки?

Де ми радимо заглибитися

Після отримання сертифікацій ви захочете піти глибше. Ось наш рекомендований шлях:

Для Platform-інженерів

Cluster API
GitOps (ArgoCD/Flux)
Патерни мультитенантності
Ресурси з Platform engineering

Для розробників

Патерни Kubernetes (sidecar, ambassador, adapter)
Розробка операторів та CRD
Програмування Kubernetes API
Плагіни Kubectl

Для фокуса на безпеці

Глибоке вивчення OPA/Gatekeeper
Falco та безпека під час виконання (runtime security)
Безпека ланцюжка постачання (Sigstore)
Складні патерни Network policy

Для SRE/експлуатації

Сповіщення на основі SLO
Chaos engineering
Планування потужностей
Реагування на інциденти

Візуалізація: Область охоплення KubeDojo

┌─────────────────────────────────────────────────────────────┐
│              ВСЕСВІТ ЗНАНЬ KUBERNETES                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│    ┌─────────────────────────────────────────────────┐     │
│    │                                                 │     │
│    │              CNCF Landscape                     │     │
│    │             (1000+ проєктів)                    │     │
│    │                                                 │     │
│    │    ┌───────────────────────────────────┐       │     │
│    │    │                                   │       │     │
│    │    │     Експлуатація в продакшені     │       │     │
│    │    │   (Специфіка компанії, інстр. тощо)│       │     │
│    │    │                                   │       │     │
│    │    │    ┌───────────────────────┐     │       │     │
│    │    │    │                       │     │       │     │
│    │    │    │  ╔═══════════════╗   │     │       │     │
│    │    │    │  ║   KubeDojo    ║   │     │       │     │
│    │    │    │  ║ (Фокус сертиф)║   │     │       │     │
│    │    │    │  ╚═══════════════╝   │     │       │     │
│    │    │    │    Навчальні         │     │       │     │
│    │    │    │    програми          │     │       │     │
│    │    │    └───────────────────────┘     │       │     │
│    │    │                                   │       │     │
│    │    └───────────────────────────────────┘       │     │
│    │                                                 │     │
│    └─────────────────────────────────────────────────┘     │
│                                                             │
│  Ми зосереджуємося на ядрі сертифікації.                    │
│  Ширша екосистема виходить за межі нашої компетенції.       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

CNCF Landscape налічує понад 1000 проєктів. Жодна людина не може опанувати їх усі. Спеціалізація необхідна.
Більшість користувачів Kubernetes у продакшені глибоко знають близько 20% Kubernetes. Вони знають те, чого вимагає їхня робота. Сертифікації доводять широту знань, а робота — формує глибину.
Програми сертифікації змінюються. Теми додаються та вилучаються. Ми відстежуємо зміни та оновлюємо контент відповідно до них.
Поняття «експерт» залежить від контексту. Експерт із мереж знає зовсім інші речі, ніж експерт із безпеки. Не існує універсального списку вимог до «експерта з Kubernetes».

Поширені запитання

«Але мені може знадобитися [тема] на роботі!»

Можливо. Наша порада:

Спочатку отримайте сертифікацію (це підтвердить ваші фундаментальні знання)
Вивчайте специфічні робочі теми безпосередньо в процесі роботи
Використовуйте документацію проєктів для конкретних інструментів (ArgoCD, Istio тощо)

«Чому б не включити все, щоб курс був повним?»

Повнота неможлива і контрпродуктивна:

Kubernetes постійно змінюється
Більше контенту = більше обслуговування = застарілий контент
Фокусований контент = вища якість

«Що, якщо на іспиті запитають про щось, чого ви не навчали?»

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

Типові помилки під час підготовки до сертифікацій K8s

Помилка	Чому це стається	Кращий підхід
Надмірне заглиблення в плагіни CNI	Мережування захоплює, а документація Calico/Cilium чудова.	Вивчіть рівно стільки, щоб вміти встановити CNI (зазвичай це одна команда `kubectl apply`) та розуміти базові NetworkPolicy.
Зазубрювання синтаксису YAML	Страх перед пустим екраном під час іспиту.	Опануйте `kubectl run` та `kubectl create` з прапорцями `--dry-run=client -o yaml` для генерації шаблонів.
Вивчення хмарних IAM	Ваша компанія використовує AWS IRSA або EKS Pod Identity, тому ви вважаєте це ядром Kubernetes.	Зосередьтеся на чистому Kubernetes RBAC (Roles, RoleBindings, ServiceAccounts). Іспит базується на стандартному (vanilla) Kubernetes.
Побудова кластера на Raspberry Pi	Ви хочете отримати «практичний» досвід побудови з нуля.	Використовуйте kind, minikube або керовану хмарну VM. Іспит перевіряє використання Kubernetes, а не боротьбу з особливостями архітектури ARM.
Занадто велика увага до Helm/Helmfiles	Це те, як ви щодня розгортаєте додатки на роботі.	Helm активно тестується в CKS і трохи в CKAD, але майже не згадується в CKA. Зосередьтеся на чистих маніфестах Kubernetes.
Вивчення GitOps (ArgoCD/Flux)	Це сучасний стандарт розгортання в Kubernetes.	ArgoCD немає на іспиті. Зрозумійте концепцію декларативного стану, але не вивчайте інструмент для іспиту.
Спроба опанувати операції з etcd	etcd — це «мозок» кластера, тому він здається критично важливим.	Вам потрібно лише знати, як робити снапшоти та відновлювати etcd за допомогою офіційної утиліти `etcdctl`. Залиште дефрагментацію кластера експертам.

Практична вправа: Проведіть аудит ваших навчальних матеріалів

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

Завдання: Розподіліть ваші навчальні матеріали на категорії «У межах іспиту» та «Спеціалізація після іспиту».

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

Ви визначили принаймні дві теми, які планували вивчати, але які насправді виходять за межі сертифікації (наприклад, Istio, специфіка EKS).
Ви перенесли ці теми до списку «Після іспиту».
Ви переконалися, що ваші основні навчальні матеріали зосереджені на стандартному (vanilla) Kubernetes.
Ви встановили чітку межу: «Я не буду вивчати Х, поки не складу іспит».

Контрольні запитання

Сценарій: Ви — молодший DevOps-інженер, що готується до CKA. Ваш керівник пропонує вам витратити наступні два тижні на глибоке вивчення Terraform та AWS EKS, оскільки команда використовує їх у продакшені. Як ви повинні відповісти щодо вашого плану підготовки до CKA?

Відповідь
Поясніть, що хоча Terraform та EKS критично важливі для роботи, вони суворо виходять за межі іспиту CKA. Іспит перевіряє загальні, стандартні компоненти Kubernetes і є повністю хмарно-агностичним. Витрата двох тижнів на Terraform покращить вашу продуктивність на роботі, але реально затримає прогрес у сертифікації. Вам варто ввічливо запропонувати розділити час або спочатку повністю зосередитися на сертифікації, перш ніж опановувати специфічний інструментарій компанії.
Сценарій: Вивчаючи NetworkPolicy для CKAD, ви знаходите неймовірний 4-годинний туторіал зі створення власних програм eBPF за допомогою Cilium. Вас захоплюють мережі. Чи варто вам пройти цей туторіал зараз?

Відповідь
Ні, вам слід зберегти його в закладки на час після іспиту. Хоча Cilium та eBPF є потужними та все частіше стають стандартом у сучасних кластерах, іспит CKAD вимагає від вас лише розуміння стандартних об'єктів Kubernetes NetworkPolicy. Занурення в eBPF — це класичний приклад «пастки 100+ годин», згаданої в цьому модулі. Дотримуйтеся правила 80/20 та спочатку опануйте основи, щоб ефективно скласти іспит.
Сценарій: Ви створюєте план навчання для CKA. Ви виділяєте 5 годин на вивчення того, як розгортати та налаштовувати ArgoCD для GitOps, і 5 годин на практику зі стандартними Kubernetes Deployment та Service. Проаналізуйте цей план.

Відповідь
Цей план навчання сильно не відповідає цілям іспиту. ArgoCD, хоча і є галузевим стандартом для GitOps, є стороннім інструментом і взагалі не згадується на іспиті CKA. Виділення однакового часу на тему поза іспитом та на основні теми іспиту порушує філософію орієнтації на іспит. Вам слід повністю перерозподілити час ArgoCD на опанування основних примітивів Kubernetes, усунення несправностей та архітектуру кластера.
Сценарій: Колега провалив іспит CKA і скаржиться: «Іспит такий нереалістичний! На роботі я просто використовую консоль AWS, щоб додавати вузли, а іспит хотів, щоб я розбирався з сервісами systemd для kubelet». Чому ваш колега провалив іспит, і що це говорить про межі іспиту?

Відповідь
Ваш колега провалив іспит, бо змішав абстракції хмарного провайдера з основним адмініструванням Kubernetes. CKA спеціально перевіряє вашу здатність адмініструвати стандартний Kubernetes, що означає безпосередню взаємодію з такими компонентами, як `kubelet` та `systemd` на звичайних вузлах Linux. Це підкреслює, чому ми в KubeDojo свідомо пропускаємо специфіку хмарних провайдерів. Покладання на хмарні абстракції маскує фундаментальні операції кластера, які насправді перевіряються під час сертифікації.
Сценарій: Ви читаєте документацію Kubernetes щодо масштабування та натрапляєте на Cluster Autoscaler та Horizontal Pod Autoscaler (HPA). Виходячи з філософії KubeDojo «Що ми свідомо пропускаємо», на чому вам слід зосередитися для іспиту і чому?

Відповідь
Вам слід повністю зосередитися на Horizontal Pod Autoscaler (HPA). HPA — це основний об'єкт API Kubernetes, який масштабує поди на основі метрик, і він явно є частиною навчальної програми іспиту. З іншого боку, Cluster Autoscaler взаємодіє з інфраструктурою хмарного провайдера для додавання або видалення реальних вузлів. Оскільки іспит суворо хмарно-агностичний, специфічні для хмари механізми масштабування інфраструктури повністю виходять за його межі.
Сценарій: Ви хочете попрактикуватися перед іспитом, тому вирішуєте витратити вихідні на налаштування високонадійного (HA) мультимайстер кластера Kubernetes на фізичних серверах (bare metal) за допомогою kubeadm, із зовнішнім кластером etcd та балансувальниками HAProxy. Чи є це корисним використанням вашого часу на навчання?

Відповідь
Це чудова вправа для старшого Platform-інженера, але жахлива трата часу для підготовки до CKA. Іспит не вимагає від вас побудови складних високонадійних архітектур з нуля; він вимагає розуміння того, як розгорнути базовий кластер за допомогою kubeadm. Побудова HA кластера на фізичних серверах додає величезну складність, яка повністю виходить за межі «Якраз достатньо» для іспиту. Замість цього вам слід використовувати просте, заздалегідь налаштоване середовище для навчання.
Сценарій: Дивлячись на графік «Рівні глибини за темами», ви бачите, що «etcd backup» оцінюється як дуже поверхнева тема для іспиту, але максимально глибока для експерта. Ви складаєте іспит наступного тижня. Чи варто вам читати офіційний whitepaper з аварійного відновлення etcd?

Відповідь
Абсолютно ні, оскільки це буде величезною тратою часу. Іспит вимагає від вас знання лише двох команд для etcd: як зробити снапшот і як відновити його за допомогою офіційної утиліти `etcdctl`. Читання документації з аварійного відновлення виходить далеко за межі принципу «Якраз достатньо» і відноситься до просунутих операцій. Ви повинні безжально пріоритезувати механічне виконання процесу створення снапшота над глибоким теоретичним розумінням.

Вправа для роздумів

Цей модуль встановлює очікування — поміркуйте над вашим навчальним шляхом:

Ваші цілі навчання:

Чому ви вивчаєте Kubernetes?
Сертифікація — це кінцева мета чи сходинка?
Яка конкретна робоча роль або проєкт вас мотивує?

Принцип 80/20:

У вашій сфері, які 20% знань покривають 80% ситуацій?
Чи завжди заглиблення допомагає, чи воно може відволікати?

Дисципліна меж (Scope discipline):

Чи ви коли-небудь витрачали час на вивчення чогось, що виявилося нерелевантним?
Як ви вирішуєте, що варто вивчати глибоко, а про що достатньо просто знати?

Після сертифікації:

Яка спеціалізація вас цікавить? (Platform engineering, безпека, SRE, розробка?)
Як би виглядала ваша ідеальна робота з Kubernetes?

Планування часу:

Скільки часу ви можете цьому приділити?
Враховуючи фокус KubeDojo, чи потрібні вам додаткові ресурси для ваших конкретних цілей?

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

Підсумок

KubeDojo робить свідомий вибір щодо меж навчання:

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

Розуміння цих меж допомагає вам встановити очікування та спланувати ваш ширший шлях навчання.

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

Модуль 1.4: Глухі кути — технології, які ми пропускаємо — Чому певні технології є застарілими та не варті вивчення.