Kubernetes 1.31: полный разбор изменений и руководство по успешному обновлению

Выпуск Kubernetes 1.31 под кодовым именем Elli — это стратегический поворот платформы. Команда разработчиков сделала ставку на зрелость и стабильность, а не на эффектные нововведения. Основной фокус сместился с добавления функций на удаление технического долга — то есть накопленных в коде проблем, которые могут замедлить развитие проекта. Такой подход принес свои плоды, но и создал определенные риски при обновлении.

Каждая новая версия Kubernetes теперь требует тщательного удаления устаревших компонентов. Пропустите несколько релизов — и ваш кластер может не пережить апгрейд.

Стратегия развития: почему Kubernetes стал удалять больше, чем добавлять

Kubernetes вошёл в фазу зрелости. Новые функции появляются реже, чем исчезают старые. Анализ истории релизов показывает чёткий тренд. Если в 2020-2022 годах основной объем изменений составляли новые функции, то сейчас до 60% посвящено рефакторингу и удалению устаревшего кода.

Это естественный этап эволюции платформы. Разработчики стремятся уменьшить сложность кодовой базы и убрать компоненты, мешающие развитию.

Для пользователей это означает одно — процесс обновления становится более рискованным. Пропустив два-три релиза, можно столкнуться с ситуацией, когда критические компоненты инфраструктуры перестанут работать после апгрейда.

Внешние облачные провайдеры: завершение пятилетней миграции

Самое значительное изменение в Kubernetes 1.31 — окончательное удаление встроенных облачных провайдеров. Этот процесс начался еще в 2019 году и теперь завершён.

Из кодовой базы Kubernetes удалили код для интеграции с AWS, Azure, Google Cloud, OpenStack и VMware vSphere. Теперь эти провайдеры работают исключительно как внешние компоненты.

Как проверить готовность кластера к миграции

Запустите команду для проверки текущего cloud-controller-manager:

			bash
kubectl get pods -n kube-system | grep cloud-controller
		

Если вывод пустой или содержит только компоненты с префиксом external, ваш кластер уже готов к обновлению.

Если видите компоненты с названиями вроде aws-cloud-controller-manager в составе kube-controller-manager — требуется миграция.

Практические последствия для разных сценариев развертывания

Для managed-сервисов (EKS, AKS, GKE) изменение пройдёт незаметно. Провайдеры уже завершили миграцию.

Для кастомных кластеров потребуется установить внешний cloud-controller-manager. Например, для AWS используйте проект cloud-provider-aws.

Наибольшему риску подвержены локальные кластеры, использующие OpenStack или vSphere. Им требуется установка соответствующих внешних провайдеров до начала обновления.

Хранилище данных: стабильность вместо экспериментов

Версия 1.31 принесла несколько важных изменений в системе работы с постоянными томами. Эти улучшения касаются как базовых механизмов работы, так и возможностей по тонкой настройке томов.

Гарантированное соблюдение политик Reclaim Policy

Политика возврата томов (Reclaim Policy) теперь работает предсказуемо. Раньше существовал неприятный баг — при удалении PersistentVolume до PersistentVolumeClaim внешний ресурс в системе хранения мог не удалиться, даже при установленной политике Delete.

В Kubernetes 1.31 механизм получил финализаторы, которые гарантируют выполнение политики независимо от порядка удаления ресурсов.

Новые возможности управления производительностью томов

VolumeAttributesClass — новый API-объект для управления параметрами производительности томов (IOPS, пропускная способность) без пересоздания самого тома.

			yaml
apiVersion: storage.k8s.io/v1
kind: VolumeAttributesClass
metadata:
  name: high-iops
parameters:
  iops: "5000"
  throughput: "250"

		

Проверьте работу этой функции в вашем CSI-драйвере. Без поддержки со стороны драйвера использование VolumeAttributesClass будет бесполезным.

Окончательный переход на CSI-драйверы для Ceph

