Kubernetes: Pod завис в ContainerCreating — диагностика CNI, FailedMount и переполнения image filesystem

Иногда Kubernetes выглядит как «всё работает, но ничего не запускается»: Pod создан, Scheduler его назначил на ноду, а дальше он надолго застревает в статусе ContainerCreating. В Events всплывают куски вроде CNI not initialized, FailedMount, volume attach timeout или image filesystem full. Ниже — практичная последовательность проверок, чтобы быстро понять, где именно стопор: сеть, volume или диск на ноде.

Симптомы: что именно означает ContainerCreating

ContainerCreating — это не ошибка сама по себе. Это «ожидание», пока kubelet на конкретной ноде:

• создаст Pod sandbox (через container runtime);
• поднимет сеть Pod (через CNI-плагин);
• смонтирует volumes (PVC, Secret/ConfigMap, hostPath и т.д.);
• скачает образ и создаст контейнеры.

Если на любом из этапов есть проблема, Pod может оставаться в ContainerCreating минутами и часами. Почти всегда это «болит» не сам Pod, а конкретная нода или системный компонент (CNI/CSI/runtime).

Быстрый чек-лист диагностики (с чего начать)

В большинстве кейсов достаточно трёх шагов: узнать ноду, прочитать Events у Pod, затем уйти в логи kubelet/runtime именно на этой ноде.

1) Найти Pod и Node

kubectl get pod -n NAMESPACE POD_NAME -o wide

Нас интересует колонка NODE и иногда IP. Если IP так и не назначен — это сильный намёк на проблему уровня CNI/Pod sandbox.

2) Прочитать события: kubectl describe pod

kubectl describe pod — ключевой шаг: внизу в Events обычно прямо написано, что не получилось.

kubectl describe pod -n NAMESPACE POD_NAME

Ищите в Events строки с маркерами:

• CNI not initialized, FailedCreatePodSandBox, network plugin is not ready;
• FailedMount, Unable to attach or mount volumes;
• volume attach timeout, AttachVolume.Attach failed;
• Failed to pull image;
• no space left on device, image filesystem full.

3) Понять: это «про Pod» или «про Node»

Если проблема в CNI или диске, обычно «ломается» сразу несколько Pod на одной ноде. Быстро проверьте распределение:

kubectl get pod -A -o wide | grep ' NODE_NAME '

Если массово висит создание sandbox или не выдаются IP — почти наверняка проблема на ноде (kubelet, runtime, CNI, диск).

Кейс 1: CNI not initialized / network plugin is not ready

Сообщение CNI not initialized означает: kubelet не смог подготовить сеть Pod. Типовые причины:

• CNI-плагин не установлен или не готов (DaemonSet в kube-system не поднялся).
• На ноде нет CNI-конфигов в /etc/cni/net.d или бинарников в /opt/cni/bin.
• Проблемы с iptables/nftables, sysctl, или конфликт разных CNI.
• Container runtime не может создать sandbox, и «сыпется» всё, что вокруг него (включая сеть).

Проверки на уровне кластера

kubectl get ds -n kube-system
kubectl get pods -n kube-system -o wide

Найдите ваш CNI (calico/cilium/weave/flannel и т.д.) и убедитесь, что DaemonSet запущен на проблемной ноде. Если Pod CNI в CrashLoopBackOff или Pending — сначала лечим его: пока CNI не готов, создание новых Pod будет массово зависать.

Проверки на ноде: CNI конфиги и бинарники

sudo ls -la /etc/cni/net.d
sudo ls -la /opt/cni/bin

В /etc/cni/net.d обычно лежат файлы *.conf или *.conflist. Если каталог пустой — kubelet физически не знает, какую сеть поднимать.

Проверки на ноде: логи kubelet и runtime

Когда в Events у Pod видите FailedCreatePodSandBox, почти всегда нужно читать логи kubelet на ноде:

sudo journalctl -u kubelet -n 300 --no-pager

Параллельно — логи runtime:

sudo journalctl -u containerd -n 300 --no-pager
sudo journalctl -u crio -n 300 --no-pager

В логах ищите упоминания CNI, ошибок выполнения плагина, проблем с iptables, а также no space left on device (иногда CNI «падает» не из-за сети, а из-за диска).

Типовые исправления (аккуратно, через вывод ноды из нагрузки)

