Kubernetes: кто его усложнил? Как сложность переехала в платформы и AI-агентов

В ноябре 2025 года SIG Network и Kubernetes Security Response Committee объявили о закрытии ingress-nginx. Поддержка закончилась в марте 2026-го: после этого нет новых релизов, исправлений ошибок и патчей безопасности. Существующие инсталляции продолжают работать — и именно поэтому риск легко не заметить. В январском заявлении Steering Committee ссылался на внутреннее исследование Datadog: ingress-nginx использовался примерно в половине облачно-ориентированных окружений. Это выборка одного поставщика наблюдаемости, а не перепись рынка.

Масштаб сам по себе впечатляет меньше, чем причина. Проект годами поддерживали один-два человека в свободное время после работы. Его гибкость — особенно возможность вставлять произвольные фрагменты NGINX через snippet-аннотации — постепенно превратилась из достоинства в технический долг, который сами авторы объявления назвали непреодолимым. В 2021 году уже было известно, что snippets способны открыть доступ к секретам кластера. В марте 2025-го цепочка IngressNightmare довела тот же класс риска до неаутентифицированного RCE.010101Классический сюжет: критичную для всего интернета библиотеку тоже сопровождала горстка волонтёров. Историю Log4Shell я пересказывал в канале со слов мейнтейнера Log4j.Книжный куб · история Log4Shell

Поэтому вопрос «кто усложнил Kubernetes?» не имеет одного обвиняемого. Апстрим создавал API с ошибочными границами. Вендоры и пользователи расширяли их под рабочую эксплуатацию. Организации хотели централизованное соответствие требованиям, мультитенантность, сервисную сетку, собственные контуры управления и всё новые нагрузки. А платформенные команды обещали, что ещё один слой скроет предыдущие. В результате сложность не исчезала — меняла владельца.

Kubernetes управляет распределённой системой, в которой процессы падают, сеть разделяется, конфигурация меняется асинхронно, а желаемое состояние должно сходиться с фактическим. Эта сложность существенна: она существовала и в Borg, и в самописных scheduler, и в shell-скриптах. Удаление Kubernetes не отменяет обнаружение сервисов, поэтапный запуск, изоляцию, планирование мощности или восстановление. Оно лишь меняет место, где эти задачи решаются.

Но есть и случайная сложность. PodSecurityPolicy прожила несколько лет, была объявлена deprecated в 1.21 и удалена в 1.25. NetworkPolicy сознательно не получила deny-правил и кластерных дефолтов, поэтому для централизованного контроля понадобился отдельный AdminNetworkPolicy API. Policy-движки росли вне ядра, а затем Kubernetes вернул часть их функций в apiserver через ValidatingAdmissionPolicy на CEL. Это не «требования бизнеса». Это последовательность архитектурных решений, некоторые из которых пришлось пересматривать.

Тим Хокин, один из создателей Kubernetes, сформулировал это как конечный бюджет сложности: каждая фича тратит не только строки кода, но и способность проекта объяснять, тестировать и когда-нибудь менять своё поведение. Для расширяемой системы проблема особенно остра. CRD — её сильнейший механизм и одновременно способ превратить кластер в сборку из десятков независимых продуктов с разными циклами обновления.020202Про то, как сложность копится и как её резать на уровне дизайна, лучшая книга — «A Philosophy of Software Design» Джона Оустерхаута (он же один из авторов Raft). Разбирал её в канале.Книжный куб · A Philosophy of Software Design

Почему тогда Kubernetes называют boring?

CNCF Annual Survey 2025 сообщает, что 82% пользователей контейнеров запускают Kubernetes в рабочей среде, а сложность называют препятствием 34% респондентов. Выше оказались культурные изменения, обучение и безопасность. Это сильный контраргумент катастрофическому нарративу: API стабилизировались, managed-сервисы стали обычными, операционные паттерны известны, а технология перестала быть экспериментом.

Но опрос внедрения и стоимость эксплуатации отвечают на разные вопросы. «Нам не страшно внедрять Kubernetes» не означает «нам дёшево и просто его сопровождать». Когда сложность становится отдельной функцией платформы, продуктовая команда действительно перестаёт видеть большую её часть. Система стала скучнее для пользователя — и толще для владельца.

Оригинальный Ingress API был намеренно маленьким: узел, путь, сервер назначения и TLS. В нём не было общего языка для таймаутов, повторных попыток, канареечных выпусков, внешней авторизации, переписывания заголовков или WAF. Контроллеры закрыли разрыв аннотациями. К июлю 2026 года документация ingress-nginx содержала около 130 уникальных ключей, а фрагменты позволяли вставлять необработанную конфигурацию NGINX. Локальная простота API породила глобальный, непереносимый DSL.

Gateway API отвечает не сокращением YAML, а явной моделью. GatewayClass принадлежит инфраструктурному провайдеру, Gateway — оператору кластера, Route — приложению. ReferenceGrant ограничивает межнеймспейсные ссылки, status сообщает, что реально принято контроллером, а политики получают формальное место вместо случайной строки в metadata. На дату статьи актуальна ветка 1.6.x; TCPRoute и UDPRoute достигли GA.

