Модуль 5.3: Збої площини управління

Складність: [COMPLEX] — Усунення несправностей критичної інфраструктури

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

Передумови: Модуль 5.1 (Методологія), Модуль 1.1 (Площина управління — глибоке занурення)

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

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

Діагностувати збої площини управління, перевіряючи маніфести статичних подів, логи компонентів та сертифікати
Виправити типові проблеми площини управління: втрата кворуму etcd, аварія scheduler, недоступність API server
Відновити площину управління зі знімка резервної копії etcd
Перевірити стан площини управління за допомогою ендпоінтів статусу компонентів та kubectl cluster-info

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

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

Аналогія з авіадиспетчерською

Площина управління — це як авіадиспетчерська служба вашого кластера. API-сервер — це радіовежа — якщо вона впаде, зв’язку немає. Планувальник — це планувальник рейсів — без нього нові рейси (Під’и) не можуть злетіти. Controller manager — це система моніторингу — вона забезпечує, щоб усі літаки дотримувались своїх маршрутів. Коли будь-який з них виходить з ладу, потрібно діяти швидко.

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

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

Діагностувати збої API-сервера
Усувати несправності планувальника
Виправляти проблеми controller manager
Розуміти перевірки здоров’я etcd
Працювати зі статичними Під’ами для компонентів площини управління

Чи знали ви?

Площина управління працює як Під’и: у кластерах kubeadm компоненти площини управління працюють як статичні Під’и, якими безпосередньо керує kubelet
Розташування маніфестів статичних Підів: /etc/kubernetes/manifests/ — редагуйте ці файли для виправлення проблем площини управління
etcd — це мозок: кожен фрагмент стану кластера зберігається в etcd — якщо він пошкоджений або повільний, страждає все
API-сервер — stateless: сам API-сервер нічого не зберігає — він лише читає/пише в etcd. Перезапуск не втрачає даних

Частина 1: Огляд архітектури площини управління

1.1 Залежності компонентів

┌──────────────────────────────────────────────────────────────┐
│              ЗАЛЕЖНОСТІ ПЛОЩИНИ УПРАВЛІННЯ                    │
│                                                               │
│                      ┌─────────────┐                         │
│                      │    etcd     │                         │
│                      │ (сховище)  │                         │
│                      └──────┬──────┘                         │
│                             │                                │
│                             ▼                                │
│                      ┌─────────────┐                         │
│                      │ API-сервер  │◄──── kubectl            │
│                      │  (шлюз)    │◄──── kubelet            │
│                      └──────┬──────┘◄──── контролери        │
│                             │                                │
│              ┌──────────────┼──────────────┐                 │
│              │              │              │                 │
│              ▼              ▼              ▼                 │
│       ┌───────────┐  ┌───────────┐  ┌───────────┐           │
│       │Планувальник│  │ Controller│  │  Cloud    │           │
│       │           │  │  Manager  │  │ Controller│           │
│       └───────────┘  └───────────┘  └───────────┘           │
│                                                               │
│   Якщо etcd впаде      → Все впаде                          │
│   Якщо API-сервер      → Нічого не може спілкуватись        │
│   Якщо планувальник    → Нові Під'и не розподіляються       │
│   Якщо controller-mgr  → Ресурси не узгоджуються            │
│                                                               │
└──────────────────────────────────────────────────────────────┘

1.2 Огляд статичних Підів

Компоненти площини управління розгортаються як статичні Під’и:

# Розташування маніфестів статичних Підів
/etc/kubernetes/manifests/
├── etcd.yaml
├── kube-apiserver.yaml
├── kube-controller-manager.yaml
└── kube-scheduler.yaml

# kubelet спостерігає за цією директорією
# Зміни в цих файлах = автоматичний перезапуск компонента

1.3 Перевірка здоров’я площини управління

# Швидка перевірка здоров'я (застарілий, але корисний)
k get componentstatuses

# Перевірити Під'и площини управління
k -n kube-system get pods | grep -E 'etcd|api|controller|scheduler'

