На KubeCon & CloudNativeCon Europe 25 июня 2026 года инженеры Maximilian Techritz и Johannes Ott показали, как внутри крупной компании можно собрать облачную оркестрацию вокруг Kubernetes, а не вокруг зоопарка разрозненных тулов. Для русскоязычных команд это сигнал вполне практичный: если инфраструктура уже расползлась по нескольким облакам, внутренним сервисам и ручным процедурам, еще один портал поверх хаоса обычно не лечит, а только аккуратнее раскладывает хаос по папкам.
О подходе сообщает InfoQ со ссылкой на выступление How to Build a European Cloud Orchestration Platform from within an Enterprise. Главная мысль доклада проста и болезненно узнаваема: современный деплой давно не сводится к выкладке приложения на сервер. Команде нужно поднимать и настраивать базы данных, хранить и ротировать секреты, подключаться к внутренним и внешним сервисам, соблюдать корпоративные политики и все это проводить через инструменты с разным интерфейсом, ритмом обновлений и степенью ручного участия. Где-то это CI/CD-пайплайны, где-то CLI, где-то тикеты, а где-то старый добрый Click-Ops, который особенно любят те, кто потом не дежурит ночью.
По словам Ott, именно эта цепочка и превращается в главный налог на разработку. При каждом выпуске новой версии нужно не только проверить код, но и убедиться, что по дороге ничего не сломается в облачных API, конфигурациях, секретах и зависимостях. Инженеры тратят внимание не на развитие продукта, а на сопровождение стека. Причем проблема усугубляется тем, что поставка софта все чаще идет не в пару знакомых дата-центров, а в private cloud и sovereign cloud. Иначе говоря, инфраструктура становится не просто распределенной, а еще и политически, юридически и организационно чувствительной. В такой среде облачная оркестрация перестает быть вопросом удобства и становится вопросом скорости изменений и стоимости ошибок.
Почему Kubernetes снова оказался в центре
Команда докладчиков пришла к выводу, что строить еще один собственный инструмент бессмысленно. Вместо этого они оперлись на уже сложившуюся экосистему Kubernetes и идею единого Control Plane. Смысл в том, чтобы описывать желаемое состояние внешних облачных ресурсов декларативно и применять его через Kubernetes. Для этого используются готовые компоненты. В докладе упоминался Crossplane: он позволяет управлять, например, базами данных в Google Cloud Platform, бакетами в AWS и сетевыми политиками в Microsoft Azure через единый слой управления. Контроллеры в кластере затем сверяют желаемое и фактическое состояние, создают ресурсы, обновляют их или удаляют, не заставляя команду каждый раз вручную идти в отдельную консоль или API.
На этом конструкция не заканчивается. External Secrets Operator синхронизирует и ротирует учетные данные между системами, Kyverno отвечает за политики и соответствие внутренним требованиям компании, а Flux добавляет GitOps-подход: конфигурация хранится в репозитории и проходит через более понятный для инженеров процесс изменений. Важный момент здесь не в модном наборе open source-брендов, а в унификации операционной модели. Если раньше каждая новая сущность в инфраструктуре приносила с собой отдельную инструкцию, новый тип доступа и новый повод открыть тикет, то здесь все сводится к схожему ресурcному API и общему способу работы. Для platform engineering это, по сути, попытка заменить россыпь локальных договоренностей на воспроизводимую систему.
Докладчики отдельно говорили про OpenControlPlane. Эта платформа позволяет владельцам внутренней инфраструктуры задавать правила использования секретов, баз данных и приложений для продуктовых команд. Сами команды заказывают Control Plane с уже установленными и преднастроенными операторами и не обязаны разбираться в установке и сопровождении всего набора инструментов. Логика понятна любому, кто хоть раз пытался масштабировать внутреннюю платформу: разработчикам не нужен полный курс по каждому инфраструктурному компоненту, им нужен внятный контракт. Чем меньше команда думает о том, какой именно оператор и с каким lifecycle сейчас стоит между ней и нужной базой, тем выше шанс, что она сосредоточится на продукте, а не на археологии YAML-файлов.
Почему adoption упирается не в технологию, а в людей
Самая интересная часть истории не в том, что Kubernetes снова предлагают как универсальный язык управления инфраструктурой. Это рынок слышит уже не первый год. Интереснее другое: Techritz и Ott прямо говорят, что при внедрении такого подхода решает не только архитектура, но и внутренняя социализация изменений. После запуска идеи они увидели сильный интерес, но быстро уперлись в неравномерный опыт команд с Kubernetes resource model. Для одной группы CRD и reconciliation loop звучат как рутина, для другой это набор слов, после которых хочется обратно в тикет-систему. В ответ они запустили ежемесячные tech talk в гибридном формате, куда приглашали сотрудников из разных частей компании. Формат был намеренно коротким и с минимальным порогом входа: не курс для избранных, а демонстрация того, как методология Control Plane может упростить повседневную работу.
Параллельно команда вложилась в enablement-материалы и сделала проект inner-source с первого дня. По словам Ott, большая часть компонентов теперь уже open source. Это важный ход для крупных организаций: если внутренняя платформа выглядит как черный ящик, adoption почти неизбежно превращается в политический процесс. Если же платформа развивается как открытый для коллег проект, у пользователей появляется шанс не только жаловаться в чат, но и реально влиять на решение. Для российских и русскоязычных компаний, где platform engineering часто буксует не из-за отсутствия экспертизы, а из-за разрыва между «центральной платформой» и продуктовыми командами, этот вывод, пожалуй, важнее выбора конкретного оператора.
Есть и более широкий контекст. Techritz отдельно отметил, что проект удалось передать в EU-funded инициативу IPCEI-CIS, связанную с темой европейского облачного суверенитета. Дальше он попал под зонтик NeoNephos Foundation, проекта Linux Foundation Europe, который должен обеспечивать vendor neutrality. Это уже не просто история про внутреннюю оптимизацию enterprise-ландшафта, а про попытку Европы вырастить собственную облачную субъектность без полной зависимости от гиперскейлеров. На практике это означает, что интерес к Control Plane-подходу подогревается не только инженерной экономикой, но и геополитикой облаков. Когда компании думают о sovereign cloud, единая модель управления ресурсами становится способом снизить lock-in хотя бы на уровне операционных практик.
Для разработчиков и бизнеса вывод довольно приземленный. Облачная оркестрация начинает окупаться не там, где строят идеальную платформу на 200 слайдов, а там, где находят несколько общих болей команд и закрывают их минимально жизнеспособным решением. Techritz сформулировал это без лишней романтики: начинать нужно с малого, выяснять, что реально важно людям, и либо писать Kubernetes Operator под конкретную задачу, либо брать готовый open source-инструмент. Отдельный акцент он сделал на обучении людей без опыта работы с Kubernetes. Это, возможно, самая недооцененная часть любой платформенной инициативы. Можно сколько угодно говорить про GitOps, policy-as-code и унификацию control plane, но если путь входа сложнее, чем старая ручная процедура, команда вернется к старой ручной процедуре. Причем быстро и без чувства вины.
Главный вопрос теперь не в том, можно ли собрать облачную оркестрацию на Kubernetes внутри enterprise. Судя по этому кейсу, можно. Вопрос в другом: сколько компаний готовы признать, что их следующая инфраструктурная победа будет выглядеть не как запуск еще одного внутреннего сервиса, а как скучная, последовательная стандартизация того, что уже давно должно было стать общим языком для разработки, платформы и облаков.