Kubernetes 1.36 приносит 20 alpha-фич: DRA, gang scheduling, HPA scale-to-zero

Это перевод статьи «Kubernetes 1.36: Deep dive into new alpha features» от DevOps-команды Palark, участника CNCF. Оригинал: palark.com/blog/kubernetes-1-36-release-features/. Разбираются все 20 новых alpha-фич релиза 1.36, а также кратко non-alpha-highlights от Дмитрия Шурупова (сооснователя Palark).

Релиз Kubernetes 1.36, запланированный на 22 апреля 2026 года, содержит разнообразный набор новых alpha-фич, сфокусированных на трёх ключевых направлениях: производительность рабочих нагрузок, масштабируемость API и эффективное использование ресурсов. В этом обновлении много давно ожидаемых возможностей: workload-aware preemption для AI/ML-задач, шардирование API-стримов для больших кластеров, глубокая интеграция Dynamic Resource Allocation (DRA) в scheduler.

В обзоре — 20 новых фич, добавленных в Kubernetes как alpha (то есть выключены по умолчанию): от node-уровневых gRPC API до graceful leader transitions. Это даёт представление, куда движется контейнерная оркестрация.

Прим. Авторы стараются указывать актуальные изменения, но из-за быстро меняющегося ландшафта фич Kubernetes часть KEP (Kubernetes Enhancement Proposals) может быть исключена из milestone ближе к дате релиза.

Nodes

DRA: Device Attributes в Downward API

KEP #5304 · Feature gate: отсутствует. Фреймворк предоставляет boolean-флаг (например, --enable-device-metadata), который драйверы встраивают в свой CLI.

KEP-5304 вводит стандартный способ для DRA-драйвера наполнять метаданные устройства. Фреймворк затем автоматически передаёт эти метаданные в контейнер, монтируя их как JSON-файл по заданному пути. Больше не нужно изобретать кастомные контроллеры или запрашивать Kubernetes API из самой рабочей нагрузки только ради этих деталей.

В текущей версии DRA, чтобы получить информацию о выделенных устройствах (например, PCIe-адреса для GPU или UUID для mediated-устройств), нужно читать статус ResourceClaim, находить подходящий ResourceSlice и парсить атрибуты. Неудобно. KEP-5304 позволяет DRA-драйверу возвращать метаданные устройства прямо в ответе на gRPC-вызов PrepareResourceClaims (kubelet → driver), а kubelet пишет их в JSON-файл и монтирует его в контейнер. В итоге приложение внутри контейнера просто читает файл /var/run/dra-device-attributes/{claimName}/{requestName}/{driverName}-metadata.json.

Новый kubelet gRPC API для локальных подов

KEP #4188 · Feature gate: PodInfoAPI.

Сейчас, чтобы получить свежий статус пода (ready ли он, его IP, его labels), компоненты на той же ноде — CNI-плагины, мониторинг-агенты — должны ходить в API-сервер. Это создаёт проблемы с надёжностью (если нода потеряла связь с control-plane, локальные компоненты не получат свежие данные, хотя они есть у локального kubelet), масштабируемостью (нагрузка на API-сервер от агентов на каждой ноде) и задержкой (сетевой вызов всегда медленнее локального).

Предлагается новый gRPC API для подов прямо на ноде: UNIX-сокет /var/lib/kubelet/pods/kubelet.sock, доступ только для привилегированных процессов. API возвращает самую свежую информацию, доступную kubelet, даже если она ещё не синхронизирована с API-сервером. Клиент может запросить полный PodSpec и PodStatus либо конкретные поля через google.protobuf.FieldMask. Три основных метода: ListPods, GetPod, WatchPods.

CRI List Streaming

KEP #5825 · Feature gate: CRIListStreaming.

Иногда kubelet нужен список всех контейнеров на ноде (например, для garbage collection). Для этого он отправляет CRI-запрос ListContainers. Проблема: существующие CRI RPC — unary, то есть клиент (kubelet) шлёт один запрос, сервер (container runtime) возвращает один ответ со всем списком. На нагруженных нодах с тысячами контейнеров (например, от множества короткоживущих CronJob) список может превысить 16 МБ — дефолтный максимум в gRPC. Этот лимит достигается уже на ~11 000 контейнерах (~14 000 подов).