Плагины CephFS и RBD окончательно удалены из кодовой базы Kubernetes. Попытка использовать том с типом cephfs или rbd теперь завершится ошибкой. Миграция на CSI-драйвер — единственный вариант. Процесс требует тщательного планирования, особенно для production-нагрузки.

Поэтапный план миграции с in-tree Ceph на CSI

Переход со встроенных плагинов CephFS и RBD на CSI-драйверы требует последовательного подхода. Неправильная миграция приведет к потере доступа к томам после обновления до Kubernetes 1.31.

Как перейти безопасно:

1. Разверните CSI-драйвер в параллельном режиме и убедитесь в его корректной работе с вашими томами.
2. Перенесите данные со старых томов на новые через CSI с использованием инструментов Velero или кастомных скриптов миграции.
3. Обновите манифесты приложений с указанием новых PVC после успешного переноса данных.

Полное завершение миграции на CSI-тома — обязательное условие перед обновлением до Kubernetes 1.31. Проверьте отсутствие обращений к старым томам через CephFS или RBD во всех пространствах имен кластера.

Сетевой стек: замена фундамента

Сетевые возможности Kubernetes постоянно эволюционируют. В версии 1.31 несколько ключевых улучшений сетевого стека перешли в бета-статус, что указывает на их скорый выход в стабильную версию.

nftables как будущая замена iptables

Бэкенд nftables для kube-proxy теперь включен по умолчанию в бета-версии. Это важный шаг в эволюции сетевого проксирования в Kubernetes.

nftables предлагает лучшую производительность на больших кластерах. Тесты показывают уменьшение времени обработки правил на 15-20% при количестве сервисов более 5000.

Проверка совместимости CNI-плагинов

Перед переходом на nftables убедитесь в совместимости вашего CNI-плагина. Некоторые плагины, особенно те, что активно манипулируют iptables, могут конфликтовать с nftables.

Проведите тестирование в staging-среде. Создайте нагрузку, имитирующую работу production-сервисов, и понаблюдайте за стабильностью сетевых соединений.

Улучшенная надежность Ingress-контроллеров

Функция Improved Ingress Connectivity Reliability перешла в стабильный статус. Она решает давнюю проблему — обрыв соединений при масштабировании нод.

Kube-proxy теперь корректно дренирует соединения для нод в состоянии Terminating. Это особенно важно для stateful-нагрузки, где разрыв соединений может привести к потере данных.

Требования для работы функции

Функция требует поддержки со стороны облачного балансировщика нагрузки. Балансировщик должен уметь использовать эндпоинт /livez kube-proxy, чтобы определять готовность ноды принимать новый трафик.

Проверьте документацию вашего облачного провайдера на предмет поддержки этой функции.

Безопасность: от эксперимента к production-готовности

Система безопасности Kubernetes продолжает развиваться. В версии 1.31 несколько ключевых функций безопасности достигли зрелости и готовы к использованию в production-среде.

AppArmor: переход к стабильному API

Поддержка AppArmor вышла из беты. Теперь это полноценная функция безопасности, готовая к использованию в production.

Важное изменение — переход с аннотаций на нативный API. Старый способ задания профилей через аннотации устарел и будет удален в будущих версиях.

Пример миграции на новый API

Старый подход через аннотации:

			yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/main: localhost/foo
		

Новый подход через securityContext:

			yaml
apiVersion: v1
kind: Pod
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: foo
		

Миграция на новый API обязательна для долгосрочной поддержки.

Контроль анонимного доступа к API

С новой альфа-функцией можно точно указать, к каким эндпоинтам API возможен анонимный доступ. Раньше анонимная аутентификация была либо включена для всех эндпоинтов, либо отключена полностью.

Теперь можно разрешить анонимный доступ только к health-эндпоинтам (/healthz, /readyz, /livez), сохраняя требование аутентификации для всех остальных операций.

