Устранение неполадок¶

Kubelet не стартует после перезагрузки виртуалок¶

После включения всех нод kubelet может не подниматься из‑за порядка запуска сервисов или недоступности зависимостей. Ниже — пошаговая диагностика и типичные исправления.

Шаг 1: Диагностика (выполнить на ноде, где не стартует kubelet)

# Статус kubelet
sudo systemctl status kubelet --no-pager

# Последние строки лога kubelet (причина падения обычно в конце)
sudo journalctl -u kubelet -n 80 --no-pager

# Проверить, запущен ли containerd (kubelet зависит от него)
sudo systemctl status containerd --no-pager

# Проверить сокет CRI
ls -la /run/containerd/containerd.sock

Шаг 2: Типичные причины и что делать

Причина	Симптом в логах / статусе	Действие
containerd не запущен	`kubelet`: connection refused к containerd.sock	Запустить containerd (см. ниже), затем `sudo systemctl restart kubelet`.
Модули ядра не загружены	containerd падает при старте или при создании контейнеров	Выполнить `sudo modprobe overlay && sudo modprobe br_netfilter`, затем `sudo systemctl restart containerd` и `sudo systemctl restart kubelet`.
sysctl не применён	Ошибки сети/iptables в логах	Выполнить `sudo sysctl --system`, затем перезапустить containerd и kubelet.
Нет доступа к API (control plane)	В логах kubelet: timeout / connection refused к API	Сначала поднять ноды control plane и убедиться, что доступен VIP или хотя бы один apiserver; затем перезапустить kubelet на worker/control plane.

Шаг 3: Быстрое восстановление порядка запуска (на всех нодах)

Запустить зависимости вручную в правильном порядке, затем kubelet:

# 1. Модули ядра (если ещё не загружены)
sudo modprobe overlay
sudo modprobe br_netfilter

# 2. sysctl (на всякий случай)
sudo sysctl --system

# 3. containerd
sudo systemctl start containerd
sudo systemctl status containerd --no-pager
# Должно быть: active (running)

# 4. kubelet
sudo systemctl start kubelet
sudo systemctl status kubelet --no-pager

Шаг 4: Зависимость kubelet от containerd (рекомендуется для автозапуска после перезагрузки)

Пакет kubelet из репозитория Kubernetes обычно уже имеет After=containerd.service. Если kubelet стартует раньше containerd, явно задать зависимость:

# Проверить текущий unit
sudo systemctl cat kubelet.service | grep -E "After|Requires|Wants"

# Если нет зависимости от containerd — создать drop-in (на каждой ноде)
sudo mkdir -p /etc/systemd/system/kubelet.service.d
sudo tee /etc/systemd/system/kubelet.service.d/10-containerd.conf <<'EOF'
[Unit]
After=containerd.service
Requires=containerd.service
EOF

sudo systemctl daemon-reload
sudo systemctl restart kubelet

Шаг 5: Загрузка модулей до containerd (на всех нодах)

Чтобы после перезагрузки модули загружались до containerd, у unit containerd можно явно указать зависимость от systemd-modules-load.service:

# Проверить, что модули настроены на автозагрузку
cat /etc/modules-load.d/k8s.conf
# Должно быть: overlay и br_netfilter

# Опционально: гарантировать порядок — containerd после загрузки модулей
sudo mkdir -p /etc/systemd/system/containerd.service.d
sudo tee /etc/systemd/system/containerd.service.d/10-after-modules.conf <<'EOF'
[Unit]
After=systemd-modules-load.service
EOF

sudo systemctl daemon-reload
sudo systemctl restart containerd
sudo systemctl restart kubelet

После изменений перезагрузить ноду и проверить:

sudo systemctl status containerd kubelet --no-pager

Kubelet и ошибка «running with swap on»¶

Если в логах: running with swap on is not supported — swap включён (часто снова включается после перезагрузки). Решение:

sudo swapoff -a
sudo sed -i '/\sswap\s/s/^/#/' /etc/fstab
free -h   # Swap должен быть 0
sudo systemctl restart kubelet

Подробнее про отключение swap — в Этап 1, раздел 1.4.1.