Модуль 5.4: Збої робочих вузлів

Складність: [MEDIUM] — Критично для роботи кластера

Час на виконання: 45–55 хвилин

Передумови: Модуль 5.1 (Методологія), Модуль 1.1 (Архітектура кластера)

---

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

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

• Діагностувати статус NotReady робочого вузла, перевіряючи kubelet, середовище виконання контейнерів та мережу
• Виправити збої kubelet, спричинені помилками конфігурації, закінченням терміну дії сертифікатів та тиском на ресурси
• Відновити вузол із стану disk pressure, memory pressure та PID pressure
• Виконати drain та cordon вузлів безпечно під час обслуговування, враховуючи PodDisruptionBudgets

---

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

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

Аналогія з фабричним цехом

Якщо площина управління — це менеджмент, робочі вузли — це фабричний цех. kubelet — це начальник цеху — якщо його немає, нічого не робиться. Container runtime — це обладнання — якщо воно зламається, виробництво зупиняється. Ресурси вузла (CPU, пам’ять, диск) — це сировина — вичерпаються, і фабрика зупиниться.

---

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

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

• Діагностувати статус NotReady вузла
• Усувати несправності kubelet
• Виправляти проблеми container runtime
• Обробляти вичерпання ресурсів вузла
• Відновлювати після мережевих збоїв вузла

---

Чи знали ви?

• Heartbeat вузла кожні 10 секунд: kubelet звітує API-серверу кожні 10с. Після 40с без heartbeat вузол позначається як Unknown
• Евікція Підів через 5 хвилин: за замовчуванням Під’и на вузлах NotReady евіктуються через 5 хвилин (pod-eviction-timeout)
• Три умови викликають тиск: MemoryPressure, DiskPressure, PIDPressure — будь-яка з них у True спричиняє проблеми з розподілом
• kubelet — це не Під: на відміну від компонентів площини управління, kubelet працює як сервіс systemd, а не контейнер

---

Частина 1: Огляд статусу вузла

1.1 Розуміння умов вузла

┌──────────────────────────────────────────────────────────────┐
│                     УМОВИ ВУЗЛА                               │
│                                                               │
│   Умова               Здоровий   Значення                    │
│   ─────────────────────────────────────────────────────────  │
│   Ready               True       Вузол здоровий, може        │
│                                  запускати Під'и             │
│   MemoryPressure      False      Пам'яті достатньо          │
│   DiskPressure        False      Місця на диску достатньо    │
│   PIDPressure         False      ID процесів доступні        │
│   NetworkUnavailable  False      Мережа налаштована          │
│                                                               │
│   Будь-яка нездорова умова → проблеми з розподілом          │
│   Ready=False або Unknown → вузол NotReady                   │
│                                                               │
└──────────────────────────────────────────────────────────────┘

1.2 Перевірка статусу вузла

# Швидкий статус
k get nodes

# Детальні умови
k describe node <node-name> | grep -A 10 Conditions

# Усі вузли з умовами
k get nodes -o custom-columns='NAME:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status,REASON:.status.conditions[?(@.type=="Ready")].reason'

# Перевірити тиск ресурсів
k describe node <node-name> | grep -E "MemoryPressure|DiskPressure|PIDPressure"

1.3 Стани статусу вузла

Статус	Значення	Типові причини
Ready	Здоровий, приймає Під’и	Нормальна робота
NotReady	Нездоровий	kubelet не працює, мережеві проблеми
Unknown	Heartbeat не отримано	Вузол недоступний, kubelet впав
SchedulingDisabled	Кордонований	Ручний cordon або обслуговування

---

Частина 2: Усунення несправностей kubelet

2.1 Огляд kubelet

