Kubernetes Node NotReady: диагностика kubelet, CNI и pressure-состояний

Состояние NotReady у ноды Kubernetes — это не «ошибка Kubernetes», а итоговая индикация: control plane перестал получать от kubelet здоровые статусы (NodeStatus, lease), или kubelet сам считает, что нода не может гарантировать базовые условия (сеть, диски, память, runtime).

Хорошая новость: в большинстве случаев причину можно локализовать за 10–20 минут, если идти по понятному чек-листу и не начинать с хаотичных рестартов.

Ниже — практичная схема диагностики по самым частым причинам: kubelet, container runtime, CNI и pressure-состояния (DiskPressure/MemoryPressure/PIDPressure), плюс отдельный блок про x509-ошибки и сертификаты kubelet.

Как быстро понять, что именно сломалось

Первое правило: «NotReady» — симптом. Сначала фиксируем, какой именно Condition красный, и какие события пишет kubelet. Это обычно сразу сужает круг до 1–2 причин.

1) Смотрим сводку по ноде и условия (Conditions)

kubectl get nodes -o wide

kubectl describe node <node-name>

В kubectl describe важны два блока:

• Conditions: Ready, NetworkUnavailable, DiskPressure, MemoryPressure, PIDPressure.

• Events: часто прямо написано, что kubelet не может обновить статус, не инициализировался CNI, или недоступен runtime.

2) Быстрая интерпретация Conditions

• Ready=False + NetworkUnavailable=True — чаще всего CNI/маршрутизация/iptables/forwarding.

• DiskPressure=True — kubelet включает eviction и может перестать принимать новые поды.

• MemoryPressure=True — нехватка RAM, OOM/eviction, иногда страдают kubelet и runtime.

• Ready=Unknown — control plane не получает heartbeat: сеть/фаервол, kubelet завис, проблемы с TLS/аутентификацией.

Главная идея: сначала зафиксируйте Conditions и последние Events — это экономит время и помогает не чинить «сеть», когда на самом деле кончились inode или упал runtime.

Проверка kubelet: сервис, логи, связь с API

Самый частый сценарий: kubelet не стартует, уходит в рестарт-луп, не может зарегистрировать ноду, не обновляет NodeStatus/lease или не проходит TLS к API.

1) Состояние сервиса kubelet и последние логи

systemctl status kubelet --no-pager

journalctl -u kubelet -n 200 --no-pager

Типовые маркеры в логах:

• failed to run Kubelet, error loading config file — ошибка конфигурации.

• container runtime is down, PLEG is not healthy — проблемы в связке kubelet ↔ runtime.

• Unable to register node, node not found — регистрация/доступ к API.

• x509: certificate has expired — истёк сертификат, время на ноде или доверие к CA.

2) Проверяем, что у ноды нет отдельного сетевого провала до API

Даже если kubectl на вашей машине работает, у ноды может быть свой маршрут/DNS/ACL-провал (особенно в сегментированных сетях).

ip route

resolvectl status

getent hosts kubernetes.default.svc

Если у вас не systemd-resolved, смотрите резолвер напрямую:

cat /etc/resolv.conf

3) Частая «невидимая» причина: время и TLS

Расхождение времени легко ломает TLS и выглядит как непонятные x509-ошибки или таймауты. Проверьте синхронизацию времени на самой ноде:

timedatectl

chronyc tracking

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

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

Подробнее

Если вы выбираете, где держать ноды и control plane, разумный старт — VDS для Kubernetes-кластера: проще контролировать сеть, диск и доступ к логам, чем на «разрозненных» средах.

Container runtime: containerd/CRI-O и связка с kubelet

Если runtime недоступен, kubelet почти всегда деградирует до NotReady: ему неоткуда взять состояние подов/контейнеров и невозможно поддерживать жизненный цикл.

1) Проверяем состояние runtime и его логи