Цена тоже стала явной. Один маршрут теперь связан с несколькими ресурсами, а привязка политик должна решать наследование, конфликты, обнаружение и разветвление статусов. Авторы GEP-713 сами признают, что механизм сложнее желаемого. Но это другой класс сложности: её можно валидировать, наблюдать и распределять между ролями. Аннотация выглядела проще только до первого расследования.

eBPF не отменяет этот вывод

eBPF дал Cilium сильную плоскость данных и решил задачи гиперскейла, но не является универсальным ответом на сетевую сложность. nftables-режим kube-proxy достиг GA в Kubernetes 1.33 и устранил линейный поиск по iptables-цепочкам без замены всего CNI. Режим ambient в Istio убрал sidecar-прокси из каждого пода через Rust-компонент ztunnel, а не через обязательный eBPF. Громкие ускорения из миллионов контейнеров нельзя автоматически переносить на кластер из пятидесяти нод. Новая плоскость данных полезна, если решает измеренную проблему, а не потому, что предыдущий слой выглядит старым.030303Под большинством этих контуров обработки данных и сервисных сеток лежит Envoy — про его историю (и про то, как один баг с обработкой дат разлогинил миллионы людей) есть отличный документальный фильм. Разбирал его в канале.Книжный куб · документалка Inside Envoy

Разделение на кластеры полезно: разный радиус поражения, версии, регионы, арендаторы и требования к обновлениям. Но само число контуров управления ничего не гарантирует. В марте 2023 года Datadog потерял сеть более чем на 60% экземпляров в пяти регионах и трёх облаках. Исправление безопасности systemd приехало через общий механизм автообновлений и удалило маршруты Cilium. Флот был распределён географически и провайдерски, но оставался коррелирован через образ ОС и политику обновления.

Та же ловушка встречается в радиальной схеме GitOps, едином реестре, глобальном поставщике идентификации, общем обработчике допуска и одном шаблоне Cluster API. Сотня кластеров, обновляемых одной политикой за час, — это один домен отказа с сотней контуров управления. Настоящая независимость требует разнести не только среды выполнения, но и пути доставки изменений, доверие, артефакты и полномочия.040404Устойчивость — это архитектурная характеристика, которую проектируют, а не свойство числа кластеров. Хорошее саммари про сбои, отказы и устойчивость из «Continuous Architecture in Practice» есть в канале.Книжный куб · Resilience как архитектурная характеристика

У количества кластеров есть и прямая цена. В EKS обычная поддержка контура управления тарифицируется по $0,10 в час, а расширенная поддержка старой версии — по $0,60 (прайс на июль 2026 года). На флоте из пятидесяти кластеров отложенные обновления превращаются из неудобства в отдельную бюджетную строку. Многокластерная схема имеет смысл как осознанная модель изоляции, а не как рефлекс «поднимем ещё один».

Платформенная инженерия появилась не потому, что разработчики захотели ещё один портал. Kubernetes стандартизировал среду выполнения, но оставил продуктовой команде слишком много решений: пакет развёртывания, политики, сеть, наблюдаемость, секреты, поэтапный запуск и ответственность. Внутренняя платформа разработки собрала эти решения в золотой путь и предложила самообслуживание вместо тикетов. Team Topologies дала для этого правильную цель — снижать когнитивную нагрузку — и полезное ограничение: Thinnest Viable Platform может быть не порталом, а курированным набором договорённостей.050505Свой подкаст Code of Leadership я начинал ровно с разбора Team Topologies — в гости позвал коллегу, который годами развивал у нас IDP. Запись — в канале.Книжный куб · Code of Leadership #1 про Team Topologies

Backstage показал продуктовую форму: каталог, шаблоны, документация, плагины. В больших организациях она естественна. У Авито платформа обслуживает тысячи сервисов и прячет Kubernetes за app.toml и CLI. У Ozon единообразие важнее локальной идеальности. Т-Банк строит собственную платформу с конца 2020 года командой примерно из пятидесяти человек. Эти кейсы доказывают не то, что IDP нужна всем, а то, сколько масштаба и устойчивой ответственности требуется для настоящего внутреннего PaaS.

Разработчику лучше, системе — не обязательно

DORA 2024 зафиксировала парадокс: использование внутренней платформы связано с ростом индивидуальной продуктивности на 8% и командной на 10%, но одновременно со снижением пропускной способности изменений на 8% и стабильности изменений на 14%. Авторы предлагают осторожную интерпретацию через J-curve: незрелая платформа сначала добавляет переходные издержки. Возможны и менее удобные объяснения — дополнительная очередь, слишком толстая абстракция или платформа, оптимизированная по удовлетворённости вместо потока.

Здесь проходит граница между золотым путём и золотой клеткой. Сэм Ньюман предупреждает: обязательная платформа теряет стимул быть удобной, потому что пользователь не может уйти. С другой стороны, безопасность, соблюдение требований и аудит не работают как факультативная рекомендация. Разрешить всё — не продуктовый подход. Запретить любой выход — тоже. Легитимный мандат ограничивается проверяемыми инвариантами, а не конкретной реализацией каждого шага.

