Не следует рассматривать ИИ-агентов и операторы Kubernetes как равноценные альтернативы внутри контура управления. Оператор предназначен для наблюдения за фактическим состоянием, его сравнения с желаемым состоянием, а затем повторяемого выполнения определённых правил, чтобы система приблизилась к заявленному результату. Агент же наиболее полезен, когда результат известен, но путь к нему требует расследования, сбора информации и оценки компромиссов.
В материале, спонсированном Cloud Native Computing Foundation (CNCF), говорится, что внедрение агентов в облачно-нативную инфраструктуру превращает определение границ полномочий в вопрос проектирования, а не просто convention. Наиболее безопасная формула заключается в том, чтобы оставить агенту ответственность за рассуждение, контекст и предложения, тогда как операторы, движки политик и детерминированные системы сохраняют полномочия по выполнению.
Контур эксплуатации, разделяющий рассуждение и выполнение
Эта модель предлагает практическую последовательность из шести этапов: наблюдение, затем диагностика, предложение, согласование, приведение в соответствие и, наконец, проверка. На первых этапах агент может проверять ресурсы, журналы, события, метрики и документацию, но автоматически не получает права применять изменения, изменять ресурсы или удалять их. Операции чтения, не связанные с чувствительными данными, можно выполнять автоматически, тогда как существенные изменения должны проходить через явное согласование или шлюз политик.
Проект kagent, проект с открытым исходным кодом в составе CNCF Sandbox, демонстрирует такой подход. Он запускает агентов как ресурсы Kubernetes и связывает их с Kubernetes, Helm, инструментами мониторинга и специализированными инструментами, позволяя расследовать проблемы или координировать работу специализированных агентов без устранения барьеров между анализом и выполнением.
Почему не следует заменять операторы языковой моделью?
Случай Karpenter ясно показывает разницу. Karpenter — это оператор, который работает с ограничениями планирования и сопоставляет ресурсы NodePools и NodeClaims. Если появляются неиспользуемые узлы, колебания ресурсов Spot или ожидающие планирования поды, эксплуатационный агент может проверить настройки NodePool и EC2NodeClass, события, журналы, Pod Disruption Budgets и метрики Prometheus в поисках причины.
Расследование может показать, что политика отключения вытеснения препятствует консолидации, бюджет нарушений не позволяет выполнять вытеснение или значение consolidateAfter приводит к предотвратимым колебаниям в изменяющейся нагрузке. Однако требуемым результатом является не общее предложение вроде «улучшить NodePool», а конкретный патч конфигурации, объясняющий доказательства и компромисс, количество потенциально затронутых узлов и продолжительность наблюдения за стабильностью.
После согласования Karpenter выполняет изменение в соответствии с имеющейся у него логикой планирования и управления нарушениями. Затем агент отслеживает результат и проверяет улучшение консолидации без увеличения времени ожидания подов или возникновения вредных нарушений. Если критерии приемки не выполнены, можно предложить откат через тот же путь.
Другой пример: Argo CD и обновления Helm
При обновлении чарта Helm, управляемом Argo CD, изменить версию в Git относительно просто, однако оценить её влияние на работающее приложение сложнее. Агент может сопоставить примечания к выпуску, текущие значения и сгенерированные данные, чтобы обнаружить, например, что новое имя значения, используемого для настройки readiness probe, может привести к незаметному возврату к значению по умолчанию.
Этот результат следует преобразовать в целенаправленный запрос на слияние, который обновляет версию и затронутые значения, объясняет операционный риск и определяет проверки перед развёртыванием. После проверки и слияния Argo CD генерирует данные и синхронизирует их в соответствии с политикой приложения. Одной успешной синхронизации недостаточно, чтобы доказать безопасность обновления: необходимо проверить показатели задержки, частоту ошибок и доступность. Если проверки не пройдены, агент может предложить отменить изменение или разработать план восстановления, учитывая, что изменения данных или схемы не всегда можно полностью отменить.
Автономность приобретается постепенно
Материал рекомендует начать с агента, предназначенного только для чтения и расследования, затем разрешить ему создавать патчи или запросы на слияние, а после этого выполнять изменения с низким риском и ограниченной областью действия при наличии чётких условий отката. Действие становится автономным только тогда, когда оно понятно и поддаётся измерению.
Редакционный комментарий: настоящее изменение здесь заключается не в добавлении агента, способного вызывать kubectl или Helm, а в перестройке контура управления таким образом, чтобы вероятностное рассуждение не превращалось в неограниченные исполнительные полномочия. Практическая ценность модели зависит от наличия поддающегося аудиту делегирования, ограниченной области действия, мониторинга и возможности отменить последствия. Ответственность за определение скорости перехода от предложения к автономности по-прежнему лежит на человеке; кроме того, материал не доказывает, что такой подход устраняет риски ошибок или делает откат возможным во всех случаях.