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

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

облако → ВМ → 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 как технологию.
Это эксперимент про слои, границы и поведение автономного агента.

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