Разграничение ролей интеллектуальных агентов и операторов Kubernetes в циклах управления

person using MacBook Pro — Campaign Creators / Unsplash

Интеллектуальные агенты и операторы Kubernetes выполняют разные функции в процессах управления облачными системами. Операторы предназначены для обеспечения предсказуемости, они согласовывают ресурсы согласно закодированным правилам, повторяют неудачные операции и приводят систему к заявленному состоянию. Интеллектуальные агенты оказываются полезными в ситуациях, когда желаемый результат определен, но путь к нему неизвестен, что позволяет им исследовать незнакомые ситуации, собирать контекст из нескольких систем, взвешивать компромиссы и предлагать план действий.

За последние 18 месяцев инструменты для создания агентов стали частью облачного стека. CNCF приняла фреймворки агентов в свой Sandbox, а Kubernetes SIG Apps запустила Agent Sandbox как подпроект для безопасного запуска рабочих нагрузок агентов. В настоящее время команды платформ определяют возможности агентов по изменению живых кластеров, обычно через отдельные запросы на слияние и без письменной политики, так как граница между рассуждением и исполнением часто устанавливается традициями, а не архитектурным дизайном.

Безопасный архитектурный шаблон предполагает объединение этих подходов, где агент обеспечивает рассуждение и контекст, а операторы, механизмы политик и другие детерминированные системы сохраняют контроль над исполнением. Проект kagent из CNCF Sandbox реализует этот подход, запуская агентов как ресурсы Kubernetes и подключая их к Helm, средствам мониторинга и специализированным инструментам. Агенты могут проверять ресурсы, извлекать журналы, события, запрашивать метрики и консультироваться с документацией.

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

В качестве примера приводится работа с Karpenter, который сам является оператором, оценивающим ограничения планирования и согласовывающим NodePools и NodeClaims. Замена этой логики большой языковой моделью сделала бы цикл управления менее предсказуемым. Агент на базе kagent должен работать над Karpenter, анализируя конфигурации, события Kubernetes, бюджеты прерывания подов и метрики Prometheus, чтобы выяснить причины отклонения поведения системы от целей команды.

Результатом работы агента должен быть не общий совет, а конкретный патч конфигурации с представленными доказательствами и описанием компромиссов. После прохождения через фильтр одобрения или политик Karpenter выполняет согласование с помощью своей существующей логики. Аналогично, при обновлении Helm-чарта через Argo CD агент может помочь объяснить значение различий в ресурсах, сравнивая заметки к релизу и манифесты, чтобы создать точный запрос на слияние с описанием операционных рисков.