┌──────────────────────────────────────────────────────────────┐
│                   ОБОВ'ЯЗКИ KUBELET                           │
│                                                               │
│   ┌──────────────────────────────────────────────────────┐   │
│   │                      kubelet                          │   │
│   │                                                       │   │
│   │  • Реєструє вузол у API-сервері                     │   │
│   │  • Спостерігає за призначенням Підів                 │   │
│   │  • Керує життєвим циклом контейнерів (через runtime) │   │
│   │  • Звітує про стан вузла/Підів                       │   │
│   │  • Обробляє проби (liveness, readiness)              │   │
│   │  • Монтує томи                                       │   │
│   │  • Запускає статичні Під'и                            │   │
│   │                                                       │   │
│   └──────────────────────────────────────────────────────┘   │
│                                                               │
│   Якщо kubelet збоїть → Вузол NotReady → Під'и перестають   │
│   працювати                                                  │
│                                                               │
└──────────────────────────────────────────────────────────────┘

2.2 Перевірка статусу kubelet

# Спочатку SSH на вузол
ssh <node-name>

# Перевірити статус сервісу kubelet
sudo systemctl status kubelet

# Перевірити чи kubelet працює
ps aux | grep kubelet

# Перевірити логи kubelet
sudo journalctl -u kubelet -f

# Перевірити останні помилки kubelet
sudo journalctl -u kubelet --since "10 minutes ago" | grep -i error

2.3 Типові проблеми kubelet

Проблема	Симптом	Діагностика	Виправлення
kubelet зупинений	Вузол NotReady	systemctl status kubelet	systemctl start kubelet
kubelet падає циклічно	Вузол мерехтить	journalctl -u kubelet	Виправити конфіг, перевірити логи
Неправильний конфіг	Не запускається	Помилка в логах	Виправити /var/lib/kubelet/config.yaml
Не може дістатись API	NotReady	Тайм-аут мережі в логах	Перевірити мережу, firewall
Проблеми з сертифікатами	Помилки TLS	Помилки сертифікатів у логах	Оновити сертифікати
Container runtime не працює	Не може створити Під’и	Помилки runtime	Виправити containerd/docker

2.4 Виправлення проблем kubelet

kubelet не працює:

# Запустити kubelet
sudo systemctl start kubelet

# Увімкнути автозапуск
sudo systemctl enable kubelet

# Перевірити статус
sudo systemctl status kubelet

Проблеми конфігурації kubelet:

# Перевірити файл конфігурації kubelet
cat /var/lib/kubelet/config.yaml

# Перевірити прапорці kubelet
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

# Після виправлення конфігу перезавантажити та перезапустити
sudo systemctl daemon-reload
sudo systemctl restart kubelet

Проблеми з сертифікатами kubelet:

# Перевірити шляхи сертифікатів
cat /var/lib/kubelet/config.yaml | grep -i cert

# Перевірити наявність сертифікатів
ls -la /var/lib/kubelet/pki/

# Для прострочених сертифікатів може знадобитись перепід'єднання вузла
# На площині управління: kubeadm token create --print-join-command
# На робочому вузлі: kubeadm reset && kubeadm join ...

---

Частина 3: Усунення несправностей Container Runtime

3.1 Огляд Container Runtime

┌──────────────────────────────────────────────────────────────┐
│                  СТЕК CONTAINER RUNTIME                       │
│                                                               │
│   kubelet                                                     │
│      │                                                        │
│      │ CRI (Container Runtime Interface)                     │
│      ▼                                                        │
│   containerd (або docker, cri-o)                             │
│      │                                                        │
│      │ OCI (Open Container Initiative)                       │
│      ▼                                                        │
│   runc (низькорівневий runtime)                              │
│      │                                                        │
│      ▼                                                        │
│   Ядро Linux (cgroups, namespaces)                           │
│                                                               │
└──────────────────────────────────────────────────────────────┘

3.2 Перевірка Container Runtime

# Перевірити containerd (найпоширеніший)
sudo systemctl status containerd
sudo crictl info

# Перевірити сокет container runtime
ls -la /run/containerd/containerd.sock

# Перелік контейнерів через crictl
sudo crictl ps

