Модуль 5.1: Методологія усунення несправностей

Складність: [MEDIUM] — Основа для всього усунення несправностей

Час на виконання: 40–50 хвилин

Передумови: Частини 1–4 завершені (архітектура кластера, робочі навантаження, мережа, сховище)

---

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

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

• Застосувати систематичну методологію усунення несправностей (симптоми → гіпотези → перевірка → виправлення → валідація)
• Класифікувати питання з усунення несправностей CKA, визначивши рівень збою (застосунок, сервіс, вузол, площина управління)
• Використовувати команди kubectl (describe, logs, events, get -o yaml) у правильному діагностичному порядку
• Уникати головної помилки при усуненні несправностей: вносити зміни до того, як зрозумієте проблему

---

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

Усунення несправностей — це 30% іспиту CKA — найбільший окремий домен. Що важливіше, усунення несправностей — це те, що відрізняє операторів Kubernetes від експертів Kubernetes. Коли продакшн-кластер лежить о 3 годині ночі, систематичне налагодження — це різниця між 5-хвилинним виправленням і 5-годинним кошмаром.

Аналогія з лікарем

Хороший лікар не вгадує лікування — він дотримується діагностичного процесу. Симптоми → огляд → аналізи → діагноз → лікування. Усунення несправностей Kubernetes працює так само. Випадкові «виправлення» можуть іноді спрацювати, але систематичне розслідування працює завжди.

---

Що ви дізнаєтесь

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

• Застосовувати систематичну методологію усунення несправностей
• Швидко визначати, який компонент дає збій
• Використовувати команди kubectl для швидкої діагностики
• Розуміти, де шукати різні типи проблем
• Сортувати проблеми за стратегією трьох проходів

---

Чи знали ви?

• 80% проблем зосереджені в 5 місцях: помилки специфікації Підів, проблеми з витягуванням образів, обмеження ресурсів, мережеві політики та неправильно налаштовані Сервіси
• Події зникають: Kubernetes зберігає події лише 1 годину за замовчуванням — якщо не перевірите вчасно, докази зникнуть
• describe > logs: Більшість початківців одразу переходять до логів. Досвідчені фахівці спочатку перевіряють describe — секція Events часто одразу виявляє проблему

---

Частина 1: Фреймворк усунення несправностей

1.1 Чотирикроковий процес

Кожна сесія усунення несправностей повинна дотримуватися цього шаблону:

┌──────────────────────────────────────────────────────────────┐
│              ФРЕЙМВОРК УСУНЕННЯ НЕСПРАВНОСТЕЙ                │
│                                                               │
│   ┌─────────────┐     ┌─────────────┐     ┌─────────────┐   │
│   │1. ВИЗНАЧИТИ │────▶│2. ІЗОЛЮВАТИ │────▶│3. ДІАГНОСТУ-│   │
│   │   Що не     │     │   Де        │     │   ВАТИ      │   │
│   │   так?      │     │   не так?   │     │   Чому?     │   │
│   └─────────────┘     └─────────────┘     └─────────────┘   │
│                                                  │            │
│                                                  ▼            │
│                                           ┌─────────────┐    │
│                                           │ 4. ВИПРАВИТИ│    │
│                                           │   Застосувати│    │
│                                           │   рішення    │    │
│                                           └─────────────┘    │
└──────────────────────────────────────────────────────────────┘

1.2 Крок 1: Визначити — Що не так?

Почніть з симптому. Будьте конкретними:

Розмито	Конкретно
«Додаток зламався»	«Під у стані CrashLoopBackOff»
«Мережа не працює»	«Під не може дістатись до зовнішнього DNS»
«Кластер повільний»	«Час відповіді API-сервера > 5с»

Початкові команди для оцінки:

# Перевірка стану всього кластера
k get nodes
k get pods -A | grep -v Running
k get events -A --sort-by='.lastTimestamp' | tail -20

# Стан компонентів
k get componentstatuses  # Застарілий, але все ще корисний
k -n kube-system get pods

1.3 Крок 2: Ізолювати — Де не так?

