Обнаружение проблем узлов (shturval-npd)

О сервисе

ПараметрЗначение
Название в интерфейсеshturval-npd
Системное название (идентификатор)shturval-npd
Назначение в кластереОбнаружение и публикация проблем на узлах кластера.
КритическийНет
Публичный репозиторийNode Problem Detector
Зависимости—

Назначение

shturval-npd сообщает Kubernetes о проблемах на узлах кластера. На каждом узле Linux работает демон node-problem-detector: он находит проблему и записывает её в API-сервер, в conditions и Event объекта Node. Демон работает как DaemonSet.

Пока на узле нет проблем, Kubernetes назначает новые поды на рабочий узел. Как только node-problem-detector заметит проблему и запишет об этом в Node, на проблемный узел перестанут назначаться новые поды. Примеры, что может обнаружить демон node-problem-detector:

  • на узле недоступен NTP;
  • неисправны процессор, память или диск;
  • зависло ядро или повреждена файловая система;
  • не отвечает среда выполнения контейнеров.

По умолчанию демон читает сообщения ядра из /dev/kmsg и журнала /var/log, после чего проставляет conditions в Node. Файлы мониторов вшиты в образ в каталоге /config. По умолчанию в shturval-npd входят мониторы: kernel-monitor.json (мониторинг зависание ядра, остановки XFS, аппаратной ошибки), readonly-monitor.json (мониторинг файловой системы). Метрики доступны на порту 20257, serviceMonitor выключен.

Сервис не входит в группу быстрой установки — может быть установлен только в развернутом кластере. Конфигурацию вы можете задать в customvalues при установке сервиса или через ShturvalServicePatch (SSP), когда сервис установлен в кластере.

Pod должен быть привилегированным (securityContext.privileged: true): чтение сообщений ядра из /dev/kmsg без привилегированности недоступно.

Пока сервис включен, health-checker следит и обновляет статус conditions на Node. После выключения сервиса в кластере conditions останутся на Node.

Где настраивать

Сервисы и репозитории → Доступные чарты → чарт shturval-npd → Установить.

Если сервис уже установлен: Установленные сервисы → shturval-npd → Управлять.

Conditions

Когда shturval-npd установлен с настройкой по умолчанию, на узлах Linux запускается демон, который добавляет к Node conditions:

ConditionОписание
ReadonlyFilesystemФайловая система перемонтирована только для чтения
KernelDeadlockЯдро Linux в состоянии блокировки
XfsShutdownФайловая система XFS остановлена
CperHardwareErrorFatalАппаратная ошибка с уровнем fatal
CorruptDockerOverlay2Повреждение хранилища overlay2

На Node при этом остаются стандартные conditions Kubernetes: Ready, MemoryPressure, DiskPressure, PIDPressure и NetworkUnavailable.

Чтобы мониторить на узлах частые перезапуски kubelet, docker и containerd, доступность container runtime и kubelet, а также ожидание освобождения сетевого устройства, задайте customvalues или примените SSP к установленному сервису. Пример ниже добавляет в Node такие conditions:

ConditionОписание
FrequentKubeletRestartkubelet часто перезапускается
FrequentDockerRestartdocker часто перезапускается
FrequentContainerdRestartcontainerd часто перезапускается
FrequentUnregisterNetDeviceЯдро часто ждёт освобождения сетевого устройства
ContainerRuntimeUnhealthycontainer runtime не отвечает
KubeletUnhealthykubelet не отвечает на проверку

Параметры для конфигурации сервиса

ПараметрПо умолчаниюОписание
settings.log_monitorskernel-monitor.json, readonly-monitor.json, docker-monitor.jsonСписок JSON лог-мониторов из каталога /config образа. Дополнительные пути из customvalues контроллер объединяет с набором по умолчанию
settings.custom_plugin_monitors[]Список JSON проверок health-checker и log-counter. Пустой список не добавляет conditions
settings.extraArgsне заданДополнительные флаги процесса node-problem-detector. Например, --config.system-stats-monitor
hostNetworkfalseСеть Pod. При true проверка kubelet открывает порт 10248 на узле. При false этот порт принадлежит Pod, и kubelet по нему недоступен
extraVolumes, extraVolumeMountsне заданыТома с узла: сокет containerd и бинарь crictl для проверки CRI
settings.prometheus_address0.0.0.0Адрес, на котором процесс отдаёт /metrics
Порт Prometheus20257Порт Service с метриками
settings.heartBeatPeriod5m0sПериод обновления conditions в Node, даже если они не менялись
metrics.enabled, serviceMonitor.enabledfalseService метрик и ServiceMonitor
securityContext.privilegedtrueПривилегированный Pod, доступ к /dev/kmsg

Не передавайте в settings.extraArgs флаг --system-log-monitors вместе с --config.system-log-monitor: процесс завершится. --port=0 и --prometheus-port=0 при пустом Stackdriver тоже останавливают процесс: не остаётся ни одного exporter.

Пример: дополнительные мониторы

По умолчанию сокет containerd не монтируется, hostNetwork выключен, custom plugin не передаётся. Блок customvalues ниже можно добавить в спецификацию сервиса при установке или в SSP. Включайте только необходимые файлы.

hostNetwork: true необходим для kubelet: health-checker ходит на localhost:10248. Без сети узла это адрес Pod, а не kubelet.

Пример ShturvalServicePatch: дополнительные мониторы

apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: shturval-npd-monitors
spec:
  shturvalServiceConfigName: shturval-npd
  customvalues:
    extraVolumeMounts:
      - mountPath: /var/run/containerd/containerd.sock
        name: containerd
        readOnly: true
      - mountPath: /bin/crictl
        name: crictl
        readOnly: true
    extraVolumes:
      - name: containerd
        hostPath:
          path: /var/run/containerd/containerd.sock
          type: Socket
      - name: crictl
        hostPath:
          path: /bin/crictl
          type: File
    hostNetwork: true
    settings:
      custom_plugin_monitors:
        - /config/health-checker-containerd.json
        - /config/systemd-monitor-counter.json
        - /config/kernel-monitor-counter.json
        - /config/network-problem-monitor.json
        - /config/health-checker-kubelet.json
      extraArgs:
        - --config.system-stats-monitor=/config/system-stats-monitor.json
      log_monitors:
        - /config/kernel-monitor.json
        - /config/readonly-monitor.json
        - /config/systemd-monitor.json

Файлы из примера попадают в Node:

ФайлЧто добавляет в Node
kernel-monitor.json, readonly-monitor.jsonТе же conditions, что при установке, кроме CorruptDockerOverlay2
systemd-monitor.jsonПостоянных conditions нет: временные Event о старте kubelet, docker и containerd
systemd-monitor-counter.jsonFrequentKubeletRestart, FrequentDockerRestart, FrequentContainerdRestart
kernel-monitor-counter.jsonFrequentUnregisterNetDevice
health-checker-kubelet.jsonKubeletUnhealthy
health-checker-containerd.jsonContainerRuntimeUnhealthy. Для вызова crictl нужны том сокета и бинарь с узла
network-problem-monitor.jsonПостоянного condition нет
system-stats-monitor.jsonConditions не пишет. В аргументы попадает через settings.extraArgs

Конструктор собирает блок customvalues для спецификации сервиса или для SSP. Списки в settings вводятся через пробел.

Собрать customvalues для SSP

Блок customvalues собирается в браузере и на сервер не отправляется. После ухода со страницы введённые значения сбрасываются.

Вставьте блок в customvalues сервиса или в spec ShturvalServicePatch.


Как развернуть этот сервис — Как развернуть новый сервис.