Пример конфигурации

			yaml
apiVersion: apiserver.config.k8s.io/v1alpha1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: "/healthz"
  - path: "/readyz" 
  - path: "/livez"
		

Эта функция особенно полезна для кластеров, в которых требуется балансировка нагрузки без полного отключения анонимного доступа.

Узлы и планировщик: тонкая настройка производительности

Работа с вычислительными ресурсами продолжает совершенствоваться. Kubernetes 1.31 приносит улучшения в управлении ресурсами и планировании workload'ов.

cgroup v2: подготовка к переходу

Поддержка cgroup v1 переведена в режим maintenance. Это означает, что новые функции для cgroup v1 добавляться не будут, а баги будут устраняться по остаточному принципу.

Индустрия активно переходит на cgroup v2. Все основные дистрибутивы Linux уже поддерживают его по умолчанию.

Проверка готовности приложений к cgroup v2

Запустите тестовый под с ограничениями ресурсов в среде с cgroup v2. Убедитесь, что:

• приложения корректно читают свои ограничения;
• мониторинг и логирование продолжают работать;
• метрики приложений (Prometheus) отображают корректные данные.

Особое внимание уделите legacy-приложениям, способным делать прямые системные вызовы для работы с cgroup.

Мониторинг здоровья устройств

Новая альфа-функция позволяет отслеживать состояние hardware-устройств (GPU, FPGA) через статус пода. Раньше при сбое устройства под мог бесконечно перезапускаться без понятной причины.

Теперь информация о состоянии устройства доступна в kubectl describe pod:

			bash
kubectl describe pod gpu-pod

		

В выводе команды появится секция с информацией о здоровье устройств.

CLI и инструментарий: взаимодействие с разработчиками улучшено

Инструменты командной строки продолжают развиваться, становясь более удобными и мощными.

Переход с SPDY на WebSockets

Бэкенд для kubectl exec, kubectl attach и kubectl port-forward теперь использует WebSockets вместо устаревшего протокола SPDY. Это улучшает производительность и надежность интерактивных сессий.

Изменение обратно совместимо — kubectl автоматически откатывается на SPDY при работе со старыми версиями API-сервера.

			yaml
apiVersion: kubectl.debug.v1
kind: DebugProfile
metadata:
  name: custom-debug
spec:
  containers:
  - name: debug-container
    image: busybox
    command: ["sh"]
    securityContext:
      runAsUser: 1000
		

Подход делает отладку в production-среде более безопасной и контролируемой.

Матрица совместимости: практическое руководство по проверке

Перед обновлением до Kubernetes 1.31 выполните следующие проверки.

Облачная инфраструктура:

• убедитесь, что используете внешние cloud-controller-manager;
• проверьте миграцию всех StorageClass на внешние модули подготовки;
• обновите конфигурации LoadBalancer-сервисов при необходимости.

Хранилище данных:

• завершите миграцию с CephFS/RBD in-tree на CSI-драйверы;
• протестируйте работу VolumeAttributesClass с вашим CSI-драйвером;
• убедитесь, что Reclaim Policy работает ожидаемо в тестовой среде.

Сеть:

• проверьте совместимость CNI-плагина с nftables;
• протестируйте дренирование соединений при масштабировании нод;
• обновите конфигурации NetworkPolicy при необходимости.

Безопасность:

• перенесите AppArmor-профили с аннотаций на securityContext;
• настройте политики анонимного доступа к API;
• проверьте работу PodSecurity-стандартов.

Приложения:

• протестируйте работу приложений под cgroup v2;
• проверьте мониторинг и логирование в новой версии;
• убедитесь, что инструменты оркестрации (Helm, Kustomize) совместимы

Процесс обновления: пошаговый план

Обновление production-кластера требует методичного подхода. Разделение процесса на этапы снижает риски и помогает выявить проблемы до их попадания в рабочую среду.

