Узел K8s — это физическая или виртуальная машина, участвующая в кластере K8s, которая может использоваться для запуска подов. Когда узел выключается, выходит из строя или процесс kubelet сталкивается с проблемой, узел переходит в состояние NotReady. Он не может использоваться для запуска подов. В этом случае все запускаемые на узле поды становятся недоступными.

Обычными причинами перехода узла K8s в состояние NotReady являются:

• Нехватка ресурсов на узле

• Проблема с процессом kubelet

• Ошибка, связанная с kube-proxy

• Кластер создали только что 

Если узел находится в состоянии NotReady, это означает, что kubelet установлен на узле, но K8s обнаружил проблему, которая не позволяет ему запустить под. Например:

Как понять статус ноды

Существует четыре возможных статуса ноды:

• Ready: нода исправна и готова к размещению подов.

• NotReady: нода столкнулась с некоторой проблемой, и на ней нельзя разместить под.

• SchedulingDisabled: на ноду поставили статус, что она не принимает поды.

• Unknown: нода недоступна для работы.

Устранение ошибки «Node NotReady»

Проверка ресурсов ноды

Если у вас есть панель мониторинга, вам следует немедленно проверить использование ресурсов ноды. Например, среднее значение нагрузки, использование процессора, использование памяти, дисковый ввод-вывод, сетевой ввод-вывод и так далее. Это даст вам некоторые направления для поиска и устранения неисправностей.

Делюсь хорошим шаблоном для мониторинга приложений в предыдущей статье. Вы можете позаимствовать эту идею и использовать ее для мониторинга вашей ноды.

Если у вас нет панели мониторинга , вы все равно можете войти в узел по ssh и использовать команды Linux, такие как top, free, uptime, ss и прочие. 

kubectl describe node [name]

Вы можете запустить kubectl describe node [name] и посмотреть в разделе Conditions, чтобы узнать, не хватает ли ресурсов на узле:

1. MemoryPressure: Значение True указывает на то, что на ноде не хватает памяти.

2. DiskPressure: Значение True в этом поле указывает на то, что ноде не хватает места.

3. PIDPressure: Если на ноде запущено слишком много процессов, это поле будет иметь значение True.

4. NetworkUnavailable : Если сеть для ноды настроена неправильно, это поле будет иметь значение True.

5. Ready: Если нода исправна и готова к принятию подов, это поле будет со значением True. В этом поле значение False эквивалентно статусу NotReady в поле get nodes. Оно также может иметь значение Unknown, что означает, что контроллер ноды не получал сообщений от ноды в течение последнего node-monitor-grace-period (по умолчанию — 40 секунд).

К примеру:

Вы также можете проверить выделенные ресурсы для данной ноды, используя ту же команду describe:

Проверка компонентов ноды К8s

Вы можете подключиться к ноде по протоколу ssh и проверить следующие компоненты K8s:

kube-proxy: kubectl logs [pod name] -n kube-system

kubelet: systemctl status kubelet

docker/containerd: systemctl status docker/containerd

Вы также можете использовать journalctl -u [service_name] для просмотра логов. Например:

Проверка событий K8s

Событие в K8s — это объект во фреймворке, который автоматически генерируется в ответ на изменения в других ресурсах — нодах, подах или контейнерах. События дают вам ценную информацию о том, как работает ваша инфраструктура.

Вы можете использовать kubectl get events —all-namespaces для сбора событий кластера

Проверьте сетевую связь

Если в поле Conditions показано NetworkUnavailable, это означает, что между нодой и плоскостью управления существует сетевая проблема.

Несколько возможных способов устранения:

• Если нода настроена на использование прокси, убедитесь, что прокси разрешает доступ к конечным точкам сервера API.

• Убедитесь, что таблицы маршрутизации настроены должным образом, чтобы избежать блокировки связи с сервером API. Вы можете использовать команду ip route.

• Если вы используете облачного провайдера, например AWS, убедитесь, что настроены надлежащие правила входа и выхода.

• Также не помешает проверить системные журналы сервера, такие как /var/log/messages или /var/log/dmesg.