Систематично звужуйте область пошуку:

┌──────────────────────────────────────────────────────────────┐
│                     РІВНІ ІЗОЛЯЦІЇ                            │
│                                                               │
│   ┌─────────────────────────────────────────────────────┐    │
│   │                    КЛАСТЕР                           │    │
│   │   ┌─────────────────────────────────────────────┐   │    │
│   │   │                  ВУЗОЛ                       │   │    │
│   │   │   ┌─────────────────────────────────────┐   │   │    │
│   │   │   │                ПІД                   │   │   │    │
│   │   │   │   ┌─────────────────────────────┐   │   │   │    │
│   │   │   │   │         КОНТЕЙНЕР            │   │   │   │    │
│   │   │   │   │   ┌─────────────────────┐   │   │   │   │    │
│   │   │   │   │   │     ДОДАТОК         │   │   │   │   │    │
│   │   │   │   │   └─────────────────────┘   │   │   │   │    │
│   │   │   │   └─────────────────────────────┘   │   │   │    │
│   │   │   └─────────────────────────────────────┘   │   │    │
│   │   └─────────────────────────────────────────────┘   │    │
│   └─────────────────────────────────────────────────────┘    │
│                                                               │
│   Починайте широко, заглиблюйтесь, поки не знайдете рівень  │
│   проблеми                                                    │
└──────────────────────────────────────────────────────────────┘

Питання для ізоляції:

• Це всі Під’и чи конкретні?
• Це всі вузли чи конкретні?
• Це всі namespace чи конкретні?
• Чи працювало раніше? Що змінилось?

1.4 Крок 3: Діагностувати — Чому не так?

Коли ви ізолювали рівень, збирайте детальну інформацію:

# Діагностика на рівні Підів
k describe pod <pod-name>     # Секція Events — це золото
k logs <pod-name>             # Поточні логи контейнера
k logs <pod-name> --previous  # Попередній контейнер (якщо впав)

# Діагностика на рівні вузлів
k describe node <node-name>
ssh <node> journalctl -u kubelet

# Діагностика на рівні кластера
k -n kube-system logs <component-pod>

1.5 Крок 4: Виправити — Застосувати рішення

Виправляти тільки після діагностики:

# Застосувати виправлення
k edit <resource>          # Пряме редагування
k apply -f <fixed-yaml>    # Застосувати виправлену специфікацію
k delete pod <pod>         # Примусовий перезапуск

# Перевірити виправлення
k get pods -w              # Спостерігати за зміною статусу
k logs <pod>               # Перевірити нові логи

---

Частина 2: Карта компонентів Kubernetes

2.1 Знайте свої компоненти

Розуміння того, що робить кожний компонент, допомагає знати, де шукати:

┌──────────────────────────────────────────────────────────────┐
│                   КАРТА ЗБОЇВ КОМПОНЕНТІВ                     │
│                                                               │
│ СИМПТОМ                          ПЕРЕВІРТЕ ЦІ КОМПОНЕНТИ     │
│ ─────────────────────────────────────────────────────────────│
│                                                               │
│ Під'и не розподіляються       →  kube-scheduler               │
│ Під'и застрягли в Pending     →  scheduler, ресурси вузлів   │
│ Під'и застрягли ContainerCreating → kubelet, pull образів,   │
│                                    тома                       │
│ Під'и CrashLoopBackOff        →  контейнер, конфіг додатку  │
│ Під'и не можуть спілкуватись  →  CNI, мережеві політики      │
│ Сервіси не працюють           →  kube-proxy, endpoints       │
│ kubectl не відповідає         →  API-сервер, etcd             │
│ Вузол NotReady                →  kubelet, container runtime   │
│ Проблеми з persistent volume  →  CSI драйвер, storage class  │
│                                                               │
└──────────────────────────────────────────────────────────────┘

2.2 Компоненти площини управління

Компонент	Що робить	Симптоми збою
kube-apiserver	Усі операції API	kubectl не працює, нічого не працює
etcd	Зберігання стану	Втрата даних, неузгоджений стан
kube-scheduler	Розміщення Підів	Під’и застрягли в Pending
kube-controller-manager	Цикли узгодження	Ресурси не оновлюються

