Node Declared Features стал stable в Kubernetes 1.37: проверка mixed-version scheduling. В тестовом node pool зафиксировать версии kubelet и runtime, объявленные возможности и решение scheduler; провести пару планирований с заведомо поддерживаемым и неподдерживаемым требованием, не запуская production workload. Практический результат — Матрица «node.
1. Зафиксируйте точный симптом и границу ответа
В кластере с узлами разных версий workload может попасть на узел без нужной runtime-возможности; Node Declared Features решает класс задач, но требует достоверной декларации и поддержки всей цепочкой. Рабочая граница материала — именно запрос «как проверить node declared features в kubernetes 1.37 для планового mixed version upgrade и не отправить pod на несовместимый node». До любого действия запишите версию, один наблюдаемый симптом, время и ожидаемый результат. Не переносите вывод на другую версию, роль, операционную систему или соседний продукт без повторной сверки. Новостная карточка или форумное обсуждение могут быть лишь lead: они не доказывают причину, охват или популярность.
2. Отделите свежее событие от технического доказательства
26 августа 2026 года Node Declared Features в Kubernetes 1.37 достиг stable; релиз-анонс и официальная concept-страница сверены 28 августа, поэтому важна не реклама функции, а проверка её фактического действия в гетерогенном пуле. Первый источник фиксирует: Официальное объявление Kubernetes 1.37 от 26 августа 2026 года перечисляет 67 enhancements и отдельно описывает статусы новых возможностей; эта страница задаёт версионную и feature-gate границу, а не обещание применимости к любому кластеру. Второй официальный контракт уточняет: Официальная concept-страница Kubernetes описывает, как узлы публикуют доступные возможности, а workload заявляет требования для планировщика; это контракт для mixed-version матрицы и негативного scheduler-теста. Из этих двух текстов не следует, что любой похожий симптом вызван тем же механизмом. Дата, версия, область действия и оговорки источника остаются частью ответа.
3. Проведите один обратимый контрольный тест
В тестовом node pool зафиксировать версии kubelet и runtime, объявленные возможности и решение scheduler; провести пару планирований с заведомо поддерживаемым и неподдерживаемым требованием, не запуская production workload. До теста сохраните исходное значение или копию только затрагиваемого объекта, заранее определите признак успеха, отрицательный исход и команду возврата. Меняйте ровно один фактор и повторяйте тот же контрольный вход. Не сбрасывайте профиль, не удаляйте данные, не отключайте защиту и не подменяйте сетевой маршрут ради удобного результата.
4. Прочитайте матрицу исходов без подмены причины
Матрица «node version × declared feature × workload requirement × scheduler decision × runtime result», негативный тест на заведомо неподходящем узле, запасной nodeSelector-план и стоп-линия до отказа от текущих placement-ограничений. Декларация в объекте Node ещё не доказывает успешный запуск workload; нужно разделять publication, scheduler filtering, binding и наблюдаемую работу на конечном узле. В каждой ячейке записывайте только наблюдаемый факт, а не предполагаемую причину. Если симптом исчез, это подтверждает границу контрольного теста, но не универсальную причину для всех конфигураций. Если результат неоднозначен, верните исходное состояние и соберите минимальный воспроизводимый пример.
5. Остановитесь до необратимого шага и эскалируйте минимум
Не убирать nodeSelector, affinity и taints в production только из-за stable-статуса; остановить upgrade, если хотя бы один узел заявляет неверный feature set или workload попадает на несовместимый runtime. Для поддержки соберите версию продукта, время с timezone, один обезличенный код ошибки или статус, один контрольный шаг и его результат. Удалите имена, email, IP, account IDs, tokens, ключи, полные конфиги и приватные ссылки. Красные флаги для немедленной остановки: потеря данных, секрета или доступа, влияние на несвязанных пользователей, отсутствие копии или невозможность возврата.
Материал подготовлен редакцией VOne с помощью ИИ; технические утверждения постатейно сверены с указанными официальными и первичными источниками 28 августа 2026 года.
Источники и проверка
- Kubernetes 1.37 release announcement проверено 2026-08-28
- Kubernetes Node Declared Features проверено 2026-08-28
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.