Kubernetes 1.36 вышел с 70 улучшениями, и это тот случай, когда список изменений важнее маркетингового имени Haru. Для команд, которые живут в кластерах каждый день, релиз означает три вполне приземлённые вещи: безопасность по умолчанию стала жёстче, API лучше готовят к большим масштабам, а поддержка AI-нагрузок наконец догоняет реальность продакшена.
Новая версия, как пишет InfoQ, стала первым крупным релизом Kubernetes в 2026 году: 18 функций перешли в статус Stable, 25 добрались до Beta и ещё 25 появились в Alpha. Над выпуском работали участники из 106 компаний и 491 индивидуальный контрибьютор. Сам фокус релиза читается без подсказок: меньше исторически сложившихся компромиссов в безопасности, больше встроенных механизмов вместо самодельной обвязки и более внятная модель работы с ускорителями, GPU и распределённым обучением.
Самая заметная история в части security — выход User Namespaces в General Availability. Идея не новая, но теперь она считается зрелой: root внутри контейнера маппится на непривилегированного пользователя на хосте. Проще говоря, если процесс сумел выбраться из контейнера, это уже не автоматический билет к административному доступу на ноде. Для платформенных команд это не косметическая настройка, а шаг к снижению ущерба от целого класса контейнерных инцидентов. В тот же стабильный статус вышли Fine-Grained Kubelet API Authorization, которые позволяют точнее ограничивать доступ к HTTPS API kubelet. Раньше observability- и monitoring-инструменты нередко получали слишком широкое разрешение через nodes/proxy; теперь Kubernetes предлагает более адекватную модель least privilege, чего от него вообще-то ждали давно.
Вторая важная часть релиза — отказ от лишней внешней механики там, где можно обойтись нативными средствами. В GA перешли Mutating Admission Policies: команды могут описывать mutation-логику как объект Kubernetes с использованием CEL, не поднимая отдельный webhook-сервер. Выигрыш тут не только в аккуратности архитектуры. Это меньше операционной возни, меньше точек отказа и меньше задержек на admission-цепочке. Для платформ, где накопилось много кастомных webhook’ов ради сравнительно простых правил, это хороший повод пересмотреть старые решения. Ещё один практический апгрейд в stable — SELinux Volume Labeling. Вместо рекурсивной перемаркировки файлов система может проставлять корректную SELinux-метку всему тому при монтировании через mount context. Для сред с принудительным SELinux это означает более быстрый старт подов и меньше неприятных сюрпризов на storage-операциях.
В GA также перешли declarative validation через validation-gen, Volume Group Snapshots для консистентных снимков сразу нескольких PersistentVolumeClaim и два механизма из мира Dynamic Resource Allocation — DRA admin access и prioritized lists. На бумаге это выглядит как набор разрозненных улучшений, но вместе они показывают вектор проекта: Kubernetes всё чаще забирает в ядро то, что раньше приходилось собирать из расширений, плагинов и аккуратно поддерживаемых соглашений между командами. Для бизнеса это обычно хорошая новость: меньше самописной платформенной магии, меньше стоимость сопровождения, выше предсказуемость апгрейдов. Для инженеров, правда, есть и обратная сторона: новые «дефолты» постепенно становятся обязательной программой, а не экзотикой для энтузиастов.
Что изменилось для AI-нагрузок
Если смотреть на Kubernetes 1.36 через призму AI и ML, релиз выглядит не как парад новых игрушек, а как попытка догнать накопившиеся боли реальных кластеров. Несколько улучшений DRA дошли до Beta и включены по умолчанию: DRA Partitionable Devices, DRA Consumable Capacity и DRA Device Taints and Tolerations. Это важный разворот от старой модели «одна GPU как один неделимый целый объект» к более реалистичному описанию ускорителей, которые можно делить, шарить и переиспользовать с учётом их фактического состояния. Для команд, строящих очереди на обучение моделей или inference-сервисы на дорогом железе, разница вполне денежная: меньше простой мощности, меньше ручной логики в scheduler-обвязке и меньше vendor-specific конструкций, которые трудно оптимизировать на уровне кластера.
Самая интересная новая Alpha-функция здесь — Workload-Aware Preemption. До сих пор планировщик мог вытеснить отдельные поды ради задачи с более высоким приоритетом, но для распределённого обучения это нередко превращалось в странную полумеру: семь ранков живы, восьмой выбит, работа не движется, ресурсы заняты. Новый подход рассматривает PodGroup как единую единицу вытеснения и сначала проверяет, поместится ли высокоприоритетная группа целиком. Это попытка закрыть очень конкретный сбойный сценарий, знакомый всем, кто запускал крупные GPU-задачи в общем кластере. Одновременно Gang Scheduling API, появившийся как alpha в 1.35, перешёл в Beta, а Mutable Pod Resources for Suspended Jobs тоже дошёл до Beta и включён по умолчанию. Последний механизм позволяет приостановить задачу, изменить её запросы по CPU, памяти, GPU или extended resources и вернуть в работу без пересоздания подов. Для систем очередей и batch-планировщиков это выглядит как давно просившийся инструмент, а не как очередная «фича для галочки».
Масштаб, апгрейды и неприятные прощания
В крупных инсталляциях Kubernetes 1.36 адресует и менее заметную, но очень дорогую проблему — узкие места в API-наблюдении. В Alpha появился механизм sharded list and watch streams: вместо одного потока обновлений на тип ресурса нагрузка может распределяться по нескольким потокам. Для очень больших кластеров, где за одними и теми же ресурсами следят многие контроллеры, это не академическое упражнение, а вопрос предсказуемости control plane. Параллельно Memory QoS via cgroup v2 добралась до Beta и обещает более аккуратную защиту памяти в соответствии с requests и limits, а In-Place Vertical Scaling for Pod-Level Resources перешла в Beta и включена по умолчанию. Под теперь можно расширять по CPU и памяти без перезапуска контейнера; если ресурсов на ноде сейчас не хватает, новый тип события ResizeDeferred позволяет не ломать приложение и дождаться повторной попытки со стороны kubelet.
Но любой релиз Kubernetes — это не только новые возможности, но и расставание с накопленным техдолгом. В 1.36 окончательно удалён volume-плагин gitRepo, давно признанный небезопасным: он позволял запускать код от root на ноде, поэтому тем, кто ещё держался за старую схему доставки содержимого из Git, придётся переходить на init containers или внешние git-sync-инструменты. Из релиза также исчезает режим IPVS в kube-proxy, удаляется поддержка flex-volume в kubeadm и in-tree драйвер Portworx. Отдельно в release-коммуникациях подсвечена ещё одна дата, которую платформенным командам лучше не пропустить: проект Ingress NGINX был выведен из эксплуатации 24 марта 2026 года, и с этого момента для него больше не выходят релизы, багфиксы и патчи безопасности. То есть апгрейд кластера теперь всё чаще превращается не в «подняли версию и пошли дальше», а в полноценную ревизию зависимостей, сетевого слоя и собственных платформенных привычек.
Главный вывод из этого релиза довольно жёсткий: Kubernetes всё меньше похож на конструктор, где любую дыру можно закрыть сторонним контроллером или историческим workaround’ом. Проект всё настойчивее навязывает более строгие правила игры в безопасности и распределении ресурсов. Для одних команд это снижение хаоса и меньше ручной инженерии. Для других — сигнал, что эпоха «как-нибудь переживём ещё один релиз на старых допущениях» заканчивается быстрее, чем хотелось бы.