2.3 Компоненти вузлів

Компонент	Що робить	Симптоми збою
kubelet	Життєвий цикл Підів	Під’и не запускаються, вузол NotReady
kube-proxy	Мережа Сервісів	Сервіси недоступні
Container runtime	Виконання контейнерів	ContainerCreating зависає
CNI плагін	Мережа Підів	Під’и не можуть спілкуватись

---

Частина 3: Основні команди для усунення несправностей

3.1 Базові команди

Запам’ятайте їх — ви будете використовувати їх постійно:

# Огляд статусу
k get pods                    # Статус Підів
k get pods -o wide            # Плюс вузол та IP
k get events --sort-by='.lastTimestamp'  # Останні події

# Глибока перевірка
k describe pod <pod>          # Повні деталі + події
k logs <pod>                  # stdout/stderr контейнера
k logs <pod> -c <container>   # Конкретний контейнер
k logs <pod> --previous       # Попередній екземпляр контейнера

# Інтерактивне налагодження
k exec -it <pod> -- sh        # Оболонка в контейнері
k exec <pod> -- cat /etc/resolv.conf  # Виконати одну команду

# Стан ресурсів
k get <resource> -o yaml      # Повна специфікація ресурсу
k explain <resource.field>    # Документація API

3.2 Фільтрація та пошук

# Знайти проблемні Під'и
k get pods -A | grep -v Running
k get pods -A --field-selector=status.phase!=Running

# Знайти Під'и на конкретному вузлі
k get pods -A --field-selector spec.nodeName=worker-1

# Знайти Під'и за міткою
k get pods -l app=nginx

# Пошук помилок в подіях
k get events -A | grep -i error
k get events -A | grep -i fail

3.3 Споживання ресурсів

# Ресурси вузлів
k top nodes
k describe node <node> | grep -A 5 "Allocated resources"

# Ресурси Підів
k top pods
k top pods --containers

# Перевірити запити/ліміти ресурсів
k get pods -o custom-columns=\
'NAME:.metadata.name,CPU_REQ:.spec.containers[*].resources.requests.cpu,MEM_REQ:.spec.containers[*].resources.requests.memory'

3.4 Налагодження мережі

# Резолвінг DNS
k exec <pod> -- nslookup kubernetes
k exec <pod> -- cat /etc/resolv.conf

# Зв'язність
k exec <pod> -- wget -qO- http://service-name
k exec <pod> -- nc -zv service-name 80

# Endpoints Сервісів
k get endpoints <service>
k get endpointslices -l kubernetes.io/service-name=<service>

---

Частина 4: Читання статусу Підів

4.1 Значення фаз Підів

┌──────────────────────────────────────────────────────────────┐
│                       ФАЗИ ПІДІВ                              │
│                                                               │
│   Pending ──────▶ Running ──────▶ Succeeded                  │
│      │              │                                         │
│      │              ▼                                         │
│      │           Failed                                       │
│      │              │                                         │
│      ▼              ▼                                         │
│   [Проблема]    [Проблема]                                   │
│                                                               │
│   Pending: Очікування розподілу або витягування образу        │
│   Running: Принаймні один контейнер працює                   │
│   Succeeded: Усі контейнери завершились з кодом 0            │
│   Failed: Принаймні один контейнер завершився з помилкою     │
│   Unknown: Зв'язок з вузлом втрачено                         │
└──────────────────────────────────────────────────────────────┘

4.2 Типові стани Підів

Статус	Значення	Що перевірити першим
Pending	Ще не розподілений	k describe pod — секція Events
ContainerCreating	Витягування образу або монтування тому	k describe pod — секція Events
Running	Контейнер(и) працюють	k logs для проблем додатку
CrashLoopBackOff	Контейнер падає багаторазово	k logs --previous
ImagePullBackOff	Не може витягнути образ	Ім’я образу, автентифікація реєстру
ErrImagePull	Помилка витягування образу	Те саме
CreateContainerConfigError	Проблема з конфігурацією	Відсутній ConfigMap/Secret
OOMKilled	Вичерпано пам’ять	Збільшити ліміт пам’яті
Evicted	Тиск на вузол	Ресурси вузла, пріоритет Підів

