Знаете эту боль? Сначала вы ставите Keycloak «на пробу» на пару месяцев. Всё летает. Вы даёте ссылку на auth.myapp.ru разрабам. А потом бац - прод, 10 тысяч пользователей, и Keycloak внезапно говорит: «Я устал, я ухожу, и все сессии с собой забираю». Мммм. Классика!

И тут из-за угла, на белом коне (слегка прихрамывающем, потому что JVM жрёт память) приезжает кластерный Keycloak.

В 2026 году Kubernetes окончательно превратился из "оркестратора контейнеров" в полноценную операционную систему для датацентра. Если в 2020-м все радовались автоматическому рестарту Pod'ов, то сейчас инфраструктурщики обсуждают GPU scheduling, inference gateway, multi-cluster federation и стоимость токена у LLM-моделей так, будто это курс нефти Brent.

И вот здесь появляется Kubernetes Operator.

Не просто очередной контроллер. Не просто "скрипт в контейнере". А полноценный способ научить Kubernetes понимать ваш бизнес-домен.

В этой статье мы напишем настоящий Kubernetes Operator на Python для одной из самых хайповых тем 2026 года - управления AI Gateway для больших языковых моделей.

В два часа ночи инфраструктура выглядит совсем не так, как на архитектурных диаграммах, которые любят показывать на внутренних демо и квартальных встречах. На схемах всё красиво и упорядоченно: Kubernetes-кластеры выстроены ровными прямоугольниками, CI/CD-пайплайны текут по аккуратным стрелкам, системы наблюдаемости заботливо собирают телеметрию, а процессы реагирования на инциденты расписаны настолько подробно, что остаётся лишь следовать инструкции. Реальность, как обычно, значительно менее фотогенична. Дежурный инженер открывает ноутбук, пытается одной рукой удержать кружку с давно остывшим кофе, а другой переключается между Prometheus, Grafana, терминалом, журналами приложений, корпоративным чатом и GitLab. Вкладок открыто столько, что даже браузер начинает вести себя как пассивно-агрессивный коллега, намекающий, что человеку давно пора спать.

Есть один неловкий момент, о котором инфраструктурщики, разработчики и архитекторы обычно говорят не со сцены и не во время официальных дискуссий. Такие разговоры случаются значительно позже - когда закончились последние доклады, бейджики перекочевали в карманы рюкзаков, а люди наконец перестали играть роли представителей компаний и снова становятся просто инженерами. Обычно это происходит где-нибудь в лобби гостиницы, возле кофемашины или за столиком в баре, когда разговор неожиданно сворачивает с обсуждения "платформенного подхода" и "инженерной синергии" к чему-то значительно более честному.

Есть момент, который почти невозможно заметить изнутри компании, пока он не случился. Вчера вы были той самой дерзкой командой, которая за выходные запускала новые сервисы, выкатывала изменения без длинных согласований и искренне гордилась тем, что "у нас всё по-простому". А потом однажды выясняется, что инфраструктурный счёт за месяц сопоставим с годовой зарплатой нескольких инженеров, крупный клиент спрашивает про RTO и RPO, служба информационной безопасности интересуется журналами аудита, а генеральный директор неожиданно хочет понять, почему отказ одного сервиса остановил продажи на несколько часов. И именно в этот момент становится очевидно: компания выросла. Даже если сама она ещё не готова себе в этом признаться.

История инфраструктурных технологий редко развивается по сценарию, в котором одна система внезапно оказывается "плохой", а другая приходит ей на смену в роли безусловного победителя. Обычно всё происходит значительно интереснее. Технологии появляются как ответ на конкретные ограничения своего времени, прекрасно решают поставленные перед ними задачи, постепенно становятся отраслевым стандартом, а затем сталкиваются с изменением окружающей среды. В этот момент выясняется, что проблема заключается вовсе не в качестве инженерных решений. Просто мир, для которого они создавались, перестал существовать в прежнем виде.

Когда в компании впервые звучит фраза: «Нам нужно определить класс защищённости», в переговорной обычно разворачивается небольшой спектакль в трёх действиях. Специалист по информационной безопасности открывает несколько десятков вкладок с приказами, методиками и разъяснениями регуляторов. DevOps-инженер незаметно пытается вспомнить, сколько серверов работают на версиях операционных систем, которые давно сняты с поддержки, и какие именно сервисы никто не обновлял последние три года, потому что "трогать страшно - вдруг перестанет работать". Бизнес, как правило, задаёт самый прагматичный вопрос:

А можно всё это сделать подешевле? И желательно без остановки сервисов?!