Чтобы не ломать совместимость, KEP добавляет новые server-side streaming RPC. При streaming-вызове container runtime не строит весь ответ в памяти — открывает gRPC-поток и отправляет StreamContainersResponse для каждого контейнера по очереди. kubelet читает из потока, пока тот не закроется, затем обёртка собирает куски в единый список.

DRA: видимость доступности ресурсов

KEP #5677 · Feature gate: DRAResourcePoolStatus.

Разработчику хочется видеть, какие DRA-ресурсы свободны в кластере, чтобы траблшутить Pod, который не шедулится из-за «insufficient DRA resources». Админу — знать, сколько GPU доступно, для планирования мощностей. Сейчас это сложно: ResourceSlices — cluster-scoped и показывают только общую capacity, ResourceClaims — namespaced и отслеживают конкретные выделения, пользователь с ограниченными правами не видит ResourceClaims вне своего namespace, нет API-механизма видеть соотношение available/allocated.

KEP добавляет ResourcePoolStatusRequest — паттерн CertificateSigningRequest: пользователь создаёт объект с указанием driver (обязательный) и pool filter (опциональный), контроллер в kube-controller-manager подхватывает его, считает availability и пишет результат в status. Для обновления — удалить старый запрос и создать новый.

Пример — посмотреть статус всех GPU-пулов:

			$ kubectl create -f - <
		

Pod-Level Resource Managers

KEP #5526 · Feature gates: PodLevelResources, PodLevelResourceManagers.

KEP-2837 позволил задавать единый бюджет ресурсов (CPU, память и т.д.) для всего пода целиком, а не для каждого контейнера отдельно. Это полезно для Guaranteed-QoS-подов в HPC, AI/ML, NFV. Проблема: текущие resource managers работают на уровне контейнера и не умеют использовать pod.spec.resources для NUMA-решений.

KEP-5526 даёт выбор из двух моделей управления ресурсами (обе поддерживают Guaranteed-поды с mix из Guaranteed- и non-Guaranteed-контейнеров):

• Pod Scope — Topology Manager назначает один ресурсный пул с одной NUMA-ноды на весь под, используя pod.spec.resources. CPU и Memory managers выделяют эксклюзивные сегменты для Guaranteed-контейнеров, остаток идёт в shared-пул для остальных
• Container Scope — ресурсы управляются для каждого контейнера отдельно, pod.spec.resources игнорируется при размещении

Первая модель — для ML-тренировочного контейнера с сайдкарами (логирование, ingestion, мониторинг) на одной NUMA-ноде. Вторая — для независимого управления контейнерами с разными требованиями внутри одного Guaranteed-пода: Guaranteed-контейнер получает эксклюзивные NUMA-выровненные ресурсы, non-Guaranteed в том же поде работают в shared-пуле ноды. Раньше это было невозможно: все контейнеры в поде должны были быть Guaranteed.

Scheduling

Workload-aware preemption

KEP #5710 · Feature gate: WorkloadAwarePreemption.

Scheduler может инициировать preemption — принудительное удаление подов с более низким приоритетом, чтобы освободить ресурсы под высокоприоритетный под. Проблема: он делает это пер-под. А AI/ML- и HPC-нагрузки обычно — группа тесно связанных подов (например, для распределённого обучения). Если даже один под из группы вытеснен, весь job стопорится и просто ждёт возврата этого пода, удерживая ресурсы впустую.

KEP-5710 вводит workload-aware preemption: группы связанных подов (PodGroups) теперь — единая сущность для scheduling и preemption. Scheduler прикидывает, можно ли освободить место под высокоприоритетную группу, вытеснив менее важные группы целиком.