4.3 Розшифровка CrashLoopBackOff

Найпоширеніший сценарій усунення несправностей:

# Крок 1: Перевірити події
k describe pod <pod> | grep -A 20 Events

# Крок 2: Перевірити попередні логи
k logs <pod> --previous

# Крок 3: Перевірити код виходу контейнера
k get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

# Типові коди виходу:
# 0   - Успіх (не повинен викликати CrashLoop)
# 1   - Помилка додатку
# 137 - SIGKILL (OOMKilled або вбитий системою)
# 139 - SIGSEGV (помилка сегментації)
# 143 - SIGTERM (graceful завершення)

---

Частина 5: Глибоке занурення у вивід describe

5.1 Ключові секції в describe pod

k describe pod <pod-name>

┌──────────────────────────────────────────────────────────────┐
│                 СЕКЦІЇ ВИВОДУ DESCRIBE                        │
│                                                               │
│ Секція               На що звертати увагу                    │
│ ─────────────────────────────────────────────────────────────│
│                                                               │
│ Status:              Поточна фаза (Pending/Running/тощо)     │
│                                                               │
│ Containers:          State, Ready, Restart Count              │
│                      Last State (інфо про падіння)           │
│                      Image (перевірте правильність)          │
│                                                               │
│ Conditions:          Ready, ContainersReady, PodScheduled     │
│                      False = проблема                        │
│                                                               │
│ Volumes:             ConfigMaps, Secrets, PVCs                │
│                      Відсутній = Під не запуститься           │
│                                                               │
│ Events:              НАЙВАЖЛИВІША СЕКЦІЯ                     │
│                      Показує що відбувається/відбулось       │
│                      Помилки з'являються тут першими          │
│                                                               │
└──────────────────────────────────────────────────────────────┘

5.2 Ключові секції в describe node

k describe node <node-name>

Секція	На що звертати увагу
Conditions	Ready=True, MemoryPressure=False, DiskPressure=False
Capacity	Загальний CPU, пам’ять, Під’и
Allocatable	Доступно для Підів (після системного резервування)
Allocated resources	Поточне використання та запити
Events	Евікції, стани тиску

---

Частина 6: Стратегія усунення несправностей на іспиті

6.1 Три проходи для усунення несправностей

┌──────────────────────────────────────────────────────────────┐
│       СТРАТЕГІЯ ТРЬОХ ПРОХОДІВ ДЛЯ УСУНЕННЯ НЕСПРАВНОСТЕЙ   │
│                                                               │
│ ПРОХІД 1: Швидкі виправлення (1–3 хв)                       │
│   • Очевидні помилки в YAML                                  │
│   • Неправильне ім'я/тег образу                              │
│   • Відсутній namespace в команді                            │
│   • Неспівпадіння label selector                             │
│                                                               │
│ ПРОХІД 2: Стандартні проблеми (4–6 хв)                       │
│   • Відсутній ConfigMap/Secret                               │
│   • Обмеження ресурсів                                       │
│   • Неспівпадіння selector Сервісу                           │
│   • Мережева політика блокує трафік                          │
│                                                               │
│ ПРОХІД 3: Складні проблеми (7+ хв)                           │
│   • Збої компонентів площини управління                      │
│   • Проблеми на рівні вузлів                                 │
│   • Проблеми з CNI/мережею                                   │
│   • Проблеми зі сховищем/CSI                                 │
│                                                               │
└──────────────────────────────────────────────────────────────┘

6.2 Управління часом

Для 2-годинного іспиту з 30% за усунення несправностей:

• ~36 хвилин на питання усунення несправностей
• Ймовірно 3–4 сценарії усунення несправностей
• ~9–12 хвилин максимум на сценарій