• —обязательны идентификация, журнал аудита, шифрование и свидетельства соблюдения политик;
• —предпочтительны, но заменяемы шаблон сервиса, CI/CD и интерфейс самообслуживания;
• —исключения имеют владельца, срок жизни и цену сопровождения;
• —платформа измеряет не число созданных компонентов, а время поставки, надёжность и долю безопасно завершённых сценариев.

AI-нагрузки снова показали границу исходной модели Kubernetes. Среда подключаемых устройств появилась в 1.8, но долго видела GPU только как целое число. MIG, разделение по времени, отдельные планировщики и GPU Operator закрывали разрыв каждый своим способом. Dynamic Resource Allocation достиг GA в 1.34 после редизайна API, а дробная ёмкость всё ещё развивалась отдельно. Это тот же цикл: маленький примитив, растущие требования, экосистема костылей и более явная модель в ядре.

CNCF называет Kubernetes де-факто операционной системой для AI, а поставщики оптимизаторов планирования по своей телеметрии сообщают о низкой утилизации дорогих GPU. Второе я привожу как наблюдение из их публикаций, а не как измерение индустрии: сводного исследования утилизации с раскрытой методикой у меня нет. Такие цифры нельзя смешивать: первая описывает внедрение среди контейнерных пользователей, вторая — телеметрию конкретного оптимизатора с собственной выборкой. Вместе они формулируют хороший вопрос: помогает ли стандарт управлять нагрузкой или лишь делает знакомым интерфейс к новой неэффективности?

Убрать человека от kubectl хотели до LLM

Ещё в 2017 году Келси Хайтауэр сравнивал kubectl с новым SSH: прямое управление рабочей средой человеком — симптом отсутствующего более высокого интерфейса. Сегодня эту роль примеряют K8sGPT, kubectl-ai, HolmesGPT, kagent и MCP-серверы. Но ассистирование нельзя выдавать за автономность. ITBench от IBM Research содержит 94 воспроизводимых SRE, CISO и FinOps сценария; лучшие агенты в исходной работе решили 13,8% SRE-задач, 25,2% задач безопасности и ни одной FinOps-задачи. Это далеко от права свободно менять рабочую среду.060606Тот же Хайтауэр в свежем интервью смеётся, что проектирование запросов — это ещё один нестабильный язык программирования: инженеры годами боролись за детерминизм, а теперь добавляют по 500 файлов Markdown с запросами. Разбирал это интервью в канале.Книжный куб · Kelsey Hightower, часть 1Книжный куб · Kelsey Hightower, часть 2

Полезный агент начинается с диагностики только для чтения, наследует идентификацию и RBAC пользователя, показывает свидетельства и умеет передать расследование человеку. Де-факто популярный Kubernetes MCP Server из организации containers идёт напрямую в API server и имеет режимы --read-only и --disable-destructive. Наличие флага — ещё не полноценное управление, но оно правильно обозначает границу: право читать кластер и право менять его — разные продукты с разными проверками.

Здесь и начинается архитектурное управление агентами. Лестница read → recommend → approve → act → rollback должна быть привязана не к «умности модели», а к конкретной возможности. Для перезапуска Pod, отката выпуска и вывода узла из работы нужны разные политики, песочница, радиус поражения и критерии остановки. На каждом уровне сохраняются идентификация, решение политики, трейс, передача человеку и проверенный откат. Иначе агент становится новым фрагментом: удобным обходным путём, который однажды превратится в неуправляемый API.

Вопрос «нужен ли Kubernetes?» слишком грубый. Нужно выбрать толщину операционной модели. Команде из десяти человек может хватить Docker и управляемое развёртывание. Десяткам команд может быть нужен общий Kubernetes API, но не собственный портал. Полноценная IDP оправдана, когда повторяемый спрос, соответствие требованиям и стоимость координации действительно больше стоимости отдельного платформенного продукта.

Карта оценки перед новым слоем

Это не сравнительный тест зрелости и не универсальный порог по числу разработчиков. Это шесть вопросов, которые заставляют посчитать цену ответственности до того, как появится ещё один обязательный API.

Если нет измеримой проблемы, постоянного владельца и плана удаления, безопаснее не строить слой. Если проблема существует, но пользователей мало, начинайте с TVP: документации, шаблона и одной хорошо наблюдаемой возможности. Портал, контур управления и агент появляются только после того, как доказан повторяемый спрос.070707Ровно про это — доклад Грегора Хопе «Build Abstractions Not Illusions»: чрезмерная абстракция выбрасывает важное и превращается в протекающую иллюзию. Пересказывал его в канале.Книжный куб · Build Abstractions Not Illusions

И это возвращает к вопросу из заголовка. Kubernetes усложнили не архитекторы ядра и не авторы YAML: сложность переехала туда, где её никто не считает бюджетом — в аннотации контроллеров, в платформенную команду, в подсказку агента. Вопрос «кто его усложнил» на практике звучит иначе: кто согласится дежурить по этому слою через три года и чем он будет мерить, что слой окупился. Пока на него нет ответа с именем и метрикой, следующий слой добавлять рано.