Подготовка (за 2-4 недели до обновления):

• начните с создания полного бэкапа кластера;
• разверните тестовый кластер версии 1.31;
• перенесите туда копии production-нагрузки.

Тестирование (1-2 недели):

• проверьте работу всех критичных сервисов;
• убедитесь в корректности мониторинга и системы оповещений;
• протестируйте процедуры аварийного восстановления.

Обновление staging-среды:

• обновите staging-кластер первым;
• наблюдайте за его работой в течение нескольких дней;
• исправьте обнаруженные проблемы.

Production-обновление:

• выполните обновление в запланированное техническое окно;
• заранее подготовьте план отката;
• мониторьте ключевые метрики в течение 24 часов после обновления.

Поэтапный подход позволяет контролировать риски на каждом этапе миграции.

Потенциальные риски и способы их минимизации

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

Несовместимость сетевых плагинов

Сетевые плагины представляют наибольшую опасность. Переход на nftables-бэкенд в kube-proxy может нарушить работу некоторых CNI-решений.

Выполните следующие проверки для минимизации рисков:

• проверьте совместимость вашего CNI-плагина с nftables в тестовой среде;
• подготовьте временное переключение на iptables-бэкенд через флаг --proxy-mode=iptables;
• протестируйте работу NetworkPolicy и сервисов типа NodePort под нагрузкой;
• сверьтесь с документацией поставщика CNI-плагина о поддержке nftables.

Проблемы с системой хранения

Изменения в работе с томами требуют особого внимания. Удаление встроенных плагинов Ceph и новые политики удаления могут затронуть критичные данные.

Чтобы обеспечить безопасность данных:

• убедитесь в работоспособности процедур восстановления из резервных копий;
• проведите тестовое восстановление томов в изолированной среде;
• завершите миграцию с CephFS/RBD на CSI-драйверы до начала обновления;
• проверьте работу VolumeAttributesClass с вашим провайдером хранилищ.

Изменения в политиках безопасности

Новые механизмы безопасности могут заблокировать рабочие процессы. Переход AppArmor на стабильный API и новые настройки анонимного доступа требуют адаптации.

Поэтапно вводите изменения в систему безопасности:

• внедряйте новые security-политики, начиная с тестовых окружений;
• перемещайте AppArmor-профили с аннотаций на поле securityContext.appArmorProfile;
• настройте политики анонимного доступа к API до обновления production-кластера;
• протестируйте работу сервисных аккаунтов и RBAC-правил в новой версии.

Дополнительные области внимания

Менее очевидные, но важные аспекты тоже требуют проверки. Совместимость инструментов мониторинга может нарушиться из-за изменения в метриках. Обновление утилит командной строки иногда приводит к смене форматов вывода.

Обратите внимание на следующие моменты:

• проверьте работу систем мониторинга после обновления тестового кластера;
• протестируйте совместимость Helm-чартов и инструментов развертывания;
• обновите утилиты kubectl и kubeadm на рабочих станциях администраторов;
• убедитесь в корректности работы пользовательских ресурсов (CRD).

Тщательная подготовка к каждому типу рисков повышает шансы на успешное обновление. Регулярное тестирование в условиях, приближенных к production, помогает выявить проблемы до их попадания в рабочую среду.

Итоги: стратегия обновления для enterprise-кластеров

Kubernetes 1.31 — релиз, требующий тщательной подготовки. Основное внимание уделяйте не новым функциям, а удалению старых.

Для крупных production-кластеров стоит увеличить срок тестирования — не менее 2-3 недель проверок в staging-среде. Не пытайтесь обновить кластер в авральном режиме. Разбейте процесс на этапы, каждый из которых должен иметь четкие критерии успеха.

Помните — в Kubernetes 1.31 изменились фундаментальные вещи, которые годами считались стабильными. Отнеситесь к обновлению ответственно, и ваш кластер получит все преимущества новой версии без потери стабильности.