Золоте правило: Якщо ви не можете визначити проблему за 3 хвилини дослідження — позначте і рухайтесь далі.

6.3 Типові шаблони на іспиті

Сценарій	Ймовірна проблема	Швидка перевірка
Під не запускається	Образ, ConfigMap/Secret	k describe pod
Сервіс недоступний	Selector, endpoints	k get endpoints
Вузол NotReady	kubelet, runtime	ssh node; systemctl status kubelet
DNS не працює	Під’и CoreDNS	k -n kube-system get pods -l k8s-app=kube-dns
Persistent volume pending	StorageClass, PV	k describe pvc

---

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

Помилка	Проблема	Рішення
Перехід до логів першим	Пропуск проблем розподілу/конфігурації	Завжди describe перед logs
Непереверяння подій	Пропуск критичних повідомлень про помилки	Перевіряти події одразу
Виправлення без діагностики	Може не виправити справжню проблему	Завжди визначати кореневу причину
Забули --previous	Неможливо побачити чому контейнер впав	Використовувати для CrashLoopBackOff
Ігнорування кодів виходу	Пропуск OOM vs помилка додатку	Перевірити код виходу для причини
Непереверяння всіх контейнерів	Під’и з кількома контейнерами	Використовувати прапорець -c <container>

---

Тест

Q1: Перша команда

Під у стані CrashLoopBackOff. Яку першу команду ви повинні виконати?

Відповідь

k describe pod <pod-name> — Перевірте секцію Events першою. Вона покаже, чому контейнер падає (проблеми з образом, проблеми з томами тощо). Потім перевірте k logs <pod> --previous, щоб побачити логи падіння.

Q2: Зберігання подій

Чому важливо швидко перевіряти події після виникнення проблеми?

Відповідь

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

Q3: Коди виходу

Контейнер має код виходу 137. Що це означає?

Відповідь

Код виходу 137 = 128 + 9 (SIGKILL). Це зазвичай означає:

1. OOMKilled — контейнер перевищив ліміт пам’яті
2. Система вбила процес (тиск на вузол)

Перевірте k describe pod для статусу OOMKilled та перевірте ліміти пам’яті.

Q4: Pending vs ContainerCreating

У чому різниця між статусом Pending і ContainerCreating?

Відповідь

• Pending: Під ще не розподілений на вузол (проблеми планувальника, немає відповідного вузла, taints, обмеження ресурсів)
• ContainerCreating: Під розподілений, вузол готує його до запуску (витягування образів, монтування томів, налаштування мережі)

Перевірте Events у describe, щоб побачити, який крок застряг.

Q5: Логи багатоконтейнерних Підів

Як переглянути логи конкретного контейнера в Підові з кількома контейнерами?

Відповідь

k logs <pod-name> -c <container-name>

# Перелік контейнерів у Підові
k get pod <pod-name> -o jsonpath='{.spec.containers[*].name}'

Без -c kubectl показує логи першого контейнера (або помилку, якщо їх кілька).

Q6: Усунення несправностей вузла

Вузол показує статус NotReady. Який ваш систематичний підхід?

Відповідь

1. k describe node <node> — перевірити секцію Conditions
2. SSH до вузла, якщо є доступ
3. systemctl status kubelet — чи працює kubelet?
4. journalctl -u kubelet -f — перевірити логи kubelet
5. systemctl status containerd (або docker) — чи працює runtime?
6. Перевірити мережеве з’єднання з площиною управління

---

Практична вправа: Практика систематичного усунення несправностей

Сценарій

Ви створите кілька зламаних ресурсів і попрактикуєтесь у систематичному усуненні несправностей.

Підготовка

# Створити namespace
k create ns troubleshoot-lab

# Створити «зламаний» Деплоймент — спробуйте знайти всі проблеми
cat <<'EOF' | k apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: broken-app
  namespace: troubleshoot-lab