Новое поле DisruptionMode в GangSchedulingPolicy контролирует, может ли Kubernetes вытеснять отдельные поды или группу только целиком (PodGroup). Поле PriorityClassName в PodGroupSpec задаёт приоритет всей группы — используется для всех решений о scheduling/preemption, перекрывая приоритеты отдельных подов. Строится на KEP-4671 (Gang Scheduling в Kubernetes).

Topology-aware workload scheduling

KEP #5732 · Feature gate: TopologyAwareWorkloadScheduling.

Строится на идеях KEP-4671 и KEP-5710. Классический scheduler принимает решения пер-под, что неоптимально для групп связанных подов: их имеет смысл размещать на одной ноде или хотя бы близких нодах — для снижения latency. KEP-5732 делает scheduler topology-aware: можно указать, чтобы группа подов размещалась в пределах одного topological domain, определённого общим label — например, topology.kubernetes.io/rack.

DRA: List-типы для атрибутов

KEP #5491 · Feature gate: DRAListTypeAttributes.

KEP обновляет DRA API под более сложные hardware-конфигурации. Раньше атрибуты устройств в ResourceSlice могли быть только скалярными (string, number, boolean). Нельзя было описать устройство с несколькими соединениями — например, CPU, подключённый к нескольким PCIe-шинам.

Теперь драйверы могут отдавать атрибуты как списки строк, чисел или версий. Обновлена логика в ResourceClaim: matchAttribute теперь требует непустого пересечения списков (не точного совпадения), distinctAttribute — попарной непересекаемости.

Пример ResourceSlice с атрибутом resource.kubernetes.io/pcieRoot в разных форматах:

DRA: поддержка ResourceClaim для Workloads

KEP #5729 · Feature gate: WorkloadPodGroupResourceClaimTemplate.

DRA даёт использовать специализированные ресурсы — GPU, FPGA, кастомные сетевые карты. Чтобы под получил такой ресурс, нужно создать соответствующий ResourceClaim. Проблема: если несколько подов делят ресурс, максимум было 256 подов на один ResourceClaim из-за лимита status.reservedFor.

KEP-5729 чинит: ResourceClaims теперь могут быть на уровне PodGroup. Один claim на всю группу, все поды в ней могут использовать ресурс. Поды ссылаются на ресурс по локальному group-name через PodGroupResourceClaim, а не прямому имени. Динамически создаваемые поды получают доступ к общему ресурсу, автоматически созданному для группы, без необходимости знать его имя заранее.

DRA: Native Resource Requests

KEP #5517 · Feature gate: DRANativeResources.

Появление DRA в Kubernetes породило два независимых механизма учёта ресурсов, которые управляют одним и тем же. Это даёт двойной учёт:

• Supply — capacity CPU/памяти ноды хранится в двух местах: Node.Status.Allocatable у kubelet и ResourceSlice у DRA-драйвера
• Consumption — поды могут запрашивать ресурсы двумя путями: через spec.containers[].resources.requests или spec.initContainers[].resources.requests (проверяет NodeResourcesFit) или через ResourceClaim (обрабатывает DynamicResources)

KEP-5517 интегрирует DRA-ресурсы со standard resource tracking scheduler-а, обеспечивая единый учёт и предотвращая overcommit. Пример: ML-job запрашивает GPU через ResourceClaim, но конкретная модель GPU требует определённого количества CPU и HugePages. Раньше пользователь должен был знать об этом и прописывать в PodSpec. Теперь GPU-устройство декларирует зависимости само — scheduler учитывает потребности GPU в CPU и HugePages дополнительно к обычным requests.

WAS (Workload-Aware Scheduling): декомпозиция PodGroup API

KEP #5832 · Feature gate: GenericWorkload.

Kubernetes имеет gang scheduling — запуск всех подов в группе вместе. Проблема: логика gang scheduling изначально тесно связана с конкретной реализацией API под названием PodGroup, которая была частью объекта Workload. Это создавало два неудобства:

• Другие проекты экосистемы (Kueue, JobSet), тоже требующие gang scheduling, были вынуждены использовать этот конкретный PodGroup API — не могли применить свои CRD для описания групп
• Обновление статуса одной маленькой Pod-группы требовало чтения/записи всего Workload-объекта, что давало просадку производительности и конфликты при большом числе групп

KEP-5832 разделяет PodGroup и Workload: PodGroup становится самостоятельным объектом, Workload — статичным шаблоном, определяющим общую политику и структуру групп. Высокоуровневые контроллеры (Job, JobSet, LeaderWorkerSet) автоматически создают инстансы PodGroup из шаблона Workload, затем поды этой PodGroup. В Pod spec появилось поле spec.schedulingGroup.podGroupName, указывающее прямо на PodGroup. Scheduler больше не следит за Workload-объектами — работает напрямую с потоком PodGroup.

API

Stale Controller Mitigation

KEP #5647 · Feature gate: StaleControllerConsistency.

Контроллеры в Kubernetes (например, kube-controller-manager) работают в reconciliation loop: следят за состоянием кластера, сравнивают желаемое с фактическим, синхронизируют. Они используют локальный кэш состояния, чтобы не перегружать API-сервер. Кэш обновляется через watch — это eventually consistent, то есть «когда-нибудь» изменения доедут. Задержка бывает от миллисекунд до минут.

В больших high-load кластерах проблема обостряется. Контроллер создаёт Pod, через секунду получает запрос reconcile того же объекта, но кэш ещё не обновился — контроллер «не видит» созданный под и пытается создать его снова или делает что-то ещё не то.

KEP-5647 вводит два изменения:

• В informer добавляется BookmarkFunc, единственная задача которого — уведомить слушателей, что произошло обновление. Вместе с обычными Add/Update/Delete это позволяет контроллеру знать, насколько свеж его кэш
• Улучшена логика контроллера. После успешной операции CREATE или UPDATE сохраняется новый resourceVersion объекта. Перед следующим reconcile контроллер проверяет, обработал ли informer resourceVersion как минимум такой же свежий. Если да — кэш актуален, можно продолжать. Если нет — reconcile пропускается, объект ставится обратно в очередь с exponential backoff

Graceful Leader Transition

KEP #5366 · Feature gate: GracefulLeaderTransition.

В high-availability кластерах несколько реплик ключевых control-plane-компонентов (kube-controller-manager, kube-scheduler) работают одновременно. Чтобы избежать конфликтов, используется leader election. Старый механизм при потере лидерства просто завершал процесс через os.Exit(), kubelet его рестартовал. Это съедало ресурсы, и компонент не мог gracefully завершить работу.

KEP-5366 вводит smarter способ передачи лидерства без полного рестарта:

• Рефакторинг кода контроллеров — чтобы все внутренние goroutines завершались чисто. Критично, чтобы не утекали ресурсы при частой смене ролей
• Улучшен release leader lease: вместо ожидания TTL, уходящий лидер активно освобождает lock при shutdown, ускоряя новые выборы. Управляется флагом ControllerManagerReleaseLeaderElectionLockOnExit
• Финальная стадия (флаг GracefulLeaderTransition) меняет core-логику компонента: при потере лидерства он не завершается через os.Exit(), а переходит в follower-состояние и пытается стать лидером снова

Server-side Sharded List and Watch

KEP #5866 · Feature gate: ShardedListAndWatch.

В Kubernetes контроллеры непрерывно мониторят состояние ресурсов (Pods, Services) через LIST и WATCH. С ростом кластеров эти операции тяжело масштабировать. Большинство контроллеров, как kube-controller-manager, масштабируются только вертикально — не умеют разделять watch-поток. Некоторые (kube-state-metrics) научились делать client-side sharding, но каждая реплика всё равно получает все события ресурса, десериализует всё, потом выбрасывает то, что не для её шарда. Лишняя сетевая нагрузка и CPU.

KEP-5866 переносит фильтрацию на API-сервер. Новый параметр shardSelector позволяет клиенту подписаться на конкретный шард данных — задаётся хэш-диапазон. Пример запроса:

			GET /api/v1/pods
  ?watch=true
  &shardSelector=shardRange(
      object.metadata.uid,
      '0x0000000000000000',
      '0x8000000000000000'
   )
		