# Перелік образів
sudo crictl images

3.3 Типові проблеми Runtime

Проблема	Симптом	Діагностика	Виправлення
containerd зупинений	Під’и ContainerCreating	systemctl status containerd	systemctl start containerd
Відсутній сокет	Помилки kubelet	Перевірити шлях сокету	Перезапустити containerd
Диск заповнений	Створення контейнера збоїть	df -h	Очистити диск
Помилки pull образів	ImagePullBackOff	Перевірити доступ до реєстру	Виправити автентифікацію реєстру
Ресурси вичерпані	Випадкові збої контейнерів	Перевірити cgroups	Збільшити ресурси

3.4 Виправлення проблем Runtime

containerd не працює:

# Запустити containerd
sudo systemctl start containerd

# Перевірити статус
sudo systemctl status containerd

# Перевірити логи на проблеми
sudo journalctl -u containerd --since "10 minutes ago"

Усунення несправностей через crictl:

# Налаштувати crictl для containerd
cat <<EOF | sudo tee /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: false
EOF

# Перелік усіх контейнерів (включаючи зупинені)
sudo crictl ps -a

# Отримати логи контейнера
sudo crictl logs <container-id>

# Інспекція контейнера
sudo crictl inspect <container-id>

---

Частина 4: Вичерпання ресурсів вузла

4.1 Типи тиску на ресурси

┌──────────────────────────────────────────────────────────────┐
│                  ТИПИ ТИСКУ НА РЕСУРСИ                       │
│                                                               │
│   ТИСК НА ПАМ'ЯТЬ                                          │
│   • Доступна пам'ять нижче порогу                           │
│   • Спричиняє евікцію Підів                                 │
│   • Перевірка: free -m, cat /proc/meminfo                   │
│                                                               │
│   ТИСК НА ДИСК                                              │
│   • Використання диску вище порогу                           │
│   • Спричиняє очищення образів                              │
│   • Перевірка: df -h                                         │
│                                                               │
│   ТИСК НА PID                                                │
│   • ID процесів вичерпані                                    │
│   • Неможливо створити нові процеси                         │
│   • Перевірка: cat /proc/sys/kernel/pid_max                  │
│                                                               │
│   Коли будь-який тиск True — вузол може не приймати нові    │
│   Під'и                                                      │
│                                                               │
└──────────────────────────────────────────────────────────────┘

4.2 Діагностика проблем з ресурсами

# Перевірити умови вузла
k describe node <node> | grep -A 10 Conditions

# На вузлі — перевірити пам'ять
free -m
cat /proc/meminfo | grep -E "MemTotal|MemFree|MemAvailable"

