Готовимся к Kubernetes 1.26: проверяем deprecation API через pluto и составляем план обновления

Kubernetes 1.26 ещё в RC, GA ждём в декабре, но у нас несколько клиентских кластеров на 1.24 и 1.25 - и было бы неплохо не повторить историю с PSP. Тогда мы разбирали миграцию с PodSecurityPolicy уже после выхода 1.25, в том числе в авральном режиме. Решили на этот раз пройтись по манифестам заранее - с помощью pluto.

Что убирают в 1.26

Список deprecation в 1.26 короче, чем в 1.25 (там вместе с PSP убрали целый пласт), но есть позиции, которые реально присутствуют в живых кластерах.

HorizontalPodAutoscaler v2beta2 - переходит только на autoscaling/v2, который стабилен с 1.23. Казалось бы, достаточно времени для миграции. Тем не менее у нескольких клиентов HPA описаны в Helm-чартах со старым apiVersion, и чарты не обновлялись с 2021 года.

FlowSchema и PriorityLevelConfiguration v1beta1 - API priority and fairness, v1beta1 уходит. Если не используете APF явно, скорее всего не задеты. Но если в GitOps-репозитории есть кастомные FlowSchema - надо смотреть.

CSIStorageCapacity v1beta1 - аналогично, stable API есть начиная с 1.24.

Batch/v1beta1 CronJob - это уже убрали в 1.25, но у одного клиента нашли в чарте старый apiVersion, который просто молча игнорировался, потому что объект был создан раньше. При пересоздании упало бы.

Pluto: что за зверь и зачем

Pluto - утилита от Fairwinds, заточенная именно под поиск deprecated и removed Kubernetes API в манифестах, Helm-чартах и live-кластерах. Альтернатива - kubectl deprecations плагин (не встроен), или ручная grep-охота по YAML. Pluto удобнее: он знает таблицу всех deprecated/removed API по версиям Kubernetes и умеет сравнивать с целевой версией.

Установка банальная - бинарник с GitHub releases или через brew. Для закрытого контура скачиваем заранее.

Три режима работы:

• pluto detect-files -d ./ - сканирует локальные манифесты рекурсивно.
• pluto detect-helm -owide - смотрит в установленные Helm-релизы через helm list (нужен доступ к кластеру).
• pluto detect-all-in-cluster - идёт напрямую через kube API и ищет объекты с deprecated apiVersion.

Флаг --target-versions k8s=v1.26.0 указывает, с чем сравниваем. По умолчанию pluto ориентируется на последнюю известную ему версию, но лучше задавать явно.

Что нашли

Запускали против GitOps-репозиториев клиентов (у нас flux, манифесты в git) и против Helm-релизов в кластере. Результаты были предсказуемы, но приятно получить их списком, а не выяснять руками.

Первое - HPA в двух клиентских чартах. autoscaling/v2beta2 в values и template. Чарт - open source, взят три-четыре версии назад. Апстрим уже исправил, нужно просто обновить. Запланировали на следующий maintenance-window.

Второе - CronJob v1beta1 в одном legacy-приложении. Клиент давно перестал его трогать, манифест живёт в git с 2020 года. Объект в кластере создан ещё в 1.20 через старый apiVersion, работает, но при любом пересоздании (например, при обновлении кластера с drained nodes) упадёт. Нужна ручная правка манифеста и пересоздание.

Третье - FlowSchema v1beta1. Нашли у одного клиента, который настраивал APF для ограничения нагрузки от CI. Апгрейд до v1beta2 несложный, схема совместима - просто правим apiVersion.

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

Containerd 1.6 и CRI

Второй блок изменений в 1.26 - CRI. Kubernetes окончательно обозначил containerd 1.6 как рекомендуемую версию, поддержка containerd 1.5 уходит. У большинства клиентов уже 1.6 - это был стандарт с начала 2022 года. Но на двух старых кластерах (поднятых в 2021) обнаружили 1.5.x. Обновление containerd в работающем кластере - аккуратная операция: rolling drain, обновление пакета, старт, проверка что crictl info отдаёт нормальный статус, undrain. Ничего страшного, но надо делать последовательно по узлам.

CRI-O тоже поддерживается, но у нас в продакшне только containerd - проще поддерживать один стек.

Про managed-сопровождение и план обновления

По итогу получили рабочий список: какие кластеры затронуты, что именно надо поправить, в каком порядке. Часть задач (обновление чартов) можно закрыть не дожидаясь 1.26 - это просто техдолг. Часть (containerd, legacy-манифесты) требует координации с клиентом по окну обслуживания.

Pluto занял час работы суммарно на все кластеры. Ручная проверка того же объёма заняла бы день и всё равно оставила бы риск что-то пропустить. Инструмент нехитрый, но именно такой и нужен.

GA 1.26 ждём в декабре - к тому времени бэклог по deprecated API должен быть закрыт.