spec:
  replicas: 2
  selector:
    matchLabels:
      app: broken-app
  template:
    metadata:
      labels:
        app: broken-app
    spec:
      containers:
      - name: app
        image: nginx:latestt
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "64Mi"
            cpu: "500m"
        volumeMounts:
        - name: config
          mountPath: /etc/nginx/conf.d
      volumes:
      - name: config
        configMap:
          name: nginx-config
EOF

Завдання

Застосуйте методологію усунення несправностей:

1. Визначити — Що не так?

k get pods -n troubleshoot-lab
# Який статус ви бачите?

2. Ізолювати — Де не так?

k describe pod -n troubleshoot-lab -l app=broken-app
# Подивіться на секцію Events

3. Діагностувати — Чому не так? Знайдіть усі проблеми (їх щонайменше 2):

• Проблема 1: _______________
• Проблема 2: _______________

4. Виправити — Застосувати рішення

# Виправити проблему 1: Помилка в імені образу
k set image deployment/broken-app -n troubleshoot-lab app=nginx:latest

# Виправити проблему 2: Відсутній ConfigMap
k create configmap nginx-config -n troubleshoot-lab --from-literal=placeholder=true

# Перевірити
k get pods -n troubleshoot-lab -w

Розширений виклик

Створіть більше зламаних сценаріїв:

# Сценарій 2: CrashLoopBackOff
cat <<'EOF' | k apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: crash-pod
  namespace: troubleshoot-lab
spec:
  containers:
  - name: app
    image: busybox
    command: ['sh', '-c', 'exit 1']
EOF

# Сценарій 3: Під у стані Pending
cat <<'EOF' | k apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: pending-pod
  namespace: troubleshoot-lab
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "100Gi"
        cpu: "100"
EOF

Усуньте несправності кожного систематично.

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

• Визначили помилку в назві образу в Деплойменті
• Визначили відсутній ConfigMap
• Виправили Деплоймент до стану Running
• Пояснили, чому crash-pod у стані CrashLoopBackOff
• Пояснили, чому pending-pod залишається в Pending

Очищення

k delete ns troubleshoot-lab

---

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

Практикуйте ці сценарії, поки вони не стануть автоматичними:

Вправа 1: Швидка перевірка статусу (30 с)

# Завдання: Знайти всі Під'и, що не працюють, у всіх namespace
k get pods -A | grep -v Running
# Або: k get pods -A --field-selector=status.phase!=Running

Вправа 2: Останні події (30 с)

# Завдання: Показати останні 10 подій, відсортованих за часом
k get events -A --sort-by='.lastTimestamp' | tail -10

Вправа 3: Дослідження падіння Підів (2 хв)

# Завдання: Повне дослідження Підів у CrashLoopBackOff
k describe pod <pod>        # Крок 1: Події
k logs <pod> --previous     # Крок 2: Логи падіння
k get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'  # Крок 3: Код виходу

Вправа 4: Перевірка здоров’я вузла (1 хв)

# Завдання: Перевірити здоров'я та ресурси вузла
k get nodes
k describe node <node> | grep -A 5 Conditions
k top nodes

Вправа 5: Перевірка endpoints Сервісу (1 хв)

# Завдання: Перевірити чи Сервіс має endpoints
k get svc <service>
k get endpoints <service>
k get pods -l <service-selector>

Вправа 6: Перевірка DNS (1 хв)

# Завдання: Перевірити роботу DNS у кластері
k run dnstest --image=busybox:1.36 --rm -it --restart=Never -- nslookup kubernetes

Вправа 7: Доступ до оболонки контейнера (30 с)

# Завдання: Отримати оболонку в працюючому контейнері
k exec -it <pod> -- /bin/sh
# Якщо sh недоступний: k exec -it <pod> -- /bin/bash

Вправа 8: Логи багатоконтейнерних Підів (1 хв)

# Завдання: Переглянути логи конкретного контейнера та слідкувати
k logs <pod> -c <container> -f
# Перелік усіх контейнерів: k get pod <pod> -o jsonpath='{.spec.containers[*].name}'

---

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

Переходьте до Модуль 5.2: Збої додатків, щоб навчитися усувати несправності Підів, Деплойментів та проблем на рівні додатків.