# Перевірити що всі компоненти працюють
k -n kube-system get pods -o wide | grep -E 'kube-'

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

2.1 Симптоми збою API-сервера

┌──────────────────────────────────────────────────────────────┐
│               СИМПТОМИ ЗБОЮ API-СЕРВЕРА                       │
│                                                               │
│   Симптом                          Вказує на                 │
│   ─────────────────────────────────────────────────────────  │
│   kubectl зависає/тайм-аут        API-сервер недоступний     │
│   «connection refused»            API-сервер не слухає       │
│   «unable to connect to server»   Проблема мережі/firewall  │
│   «Unauthorized»                  Проблема автентифікації    │
│   «etcd cluster is unavailable»   API не може дістатись etcd │
│   Дуже повільні відповіді         Перевантажений або etcd    │
│                                   повільний                  │
│                                                               │
└──────────────────────────────────────────────────────────────┘

2.2 Діагностика проблем API-сервера

Крок 1: Перевірити чи Під API-сервера працює

# З вузла площини управління
crictl ps | grep kube-apiserver

# Або перевірити статус статичного Підів
ls -la /etc/kubernetes/manifests/kube-apiserver.yaml

Крок 2: Перевірити логи API-сервера

# Якщо працює як Під
k -n kube-system logs kube-apiserver-<node>

# Якщо Під не працює, використовуйте crictl
crictl logs $(crictl ps -a | grep apiserver | awk '{print $1}')

# Або перевірте логи kubelet щоб зрозуміти чому не запускається
journalctl -u kubelet | grep apiserver

Крок 3: Перевірити сертифікати

# Перевірити сертифікати
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout | grep -A 2 "Validity"

# Перевірити чи сертифікати не прострочені
kubeadm certs check-expiration

2.3 Типові проблеми API-сервера

Проблема	Симптом	Виправлення
Сертифікат прострочений	«x509: certificate has expired»	`kubeadm certs renew all`
etcd недоступний	«etcd cluster is unavailable»	Перевірте здоров’я etcd, виправте etcd
Неправильні endpoints etcd	Збій при запуску	Перевірте `--etcd-servers` у маніфесті
Конфлікт порту	«bind: address already in use»	Знайдіть і завершіть конфліктний процес
Недостатньо пам’яті	OOMKilled, повільні відповіді	Збільшіть ресурси вузла
Неправильні прапорці	Не запускається	Перевірте синтаксис YAML маніфесту

2.4 Виправлення проблем API-сервера

Оновлення сертифікатів:

# Перевірити статус сертифікатів
kubeadm certs check-expiration

# Оновити всі сертифікати
kubeadm certs renew all

# Перезапустити Під'и площини управління
# kubelet автоматично перезапускає статичні Під'и при зміні маніфестів

Виправлення маніфестів:

# Редагувати маніфест статичного Підів
sudo vim /etc/kubernetes/manifests/kube-apiserver.yaml

# Типові виправлення:
# - Виправити друкарські помилки у прапорцях
# - Виправити шляхи до сертифікатів
# - Виправити endpoints etcd

# kubelet автоматично виявляє зміни та перезапускає Під

Частина 3: Усунення несправностей планувальника

3.1 Симптоми збою планувальника

┌──────────────────────────────────────────────────────────────┐
│              СИМПТОМИ ЗБОЮ ПЛАНУВАЛЬНИКА                      │
│                                                               │
│   Симптом                             Перевірте              │
│   ─────────────────────────────────────────────────────────  │
│   Усі нові Під'и застрягли Pending    Планувальник не працює │
│   «no nodes available to schedule»    Усі вузли недоступні   │
│   Під'и не розподіляються рівномірно  Планувальник            │
│                                       неправильно            │
│                                       налаштований           │
│   Дуже повільне розподілення          Планувальник            │
│                                       перевантажений         │
│                                                               │
│   Пам'ятайте: існуючі Під'и продовжують працювати при збої  │
│   планувальника! Це впливає лише на НОВІ Під'и.             │
│                                                               │
└──────────────────────────────────────────────────────────────┘

