Классический цикл «Build-Push-Deploy» прост только на бумаге. В реальности мы регулярно упираемся в проблему: пайплайн отработал идеально, тесты прошли, артефакт собран… и релиз улетает в кластер, который прямо сейчас находится под высокой нагрузкой (Memory pressure, CPU throttling или риски OOM).
Обычно эту проблему решают написанием громоздких bash/python-скриптов или запросов к API Prometheus, которые проверяют Deployment Gates. Но эти скрипты жесткие, хрупкие и требуют постоянного обслуживания.
На смену им приходит Agentic CI/CD — подход, где роль гейткипера перед деплоем выполняет AI-агент, взаимодействующий с инфраструктурой через Model Context Protocol (MCP).
Как это работает на практике?
Вместо выполнения захардкоженного скрипта GitHub Actions обращается к Elastic MCP Server и запрашивает статус кластера на понятном языке.
⚪️Сбор метрик: OpenTelemetry Collector непрерывно собирает данные о состоянии Kubernetes-кластера.
⚪️AI-агент: в Elastic создается специализированный
Observability Kubernetes Agent с системными инструкциями и кастомными ES|QL-инструментами для анализа ресурсов.⚪️Запрос из CI/CD: GitHub Actions через MCP-протокол отправляет агенту промпт:
«Скажи, использует ли кластер otel-test более 25% CPU или памяти на любом из узлов?»
⚪️Принятие решения: агент запрашивает метрики, находит просадку, форматирует понятный отчет и отдаёт статус. Если кластер нестабилен — пайплайн автоматически падаёт до этапа синхронизации в ArgoCD/Flux.
Зачем это нужно?
⚪️ Вы не тратите ресурсы на выкатку релиза в падающий или перегруженный кластер.
⚪️ Агент может учитывать сразу комплекс факторов (метрики, активные алерты, динамические пороги), а не просто сверять одну статичную цифру.
⚪️ В логах CI/CD остается не безымянный
exit code 1, а человекочитаемый разбор от агента с указанием конкретной ноды и метрик.@DevOpsKaz 😛