# Перевірити диск
df -h
du -sh /var/lib/containerd/*  # Сховище контейнерів
du -sh /var/log/*             # Сховище логів

# Перевірити PID
cat /proc/sys/kernel/pid_max
ps aux | wc -l

4.3 Пороги евікції

Стандартні пороги евікції kubelet:

evictionHard:
  memory.available: "100Mi"
  nodefs.available: "10%"
  nodefs.inodesFree: "5%"
  imagefs.available: "15%"

Коли ці пороги перевищені:

1. Умова вузла встановлюється в True (напр., MemoryPressure)
2. Нові Під’и не розподіляються
3. Існуючі Під’и можуть бути евіктовані

4.4 Виправлення проблем з ресурсами

Тиск на пам’ять:

# Знайти процеси, що споживають багато пам'яті
ps aux --sort=-%mem | head -20

# Знайти Під'и, що використовують найбільше пам'яті
k top pods -A --sort-by=memory

# Варіанти:
# 1. Вбити непотрібні процеси
# 2. Евіктувати Під'и з низьким пріоритетом
# 3. Додати пам'яті на вузол

Тиск на диск:

# Знайти великі файли
sudo find / -type f -size +100M -exec ls -lh {} \;

# Очистити образи контейнерів
sudo crictl rmi --prune

# Очистити старі логи
sudo journalctl --vacuum-time=3d

# Очистити невикористані контейнери
sudo crictl rm $(sudo crictl ps -a -q --state exited)

Тиск на PID:

# Перевірити поточний ліміт PID
cat /proc/sys/kernel/pid_max

# Збільшити ліміт тимчасово
echo 65536 | sudo tee /proc/sys/kernel/pid_max

# Знайти процеси за кількістю
ps aux | awk '{print $1}' | sort | uniq -c | sort -rn | head

---

Частина 5: Мережеві проблеми вузла

5.1 Мережеві вимоги вузла

┌──────────────────────────────────────────────────────────────┐
│                МЕРЕЖЕВІ ВИМОГИ ВУЗЛА                          │
│                                                               │
│   Вузол потребує з'єднання з:                                │
│   ┌─────────────────────────────────────────────────────┐    │
│   │ API-сервер     (порт 6443)   - Обов'язково         │    │
│   │ Інші вузли     (різні)       - Для мережі Підів    │    │
│   │ DNS-сервери    (порт 53)     - Для резолвінгу імен │    │
│   │ Реєстр         (порт 443)    - Для pull образів    │    │
│   └─────────────────────────────────────────────────────┘    │
│                                                               │
│   Мережеві збої → Вузол NotReady або Unknown                 │
│                                                               │
└──────────────────────────────────────────────────────────────┘

5.2 Діагностика мережевих проблем

# Перевірити базове з'єднання
ping <api-server-ip>

# Перевірити доступність API-сервера
curl -k https://<api-server>:6443/healthz

# Перевірити DNS
nslookup kubernetes.default.svc.cluster.local
cat /etc/resolv.conf

# Перевірити firewall
sudo iptables -L -n
sudo firewall-cmd --list-all  # Якщо використовується firewalld

# Перевірити мережеві інтерфейси
ip addr
ip route

5.3 Типові мережеві проблеми

Проблема	Симптом	Діагностика	Виправлення
Firewall блокує	Не може дістатись API	telnet api-server 6443	Відкрити порти firewall
Збій DNS	Резолвінг імен не працює	nslookup	Виправити /etc/resolv.conf
Зміна IP-адреси	Вузол NotReady	Перевірити IP у специфікації вузла	Переналаштувати або перепід’єднати
Проблеми CNI плагіна	Мережа Підів не працює	Перевірити Під’и CNI	Перезапустити CNI, виправити конфіг
Неспівпадіння MTU	Періодичні збої	Перевірити налаштування MTU	Вирівняти значення MTU

5.4 Обов’язкові порти

Порт	Протокол	Компонент	Призначення
6443	TCP	API-сервер	Kubernetes API
10250	TCP	kubelet	kubelet API
10259	TCP	kube-scheduler	Метрики планувальника
10257	TCP	kube-controller-manager	Метрики контролера
2379-2380	TCP	etcd	Клієнтський та peer
30000-32767	TCP	NodePort	NodePort Сервісів

---

Частина 6: Процедури відновлення вузла

6.1 Дерево рішень для відновлення

┌──────────────────────────────────────────────────────────────┐
│              ДЕРЕВО РІШЕНЬ ДЛЯ ВІДНОВЛЕННЯ ВУЗЛА             │
│                                                               │
│   Вузол NotReady?                                            │
│        │                                                      │
│        ├── Можна SSH на вузол?                                │
│        │        │                                             │
│        │        ├── ТАК → Перевірити kubelet, runtime, мережу │
│        │        │                                             │
│        │        └── НІ  → Перевірити фізично/VM, cloud       │
│        │                  консоль                             │
│        │                                                      │
│        ├── kubelet працює?                                    │
│        │        │                                             │
│        │        ├── ТАК → Перевірити логи, сертифікати,       │
│        │        │         з'єднання з API                     │
│        │        │                                             │
│        │        └── НІ  → Запустити kubelet                   │
│        │                                                      │
│        └── Все ще NotReady після виправлень?                  │
│                 │                                             │
│                 └── Drain та перепід'єднати вузол             │
│                                                               │
└──────────────────────────────────────────────────────────────┘

6.2 Дренування вузла

# Дренувати вузол (безпечно евіктує Під'и)
k drain <node-name> --ignore-daemonsets --delete-emptydir-data

# Тільки кордон (запобігти новим Під'ам)
k cordon <node-name>

# Зняти кордон (дозволити розподілення знову)
k uncordon <node-name>

6.3 Перепід’єднання вузла

Якщо вузол потребує повного скидання:

# На робочому вузлі
sudo kubeadm reset

# На площині управління — згенерувати новий токен
kubeadm token create --print-join-command

# На робочому вузлі — перепід'єднатись
sudo kubeadm join <api-server>:6443 --token <token> --discovery-token-ca-cert-hash <hash>

6.4 Видалення вузла

# Спочатку дренувати
k drain <node> --ignore-daemonsets --delete-emptydir-data

# Видалити вузол з кластера
k delete node <node-name>

# На самому вузлі
sudo kubeadm reset

---

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

Помилка	Проблема	Рішення
Не перевіряти kubelet першим	Пропуск очевидної проблеми	Завжди починайте з systemctl status kubelet
Ігнорування умов вузла	Пропуск тиску на ресурси	Перевіряйте всі умови, не лише Ready
Видалення вузла перед drain	Порушення роботи Підів	Завжди дренуйте перед видаленням
Забули про DaemonSet Під’и	Drain не вдається	Використовуйте --ignore-daemonsets
Не перевіряти runtime	Звинувачення kubelet	Перевірте статус containerd теж
Ігнорування використання диску	Деградація вузла	Моніторте диск, очищайте регулярно

---

Тест

Q1: Heartbeat вузла

Через скільки часу після останнього heartbeat вузол стає Unknown?

Відповідь

40 секунд. kubelet надсилає heartbeat кожні 10 секунд. Після 4 пропущених heartbeat (40с), node-controller позначає вузол як Unknown. Через 5 хвилин (за замовчуванням) Під’и на цьому вузлі плануються до евікції.

Q2: kubelet vs статичні Під’и

Яка ключова різниця між kubelet та компонентами площини управління з точки зору їх запуску?

Відповідь

kubelet працює як сервіс systemd на хості, тоді як компоненти площини управління (API-сервер, планувальник, controller manager, etcd) працюють як статичні Під’и, якими керує kubelet.

Це означає:

• kubelet: перевіряйте через systemctl status kubelet
• Площина управління: перевіряйте через crictl ps або k get pods -n kube-system

Q3: MemoryPressure

Вузол має MemoryPressure=True. Що станеться з новими Під’ами?

Відповідь

Нові Під’и не будуть розподілені на цей вузол. Планувальник враховує умови вузла при прийнятті рішень щодо розміщення. Крім того, існуючі Під’и можуть бути евіктовані для звільнення пам’яті, починаючи з BestEffort Підів (без запитів/лімітів ресурсів), потім Burstable, потім Guaranteed.

Q4: crictl vs kubectl

Коли слід використовувати crictl замість kubectl?

Відповідь

Використовуйте crictl коли:

• kubelet або API-сервер не працює (kubectl не працюватиме)
• Налагодження проблем container runtime
• Інспекція контейнерів на рівні runtime
• Вузол у стані NotReady

crictl спілкується безпосередньо з container runtime (containerd), повністю обминаючи Kubernetes API.

Q5: Drain vs Cordon

Яка різниця між kubectl drain та kubectl cordon?

Відповідь

• cordon: Позначає вузол як нерозподілюваний (без нових Підів). Існуючі Під’и продовжують працювати.
• drain: Кордонує вузол І евіктує всі Під’и (крім DaemonSet Підів). Готує вузол до обслуговування.

Використовуйте cordon для «м’якого» обслуговування, drain для відключення вузла.

Q6: Сокет Container Runtime

Де зазвичай розташований сокет containerd?

Відповідь

/run/containerd/containerd.sock

Це Unix-сокет, який kubelet використовує для зв’язку з containerd через CRI. Якщо цього сокету немає або containerd не слухає на ньому, kubelet не може керувати контейнерами.

Перевірте за допомогою: ls -la /run/containerd/containerd.sock

---

Практична вправа: Симуляція усунення несправностей вузла

Сценарій

Практика діагностики проблем вузла за допомогою доступних команд.

Передумови

• Доступ до кластера Kubernetes
• SSH-доступ щонайменше до одного робочого вузла

Завдання 1: Оцінка здоров’я вузла

# Перевірити всі вузли
k get nodes -o wide

# Отримати детальну інформацію про вузол
k describe node <node-name>

# Перевірити умови вузла конкретно
k get node <node-name> -o jsonpath='{.status.conditions[*].type}' | tr ' ' '\n'

Завдання 2: Дослідження kubelet

# SSH на робочий вузол
ssh <node>

# Перевірити статус kubelet
sudo systemctl status kubelet

# Переглянути останні логи kubelet
sudo journalctl -u kubelet --since "5 minutes ago" | tail -50

# Перевірити конфігурацію kubelet
cat /var/lib/kubelet/config.yaml | head -30

Завдання 3: Перевірка Container Runtime

# Перевірити статус containerd
sudo systemctl status containerd

# Перелік працюючих контейнерів
sudo crictl ps

# Перевірити інформацію container runtime
sudo crictl info

# Перелік образів на вузлі
sudo crictl images

Завдання 4: Оцінка ресурсів

# Перевірити пам'ять
free -m

# Перевірити диск
df -h

# Перевірити що використовує ресурси
k top node <node-name>

# Переглянути виділені ресурси
k describe node <node-name> | grep -A 10 "Allocated resources"

Завдання 5: Cordon та Uncordon (безпечно)

# Кордонувати вузол (запобігає новому розподіленню)
k cordon <node-name>

# Перевірити що він нерозподілюваний
k get node <node-name>

# Спробувати розподілити Під
k run test-pod --image=nginx
k get pods test-pod -o wide  # НЕ повинен бути на кордонованому вузлі

# Зняти кордон
k uncordon <node-name>

# Очищення
k delete pod test-pod

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

• Перевірили умови вузлів для всіх вузлів
• Підтвердили що kubelet працює
• Підтвердили що containerd працює
• Оцінили використання ресурсів вузла
• Успішно кордонували та зняли кордон з вузла

Очищення

Вузол повинен бути без кордону після вправи.

---

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

Вправа 1: Перевірка статусу вузла (30 с)

# Завдання: Перелічити всі вузли з їх статусом
k get nodes

Вправа 2: Умови вузла (1 хв)

# Завдання: Перевірити всі умови конкретного вузла
k describe node <node> | grep -A 10 Conditions

Вправа 3: Статус kubelet (30 с)

# Завдання: Перевірити чи kubelet працює (на вузлі)
sudo systemctl status kubelet

Вправа 4: Логи kubelet (1 хв)

# Завдання: Переглянути останні 20 рядків логів kubelet
sudo journalctl -u kubelet -n 20

Вправа 5: Статус Container Runtime (30 с)

# Завдання: Перевірити containerd та перелічити контейнери
sudo systemctl status containerd
sudo crictl ps

Вправа 6: Використання ресурсів (1 хв)

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

Вправа 7: Дренування вузла (1 хв)

# Завдання: Безпечно дренувати вузол
k drain <node> --ignore-daemonsets --delete-emptydir-data

Вправа 8: Використання диску (30 с)

# Завдання: Перевірити використання диску на вузлі
df -h
du -sh /var/lib/containerd/

---

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

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