Проведите расследование сбоя GKE с помощью Antigravity CLI и расширения SRE и составьте подробный отчет о причинах произошедшего.

1. Введение

856ff52e60953a92.png

Последнее обновление: 13.05.2026

Проведите расследование сбоя GKE с помощью расширения SRE и составьте подробный отчет о причинах сбоя.

Добро пожаловать на этот семинар по SRE для операторов, желающих поэкспериментировать с инструментами SRE в Google Cloud!

Этот практический урок поможет вам в этом:

  1. Установите кластер GKE на основе известной демонстрационной версии микросервисов с открытым исходным кодом.
  2. Создайте сбой, разбив его на части разными способами (некоторые из них более эффектные, другие — более тонкие).
  3. Для выполнения следующей части установите и используйте Antigravity CLI (или аналогичный плагин) + расширение SRE .
  4. Провести расследование и, будем надеяться, устранить причину сбоя.
  5. Создайте отчет о результатах исследования.
  6. Используйте навыки построения графиков, чтобы создать наглядный график, который позволит зрителям понять, что произошло и когда.

Вот пошаговая структура этого практического занятия:

Структурная схема Codelab

Цель этого семинара:

  1. Продемонстрировать возможности расширения SRE и показать, что с его помощью можно сделать: настройка OneMCP, безопасный исполнитель, расследование, генерация отчетов о сбоях, графы и CSV-файлы с фрагментами кода.
  2. Научу вас навыкам анализа собственной ситуации в Google Cloud.

Этап 1: Настройка среды и моделирование отключения электроэнергии.

Цель этого этапа — настроить демонстрационное приложение Kubernetes на GKE Autopilot, установить Antigravity CLI и искусственно запустить сценарии сбоев кластера GKE для имитации инцидентов в производственной среде.

Этап 2: Расследование и устранение последствий с помощью расширения SRE.

После взлома среды вы будете использовать инструменты командной строки agentic, оснащенные расширением SRE, для систематического обнаружения инфраструктуры, анализа проблем, внедрения безопасного шаблона выполнения для исправлений и проверки работоспособности кластера.

Этап 3: Анализ результатов и построение графика.

После устранения неполадок вы создадите структурированный документ с анализом инцидента и используете API GCM (Google Cloud Monitoring) для получения реальных данных метрик, создавая визуальные диаграммы, документирующие, когда и как произошел сбой.

Что вы построите

В этом практическом занятии вы будете исследовать и устранять сбои в работе GKE с помощью расширения SRE. Вы научитесь:

  • Имитируйте сбой в работе GKE, используя блокировку сетевых политик, некорректные тестовые развертывания и обновления правил брандмауэра.
  • Проведите диагностику сбоя кластера с помощью CLI-помощника, работающего на базе расширения SRE.
  • Внедряйте меры по устранению неполадок безопасно, используя шаблон «Безопасный исполнитель».
  • Составьте подробный посмертный документ.
  • Построение графиков метрик инцидентов с использованием запросов временных рядов Google Cloud Monitoring.

Что вы узнаете

  • Как проверить ресурсы и политики Kubernetes в GKE с помощью навыков расширения SRE.
  • Как использовать шаблон Safe Executor для выполнения команд, предложенных агентом, с надлежащей оценкой рисков.
  • Как использовать навык monitoring-graphs для создания наглядных диаграмм метрик непосредственно из GCM.
  • Как задокументировать результаты расследования инцидента в структурированном формате посмертного исследования.

Что вам понадобится

  • Проект в Google Cloud с включенной функцией выставления счетов.
  • Инструменты командной строки: gcloud , kubectl , terraform .
  • Antigravity CLI установлен локально или в Cloud Shell.
  • Среда разработки (IDE, например, VS Code, IntelliJ, RubyMine или Vim).

Почему именно SRE Extension + Agentic CLI?

Сбои в производственной среде происходят быстро и требуют сопоставления данных из множества подсистем (ресурсы Kubernetes, сети VPC, метрики облачного мониторинга, разрешения IAM). Расширение SRE позволяет агентным помощникам CLI (например, Antigravity CLI) выступать в роли автономных помощников, выполняя предварительно скомпилированные сценарии автоматизации, запрашивая данные из графов мониторинга и предлагая безопасные решения проблем, при этом сохраняя связь с оператором.

2. Настройка

Выберите один из следующих вариантов: Самостоятельная настройка среды, если вы хотите запустить это.

Выполните практическое занятие на своем компьютере или запустите Cloud Shell, если хотите провести это занятие полностью в облаке.