Сначала посмотрите runtime в kubectl describe node (поля Container Runtime/Runtime). На ноде проверьте сервис.

systemctl status containerd --no-pager

journalctl -u containerd -n 200 --no-pager

Если используется CRI-O:

systemctl status crio --no-pager

journalctl -u crio -n 200 --no-pager

2) Быстрая проверка через crictl

crictl помогает отделить «kubelet сломан» от «runtime сломан». Если crictl info не отвечает, почти всегда проблема на стороне CRI.

crictl info

crictl ps

crictl pods

Частые причины деградации runtime:

• Заполнен диск или кончились inode.

• Ошибки в storage (overlay/snapshot), проблемы в /var/lib/containerd или /var/lib/containers.

• Слишком агрессивный логгинг, который раздувает файловую систему и ломает запись.

3) Когда «просто перезапустить runtime» не помогает

Если первопричина — диск/иноды/FS-ошибки, перезапуск может только ускорить падение: сервис снова попытается создать файлы и упадёт. Сначала устраняйте первопричину, потом перезапускайте.

CNI: почему проблемы сети выглядят как Node NotReady

Пока не работает CNI-плагин, kubelet не может обеспечить сетевую готовность. В результате поды часто зависают в ContainerCreating, а на ноде появляются ошибки про sandbox/network.

1) Признаки проблем CNI

• NetworkUnavailable=True в Conditions (часто, но не всегда).

• Поды CNI (DaemonSet) в CrashLoopBackOff или Init:Error.

• В событиях: failed to setup network, CNI plugin not initialized.

2) Проверяем DaemonSet CNI и логи

kubectl get pods -A -o wide

kubectl -n kube-system get ds

kubectl -n kube-system describe pod <cni-pod-name>

kubectl -n kube-system logs <cni-pod-name> --tail=200

3) На ноде: конфиги CNI и базовая проверка сети

Почти все CNI читают конфиги из /etc/cni/net.d и используют бинарники в /opt/cni/bin.

ls -la /etc/cni/net.d

ls -la /opt/cni/bin

ip link

ip addr

ip rule

ip route show table main

Если CNI завязан на iptables, проверьте, создаются ли цепочки и не режется ли форвардинг «жёстким» firewall:

iptables -S

iptables -t nat -S

4) Типовые корни проблем CNI

• MTU/фрагментация: частый кейс на оверлеях и при туннелях — поды вроде бы стартуют, но сеть «сыпется».

• Конфликт с firewall: запрещён форвардинг, дропается трафик между pod CIDR и node CIDR.

• Два конкурирующих конфига в /etc/cni/net.d после обновления/смены CNI.

Если вы строите лёгкие кластеры (edge/dev) и часто упираетесь в сетевые нюансы, может быть полезно сравнить подходы к ingress и сетевому контуру в материале Ingress в k3s: Traefik, Nginx и HAProxy — что выбрать.

Pressure-состояния: DiskPressure, MemoryPressure, PIDPressure

Pressure означает, что kubelet сообщает: «я не гарантирую стабильную работу». В таких ситуациях нода может стать NotReady или начать агрессивно эвиктить поды. На практике чаще всего стреляют DiskPressure и MemoryPressure.

1) DiskPressure: место и inode

Проверяем объём и inode:

df -h

df -i

Ищем, что именно раздулось (обычно /var, /var/lib/containerd, /var/log):

du -x -h -d 2 /var | sort -h

du -x -h -d 2 /var/lib | sort -h

Если внезапно кончились inode, ищите каталоги с миллионами мелких файлов: логи, кэши, временные директории, артефакты сборок.

2) MemoryPressure: нехватка RAM и eviction

Проверяем память и swap:

free -m

swapon --show

vmstat 1 5

Смотрим OOM в ядре:

journalctl -k -n 200 --no-pager

Если в кластере настроены requests/limits, обратите внимание на QoS и большие best-effort поды: они обычно эвиктятся первыми, но при сильном давлении может пострадать и сам kubelet/runtime.

