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.Книжный куб · история Log4Shell01Классический сюжет: критичную для всего интернета библиотеку тоже сопровождала горстка волонтёров. Историю Log4Shell я пересказывал в канале со слов мейнтейнера Log4j.Книжный куб · история Log4Shell

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

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

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

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

nftables-режим kube-proxy достиг GA в Kubernetes 1.33 и устранил линейный поиск по iptables-цепочкам без замены плагина Container Network Interface (CNI).

Режим ambient в Istio убрал sidecar-прокси из каждого пода через Rust-компонент ztunnel, а не через обязательный eBPF.

У каждой технологии своя задача. Производительность тоже нужно оценивать отдельно: в одном из своих сетевых тестов Cilium показывает почти миллион запросов в секунду, но этот результат получен на двухузловом стенде со 100-гигабитной сетью. Его нельзя автоматически переносить на кластер из пятидесяти нод. Новая плоскость данных полезна, если решает измеренную проблему, а не потому, что предыдущий слой выглядит старым.030303Под большинством этих контуров обработки данных и сервисных сеток лежит Envoy — про его историю (и про то, как один баг с обработкой дат разлогинил миллионы людей) есть отличный документальный фильм. Разбирал его в канале.Книжный куб · документалка Inside Envoy03Под большинством этих контуров обработки данных и сервисных сеток лежит Envoy — про его историю (и про то, как один баг с обработкой дат разлогинил миллионы людей) есть отличный документальный фильм. Разбирал его в канале.Книжный куб · документалка Inside Envoy

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

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

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

Kubernetes стандартизировал запуск контейнерных приложений, но продуктовым командам всё ещё приходилось самим отвечать на практические вопросы: как собирать и развёртывать приложение, настраивать политики, сеть, наблюдаемость и секреты, безопасно выпускать изменения и кто отвечает за дальнейшую эксплуатацию. Платформенная инженерия выносит повторяющуюся часть этой работы в общий внутренний продукт: платформенная команда поддерживает шаблоны, автоматизацию и проверки, а продуктовые команды по-прежнему отвечают за свои приложения. Внутренняя платформа разработки собирает эти возможности в золотой путь и предлагает самообслуживание вместо тикетов. Team Topologies дала для этого правильную цель — снижать когнитивную нагрузку — и полезное ограничение: Thinnest Viable Platform может обходиться без отдельного веб-портала; иногда достаточно поддерживаемого набора правил и шаблонов.050505Свой подкаст Code of Leadership я начинал ровно с разбора Team Topologies — в гости позвал коллегу, который годами развивал у нас IDP. Запись — в канале.Книжный куб · Code of Leadership #1 про Team Topologies05Свой подкаст 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 только как целое число. NVIDIA Multi-Instance GPU (MIG) делит один GPU на изолированные экземпляры. Разделение по времени, отдельные планировщики и GPU Operator закрывали тот же разрыв другими способами. Dynamic Resource Allocation достиг GA в 1.34 после редизайна API, а дробная ёмкость всё ещё развивалась отдельно. Это тот же цикл: маленький примитив, растущие требования, экосистема костылей и более явная модель в ядре.

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

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

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

В мае 2026 года IBM и Artificial Analysis продолжили эту работу в ITBench-AA: 59 SRE-задач по офлайн-снимкам инцидентов в Kubernetes, 40 открытых и 19 непубличных контрольных, по три прогона на задачу. На старте лучший результат составил 47%; по состоянию на 11 августа 2026 года лидер обновляемой таблицы набрал 56,2% по метрике, которая обнуляет прогон при пропуске хотя бы одной первопричины и иначе штрафует за лишние сущности. С исходными 13,8% диагностики SRE это число напрямую не сравнивается: изменились набор задач, среда выполнения и метрика. Ни одна из двух цифр не измеряет безопасное устранение инцидента в рабочей среде и не даёт агенту права свободно её менять.

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

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

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

У этой шкалы есть и честный ноль. Лагерь «не берите Kubernetes вообще» — Nomad, ECS, serverless-платформы или репатриация из облака в духе 37signals — это не ретроградство, а рациональный ответ команд без платформенных амбиций: там, где никто не собирается строить общий слой поставки, оркестратор общего назначения покупает возможности, которыми некому владеть. Карта из шести вопросов ниже даёт этому лагерю точную формулировку: если ни на один вопрос нет ответа с именем владельца, «не брать» честнее, чем «взять и отложить сложность на потом».

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

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

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

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