• CNI DaemonSet не стартует из-за taints/labels. Проверьте, что нода не исключена селекторами (nodeSelector/affinity) или taints без tolerations.
• Конфликт нескольких CNI. На ноде не должно быть «двух разных» конфигов в /etc/cni/net.d. В спорных ситуациях сначала делайте cordon, затем приводите конфиги к ожидаемому состоянию.
• iptables/nftables несовместимость. Если вы недавно переключали режим iptables, CNI мог начать падать. Возврат к ожидаемому режиму и перезапуск CNI Pod/kubelet часто решает проблему, но делайте это по регламенту (это влияет на сетевую плоскость узла).

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Кейс 2: FailedMount и volume attach timeout

Если в kubectl describe pod вы видите FailedMount или volume attach timeout, проблема в том, что kubelet не смог смонтировать volume в контейнер. Это может быть как «чистый Kubernetes» (PVC не Bound), так и деградация ноды/CSI.

Как отличить mount от attach

• Attach — операция на уровне CSI/облака: «прицепить» диск к ноде (актуально для блочных томов).
• Mount — примонтировать устройство/папку в файловую систему ноды и затем пробросить в Pod.

Что смотреть в kubectl describe pod

В событиях обычно есть подсказка: какой volume не смонтировался, какой PVC, какой CSI driver, и на каком шаге. Строки, которые стоит копировать в поиск по логам:

• Unable to attach or mount volumes
• timed out waiting for the condition
• AttachVolume.Attach failed
• MountVolume.SetUp failed

Проверки: PVC/PV/StorageClass

kubectl get pvc -n NAMESPACE
kubectl describe pvc -n NAMESPACE PVC_NAME
kubectl get pv
kubectl get storageclass

Если PVC не в Bound, Pod будет ждать бесконечно (или до таймаутов) — это не проблема kubelet, а проблема provisioning/storage.

Проверки: CSI компоненты и их логи

kubectl get pods -n kube-system -o wide

Найдите Pod’ы CSI (controller и node). На практике чаще всего полезно проверить именно node-плагин CSI на проблемной ноде: он отвечает за attach/mount с точки зрения узла.

Проверки на ноде: состояние ОС и диагностика I/O

mount | grep -i kube
lsblk
sudo dmesg -T | tail -n 100

Если в dmesg есть I/O ошибки, reset устройства, проблемы файловой системы — mount будет срываться независимо от Kubernetes.

Типовые исправления FailedMount/attach timeout

• CSI node plugin деградировал на конкретной ноде. Перезапуск node-пода CSI на этой ноде часто возвращает работоспособность, но сначала оцените риски для уже примонтированных томов.
• Нода в плохом состоянии (FS read-only, I/O error). Лечится на уровне ОС: проверка диска, перезагрузка, перенос нагрузок.
• Несовпадение параметров StorageClass/PVC. Например, режим доступа, ограничения по zone/region, topology constraints.
• Том «завис» в состоянии attached к другой ноде. Смотрите события контроллера/CSI и фактическое состояние тома (для вашего провайдера/хранилища).

Кейс 3: image filesystem full и «no space left on device»

Одна из самых недооценённых причин ContainerCreating: место на диске закончилось не «вообще», а именно на разделе, где runtime хранит образы и слои. В событиях часто видно image filesystem full или разные варианты no space left on device.

Как быстро подтвердить проблему диска на ноде

df -h
df -i

Смотрите не только проценты, но и inode: если закончились inode, симптомы будут похожи на переполнение диска.

Где лежат данные container runtime

Зависит от runtime и настроек, но часто:

• containerd: /var/lib/containerd
• Docker: /var/lib/docker
• kubelet: /var/lib/kubelet

Полезно быстро найти самых «тяжёлых» потребителей (на одном filesystem, без перехода на другие точки монтирования):

sudo du -xhd1 /var/lib | sort -h
sudo du -xhd1 /var/lib/containerd | sort -h
sudo du -xhd1 /var/lib/kubelet | sort -h

Если у вас SSD и симптомы похожи на деградацию I/O при заполненном разделе, отдельно полезно проверить, включён ли TRIM на хосте. По теме у нас есть отдельная заметка: как настроить fstrim/discard и что проверить на SSD.

Очистка: образы, снапшоты, «висячие» артефакты

Точка входа: удаляем неиспользуемые образы и мусор runtime, но не трогаем то, что прямо сейчас используется работающими Pod’ами.

Для containerd часто удобно работать через crictl (если установлен):

sudo crictl images
sudo crictl rmi --prune