API-сервер использует быстрый FNV-1a для хэша metadata.uid. Если хэш попадает в диапазон — событие уходит клиенту. Каждая реплика подписывается на свой диапазон и получает clean, non-overlapping поток.

Manifest Based Admission Control Config

KEP #5793 · Feature gate: ManifestBasedAdmissionControlConfig.

Чинит серьёзную startup-уязвимость в Kubernetes. Обычно все правила валидации запросов (admission webhooks — MutatingAdmissionWebhook, ValidatingAdmissionWebhook, access policies) — это API-объекты внутри кластера. Это даёт опасное окно: при старте API-сервера (или недоступности etcd) запросы могут обрабатываться до того, как правила загружены. Плюс любой пользователь с повышенными правами может — намеренно или случайно — удалить admission policies по сети.

KEP-5793 добавляет способ задавать security-политики через локальные манифест-файлы на диске control-plane-сервера. Эти файлы загружаются и применяются до того, как сервер начнёт слушать сеть. API-сервер непрерывно мониторит локальный каталог — при изменении файла правило немедленно подхватывается, валидируется и применяется без рестарта. Если валидация упала, сервер отклоняет новый манифест, логирует warning и возвращается к last-known-good конфигурации.

Apps

WAS: интеграция Workload API с Job controller

KEP #5547 · Feature gate: EnableWorkloadWithJob.

Job controller в Kubernetes отвечает за запуск джобов. Он создаёт поды, но нет гарантии, что они стартанут одновременно. Реальная проблема для распределённых нагрузок (AI/ML, MPI-задачи), где всё должно стартовать синхронно.

KEP-5547 расширяет Job controller нативной поддержкой gang scheduling (KEP-4671) через Workload и PodGroup API. Когда создаётся Job с нужными параметрами (для альфы это parallelism > 1, completionMode: Indexed, parallelism = completions), контроллер автоматически:

• Создаёт объект Workload с политикой scheduling для группы подов, указывая gang.minCount равным parallelism
• Создаёт объект PodGroup по шаблону из Workload
• При создании подов Job добавляет schedulingGroup.podGroupName в их спецификацию, связывая поды с соответствующей PodGroup

Scheduler видит, что поды — часть PodGroup, и ждёт возможности запустить все поды из minCount (минимум для старта workload) одним махом.

Storage

PVC — время последнего использования

KEP #5541 · Feature gate: PersistentVolumeClaimUnusedSinceTime.

Со временем в кластерах накапливаются PVC, которые больше не используются. Приложение удалили, мигрировали или просто остановили, а PVC остаётся — жрёт хранилище и деньги. Сейчас в Kubernetes нет простого способа посмотреть, когда PVC использовался в последний раз.

KEP-5541 добавляет поле UnusedSince в статус PVC (PersistentVolumeClaimStatus). PVC protection controller ставит туда metav1.Now при удалении или переходе в terminal state последнего пода, ссылающегося на PVC, и nil при появлении нового пода, начинающего ссылаться на этот PVC.

Various

HPA: масштабирование до/от нуля по object/external metrics

KEP #2021 · Feature gate: HPAScaleToZero.

Раньше Horizontal Pod Autoscaler не мог скейлить до нуля реплик. Он опирался на метрики активных подов — CPU, память — поэтому всегда требовался минимум один работающий под для сбора данных.

KEP вводит поддержку external и object metrics: HPA может принимать решения по внешним индикаторам (например, длина очереди сообщений). Если задач нет — число подов приложения скейлится до нуля, фактически глушит его. HPA записывает это в специальный status-поле ScaledToZero. Это предотвращает случайный scale-up приложения, которое админ вручную опустил до нуля через replicas: 0. Как только появляется задача (сообщение в очереди) — HPA поднимает первую реплику.

Native Histogram Support для метрик Kubernetes

KEP #5808 · Feature gate: NativeHistograms.

