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

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

облако → ВМ → 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
продолжал действовать на уровне кластера, хотя проблема находилась на уровне облака

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

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

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

возможно, проблема связана с квотами на Load Balancer

Но это была неуверенная гипотеза, а не чёткий вывод.
Он не перешёл сразу к проверке квот и продолжал ожидать изменений внутри 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 как технологию.
Это эксперимент про слои, границы и поведение автономного агента.

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

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