Настройка среды для самостоятельного обучения

  1. Войдите в консоль Google Cloud и создайте новый проект или используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • Название проекта — это отображаемое имя участников данного проекта. Это строка символов, не используемая API Google. Вы всегда можете его изменить.
  • Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (его нельзя изменить после установки). Консоль Cloud автоматически генерирует уникальную строку; обычно вам неважно, какая она. В большинстве практических заданий вам потребуется указать идентификатор вашего проекта (обычно обозначается как PROJECT_ID ). Если сгенерированный идентификатор вас не устраивает, вы можете сгенерировать другой случайный идентификатор. В качестве альтернативы вы можете попробовать свой собственный и посмотреть, доступен ли он. После этого шага его нельзя изменить, и он сохраняется на протяжении всего проекта.
  • К вашему сведению, существует третье значение — номер проекта , которое используется некоторыми API. Подробнее обо всех трех значениях можно узнать в документации .
  1. Далее вам потребуется включить оплату в консоли Cloud для использования ресурсов/API Cloud. Выполнение этого практического задания не потребует больших затрат, если вообще потребует. Чтобы отключить ресурсы и избежать дополнительных расходов после завершения этого урока, вы можете удалить созданные ресурсы или удалить проект. Новые пользователи Google Cloud имеют право на бесплатную пробную версию стоимостью 300 долларов США .

Запустить Cloud Shell

Хотя Google Cloud можно управлять удаленно с ноутбука, в этом практическом занятии вы будете использовать Google Cloud Shell — среду командной строки, работающую в облаке.

В консоли Google Cloud нажмите на значок Cloud Shell на панели инструментов в правом верхнем углу:

Активировать Cloud Shell

Подготовка и подключение к среде займут всего несколько минут. После завершения вы должны увидеть что-то подобное:

Скриншот терминала Google Cloud Shell, показывающий, что среда подключена.

Эта виртуальная машина содержит все необходимые инструменты разработки. Она предоставляет постоянный домашний каталог объемом 5 ГБ и работает в облаке Google, что значительно повышает производительность сети и аутентификацию. Вся работа в этом практическом задании может выполняться в браузере. Вам не нужно ничего устанавливать.

3. Предварительные условия (Установка)

Для выполнения этого руководства вам необходимо установить:

1. Python и UV

python и uv (менеджер пакетов для Python ). Убедитесь, что у вас установлен uv :

$ curl -LsSf https://astral.sh/uv/install.sh | sh

Почему именно uv? Хотя вы можете использовать любой менеджер Python по своему усмотрению, использование uv гарантирует, что настройка ENV/PATH для Python будет одинаковой как для вас, так и для Antigravity CLI, поэтому ваш опыт работы с оболочкой будет в основном таким же, как и в Antigravity CLI. Например, если вы используете virtualenv , Antigravity CLI будет вынужден выполнять такие действия, как "source .env/venv/bin/activate && my-original-command", чтобы имитировать вашу среду.

2. Антигравитационный CLI ( agy )

Для установки официального интерфейса командной строки Antigravity (команда agy ) откройте терминал и запустите установщик начальной загрузки:

Для macOS и Linux:

$ curl -fsSL https://antigravity.google/cli/install.sh | bash

Для Windows (PowerShell):

irm https://antigravity.google/cli/install.ps1 | iex

Этот скрипт динамически определит вашу операционную систему и архитектуру, а затем загрузит последнюю скомпилированную версию.

agy

и настройте переменную PATH. Перезапустите терминал или обновите конфигурацию оболочки, чтобы изменения вступили в силу.

efade99623113f1.png

Аутентификация

Вам потребуется либо ключ API Google AI Studio .

Экспортируйте свой API-ключ:

export GEMINI_API_KEY="your-api-key"

Аутентификация с помощью gcloud:

export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
export GOOGLE_CLOUD_LOCATION="YOUR_PROJECT_LOCATION"
gcloud auth application-default login

Настройте рабочую среду и разверните демонстрационное приложение на основе микросервисов.

Давайте клонируем приложение microservices-demo и развернем инфраструктуру и приложение с помощью Terraform.

Сейчас самое время открыть свою IDE (Visual Studio Code, IntelliJ, RubyMine и т. д.) и открыть папку.

# 1. Find an empty directory, and download this repo.
git clone https://github.com/GoogleCloudPlatform/microservices-demo.git
cd microservices-demo/terraform

# 2. Update project ID to your gcloud project ID
sed -i 's/<project_id_here>/YOUR_ACTUAL_PROJECT_ID/g' terraform.tfvars

# 3. Deploy the microservices-demo application in GKE autopilot
# If there is a prompt answer yes and continue. This step can take up to 10 mins for provision gke autopilot cluster and deploy microservices-demo application
terraform init
terraform plan
terraform apply

# 4. Verify the IP address of frontend-service to access the online-boutique application
kubectl get service frontend-external | awk '{print $4}'

