Kubernetes 1.19 и 12-месячный цикл: строим матрицу совместимости до обновления

Kubernetes 1.19 по плану выходит в августе, и мы начали готовиться заранее - не потому что торопимся, а потому что одно изменение в этом релизе меняет логику всей работы с версиями кластеров.

Проект managed-сопровождения у нас сейчас включает несколько кластеров на 1.17 и 1.18. Обновление с 1.18 на 1.19 само по себе рутинное, но есть два пункта, которые требуют подготовки до, а не после: Ingress GA и новый 12-месячный жизненный цикл релизов.

12 месяцев: почему это меняет планирование

До 1.19 поддержка релиза Kubernetes составляла девять месяцев. При темпе три релиза в год это означало, что окно обновления - грубо три-четыре месяца между выходом новой версии и EOL предыдущей. На практике - вечная спешка, особенно когда обновление надо синхронизировать с freeze у клиента или регуляторными циклами.

С 1.19 сообщество официально переходит на 12 месяцев поддержки. Это не означает, что обновлять кластеры станет реже - три релиза в год никуда не делись. Но это означает, что при пропуске одного релиза вы всё ещё находитесь в поддерживаемой версии. Для клиентов с жёсткими freeze-периодами - банки, ритейл перед новым годом - это реальное облегчение.

Практическое следствие: матрица совместимости helm-чартов и API-групп теперь строится на горизонт год, а не квартал. Это немного больше работы при составлении, зато гораздо меньше срочных апгрейдов.

Ingress GA: что это значит для чартов

В 1.18 мы уже разбирали deprecation-ситуацию с extensions/v1beta1 - Ingress там был официально deprecated, networking.k8s.io/v1beta1 работал как промежуточный вариант. В 1.19 Ingress получает GA в networking.k8s.io/v1, и API-группы выглядят так:

• extensions/v1beta1/ingresses - deprecated с 1.14, удаление запланировано
• networking.k8s.io/v1beta1/ingresses - доступна в 1.19, но тоже deprecated относительно v1
• networking.k8s.io/v1/ingresses - целевой вариант с 1.19

Схема networking.k8s.io/v1 для Ingress немного отличается от v1beta1: поле spec.backend теперь называется spec.defaultBackend, поле servicePort разбивается на service.name и service.port.number. Это не breaking change в смысле «всё упадёт», но это несовместимые манифесты - helm-чарт написанный под v1 не задеплоится на кластер 1.18 без v1, и наоборот.

Что мы делаем: матрица совместимости

До выхода 1.19 мы составляем таблицу по каждому кластеру: какие helm-чарты используются, какой apiVersion в их шаблонах Ingress, что нужно обновить и в каком порядке.

Логика работы с матрицей:

Сначала - инвентаризация через audit log. Метод тот же, что применяли при переходе на 1.18: смотрим за две недели, кто шлёт запросы к каким API-группам. extensions/v1beta1 для Ingress - красный флаг, networking.k8s.io/v1beta1 - жёлтый, надо обновить до v1.

Дальше - версионирование чартов. Для каждого чарта фиксируем: минимальная версия с поддержкой networking.k8s.io/v1. Для nginx-ingress это примерно 3.x (community chart), для cert-manager - следующая мажорная версия с поддержкой v1, для prometheus-operator сложнее - там Ingress используется в нескольких местах.

Наконец - порядок обновления. Сначала обновляются чарты до версий с поддержкой v1, потом кластер обновляется до 1.19. Обратный порядок - обновить кластер, потом разбираться с чартами - работает технически (v1beta1 в 1.19 ещё живёт), но создаёт окно с deprecated API в продакшне.

Storage Capacity tracking

Третья тема в 1.19 - Storage Capacity Tracking, alpha. Суть: планировщик теперь может учитывать доступную ёмкость хранилища при размещении подов, которым нужны PVC через CSI-драйверы с поддержкой этой фичи.

На наших кластерах это актуально для одного клиента с Ceph через ceph-csi: иногда поды с большими PVC зависают в Pending, потому что планировщик не знает, на каких нодах хватит ёмкости. Alpha-статус означает включение через feature gate и без гарантий стабильности API - в продакшн не тащим, но включим в тестовой среде посмотреть на поведение.

Что делаем прямо сейчас

До выхода 1.19 в августе у нас несколько недель. Текущий план:

• Инвентаризация API-обращений - прогоняем audit log по всем managed-кластерам, фиксируем результат в матрице.
• Обновление чартов - те что уже поддерживают networking.k8s.io/v1, обновляем сейчас, не ждём 1.19. Те что не поддерживают - открываем задачи на апгрейд версии чарта или форк шаблона.
• Тестирование на staging - один staging-кластер переедет на 1.19 RC, как только выйдет; там проверяем матрицу на практике.
• Обновление SLA-матрицы - с учётом новых 12 месяцев пересчитываем даты EOL для 1.17, 1.18, 1.19 по каждому клиенту и обновляем графики плановых работ.

Annotation kubernetes.io/ingress.class в v1 тоже меняется на spec.ingressClassName - это ещё один пункт в чек-листе. Мелочь, но таких мелочей наберётся десяток, и лучше иметь список заранее, чем ловить их по одной в день обновления.