3.2 Діагностика проблем планувальника

# Перевірити статус Підів планувальника
k -n kube-system get pod -l component=kube-scheduler

# Перевірити логи планувальника
k -n kube-system logs kube-scheduler-<node>

# Перевірити події планування
k get events -A --field-selector reason=FailedScheduling

# Описати Під у Pending для з'ясування причини
k describe pod <pending-pod> | grep -A 10 Events

3.3 Типові проблеми планувальника

Проблема	Симптом	Виправлення
Планувальник не працює	Усі нові Під’и в Pending	Перевірте маніфест статичного Підів
Не може підключитись до API	«connection refused»	Перевірте kubeconfig, сертифікати
Збій обрання лідера	Планувальник не активний	Перевірте прапорець `--leader-elect`
Немає доступних вузлів	Збої розподілення	Перевірте taints, ресурси вузлів

3.4 Виправлення проблем планувальника

Перевірка та виправлення статичного Підів:

# Перевірити наявність маніфесту
cat /etc/kubernetes/manifests/kube-scheduler.yaml

# Перевірити наявність помилок YAML
cat /etc/kubernetes/manifests/kube-scheduler.yaml | python3 -c "import yaml,sys; yaml.safe_load(sys.stdin)"

# Типові виправлення у маніфесті:
# --kubeconfig=/etc/kubernetes/scheduler.conf
# --leader-elect=true

# Перевірити наявність kubeconfig
ls -la /etc/kubernetes/scheduler.conf

Ручне розподілення (обхідний шлях):

# Якщо планувальник не працює, можна вручну розподілити Під'и
k patch pod <pod> -p '{"spec":{"nodeName":"worker-1"}}'

Частина 4: Усунення несправностей Controller Manager

4.1 Симптоми збою Controller Manager

┌──────────────────────────────────────────────────────────────┐
│           СИМПТОМИ ЗБОЮ CONTROLLER MANAGER                    │
│                                                               │
│   Симптом                            Уражений контролер      │
│   ─────────────────────────────────────────────────────────  │
│   Під'и не створюються з Деплоймента Контролер ReplicaSet    │
│   Видалені Під'и не замінюються      Контролер ReplicaSet    │
│   PVC залишаються в Pending          Контролер PV            │
│   Сервіси не мають endpoints         Контролер Endpoints     │
│   Вузли залишаються NotReady назавжди Контролер Node         │
│   Job'и не завершуються              Контролер Job           │
│   Немає автоматичного очищення       Контролер GC            │
│                                                               │
│   Кластер «заморожується» — немає узгодження                │
│                                                               │
└──────────────────────────────────────────────────────────────┘

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

# Перевірити Під controller manager
k -n kube-system get pod -l component=kube-controller-manager

# Перевірити логи
k -n kube-system logs kube-controller-manager-<node>

# Перевірити проблеми конкретних контролерів
k -n kube-system logs kube-controller-manager-<node> | grep -i error

# Перевірити що контролери працюють
# Створіть Деплоймент і перевірте чи створений ReplicaSet
k create deployment test --image=nginx
k get rs | grep test

4.3 Типові проблеми Controller Manager

Проблема	Симптом	Виправлення
Не працює	Немає узгодження	Перевірте маніфест статичного Підів
Відсутній service account	Не може створювати Під’и	Перевірте service-account-private-key-file
Не може підключитись до API	Усі контролери збоять	Перевірте шлях kubeconfig
Відсутній cluster-signing-cert	CSR не затверджується	Перевірте шляхи сертифікатів у маніфесті

4.4 Виправлення проблем Controller Manager

# Перевірити маніфест
cat /etc/kubernetes/manifests/kube-controller-manager.yaml

# Ключові прапорці для перевірки:
# --kubeconfig=/etc/kubernetes/controller-manager.conf
# --service-account-private-key-file=/etc/kubernetes/pki/sa.key
# --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
# --root-ca-file=/etc/kubernetes/pki/ca.crt