# 5. Find an empty directory , and download this repo.
git clone https://github.com/palladius/sre-testing-suite.git
cd sre-testing-suite/test-scenarios/microservices-demo-gke/breakage-scenarios

Чтобы проверить свою настройку, вы можете перейти по адресу http://[IP-адрес] и запустить приложение онлайн-бутика.

Настройте рабочую среду для sre-antigravity-cli-extension 

# 1. Install the SRE Extension plugin globally
git clone https://github.com/gemini-cli-extensions/sre.git ~/.gemini/config/plugins/sre-extension

# 2. Launch the Antigravity CLI (agy)
agy  # This runs the CLI under your current breakage-scenarios folder.
# Login with your corporate or personal account when prompted.

# 3. Within the agy agent prompt, configure your MCP servers and GCP project
Use the gcp-mcp-setup skill to setup my GCP project "<gcp_project_id>" with email jane-doe-sre@credible-company.com

4. Шаг 1: Моделирование отключения электроэнергии (сценарии поломок)

На этом этапе мы намеренно нарушим работу развернутого кластера GKE, чтобы имитировать реальный производственный инцидент. У вас есть три сценария на выбор (или вы можете попробовать все три последовательно):

Сценарий 1: Блокировка сети кассового обслуживания (стандартный режим/автоматический режим)

В этом сценарии имитируется разрыв соединения между фронтендом и службой оформления заказа путем применения NetworkPolicy Kubernetes, которая действует как «черная дыра» для трафика.

  1. Перейдите в папку со сценарием: 
    cd breakage1-checkout
  2. Причину поломки:
    ./break.sh
    Это создаёт сетевую политику с именем update-checkout-from-frontend в пространстве имён default , которая запрещает входящий трафик к checkoutservice , если он не исходит от пода с меткой app: frontend-checkout-test (которого не существует).
  3. Попробуйте оформить покупку на сайте интернет-магазина. Страница оформления заказа зависнет или выдаст ошибку HTTP 500.

Сценарий 2: Выезд багги Canary (автопилот с Istio)

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

  1. Перейдите в папку со сценарием: 
    cd ../breakage2-canary
  2. Причину поломки:
    ./break.sh
    В результате развертывания используется тестовая версия frontend-canary , в переменных окружения которой обнаружена опечатка: PRODUCT_CATALOG_SERVICE_ADDR настроена на значение productcatalogservices:3550 вместо productcatalogservice:3550 .
  3. Загрузите главную страницу фронтенда. Иногда это может не сработать (в зависимости от весовых коэффициентов маршрутизации), поскольку тестовый сервис не может получить доступ к каталогу товаров.

Сценарий 3: Блокировка кластера межсетевых экранов VPC

Этот сценарий имитирует ошибку в конфигурации брандмауэра VPC, которая блокирует весь входящий трафик к кластеру GKE.

  1. Перейдите в папку со сценарием: 
    cd ../breakage3-firewall
  2. Причину поломки:
    ./break.sh
    Это создаёт правило брандмауэра на уровне VPC с именем frontend-ingress-v2 , priority=1 и действием DENY , нацеленное на входящий трафик к портам 80 , 443 и 8080 .
  3. Сайт онлайн-бутика станет полностью недоступным, а запросы будут прерываться по истечении времени ожидания.

5. Шаг 2: Расследование сбоя с помощью расширения SRE.

Теперь, когда приложение недоступно, давайте начнем расследование, используя ваш CLI-помощник (Antigravity CLI).

  1. Вернитесь в основную папку со сценариями поломок и запустите вспомогательную программу командной строки: 
    cd ..
agy
  2. Попросите помощника выполнить проверку инфраструктуры на наличие уязвимостей и диагностику: 
    Investigate my GKE cluster for outages. Are all services healthy?
  3. Чем занимается агент:
    • Это активирует навыки investigation-entrypoint и gcp-playbooks .
    • Он отображает список подов, развертываний и сервисов Kubernetes для выявления неисправных целевых объектов.
    • Она проверяет сетевые политики (для сценария 1), конфигурации развертывания (для сценария 2) или правила брандмауэра (для сценария 3).
  4. Для сценария 1 агент должен сообщить: 🔴 Выявлен инцидент : NetworkPolicy с именем update-checkout-from-frontend изолирует модули checkoutservice .
  5. Для сценария 2 агент должен сообщить: 🔴 Выявлен инцидент : развертывание frontend-canary настроено с недопустимой конечной точкой службы productcatalogservices:3550 вместо productcatalogservice:3550 .
  6. Для сценария 3 агент должен сообщить следующее: 🔴 Выявлен инцидент : правило брандмауэра VPC frontend-ingress-v2 запрещает входящий трафик на портах 80 , 443 и 8080 .

