Kubernetes 1.21: immutable ConfigMaps, CronJob в stable и что делать с IPv6

Kubernetes 1.21 вышел в начале апреля, и на этот раз релиз на удивление спокойный - никаких пожарных deprecated, никакого экстренного переобувания. Зато есть несколько вещей, которые реально меняют повседневную работу с кластером. Разбираем по делу.

Immutable ConfigMaps - маленькая фича с большими последствиями

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

Суть простая: добавляешь в ConfigMap или Secret поле immutable: true - и Kubernetes больше не даёт изменить данные этого объекта. kubectl edit, kubectl apply с изменёнными данными - всё это вернёт ошибку. Единственный способ что-то поменять - удалить объект и создать новый.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-v2
data:
  DATABASE_URL: "postgres://db.internal:5432/appdb"
  CACHE_TTL: "300"
immutable: true

На первый взгляд кажется ограничением. На второй - это именно то поведение, которое нужно в production.

У нас был эпизод, который хорошо иллюстрирует проблему. Инженер правил конфигурацию staging-окружения, перепутал namespace, сделал kubectl edit configmap app-config в production - и под ушёл в crash loop, потому что неожиданно получил staging-строку подключения к базе. Времени на диагностику ушло минут сорок: симптомы не были очевидными, конфиги с виду выглядели правильно, пока кто-то не догадался проверить историю изменений в ConfigMap.

С immutable: true такой сценарий физически невозможен. Работающий под продолжает использовать смонтированный конфиг - и никакой случайный kubectl edit его не тронет.

Дополнительный бонус, который упоминается в release notes но звучит немного абстрактно: kube-apiserver перестаёт следить за изменениями immutable ConfigMaps/Secrets через watch. При большом количестве конфигов в кластере это реально снижает нагрузку на control plane. Мы пока не замерили разницу в своих кластерах, но смысл понятен.

Как переводить production ConfigMaps на immutable. Нельзя просто добавить поле к существующему объекту, если данные уже менялись, - поле immutable можно установить только один раз. Наш подход: версионирование в имени (app-config-v1, app-config-v2) плюс обновление ссылки в деплойменте при каждом изменении конфига. Это ломает привычку тихо патчить ConfigMap и перечитывать его в работающем поде, зато вносит порядок: каждое изменение конфигурации - это намеренное действие с историей в git.

Для Secrets всё то же самое, и там аргументов в пользу immutable ещё больше.

CronJob в GA - наконец-то

CronJob существовал в Kubernetes с незапамятных времён, висел в beta и накопил за эти годы несколько неприятных поведенческих особенностей с конкурентной политикой и missed schedules. В 1.21 он наконец вышел в stable с небольшими, но важными улучшениями: более предсказуемая обработка пропущенных запусков, лучшая диагностика через события.

Практически это означает, что CronJob теперь безопасно использовать как зрелый примитив - не нужно держать в голове «это beta, может измениться». Для наших заказчиков, которые держат на CronJob ночные ETL-задачи и ротацию отчётов, это хорошая новость без необходимости что-то менять.

IPv4/IPv6 dual-stack - beta, но не для всех

IPv6 dual-stack перешёл в beta - кластер можно настроить так, чтобы поды получали и IPv4, и IPv6 адреса одновременно. Звучит привлекательно, особенно если в организации уже идёт движение к IPv6.

Но здесь надо быть честными: для большинства корпоративных кластеров, которые мы обслуживаем в рамках managed-сопровождения, dual-stack сейчас - это скорее предмет для изучения, чем для немедленного включения в production. Причины практические:

Сетевой плагин должен поддерживать dual-stack. Calico поддерживает, Flannel - с ограничениями, Cilium - да. Если кластер стоит на Weave или на проприетарном CNI от облачного провайдера - надо специально проверять.

Корпоративная периметровая инфраструктура. Firewall, IDS, балансировщики, мониторинг - всё это надо проверить на поддержку IPv6. В большинстве корпоративных сетей IPv6 либо выключен, либо пропускается без анализа, что само по себе создаёт слепые зоны в безопасности.

Сервисы внутри кластера. Приложение, которое слушает только 0.0.0.0, может не обрабатывать IPv6 соединения корректно без тестирования.

Это не значит, что dual-stack не нужен. Если организация планомерно идёт к IPv6 и сетевая инфраструктура готова - beta-статус уже достаточный для пилота. Но включать его на существующем production-кластере без полноценного аудита сети и приложений - риск без понятной пользы прямо сейчас.

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

Immutable ConfigMaps/Secrets начали внедрять для production-окружений новых заказчиков сразу. Для существующих кластеров - аудит ConfigMaps и постепенный перевод по мере плановых обновлений деплойментов.

CronJob в GA - ничего дополнительно делать не нужно, существующие манифесты работают без изменений.

Dual-stack - добавили в план ближайшего квартала как пилотную тему: поднять тестовый кластер с Calico и dual-stack, проверить как ведут себя наши типовые рабочие нагрузки, получить конкретные цифры по overhead и список граблей. Без этого давать рекомендации по production-внедрению было бы безответственно.

Обновление до 1.21 само по себе некритичное - changelog без болезненных breaking changes. Но immutable ConfigMaps - это та фича, ради которой стоит планировать апгрейд раньше, а не тянуть до следующего релиза.