3) PIDPressure: кончились процессы

Редко, но очень неприятно: нода перестаёт форкать процессы, сервисы деградируют каскадом. Проверяем лимиты и текущую нагрузку PID:

cat /proc/sys/kernel/pid_max

ps -e --no-headers | wc -l

Kubelet certificate: истёк, не подходит CA, сломалась ротация

Когда истекает клиентский сертификат kubelet или ломается доверие к API, нода может уйти в NotReady или Ready=Unknown, а в логах появляются x509-ошибки.

1) Как это выглядит в логах

• x509: certificate has expired or is not yet valid

• x509: certificate signed by unknown authority

• tls: bad certificate

Первым делом снова проверьте время на ноде:

timedatectl

2) Где обычно лежат сертификаты kubelet и как посмотреть сроки

В типичных kubeadm-кластерах сертификаты kubelet лежат в /var/lib/kubelet/pki, а kubeconfig — в /etc/kubernetes/kubelet.conf. Быстро посмотреть сроки можно через openssl:

ls -la /var/lib/kubelet/pki

openssl x509 -noout -subject -issuer -dates -in /var/lib/kubelet/pki/kubelet-client-current.pem

Если файла нет или имя другое — ориентируйтесь по логам kubelet: там обычно виден путь, который он пытается использовать.

3) Что делать, если сертификат истёк

Универсальной «одной команды» нет: всё зависит от способа установки (kubeadm, managed, k3s и т.д.). Но логика одинакова:

1. Убедиться, что время и синхронизация корректны.

2. Проверить, включена ли ротация клиентских сертификатов kubelet.

3. Если ротация сломалась — аккуратно восстановить kubeconfig/доверие, затем перезапустить kubelet.

Перед любыми действиями с файлами в /etc/kubernetes и /var/lib/kubelet сделайте резервную копию и фиксируйте изменения: ошибки в PKI легко превращаются в простой части кластера.

Если вы заранее закрываете вопрос с HTTPS и управлением сроками, проще жить с нормальной ротацией и предсказуемыми продлениями. Для публичных интерфейсов (ingress, панели, API-шлюзы) обычно удобнее использовать SSL-сертификаты с понятными сроками и поддержкой.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Практичный чек-лист: вернуть ноду в Ready

Если нужно быстро и повторяемо «раскрутить» инцидент, идите в таком порядке:

1. Со стороны кластера: kubectl describe node, Conditions, Events, время последнего heartbeat.

2. На ноде: systemctl status kubelet и journalctl -u kubelet.

3. Runtime: systemctl status containerd/crio, затем crictl info.

4. Pressure: df -h, df -i, free -m, journalctl -k на OOM.

5. CNI: статус DaemonSet, логи CNI-пода, наличие конфигов в /etc/cni/net.d, базовая диагностика ip/iptables.

6. TLS/сертификаты: x509-ошибки, проверка времени, сроки kubelet client cert.

Профилактика: что сделать заранее, чтобы NotReady случался реже

• Мониторинг pressure: алерты по заполнению диска/инодов и по памяти до того, как kubelet начнёт eviction.

• Лог-менеджмент: контролируйте рост /var/log и контейнерных логов, включайте ротацию и лимиты.

• План ротации сертификатов: следите за сроками, особенно если кластер живёт годами и переживал миграции/ручные правки.

• Единая политика firewall: документируйте правила между node/pod CIDR и control plane, чтобы CNI не ломался после «ужесточения».

Если нода продолжает уходить в NotReady без очевидных ошибок, соберите минимальный набор артефактов: вывод kubectl describe node, последние 200–500 строк логов kubelet/runtime, показатели диска/памяти и статус CNI DaemonSet. С таким набором причину обычно уже можно точно классифицировать и чинить точечно, а не перезапускать всё подряд.

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