Kubernetes 1.26 в продакшне: CRI API стабилен, PSA вместо PSP - перестраиваемся под новую модель

В декабре прогнали апгрейд до 1.26 на dev/staging и зафиксировали первые наблюдения. Сейчас, в феврале, уже несколько продакшн-кластеров на 1.26, и картина стала полнее. Не потому что появились новые проблемы - а потому что в проде вылезло то, что на стейджинге было незаметно.

Если коротко: 1.26 - это не просто очередной инкрементальный релиз. Два изменения вместе дают архитектурный сдвиг в том, как устроена безопасность и взаимодействие с контейнерным рантаймом. И у нас появился повод переосмыслить несколько вещей в стандартном чеклисте обновления.

Стабильный CRI API: что это меняет на практике

Container Runtime Interface вышел в статус stable (v1) ещё в 1.24, но в 1.26 это проявилось практически: v1alpha2 полностью убран. Если containerd на нодах старше 1.6.0 - он не умеет говорить по CRI v1, и kubelet просто откажется стартовать после обновления.

На наших кластерах с этим столкнулись на одном продакшн-узле, где containerd 1.5.x сохранился после предыдущего цикла обновлений. Нода ушла в NotReady сразу после перезапуска kubelet, поды сэвакуировались на соседние - штатно, но нервно.

Теперь перед апгрейдом control plane добавили в чеклист жёсткую проверку:

• kubectl get nodes -o custom-columns с полем .status.nodeInfo.containerRuntimeVersion по всем нодам. Если видим containerd://1.5 - сначала containerd, потом k8s.
• crictl version непосредственно на ноде** - убедиться что containerd отвечает по /run/containerd/containerd.sock нужной версией.
• Конфиг /etc/containerd/config.toml держим в git - при обновлении пакета он может перезаписаться (особенно на РЕД ОС), и тогда потеряются настройки зеркал реестра.

Стабильность CRI API - это хорошо с долгосрочной точки зрения: теперь можно менять рантайм (containerd, CRI-O) без привязки к конкретной версии k8s. Но переходный период потребовал аккуратности.

Pod Security Admission в мультиарендном кластере

PSP убрали ещё в 1.25, и мы уже писали про базовую миграцию. Но тогда речь шла про однотипные кластеры с похожими workload. В феврале столкнулись с тем, что PSA в мультиарендном кластере - это отдельная история.

Конфигурация: один кластер, несколько команд-арендаторов, у каждой свои неймспейсы. Раньше PSP-политики были дифференцированы по группам: одни разработчики получали политику с доступом к hostPath (для агентов мониторинга), другие - строгую политику без привилегий. Через RBAC это управлялось гранулярно, пусть и с запутанными привязками ролей.

С PSA модель другая. Метки на неймспейс - и весь неймспейс живёт в одном из трёх профилей. Это проще для понимания, но сложнее для дифференциации внутри арендатора.

Где пришлось подумать:

• Системные неймспейсы (kube-system, monitoring) - privileged. Тут без вариантов: daemonset-ы сетевого плагина, node-exporter, агенты логирования требуют доступа к хосту.
• Прикладные неймспейсы арендаторов - большинство нормально живут на restricted. Но два неймспейса с legacy-приложениями, которые запускают контейнеры от root, пришлось временно оставить на baseline. Это компромисс, зафиксированный в трекере как техдолг.
• Режим warn как диагностика. Перед тем как ставить enforce, навесили на неймспейс warn с нужным профилем и дали недельный прогрев. Kubernetes начал выдавать предупреждения в ответах API при создании несовместимых подов - без блокировки. Это позволило найти три места где манифесты нарушали restricted незаметно.

Чего не хватает в PSA по сравнению с PSP:

• Нет гранулярного контроля hostPath. PSP позволял разрешить конкретные пути (/var/log, /proc/stat), PSA дает только грубое baseline (разрешает hostPath вообще) или restricted (запрещает). Для точного контроля нужен OPA/Gatekeeper или Kyverno - встроенного механизма нет.
• Нет allowedCapabilities с точным списком. На наших текущих кластерах критично не выглядит, но у клиентов с нестандартными сетевыми агентами это реальное ограничение.

Что изменили в процессе обновления

После опыта с несколькими кластерами на 1.26 в проде чеклист обновления у нас вырос примерно вдвое. Основные добавления:

• Проверка CRI-версий на всех нодах - первым пунктом, до начала апгрейда control plane.
• PSA warn-прогрев - минимум неделя на каждом неймспейсе перед переключением на enforce.
• Аудит --set флагов в CI/CD - не только манифесты в git, но и скрипты деплоя на предмет hardcoded apiVersion. Научены горьким опытом декабря.
• Отдельная проверка операторов - если в кластере есть операторы с CRD, смотрим release notes: у части из них есть migration jobs, которые надо запустить до апгрейда, а не после.

Где стоим сейчас

Три из пяти продакшн-кластеров на 1.26. Два оставшихся - в очереди на март, там более сложный профиль workload и несколько legacy-приложений с нетривиальными требованиями к безопасности. Для них потребуется отдельный проект по приведению в совместимость с baseline PSA, параллельно с апгрейдом.

В рамках managed-сопровождения мы сейчас стандартизируем этот процесс: не «обновить версию», а полный цикл - аудит CRI, анализ PSA-совместимости workload, прогрев через warn, и только потом enforce и апгрейд. Дольше, но предсказуемее.