Гистограммы в Prometheus сейчас работают через предопределённые buckets. Разработчик заранее задаёт диапазоны значений. Например, для latency: до 10 мс, до 50 мс, до 100 мс, до 500 мс. Если запрос занял 49 мс — инкрементится «до 50 мс». У этого два недостатка:

• Неоднозначность — невозможно узнать точное распределение внутри bucket (все запросы на 11 мс или все на 49 мс? Эта информация теряется)
• Избыточность — передаются данные для всех bucket'ов, даже если туда ничего не попало. Жрёт ресурсы и диск

Prometheus v2.40 ввёл Native Histograms (стали stable в v3.8.0) с умными auto-adjusting экспоненциальными buckets. KEP-5808 интегрирует Prometheus Native Histograms в метрики компонентов Kubernetes.

Обработка незашифровываемых ресурсов

KEP #3926 · Feature gate: AllowUnsafeMalformedObjectDeletion.

Шифрование API-ресурсов at-rest давно используется в Kubernetes. Иногда оно ломается из-за внешних сбоев или неверной настройки. Если один объект определённого типа не расшифровывается, то list этого типа в префиксе, содержащем объект, всегда падает — даже если остальные объекты читаются. Поломанный объект нельзя удалить через Kubernetes API, админ должен лезть в etcd вручную.

KEP-3926 предлагает метод идентификации ресурсов, которые не расшифровываются или не декодируются в объект, и вводит новый DeleteOption — IgnoreStoreReadErrorWithClusterBreakingPotential, разрешающий удалить ресурс, даже если его данные не читаются.

Non-alpha highlights релиза 1.36 — выбор Дмитрия Шурупова

Статья намеренно фокусируется на alpha-фичах, чтобы показать, куда движется разработка. Но каждый релиз содержит много других обновлений — это alpha, введённые раньше, или фичи, сейчас находящиеся в beta/stable. Самые заметные, по мнению Дмитрия Шурупова (сооснователя Palark, CNCF Ambassador):

• Device taints и tolerations в DRA (KEP 5055) и DRA support for partitionable devices (KEP 4815) — Beta. Включены по умолчанию
• OCI VolumeSource (KEP 4639) — Stable. Новый VolumeSource (появился в 1.31), поддерживает OCI-образы: хранение файлов и расшаривание между контейнерами в поде без включения в основной образ
• User namespaces в Pods (KEP 127) — Stable. Стартовал в alpha в 1.25 (август 2022), через 3,5 года наконец GA
• Mutating Admission Policies (KEP 3962) — Stable. Расширяет mutating admission webhooks через CEL-выражения
• Accelerated recursive SELinux label change (KEP 1710) — Stable. В beta с 1.27 (апрель 2023)
• gitRepo volume plugin (KEP 5040) — удалён. Критическая security-проблема: выполнение кода как root на ноде

Часть alpha-фич из 1.35 и более ранних релизов (gang scheduling, user namespaces в HostNetwork-подах) значительно доработана, но осталась в альфе.

Это не полный список изменений — полную информацию можно посмотреть в official enhancements tracker и changelog.

Заключение

Релиз Kubernetes 1.36 существенно расширяет инструментарий оркестратора, фокусируясь на производительности, безопасности и удобстве использования. Интегрируя gang scheduling и продвинутое управление ресурсами, Kubernetes всё лучше подходит для современных распределённых нагрузок и больших кластеров, одновременно оптимизируя ядро своих API.

Спасибо всем разработчикам и авторам KEP, сделавшим Kubernetes 1.36 возможным. Вы потрясающе сработали.

Кирилл Кононовичtechnical writer, Palark

Интересуют другие alpha-фичи, недавно добавленные в Kubernetes? Читайте deep-dives по Kubernetes 1.35 (декабрь 2025) и Kubernetes 1.34 (август 2025).

Оригинал статьи: palark.com/blog/kubernetes-1-36-release-features/. Перевод публикуется с сохранением оригинальной структуры и всех технических деталей.