Платформы Kubernetes нередко тратят месяцы на разработку собственных контроллеров, которые связывают несколько облачных и кластерных ресурсов в один сервис для внутреннего пользователя. 29 октября 2026 года эту проблему разобрал The New Stack: для российских platform-инженеров она знакома по попыткам превратить набор CRD, Helm-чартов и Terraform-модулей в понятный каталог самообслуживания.
Поводом стал материал Адама Краудера Why Kubernetes platforms keep rebuilding a layer they could share. Его главный тезис прост: команда, строящая внутреннюю платформу, почти неизбежно добавляет Kubernetes-контроллер, который создаёт и координирует ресурсы. Это может быть база данных вместе с секретами и сетевыми правилами, окружение приложения с репозиторием и CI/CD либо другой составной сервис. Проблема не в самом контроллере: она в том, что похожая логика снова и снова появляется в разных компаниях и командах.
Kubernetes хорошо описывает и поддерживает отдельные объекты через декларативное желаемое состояние и reconciliation loop. Но продуктовая потребность обычно лежит уровнем выше одного объекта. Разработчику нужен не отдельный ServiceAccount, PVC или запись DNS, а готовая возможность: создать тестовый стенд, получить очередь, подключить управляемую БД, открыть доступ команде. Между таким запросом и десятком разнородных ресурсов возникает слой компоновки. Именно его платформы Kubernetes часто реализуют самостоятельно.
На практике самодельный слой быстро обрастает правилами: параметрами, значениями по умолчанию, политиками доступа, обработкой ошибок, статусами, обновлениями и удалением зависимостей. Снаружи всё выглядит аккуратно — один CRD или запись в портале разработчика. Внутри команда должна решить, в каком порядке создавать объекты, как ждать их готовности, как повторять неудачные операции и что делать с частично созданной инфраструктурой. Такой код редко становится главным конкурентным преимуществом компании, но его поддержка вполне способна съесть заметную часть времени платформенной команды.
У этой повторяемости есть и организационная причина. Каждая команда начинает с локальной задачи: убрать ручную заявку в инфраструктуру, стандартизировать шаблон сервиса или дать разработчикам self-service. Готовые инструменты могут закрывать только часть цепочки, а требования к безопасности, облачному провайдеру и внутренним процессам различаются. Поэтому вместо общего механизма появляется ещё один контроллер — часто разумный в моменте, но дорогой в сопровождении через год.
Для российских компаний эта логика особенно актуальна там, где Kubernetes уже стал базой для нескольких команд и сред. Если каталог платформы выдаёт ресурсы в нескольких кластерах, интегрируется с секретами, сетью, наблюдаемостью и внешними облачными API, код компоновки превращается в критическую часть control plane. Ошибка в нём влияет уже не на один deployment, а на путь от заявки разработчика до работающего сервиса. Значит, его стоит проектировать как продукт: с версионированием интерфейсов, наблюдаемыми статусами, безопасным удалением и понятной моделью владения.
Есть и менее очевидный риск: каждый новый внутренний абстрактный объект может скрыть Kubernetes слишком хорошо. Разработчикам становится проще стартовать, но платформа рискует получить непрозрачный набор «магических» сущностей, которые сложно диагностировать в инциденте. Хорошая композиция не отменяет базовые ресурсы, а показывает связь между пользовательским запросом, созданными объектами и их состоянием. Иначе self-service превращается в тикет-систему, только с API.
Платформы Kubernetes поэтому стоит оценивать не по числу написанных контроллеров, а по тому, сколько повторяющейся оркестрации удалось не писать. Вопрос на ближайший цикл развития platform engineering звучит прагматично: какие правила композиции действительно уникальны для бизнеса, а какие команды продолжают копировать просто потому, что общего и удобного слоя пока не выбрали?
