Kubernetes v1.36: грядущие изменения, удаления API и подготовка к релизу

Релиз Kubernetes v1.36 запланирован на конец апреля 2026 года и обещает стать одним из самых насыщенных по количеству улучшений. Однако вместе с новыми возможностями придут и важные удаления API, к которым стоит подготовиться заранее. Разработчики проекта уже опубликовали предварительный список изменений, основанный на текущем состоянии разработки. Хотя до финального релиза детали могут корректироваться, общее направление понятно: команда Kubernetes продолжает чистить устаревшие API и внедрять новые механизмы, повышающие стабильность и безопасность платформы.

Что удалят и объявят устаревшим в Kubernetes 1.36

Kubernetes v1.36 продолжает следовать документированной политике депрекации и удаления API. Стабильные (GA) версии API могут быть помечены как устаревшие, но не могут быть удалены в рамках одной мажорной версии. Бета-версии API обязаны поддерживаться как минимум три релиза после объявления депрекации, а альфа-версии могут быть удалены в любом релизе без предупреждения. В этом цикле разработчики сосредоточились на удалении нескольких давно устаревших API, которые уже имеют стабильные замены. Конкретный список удаляемых ресурсов пока не опубликован, но ожидается, что он будет включать несколько бета-версий, перешедших в GA несколько релизов назад. Администраторам кластеров рекомендуется заранее проверить свои манифесты и Helm-чарты на предмет использования устаревших версий API.

Какие API точно будут удалены в v1.36?

На момент написания статьи точный перечень ещё не оглашён, но можно с высокой вероятностью предположить, что под нож пойдут batch/v1beta1 для CronJob и policy/v1beta1 для PodSecurityPolicy. Первый уже давно заменён стабильным batch/v1, второй — встроенными механизмами безопасности, появившимися в более ранних версиях. Разработчикам стоит проверить свои манифесты на наличие этих версий и обновить их до стабильных. Если вы используете kubectl convert или инструменты вроде pluto, процесс миграции будет простым. Главное — не откладывать, так как после выхода v1.36 устаревшие API перестанут работать.

Предыстория и контекст: как Kubernetes чистит API

Политика депрекации API в Kubernetes не нова — она действует с первых стабильных версий. Её цель — дать сообществу время на миграцию, сохраняя обратную совместимость в разумных пределах. Например, несколько лет назад были удалены API версий extensions/v1beta1 для Ingress и apps/v1beta1 для Deployment. Каждый раз процесс сопровождается подробным руководством по миграции. В v1.36 эта практика продолжается: удаляются API, которые уже давно имеют стабильные альтернативы. Важно отметить, что не только API могут быть удалены: в марте 2026 года SIG-Security объявила о прекращении поддержки проекта ingress-nginx, рекомендовав сообществу переходить на альтернативные ingress-контроллеры, соответствующие современным требованиям безопасности. Это показывает, что процесс очистки затрагивает не только код, но и целые компоненты экосистемы.

Технические подробности: что изменится в работе с API

Kubernetes v1.36 не только удаляет, но и добавляет новые возможности. Хотя полный список enhancement-ов пока не раскрыт, разработчики обещают «впечатляющее количество улучшений». Среди ожидаемых нововведений — доработки в области безопасности, улучшения работы с сетевыми политиками и повышение производительности etcd. Также ожидается, что будут внесены изменения в механизмы аутентификации и авторизации, в частности, касающиеся сервисных аккаунтов и токенов. Для администраторов кластеров важно будет обновить инструменты управления, такие как kubeadm, и проверить совместимость с новыми версиями API.

Кого затронут изменения в Kubernetes v1.36

Изменения затронут все группы пользователей Kubernetes. Разработчикам приложений, которые используют устаревшие API в своих манифестах, придётся обновить их до стабильных версий. Администраторам кластеров нужно будет обновить конфигурации и, возможно, пересмотреть политики безопасности. Особое внимание стоит уделить тем, кто использует ingress-nginx: после объявления о прекращении поддержки проекта сообществу рекомендовано перейти на альтернативы, такие как ingress-nginx от NGINX, Contour, Traefik или Envoy-based решения. В российском сегменте также популярны решения на базе Kong или собственные разработки. Рекомендуется заранее протестировать миграцию на стендах.

Как проверить, какие API используются в вашем кластере?

Для аудита можно использовать встроенные средства Kubernetes: команда kubectl api-resources --verbs=list -o name покажет все доступные ресурсы, а kubectl get --raw /openapi/v2 — полную схему OpenAPI. Более удобный способ — применить утилиту pluto, которая сканирует манифесты и выявляет устаревшие версии. Также полезно регулярно запускать kubectl deprecations (если доступно) или отслеживать предупреждения в логах kube-apiserver. Не забывайте проверять Helm-чарты: они могут содержать жёстко закодированные версии API, которые потребуют обновления.

Что будет дальше: как подготовиться к v1.36

До выхода релиза остаётся около месяца. Разработчикам и администраторам стоит уже сейчас начать аудит своих кластеров на предмет использования устаревших API. Инструменты вроде kubectl deprecations или pluto помогут выявить проблемные места. Также рекомендуется следить за официальным блогом Kubernetes, где в ближайшие недели появится полный список изменений. После выхода v1.36 стоит обновить кластеры в тестовой среде, чтобы убедиться в совместимости. Игнорирование депрекаций может привести к тому, что после обновления некоторые ресурсы перестанут работать.

Итог

Kubernetes v1.36 — важный релиз, который продолжает политику очистки API и внедрения новых возможностей. Главное, что нужно сделать прямо сейчас — проверить свои манифесты на наличие устаревших версий API и подготовиться к миграции. Следите за обновлениями в официальном блоге, чтобы не пропустить детальные инструкции по обновлению.