Kubernetes 1.15 и зрелые CRD: начинаем оценивать операторы для StatefulSet-приложений

Kubernetes 1.15 вышел в конце июня, и в этот раз несколько строчек в release notes перевесили всё остальное: Custom Resource Definitions получили structural schemas и conversion webhooks в beta, версионирование API с гарантиями конвертации. После полутора лет работы с операторами в beta-статусе с минимальными гарантиями это меняет разговор о том, что можно нести в production.

Что реально изменилось в 1.15

Помимо CRD-стабильности, в 1.15 есть несколько вещей, которые касаются нас напрямую.

Scheduler framework и plugin-система. Расширяемость scheduler перестала быть хаком через predicates и priorities и получила нормальный plugin-API. Для большинства кластеров это пока академично, но если нужна кастомная логика размещения подов - теперь есть понятный механизм вместо форков.

CRD: версионирование и validation webhooks. CRD теперь поддерживают несколько версий одновременно с conversion webhooks - можно мигрировать API оператора без удаления всех объектов. Это та самая боль, о которой мы писали после опыта с Postgres Operator: при обновлении оператора пришлось мигрировать объекты руками. Теперь это можно делать через webhook-конвертацию.

Structural schema в CRD. Валидация через OpenAPI v3 schema теперь встроена в сам API-сервер, а не живёт только в validating webhook. Это значит что kubectl apply сразу скажет об ошибке в ресурсе, не дожидаясь пока оператор попробует его обработать.

Улучшения kubectl. kubectl diff наконец-то работает нормально - показывает что реально изменится в кластере перед apply. Мелочь, но на managed-кластерах с несколькими командами это используется постоянно.

Почему зрелость CRD в 1.15 меняет нашу оценку

За последние полтора года мы прошли через несколько итераций с операторами. Etcd Operator от CoreOS - тестовый стенд, так и не ушёл в production. Prometheus Operator - рабочий инструмент уже почти год. Zalando Postgres Operator - рабочий, но с оговорками про API-стабильность.

Главная оговорка у всех трёх была одна: CRD в beta - это честно названный «мы ещё итерируем». Нарваться на ломающее изменение API между версиями оператора было реальным риском, мы это видели в прямом эфире. Переводить это в критичный production сложнее, когда фундамент под оператором ещё не стабилен.

Теперь ситуация другая. Structural schemas в beta и conversion webhooks - это понятные гарантии от upstream: версионирование API оператора с контролируемой конвертацией. Авторы операторов, которые опираются на это, получают более предсказуемый контракт.

Что мы оцениваем прямо сейчас

На managed-инфраструктуре у нас несколько клиентов с StatefulSet-приложениями, которые пока живут через ручные скрипты и runbook-ы. Типичная история: PostgreSQL-кластер с Patroni снаружи Kubernetes, управляется Ansible-плейбуками, failover проверяется раз в квартал вручную. Работает, но требует человека с нужным контекстом при каждом нетривиальном событии.

Вопрос, который мы ставим после выхода 1.15: можно ли перевести это в оператор так, чтобы операционная нагрузка снизилась, а не выросла?

Кандидаты под оценку:

• Zalando Postgres Operator - уже знакомый, теперь его API-совместимость может опираться на conversion webhooks; хотим посмотреть на версию под 1.15 и на то как работает конвертация при обновлении оператора.
• Rook для Ceph - у одного из клиентов есть потребность в объектном хранилище внутри кластера, Rook 1.0 вышел в мае и тоже опирается на CRD.
• Custom operator для внутренней задачи - один из сценариев слишком специфичен для готового оператора: многоэтапный деплой legacy-приложения с несколькими состояниями, которые сейчас закодированы в Ansible. Написать собственный контроллер через controller-runtime выглядит реалистично, теперь когда CRD получили structural schemas и нормальное версионирование.

Что ещё не ясно

Зрелость CRD в 1.15 не означает что все операторы стали production-grade. Сам оператор - это код, который кто-то написал, с его багами, операционными допущениями и качеством тестирования. Фундамент стал надёжнее, надстройка - по-разному.

Второй открытый вопрос: scheduler plugins в 1.15 - это alpha API. Смотрим, но не трогаем.

Третье: multi-cluster federation в заголовке 1.15 не стоит переоценивать. KubeFed v2 развивается отдельно от core Kubernetes, и хотя он тоже опирается на CRD, его зрелость - другой разговор. У нас несколько кластеров, и тема управления ими как единым целым поднимается, но не через federation - пока через GitOps и отдельные пайплайны на каждый кластер.

Где мы сейчас

Обновление до 1.15 планируем на следующий месяц на тестовых кластерах, в production - с небольшим лагом. Оценка операторов под конкретные задачи - параллельно, результат будет виден к осени. Пока что самое ценное в этом релизе - не новые фичи, а то что CRD-расширяемость значительно повзрослела: structural schemas, conversion webhooks, версионирование. Это меняет уровень доверия к операторскому подходу в целом.