# Перевірити наявність файлів
ls -la /etc/kubernetes/pki/

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

5.1 Вплив збою etcd

┌──────────────────────────────────────────────────────────────┐
│                    ВПЛИВ ЗБОЮ ETCD                            │
│                                                               │
│   ┌─────────────────────────────────────────────────────┐    │
│   │                    etcd НЕ ПРАЦЮЄ                    │    │
│   └────────────────────────┬────────────────────────────┘    │
│                            │                                  │
│              ┌─────────────┼─────────────┐                   │
│              ▼             ▼             ▼                   │
│         Немає запису   Немає читання Помилки API             │
│              │             │             │                   │
│              ▼             ▼             ▼                   │
│         Не можна      Не можна     «etcd cluster            │
│         створювати    переглядати   is unavailable»          │
│         ресурси       ресурси                                │
│                                                               │
│   Примітка: існуючі Під'и працюють (kubelet незалежний)     │
│   Але жодні нові зміни до кластера зробити не можна         │
│                                                               │
└──────────────────────────────────────────────────────────────┘

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

# Перевірити статус Підів etcd
k -n kube-system get pod -l component=etcd

# Перевірити логи etcd
k -n kube-system logs etcd-<node>

# Перевірити здоров'я etcd за допомогою etcdctl
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health

# Перевірити список членів etcd
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  member list

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

Проблема	Симптом	Виправлення
Пошкоджена директорія даних	Не запускається	Відновити з резервної копії
Прострочений сертифікат	Помилки TLS	Оновити сертифікати
Диск заповнений	Збої запису	Звільнити місце на диску
Член недоступний	Кластер нездоровий	Перевірте мережу, перезапустіть член
Розсинхронізація годинників	Збої Raft	Синхронізуйте NTP

5.4 Резервне копіювання та відновлення etcd

Резервне копіювання (для довідки — може бути на іспиті):

ETCDCTL_API=3 etcdctl snapshot save /tmp/etcd-backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Перевірити резервну копію
ETCDCTL_API=3 etcdctl snapshot status /tmp/etcd-backup.db

Відновлення (концептуально — складне на практиці):

# Спочатку зупиніть API-сервер
mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/

# Відновити знімок
ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcd-backup.db \
  --data-dir=/var/lib/etcd-restored

# Оновити маніфест etcd для використання нової директорії даних
# Перемістити маніфест API-сервера назад

Частина 6: Усунення несправностей статичних Підів

6.1 Як працюють статичні Під’и

┌──────────────────────────────────────────────────────────────┐
│               ЖИТТЄВИЙ ЦИКЛ СТАТИЧНИХ ПІДІВ                  │
│                                                               │
│   /etc/kubernetes/manifests/           kubelet               │
│   ┌───────────────────────┐           ┌──────────────────┐  │
│   │ kube-apiserver.yaml   │◄─ watch ──│                  │  │
│   │ kube-scheduler.yaml   │           │  Створює Під'и   │  │
│   │ controller-manager... │──────────▶│  з маніфестів    │  │
│   │ etcd.yaml             │           │                  │  │
│   └───────────────────────┘           └──────────────────┘  │
│                                              │               │
│   Файл змінено/створено ──────────────────▶│               │
│   Файл видалено ──────────────────────────▶│               │
│                                              ▼               │
│                                     Під створено/видалено    │
│                                                               │
│   Іменування: <name>-<node-name>                            │
│   (напр., kube-apiserver-master)                             │
│                                                               │
└──────────────────────────────────────────────────────────────┘

6.2 Типові проблеми зі статичними Під’ами

# Перевірити чи kubelet налаштований спостерігати директорію маніфестів
cat /var/lib/kubelet/config.yaml | grep staticPodPath

# Перевірити синтаксис маніфесту
cat /etc/kubernetes/manifests/kube-apiserver.yaml | head -20

