Модуль 1.9: Основи налагодження (Теорія)

Складність: [ШВИДКО] - Мислення швидкого тріажу

Час на виконання: 15-20 хвилин

Передумови: Модулі 1.1–1.8 (Основи K8s)

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

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

Пояснити систематичний підхід до діагностики збоїв навантажень Kubernetes
Визначити типові шаблони збоїв за статусом Pod, подіями та виводом логів
Простежити шлях відлагодження від симптому до першопричини за допомогою kubectl describe та logs
Порівняти різні категорії збоїв: помилки завантаження образу, планування, crashloop та конфігурації

Зміст

Як швидко зчитувати стан Пода
Основні команди для першої реакції при налагодженні
Типові патерни збоїв та що вони означають
Ментальна модель: детектив з трикроковим чек-листом (стан → події → логи)
Міні-сценарій: “Мій застосунок не працює, у мене 3 хвилини — що перевірити спочатку?”

Зчитуйте сигнали (дошка підказок)

Фаза Пода: Pending, Running, Succeeded, Failed, Unknown.
Лічильники перезапусків: Багато перезапусків зазвичай означають цикли збоїв або OOM kills.
Події: Причини від Scheduler або kubelet часто пояснюють стани Pending/Failed.
Стан контейнера: Waiting (ImagePullBackOff, ErrImagePull), Terminated (ExitCode, OOMKilled).

kubectl get pods -A
kubectl describe pod <name> -n <ns>    # події + стан контейнера
kubectl logs <name> -n <ns>            # за замовчуванням: перший контейнер
kubectl logs <name> -n <ns> -c <c>     # поди з кількома контейнерами
kubectl logs -p <name> -n <ns>         # попередній екземпляр (цикли збоїв)

Типові патерни збоїв

ImagePullBackOff / ErrImagePull: Неправильне ім’я/тег образу, автентифікація реєстру або мережевий шлях.
CrashLoopBackOff: Застосунок завершується швидко; перевірте логи, проби, монтування config/secret, аргументи точки входу.
Pending: Жоден вузол не відповідає (taints/affinity), недостатньо CPU/пам’яті, проблеми прив’язки PVC.
OOMKilled: Контейнер перевищив пам’ять; перевірте limits/requests та профіль пам’яті застосунку.
Збої проб: Liveness постійно перезапускає Под; readiness тримає його поза Endpoints Service.

Швидкі перевірки (порядок операцій)

kubectl get pods -o wide (фаза/вузол).
kubectl describe pod (події, причини).
kubectl logs (та -p якщо перезапускається).
kubectl get events --sort-by=.lastTimestamp | tail (підказки на рівні кластера).
Якщо пов’язано з вузлом: kubectl get nodes -o wide та перевірте taints/умови.

Мислення для іспиту: Знайте, де дивитися спочатку. KCNA очікує обізнаність про ці сигнали, а не глибокі скрипти усунення несправностей.

Ментальна модель: Тріаж як у невідкладній допомозі: показники (фаза/перезапуски), записи (події), потім історія пацієнта (логи). Не переходьте до хірургії (зміни конфігурації) до перевірки показників.

КАРТА ПІДКАЗОК
[Показники]   kubectl get pods
[Записи]      kubectl describe pod
[Історія]     kubectl logs (-p)
[Обстановка]  kubectl get events --sort-by=.lastTimestamp | tail

Радар пасток: Повторний запуск kubectl apply рідко виправляє неправильний образ, відсутній secret або збійну пробу — знайдіть підказку спочатку.