Продолжение эксперимента: где автономный агент теряет слой в Kubernetes

В первой статье я описал эксперимент с автономным ИИ-агентом и предложил модель слоёв исполнения:
агент должен понимать, на каком уровне системы он сейчас работает и где именно возникла проблема.

Если в предыдущем эксперименте слои выглядели так:

облако → ВМ → Docker → приложение

то следующим логичным шагом стал Kubernetes — со значительно более сложной и размытой границей ответственности:

облако → managed Kubernetes → node group → kubectl → ingress → облачные ресурсы

Это вторая статья серии и продолжение того же эксперимента.

Цель эксперимента

Задача формулировалась намеренно просто:

• создать Managed Kubernetes в Yandex Cloud

• создать node group

• подключиться к кластеру через kubectl

• установить ingress-nginx

• получить внешний доступ к сервису

Без Terraform.
Без GitOps.
Без ручного выполнения команд человеком.

Агент сам выполняет действия.
Человек остаётся в контуре контроля и наблюдает поведение.

Почему Kubernetes — это отдельный уровень сложности

В прошлых экспериментах агент работал в относительно линейной модели:

• команда → результат

• ошибка → исправление

• состояние меняется сразу

Kubernetes меняет эту модель:

• состояние декларативное

• результат появляется асинхронно

• часть решений принимает Kubernetes

• часть решений остаётся за облачным провайдером

Для агента это означает:
нужно удерживать несколько слоёв одновременно, а не просто исполнять команды.

Что агент сделал корректно

С точки зрения выполнения шагов агент отработал уверенно:

• кластер Managed Kubernetes был создан

• node group вышла в состояние RUNNING

• kubeconfig получен

• kubectl-контекст корректно настроен

• ingress-nginx установлен

• ресурсы Kubernetes создавались без ошибок

Если смотреть только на Kubernetes, всё выглядело правильно.

Где возникла проблема

После установки ingress-nginx сервис типа LoadBalancer остался в состоянии <pending>.

Важно подчеркнуть:

В событиях сервиса Kubernetes прямо указывалось, что облако отказалось создавать внешний Load Balancer из-за исчерпанной квоты.

Поведение агента: ключевое наблюдение

Именно здесь эксперимент стал по-настоящему интересным.

Лишние действия на неверном слое

Несмотря на то что причина была указана в логах, агент:

• выполнил 8 (!) лишних действий

• повторно проверял Ingress и Service

• пересоздавал или перепроверял ресурсы Kubernetes

• продолжал действовать на уровне кластера, хотя проблема находилась на уровне облака

То есть агент не сопоставил ошибку с правильным слоем системы.

Неуверенная гипотеза

Спустя некоторое время агент всё же предположил:

Но это была неуверенная гипотеза, а не чёткий вывод.
Он не перешёл сразу к проверке квот и продолжал ожидать изменений внутри Kubernetes.

После расширения квоты

Квота на Load Balancer была расширена вручную.

После этого:

• внешний IP был успешно выделен

• Service перешёл в рабочее состояние

• агент продолжил выполнение сценария без дополнительных исправлений

Это подтверждает, что:

• декларативная часть Kubernetes была корректной

• ошибка находилась ниже уровня кластера

Почему это важно в модели слоёв

Это и есть результат эксперимента.

Агент:

• умеет работать на уровне Kubernetes

• читает состояние ресурсов

• корректно применяет манифесты

Но он пока не делает жёсткую привязку ошибки к конкретному слою:

• проблема была в облаке

• действия выполнялись в Kubernetes

Это не баг исполнения.
Это дефицит интерпретации слоёв.

Отдельное наблюдение: поведение при отсутствии домена

После появления внешнего IP возникла следующая практическая задача:
Ingress маршрутизирует трафик по HTTP Host, а домена нет.

Здесь поведение агента было другим — и показательно правильным.

Он не полез в облачный слой (DNS-зоны, домены),
а остался внутри слоя Kubernetes, который уже удерживал.

В рамках этого слоя агент сам предложил использовать “ленивый DNS” через nip.io — как способ получить доменные имена без выхода за границы текущего контекста.

Фактически его рассуждение укладывалось в Kubernetes-логику:

• Ingress маршрутизирует по Host

• Host можно задать любым доменным именем

• DNS должен резолвить это имя в IP балансера

• публичная DNS-зона решает это без настройки инфраструктуры

Это решение:

• не требовало домена

• не требовало настройки DNS

• полностью укладывалось в Kubernetes-слой

• позволило сразу проверить маршрутизацию

Важно:
здесь nip.io — не фича и не рекомендация, а маркер того, что агент корректно сопоставил слой задачи.

Контраст внутри одного эксперимента

В одном и том же сценарии агент показал два разных типа поведения:

• с Load Balancer — долго действовал на неверном уровне

• с доменом — сразу остался в правильном слое

Именно этот контраст делает эксперимент ценным.

Главный вывод

Этот эксперимент показал, что автономный агент:

• уже уверенно работает на уровне Kubernetes

• удерживает kubectl-контексты

• разворачивает инфраструктурные компоненты

Но:

В результате:

• выполняются лишние действия

• теряется время

• гипотезы формулируются поздно и неуверенно

И да — без понимания логов со стороны человека проблема могла бы так и остаться нерешённой

Что дальше

Следующий логичный шаг эксперимента:

• научить агента:

  • сразу классифицировать ошибки по слою

  • отделять проблемы Kubernetes от проблем облака

  • прекращать действия на неверном уровне

  • менять стратегию осознанно

Это уже переход к следующему уровню автономности —
не просто исполнение, а интерпретация границ ответственности.

Вместо итога

Это продолжение эксперимента не про Kubernetes как технологию.
Это эксперимент про слои, границы и поведение автономного агента.

Именно здесь сейчас проходит его реальный предел.