# Типові проблеми:
# - Помилки синтаксису YAML (табуляції замість пробілів)
# - Неправильне розширення файлу (має бути .yaml або .yml)
# - Неправильні права доступу (має бути для читання)
# - Відсутні обов'язкові поля

6.3 Налагодження статичних Підів

# Якщо статичний Під не запускається, перевірте логи kubelet
journalctl -u kubelet -f

# Шукайте помилки щодо конкретного маніфесту
journalctl -u kubelet | grep -i "kube-apiserver\|error\|failed"

# Перевірте чи контейнер існує, але нездоровий
crictl ps -a | grep kube-

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

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

Помилка	Проблема	Рішення
Редагування Підів замість маніфестів	Зміни втрачаються при перезапуску	Редагуйте файли у `/etc/kubernetes/manifests/`
Використання kubectl коли API не працює	Команди не виконуються	Використовуйте crictl для управління контейнерами
Не перевіряти логи kubelet	Пропуск кореневої причини	Завжди перевіряйте `journalctl -u kubelet`
Забули про залежності сертифікатів	Компоненти не можуть спілкуватись	Перевірте наявність всіх шляхів сертифікатів
Не перевіряти etcd першим	Пропуск проблем на рівні сховища	Проблеми etcd впливають на все
Перезапуск перед діагностикою	Втрата доказів	Зберіть логи спочатку, потім перезапустіть

Тест

Q1: Розташування статичних Підів

Де зберігаються маніфести статичних Підів площини управління в кластері kubeadm?

Відповідь

/etc/kubernetes/manifests/

Ця директорія містить:

kube-apiserver.yaml
kube-scheduler.yaml
kube-controller-manager.yaml
etcd.yaml

kubelet спостерігає за цією директорією і автоматично створює/оновлює/видаляє Під’и при зміні файлів.

Q2: API-сервер не працює

kubectl не відповідає. Який ваш перший крок усунення несправностей на вузлі площини управління?

Відповідь

Перевірити чи контейнер API-сервера працює:

crictl ps | grep kube-apiserver

Якщо не працює, перевірити чому:

crictl ps -a | grep kube-apiserver  # Перевірити чи існує, але зупинений
journalctl -u kubelet | grep apiserver  # Перевірити логи kubelet

Q3: Планувальник vs Controller Manager

Під’и застрягли в Pending, але Деплойменти показують правильну кількість реплік. Який компонент, ймовірно, збоїть?

Відповідь

Ймовірно збоїть планувальник.

Controller manager створює ReplicaSets і забезпечує кількість реплік (працює — тому Деплоймент показує правильну кількість)
Планувальник призначає Під’и на вузли (збоїть — Під’и застрягли в Pending)

Перевірте: k -n kube-system logs kube-scheduler-<node>

Q4: Перевірка здоров’я etcd

Напишіть команду для перевірки здоров’я кластера etcd.

Відповідь

ETCDCTL_API=3 etcdctl endpoint health \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Або якщо змінні середовища налаштовані:

etcdctl endpoint health

Q5: Прострочення сертифікатів

Як перевірити чи сертифікати Kubernetes прострочені?

Відповідь

kubeadm certs check-expiration

Це показує терміни дії всіх сертифікатів кластера. Для оновлення:

kubeadm certs renew all

Q6: Симптоми Controller Manager

Controller manager не працює. Що з наведеного ви спостерігатимете? a) Команди kubectl не працюють b) Існуючі Під’и перестають працювати c) Нові Під’и з Деплойментів не створюються d) Сервіси втрачають свої endpoints

Відповідь

Правильно c) та d):

Нові Під’и з Деплойментів не створюються (контролер ReplicaSet)
Сервіси втрачають свої endpoints (контролер Endpoints)

a) неправильно — API-сервер обробляє kubectl b) неправильно — kubelet утримує Під’и незалежно

Controller manager обробляє цикли узгодження. Коли він не працює, кластер «заморожується» — існуючий стан залишається, але жодні зміни не узгоджуються.

Практична вправа: Усунення несправностей площини управління

Сценарій