6. Шаг 3: Устранение последствий отключения электроэнергии и исправление неполадок

Давайте воспользуемся шаблоном Safe Executor из командной строки, чтобы устранить сбой.

  1. Попросите вашего помощника в командной строке предложить и применить исправление: 
    Propose a fix for the outage and apply it.
  2. Safe Executor в действии:
    • Перед выполнением предложенных команд расширение SRE проводит проверку безопасности с использованием навыка safe-sre-investigator .
    • Программа покажет вам точную команду, которую она намеревается выполнить, и оценит уровень риска (например, низкий, средний, высокий).
    • В первом сценарии будет предложено следующее: 
      kubectl delete networkpolicy update-checkout-from-frontend
    • Для сценария 2 будет предложено следующее: 
      kubectl delete deployment frontend-canary
    • В третьем сценарии будет предложено следующее: 
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. Подтвердите выполнение команды, когда появится соответствующий запрос в командной строке.
  4. Убедитесь, что сайт снова работает и полностью функционален, обновив главную страницу онлайн-бутика.
  5. В командной оболочке вы можете запустить соответствующий скрипт проверки сценария, чтобы убедиться в работоспособности системы: 
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

7. Шаг 4: Составление протокола расследования инцидента.

Важной частью жизненного цикла SRE является документирование инцидента, чтобы команда могла извлечь из него уроки. Давайте автоматизируем этот процесс с помощью навыка postmortem-create .

  1. В командной строке выберите опцию создания документа по итогам расследования: 
    Create a postmortem for the checkout service network policy outage.
  2. Агент соберет информацию о следующем:
    • Время начала инцидента (получено из истории/журналов командной строки).
    • Первопричина (блокирующая сетевая политика).
    • Меры, принятые для смягчения последствий.
  3. В результате в вашей рабочей области будет создан новый файл Markdown с именем postmortem.md .
  4. Откройте postmortem.md , чтобы просмотреть подробности. Вы увидите разделы, например:
    • Краткое описание инцидента
    • Хронология событий
    • Анализ первопричин (RCA)
    • Меры по выполнению действий / Профилактические меры

8. Шаг 5: Добавление графиков обоснованных метрик

Для профессионального анализа инцидента нам необходимы визуальные доказательства. Мы воспользуемся инструментом monitoring-graphs , чтобы получить данные временных рядов из Google Cloud Monitoring (GCM) и сгенерировать диаграмму в формате PNG, показывающую всплеск ошибок.

  1. Попросите вспомогательную программу командной строки сгенерировать график и добавить его в анализ причин сбоя: 
    Query GCM for frontend HTTP request error rates over the last 1 hour, generate a line chart, and embed it into postmortem.md.
  2. Под капотом:
    • Агент вызывает скрипт Python monitoring-graphs для выполнения запросов к Cloud Monitoring.
    • Он получает метрики (например, kubernetes.io/container/restart_count или loadbalancing.googleapis.com/https/request_count ).
    • Диаграмма строится с помощью matplotlib и сохраняется как incident_metrics.png .
    • Эта функция обновляет файл postmortem.md , вставляя ссылку на изображение: 
      ![Incident Metric Graph](incident_metrics.png)
  3. Откройте сгенерированный файл incident_metrics.png , чтобы увидеть диаграмму, иллюстрирующую точные моменты, когда кластер вышел из строя, и моменты, когда трафик вернулся к нормальному состоянию.

9. Шаг 6: Уборка

Чтобы избежать ненужных расходов на ваш аккаунт Google Cloud, давайте очистим развернутую инфраструктуру.

  1. Перейдите в папку terraform: 
    cd ../../microservices-demo/terraform
  2. Выполните команду уничтожения: 
    terraform destroy -auto-approve
  3. Убедитесь, что все ресурсы GCP GKE были успешно удалены.

10. Поздравляем!

Вы завершили лабораторную работу по расследованию поломок и отключений кластера GKE!

Что вы уже рассмотрели:

  • Демонстрационный пример 10-уровневого микросервиса Online Boutique был развернут в GKE.
  • Смоделированы три реальных сбоя в работе SRE-системы (отказ в применении сетевой политики, некорректное развертывание тестовой среды, отказ в применении правила брандмауэра VPC).
  • Для обнаружения и диагностики сбоев использовалось расширение SRE для Antigravity CLI.
  • Использовали шаблон Safe Executor для проверки и выполнения команд по устранению неполадок.
  • Создал профессиональный анализ причин сбоя в Markdown.
  • Запрошенные метрики облачного мониторинга для автоматического создания и встраивания графа инцидентов.

Для получения более подробной информации о расширении возможностей вашего CLI-агента, посетите страницу расширения SRE на GitHub .