Если у вас Docker:

sudo docker system df
sudo docker image prune -a

Важно: на проде с ограниченным каналом «агрессивная» очистка (prune -a) может привести к массовому повторному скачиванию образов и всплеску времени деплоя. Правильный порядок: cordon, при необходимости drain, чистка, затем возврат ноды.

Проверить условия Node и эвикшены kubelet

kubectl describe node NODE_NAME

Ищите условия DiskPressure и события, связанные с eviction. Если диск забит логами или снапшотами, kubelet может не успеть освободить место автоматически.

Кейс 4: проблема в kubelet или container runtime (не только CNI)

Иногда Pod висит в ContainerCreating, но события «размытые» и не указывают прямо на CNI/mount/disk. Тогда копаем с ноды: kubelet может не успевать обрабатывать очередь, runtime может быть в деградации, а на диске — I/O задержки.

Что искать в логах kubelet

• ошибки CRI (rpc error, timeouts);
• ошибки создания sandbox;
• ошибки монтирования;
• ошибки записи на диск;
• повторяющиеся рестарты kubelet.

sudo journalctl -u kubelet --since '30 min ago' --no-pager

Состояние ноды: CPU, память, I/O

uptime
free -m
sudo iostat -x 1 5

Если I/O в потолок (большие await), создание sandbox и распаковка образов будут «тормозить» и выглядеть как зависание. В таких случаях иногда проще и быстрее временно масштабировать пул нод.

Безопасная тактика: как чинить, не усугубляя инцидент

Частая ошибка — пытаться лечить ноду «на горячую», пока туда продолжают назначаться Pod’ы. Более безопасный порядок:

1. Остановить новые назначения на ноду (cordon), чтобы не размножать зависшие Pod’ы.
2. Уточнить причину по Events и логам (CNI, mount, диск, runtime).
3. Сделать точечное исправление.
4. Только потом возвращать ноду в планирование.

kubectl cordon NODE_NAME

Если нужно вывести текущие нагрузки (осторожно, учитывайте PDB и критичные Pod’ы):

kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data

Сводная шпаргалка «сообщение → куда смотреть → что делать»

• CNI not initialized: проверьте CNI DaemonSet в kube-system, наличие /etc/cni/net.d и /opt/cni/bin, затем логи kubelet и runtime на ноде.
• FailedMount: в kubectl describe pod найдите конкретный volume/PVC, проверьте PVC/PV/StorageClass, затем логи CSI node plugin и dmesg на ноде.
• volume attach timeout: фокус на CSI/controller, топологии (zone), «зависших» attach, состоянии ноды.
• image filesystem full: df -h, df -i, чистка образов/снапшотов, проверка DiskPressure.
• Нет явной ошибки, но всё в ContainerCreating: journalctl -u kubelet и логи runtime, плюс проверка I/O и места на диске.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Профилактика: чтобы ContainerCreating не превращался в регулярный инцидент

• Мониторинг свободного места на разделах runtime и /var/lib/kubelet (и отдельно inode).
• Ротация логов (runtime, journald) и контроль ретенции.
• Алерты по DiskPressure и деградации Node.
• Проверка обновлений CNI/CSI по регламенту, особенно после обновлений kernel/iptables.
• Стандарт на контейнерные образы (меньше слоёв и «жирных» артефактов), чтобы снижать давление на image filesystem.

Если Pod застрял в ContainerCreating, не пытайтесь «лечить Pod». Почти всегда лечить нужно ноду: CNI, storage attach/mount или диск под образы. Начните с kubectl describe pod и заканчивайте логами kubelet на конкретной ноде — эта связка быстрее всего приводит к первопричине.

Мини-шпаргалка команд (можно копировать в заметки)

kubectl get pod -n NAMESPACE POD_NAME -o wide
kubectl describe pod -n NAMESPACE POD_NAME
kubectl describe node NODE_NAME
kubectl get pods -n kube-system -o wide
sudo journalctl -u kubelet -n 300 --no-pager
sudo journalctl -u containerd -n 300 --no-pager
df -h
df -i
sudo ls -la /etc/cni/net.d
sudo ls -la /opt/cni/bin
mount | grep -i kube
lsblk
sudo dmesg -T | tail -n 100

Если поднимаете небольшой кластер «с нуля» и хотите уменьшить шанс подобных проблем за счёт более предсказуемой инфраструктуры, пригодится гайд: установка k3s на VDS и базовая обвязка.