Практика діагностики проблем площини управління в контрольованому середовищі.

Передумови

Ця вправа вимагає кластер на основі kubeadm з SSH-доступом до вузлів площини управління.

Підготовка

# Перевірте що маєте доступ до площини управління
ssh <control-plane-node>
sudo ls /etc/kubernetes/manifests/

Завдання 1: Дослідження компонентів площини управління

# Перелік усіх маніфестів статичних Підів
ls -la /etc/kubernetes/manifests/

# Перевірити поточний стан Підів площини управління
k -n kube-system get pods | grep -E 'etcd|api|scheduler|controller'

# Переглянути конфігурацію API-сервера
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep -A 5 "command:"

Завдання 2: Перевірка здоров’я etcd

# Використати etcdctl для перевірки здоров'я
# Спочатку налаштуйте alias для зручності
alias etcdctl='ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key'

# Перевірити здоров'я
etcdctl endpoint health

# Перевірити список членів
etcdctl member list

# Перевірити статус кластера
etcdctl endpoint status --write-out=table

Завдання 3: Симуляція збою планувальника (обережно!)

# Спочатку зверніть увагу на поведінку Підів
k run test-scheduler --image=nginx
k get pods test-scheduler

# Тимчасово перейменувати маніфест планувальника (це зупинить його)
sudo mv /etc/kubernetes/manifests/kube-scheduler.yaml /tmp/

# Зачекайте 30 секунд, спробуйте створити інший Під
sleep 30
k run test-scheduler-2 --image=nginx

# Перевірити статус — повинен бути Pending
k get pods test-scheduler-2
k describe pod test-scheduler-2 | grep -A 5 Events

# Відновити планувальник
sudo mv /tmp/kube-scheduler.yaml /etc/kubernetes/manifests/

# Зачекати на перезапуск планувальника
sleep 30
k get pods -w

Завдання 4: Перевірка терміну дії сертифікатів

# Використати kubeadm для перевірки всіх сертифікатів
sudo kubeadm certs check-expiration

# Вручну перевірити конкретний сертифікат
sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout | grep -A 2 Validity

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

Перелічили всі маніфести статичних Підів
Перевірили здоров’я etcd за допомогою etcdctl
Зрозуміли симптоми збою планувальника
Перевірили терміни дії сертифікатів

Очищення

k delete pod test-scheduler test-scheduler-2

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

Вправа 1: Статус Підів площини управління (30 с)

# Завдання: Показати статус усіх Підів площини управління
k -n kube-system get pods | grep -E 'etcd|api|scheduler|controller'

Вправа 2: Перевірка логів компонентів (1 хв)

# Завдання: Переглянути останні 50 рядків логів API-сервера
k -n kube-system logs kube-apiserver-<node> --tail=50

Вправа 3: Перевірка маніфесту статичного Підів (30 с)

# Завдання: Переглянути конфігурацію планувальника
cat /etc/kubernetes/manifests/kube-scheduler.yaml

Вправа 4: Здоров’я etcd (1 хв)

# Завдання: Перевірити здоров'я endpoint etcd
ETCDCTL_API=3 etcdctl endpoint health \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Вправа 5: Перевірка сертифікатів (30 с)

# Завдання: Перевірити терміни дії всіх сертифікатів
kubeadm certs check-expiration

Вправа 6: Логи kubelet для площини управління (1 хв)

# Завдання: Перевірити логи kubelet на помилки площини управління
journalctl -u kubelet --since "10 minutes ago" | grep -i "error\|failed"

Вправа 7: Статус контейнерів через crictl (30 с)

# Завдання: Перелічити всі контейнери площини управління
crictl ps | grep kube

Вправа 8: Тест з’єднання з API-сервером (30 с)

# Завдання: Протестувати endpoint API-сервера
curl -k https://localhost:6443/healthz

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

Переходьте до Модуль 5.4: Збої робочих вузлів, щоб навчитися усувати несправності kubelet, container runtime та проблеми на рівні вузлів.