Статус Ready и соответствие конфигурации kubelet эталону — разные гарантии. Рассмотрим ситуацию: для нескольких классов нод в Git заданы настройки резервирования ресурсов, пороги реакции на нехватку ресурсов и параметры очистки образов. Фактические файлы на хостах могут отличаться от этих эталонов, хотя Kubernetes продолжает считать ноды готовыми.
Это позволяет разобрать проблему без описания конкретного кластера или инструмента эксплуатации. Нода может работать сейчас, но при нехватке памяти или места на диске повести себя не так, как ожидается от её класса.
Ready и соответствие эталону — разные проверки
Условие Ready=True означает, что Kubernetes считает ноду здоровой и готовой принимать поды.1 Оно описывает текущее рабочее состояние ноды, но ничего не знает о правилах, принятых внутри конкретной платформы.
Kubernetes не знает, какой файл выбран эталонным, какой коммит Git определяет нужную версию и какая контрольная сумма ожидается на хосте. Поэтому два результата не противоречат друг другу:
Ready=True
desired_config != actual_config
Kubelet может успешно запуститься с существующим файлом, публиковать статус ноды и обслуживать поды. Проблема не обязательно в синтаксической ошибке конфигурации: файл может быть допустимым, но отличаться от выбранного эталона.
Почему дрейф долго не проявляется
Многие параметры kubelet определяют поведение ноды на границе доступных ресурсов. Пока запас памяти и диска достаточен, две ноды с разными настройками могут выглядеть одинаково.
Различия в kubeReserved и systemReserved меняют расчёт Node Allocatable, а при соответствующей настройке enforceNodeAllocatable позволяют kubelet применять эти резервы к cgroup системных процессов.2 Значения evictionHard и evictionSoft определяют пороги сигналов нехватки ресурсов. После их достижения kubelet пытается освободить ресурсы ноды, а если этого недостаточно, может начать завершать поды.3 Параметры очистки образов также могут изменить момент, когда нода начнёт возвращать дисковое пространство.
Поэтому дрейф конфигурации чаще выглядит не как немедленная поломка, а как отложенное расхождение в поведении. Оно становится заметным только тогда, когда нагрузка достигает порога, заданного в отличающейся конфигурации.
Как превратить эталон в проверку
Для обнаружения дрейфа нужно независимо определить ожидаемую конфигурацию, прочитать фактически используемый файл и сравнить их. Проверка должна показывать не только факт несовпадения, но и различия, достаточные для решения о следующем действии.
На уровне поведения контракт выглядит так:
ожидаемая конфигурация определена заранее
→ фактическая конфигурация прочитана без изменения
→ совпадение, расхождение или ошибка чтения показаны отдельно
Ошибка чтения не должна превращаться в сообщение «дрейфа нет». Иначе проверка будет подтверждать состояние, которого она не наблюдала.
Обнаружение полезно отделять от исправления. Проверка различий сама по себе не должна перезапускать kubelet или менять файл на хосте. Применение конфигурации, проверка восстановления сервиса и возврат к предыдущему состоянию требуют отдельного управляемого процесса.
Способ доставки проверки на ноды — отдельный выбор реализации. Для понимания границы между здоровьем и соответствием эталону не нужен конкретный агент или его интерфейс.
Совпадение файла тоже нужно правильно понимать
Сравнивать следует тот файл, который действительно использует kubelet. Путь задаётся параметром --config, а параметры командной строки могут переопределять совпадающие значения из конфигурационного файла.4
Поэтому перед сравнением нужно изучить параметры запуска kubelet и определить источники конфигурации. Совпадение файла по привычному пути ещё не доказывает, что именно эти настройки использует процесс. Иначе проверка создаст такое же ложное чувство уверенности, как и один зелёный статус Ready.
Три вопроса о состоянии ноды
Полезно разделять проверку ноды на три независимых вопроса:
| Вопрос | Источник ответа |
|---|---|
| Доступна ли нода Kubernetes прямо сейчас? | Условие Ready и другие сигналы состояния |
| Соответствует ли её конфигурация принятому эталону? | Отдельная проверка дрейфа |
| Поведёт ли она себя ожидаемо под нагрузкой? | Наблюдаемость и проверка выбранных порогов |
Ready отвечает на первый вопрос. Проверка контрольных сумм и различий отвечает на второй, но не доказывает правильность самого эталона. Третий требует наблюдать ноду в тех режимах, для которых заданы резервирование ресурсов, пороги нехватки ресурсов и очистка образов.
Вывод
Статус Ready остаётся полезным, если не приписывать ему лишний смысл. Он показывает, что Kubernetes сейчас считает ноду достаточно здоровой для работы, но не подтверждает соответствие локальной конфигурации выбранному эталону.
Когда одинаковое поведение нод является частью требований, соответствие эталону должно иметь собственную проверку. Нода может быть Ready и одновременно отличаться от соседних нод именно в тех настройках, которые определят её поведение при следующем дефиците ресурсов.