Badanie awarii GKE za pomocą interfejsu Antigravity CLI i rozszerzenia SRE oraz tworzenie szczegółowego raportu po awarii

1. Wprowadzenie

856ff52e60953a92.png

Last Updated: 2026-05-13

Zbadaj awarię GKE za pomocą rozszerzenia SRE i utwórz szczegółowy raport poawaryjny

Witamy na warsztatach SRE dla operatorów, którzy chcą eksperymentować z narzędziami SRE w Google Cloud.

W tym ćwiczeniu dowiesz się, jak to zrobić:

  1. Zainstaluj klaster GKE na podstawie znanego projektu open source microservices-demo.
  2. Wywołaj przerwę w działaniu, przerywając ją na różne sposoby (niektóre bardziej uderzające, inne bardziej subtelne).
  3. Zainstaluj i użyj interfejsu Antigravity CLI (lub podobnego narzędzia) oraz rozszerzenia SRE w dalszej części.
  4. Sprawdź i spróbuj usunąć przyczynę awarii.
  5. Utwórz analizę po fakcie.
  6. Użyj umiejętności tworzenia wykresów, aby wygenerować wykres z uzasadnieniem, który pozwoli widzom zrozumieć, co się wydarzyło i kiedy.

Ćwiczenia z programowania są podzielone na te sekcje:

Diagram struktury ćwiczeń z programowania

Celem tych warsztatów jest:

  1. zaprezentować możliwości rozszerzenia SRE i pokazać, co można dzięki niemu zrobić: konfiguracja OneMCP, Safe Executor, dochodzenie, generowanie raportów po awarii, wykresy i wyciągi z plików CSV.
  2. nauczyć Cię umiejętności potrzebnych do zbadania własnego scenariusza Google Cloud;

Kamień milowy 1. Konfiguracja środowiska i symulacja awarii

Celem tego etapu jest skonfigurowanie przykładowej aplikacji Kubernetes w GKE Autopilot, zainstalowanie Antigravity CLI i sztuczne wywoływanie scenariuszy awarii klastra GKE w celu symulowania incydentów w środowisku produkcyjnym.

Etap 2. Analiza i ograniczanie zagrożeń za pomocą rozszerzenia SRE

Po uszkodzeniu środowiska użyjesz narzędzi CLI opartych na agentach wyposażonych w rozszerzenie SRE, aby systematycznie odkrywać infrastrukturę, klasyfikować problemy, wdrażać bezpieczny wzorzec wykonywania poprawek i weryfikować stan klastra.

Milestone 3: Post Mortem and Graph Generation

Po rozwiązaniu problemu wygenerujesz dokument podsumowujący incydent w formie strukturalnej i użyjesz interfejsów GCM (Google Cloud Monitoring) API, aby pobrać rzeczywiste dane dotyczące pomiarów. Następnie utworzysz wykresy wizualne, aby udokumentować, kiedy i jak doszło do awarii.

Co utworzysz

W tym ćwiczeniu dowiesz się, jak badać i naprawiać awarie GKE za pomocą rozszerzenia SRE. W ramach ćwiczenia:

  • Symulowanie awarii GKE za pomocą blokowania zasad sieciowych, wadliwych wdrożeń kanarkowych i aktualizacji reguł zapory sieciowej.
  • Przeprowadź wstępną analizę awarii klastra za pomocą asystenta interfejsu wiersza poleceń opartego na rozszerzeniu SRE.
  • Bezpiecznie wdrażaj działania naprawcze za pomocą wzorca Safe Executor.
  • Wygeneruj obszerny dokument po zakończeniu projektu.
  • Wyświetlanie wskaźników incydentów na wykresie za pomocą zapytań dotyczących szeregów czasowych Google Cloud Monitoring.

Czego się nauczysz

  • Jak sprawdzać zasoby i zasady Kubernetes w GKE za pomocą umiejętności związanych z rozszerzeniem SRE.
  • Jak korzystać z wzorca bezpiecznego wykonawcy, aby uruchamiać polecenia sugerowane przez agenta z odpowiednią oceną ryzyka.
  • Jak używać umiejętności monitoring-graphs do generowania wykresów wskaźników powiązanych ze źródłami informacji bezpośrednio z GCM.
  • Jak dokumentować wyniki incydentów w uporządkowanym formacie analizy po incydencie.

Czego potrzebujesz

  • Projekt Google Cloud z włączonymi płatnościami.
  • Narzędzia wiersza poleceń: gcloud, kubectl, terraform.
  • Antigravity CLI zainstalowany lokalnie lub w Cloud Shell.
  • IDE (np. vscode, IntelliJ, RubyMine lub Vim).

Dlaczego warto korzystać z rozszerzenia SRE i interfejsu wiersza poleceń Agentic?

Awarie produkcyjne są dynamiczne i wymagają korelacji w wielu podsystemach (zasoby Kubernetes, sieci VPC, dane Cloud Monitoring, uprawnienia IAM). Rozszerzenie SRE umożliwia pomocniczym interfejsom wiersza poleceń opartym na agentach (takim jak interfejs wiersza poleceń Antigravity) działanie jako autonomiczne narzędzia wspomagające, które wykonują wstępnie skompilowane podręczniki, wysyłają zapytania do wykresów monitorowania i sugerują bezpieczne rozwiązania, jednocześnie informując operatora.

2. Przygotowania

Wybierz jedną z tych opcji: Self-paced environment setup (Konfiguracja środowiska we własnym tempie), jeśli chcesz uruchomić to

codelab na własnym komputerze lub uruchom Cloud Shell, jeśli chcesz przeprowadzić ten codelab w całości w chmurze.

Samodzielne konfigurowanie środowiska

  1. Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub użyj istniejącego. Jeśli nie masz jeszcze konta Gmail lub Google Workspace, musisz je utworzyć.

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • Nazwa projektu to wyświetlana nazwa dla uczestników tego projektu. Jest to ciąg znaków, który nie jest używany przez interfejsy API Google. Zawsze możesz ją zaktualizować.
  • Identyfikator projektu jest unikalny we wszystkich projektach Google Cloud i nie można go zmienić po ustawieniu. Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się tym przejmować. W większości ćwiczeń z programowania musisz odwoływać się do identyfikatora projektu (zwykle oznaczanego jako PROJECT_ID). Jeśli wygenerowany identyfikator Ci się nie podoba, możesz wygenerować inny losowy identyfikator. Możesz też spróbować własnej nazwy i sprawdzić, czy jest dostępna. Po tym kroku nie można go zmienić i pozostaje on taki przez cały czas trwania projektu.
  • Warto wiedzieć, że istnieje też trzecia wartość, numer projektu, której używają niektóre interfejsy API. Więcej informacji o tych 3 wartościach znajdziesz w dokumentacji.
  1. Następnie musisz włączyć płatności w konsoli Cloud, aby korzystać z zasobów i interfejsów API Google Cloud. Wykonanie tego laboratorium nie będzie kosztować dużo, a może nawet nic. Aby wyłączyć zasoby i uniknąć naliczania opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub projekt. Nowi użytkownicy Google Cloud mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.

Uruchamianie Cloud Shell

Z Google Cloud można korzystać zdalnie na laptopie, ale w tym ćwiczeniu użyjesz Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.

W konsoli Google Cloud kliknij ikonę Cloud Shell na pasku narzędzi w prawym górnym rogu:

Aktywowanie Cloud Shell

Uzyskanie dostępu do środowiska i połączenie się z nim powinno zająć tylko kilka chwil. Po zakończeniu powinno wyświetlić się coś takiego:

Zrzut ekranu terminala Google Cloud Shell pokazujący, że środowisko zostało połączone

Ta maszyna wirtualna zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera również stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i usprawnia proces uwierzytelniania. Wszystkie zadania w tym laboratorium możesz wykonać w przeglądarce. Nie musisz niczego instalować.

3. Wymagania wstępne (instalacja)

W tym samouczku musisz zainstalować:

1. Python i uv

python i uv (menedżer pakietów dla Pythona). Sprawdź, czy masz zainstalowany pakiet uv:

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

Dlaczego uv? Możesz używać dowolnego menedżera Pythona, ale użycie uv zapewni, że konfiguracja ENV/PATH dla Pythona będzie taka sama dla Ciebie i interfejsu wiersza poleceń Antigravity, więc środowisko powłoki będzie w większości takie samo jak w przypadku interfejsu wiersza poleceń Antigravity. Jeśli na przykład używasz virtualenv , Antigravity CLI będzie musiał wykonać czynności takie jak „source .env/venv/bin/activate && my-original-command”, aby naśladować Twoje środowisko.

2. Antigravity CLI (agy)

Aby zainstalować oficjalny Antigravity CLI (polecenie agy), otwórz terminal i uruchom instalator początkowy:

W systemach macOS i Linux:

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

W systemie Windows (PowerShell):

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

Ten skrypt dynamicznie wykryje Twój system operacyjny i architekturę, a następnie pobierze najnowszą skompilowaną wersję

agy

plik binarny i skonfiguruj zmienną PATH. Aby zmiany zaczęły obowiązywać, uruchom ponownie terminal lub załaduj ponownie konfigurację powłoki.

efade99623113f1.png

Uwierzytelnianie

Musisz mieć klucz interfejsu API Google AI Studio.

Wyeksportuj klucz interfejsu API:

export GEMINI_API_KEY="your-api-key"

Uwierzytelnij się za pomocą gcloud:

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

Konfigurowanie środowiska pracy i wdrażanie aplikacji demonstracyjnej mikroserwisów

Sklonujmy aplikację microservices-demo i wdróżmy infrastrukturę oraz aplikację za pomocą Terraform.

W tym momencie możesz otworzyć IDE (Visual Studio Code, IntelliJ, RubyMine itp.) i otworzyć folder.

# 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

Aby przetestować konfigurację, możesz otworzyć adres http://[IP ADDRESS] i wczytać aplikację online-boutique.

Konfigurowanie środowiska pracy na potrzeby 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. Krok 1. Symulacja awarii (scenariusze awarii)

W tym kroku celowo uszkodzimy wdrożony klaster GKE, aby zasymulować rzeczywiste zdarzenie produkcyjne. Masz do wyboru 3 scenariusze (możesz też wypróbować je wszystkie po kolei):

Scenariusz 1. Blokada sieci usługi płatności (standardowa/autopilot)

Ten scenariusz symuluje zerwane połączenie między interfejsem a usługą płatności przez zastosowanie Kubernetes NetworkPolicy, który działa jak „czarna dziura” dla ruchu.

  1. Przejdź do folderu scenariusza: 
    cd breakage1-checkout
  2. Wywołaj uszkodzenie: 
    ./break.sh
    Tworzy to zasadę sieciową o nazwie update-checkout-from-frontend w przestrzeni nazw default, która odrzuca ruch przychodzący do checkoutservice, chyba że pochodzi on z poda z etykietą app: frontend-checkout-test (która nie istnieje).
  3. Spróbuj kupić produkty w interfejsie Online Boutique. Strona płatności zawiesi się lub wyświetli błąd HTTP 500.

Scenariusz 2. Wprowadzenie wersji kanaryjskiej z błędami (autopilot z Istio)

Ten scenariusz symuluje nieprawidłowe wdrożenie, w którym wadliwa wersja frontendu jest wdrażana za pomocą wdrożenia do wczesnych testów Kubernetes.

  1. Przejdź do folderu scenariusza: 
    cd ../breakage2-canary
  2. Wywołaj uszkodzenie: 
    ./break.sh
    Wdraża to wdrożenie do wczesnych testów frontend-canary, które zawiera błąd w zmiennych środowiskowych: PRODUCT_CATALOG_SERVICE_ADDR jest skonfigurowane na productcatalogservices:3550 zamiast productcatalogservice:3550.
  3. Załaduj stronę główną interfejsu. Czasami może się to nie udać (w zależności od wag routingu), ponieważ usługa testowa nie może rozpoznać katalogu produktów.

Scenariusz 3. Blokada klastra zapory sieciowej VPC

Ten scenariusz symuluje błąd w konfiguracji zapory sieciowej VPC, który blokuje cały ruch przychodzący do klastra GKE.

  1. Przejdź do folderu scenariusza: 
    cd ../breakage3-firewall
  2. Wywołaj uszkodzenie: 
    ./break.sh
    Spowoduje to utworzenie reguły zapory sieciowej na poziomie VPC o nazwie frontend-ingress-v2 z wartościami priority=1 i działaniem DENY, która będzie dotyczyć ruchu przychodzącego do portów 80, 443 i 8080.
  3. Witryna Online Boutique stanie się całkowicie niedostępna, a żądania będą przekraczać limit czasu.

5. Krok 2. Badanie awarii za pomocą rozszerzenia SRE

Aplikacja nie działa, więc zacznijmy sprawdzanie za pomocą asystenta CLI (Antigravity CLI).

  1. Wróć do głównego folderu ze scenariuszami przerwania i uruchom narzędzie CLI: 
    cd ..
agy
  2. Poproś asystenta o przeprowadzenie wykrywania infrastruktury i sprawdzenia diagnostycznego: 
    Investigate my GKE cluster for outages. Are all services healthy?
  3. Co robi agent:
    • Włącza to umiejętności investigation-entrypoint i gcp-playbooks.
    • Zawiera listę podów, wdrożeń i usług Kubernetes, aby zlokalizować nieprawidłowe cele.
    • Sprawdza zasady sieciowe (w scenariuszu 1), konfiguracje wdrożenia (w scenariuszu 2) lub reguły zapory sieciowej (w scenariuszu 3).
  4. W scenariuszu 1 agent powinien zgłosić: 🔴 Zidentyfikowano incydent: NetworkPolicy o nazwie update-checkout-from-frontend izoluje pody checkoutservice.
  5. W przypadku scenariusza 2 pracownik obsługi klienta powinien zgłosić: 🔴 Zidentyfikowano incydent: wdrożenie frontend-canary jest skonfigurowane z nieprawidłowym punktem końcowym usługi productcatalogservices:3550 zamiast productcatalogservice:3550.
  6. W scenariuszu 3 pracownik obsługi klienta powinien zgłosić: 🔴 Zidentyfikowano incydent: reguła zapory sieciowej VPC frontend-ingress-v2 odrzuca ruch przychodzący na portach 80, 443 i 8080.

6. Krok 3. Ograniczanie skutków awarii i jej usuwanie

Aby usunąć awarię, użyjmy wzorca bezpiecznego wykonawcy interfejsu CLI.

  1. Poproś asystenta interfejsu wiersza poleceń o zaproponowanie i zastosowanie poprawki: 
    Propose a fix for the outage and apply it.
  2. Safe Executor w działaniu:
    • Przed wykonaniem sugerowanych poleceń rozszerzenie SRE przeprowadza kontrolę bezpieczeństwa za pomocą funkcji safe-sre-investigator.
    • Wyświetli dokładne polecenie, które zamierza uruchomić, i oceni ryzyko (np. niskie, średnie, wysokie).
    • W przypadku scenariusza 1 zaproponuje: 
      kubectl delete networkpolicy update-checkout-from-frontend
    • W przypadku scenariusza 2 zaproponuje: 
      kubectl delete deployment frontend-canary
    • W przypadku scenariusza 3 zaproponuje: 
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. Gdy interfejs wiersza poleceń wyświetli odpowiedni komunikat, potwierdź wykonanie polecenia.
  4. Odśwież stronę główną Online Boutique, aby sprawdzić, czy witryna działa i jest w pełni funkcjonalna.
  5. W powłoce możesz uruchomić odpowiedni skrypt sprawdzania scenariusza, aby zweryfikować stan: 
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

7. Krok 4. Generowanie raportu po incydencie

Kluczowym elementem cyklu życia SRE jest dokumentowanie incydentów, aby zespół mógł wyciągać z nich wnioski. Zautomatyzujmy to za pomocą umiejętności postmortem-create.

  1. W asystencie CLI poproś o napisanie dokumentu podsumowującego: 
    Create a postmortem for the checkout service network policy outage.
  2. Agent zbierze informacje o:
    • Czas rozpoczęcia incydentu (pobierany z historii lub logów poleceń interfejsu wiersza poleceń).
    • Główna przyczyna (blokująca zasada NetworkPolicy).
    • działania podjęte w celu ograniczenia tego ryzyka.
  3. W obszarze roboczym utworzy nowy plik Markdown o nazwie postmortem.md.
  4. Otwórz postmortem.md, aby sprawdzić szczegóły. Zobaczysz sekcje takie jak:
    • Podsumowanie incydentu
    • Oś czasu zdarzeń
    • Analiza głównej przyczyny (RCA)
    • Działania / środki zapobiegawcze

8. Krok 5. Dodawanie wykresów danych podstawowych

Aby analiza powypadkowa była profesjonalna, potrzebujemy wizualnych dowodów na zaistnienie zdarzenia. Użyjemy monitoring-graphs umiejętności, aby pobrać dane ciągu czasowego z Cloud Monitoring (GCM) i wygenerować wykres PNG przedstawiający wzrost liczby błędów.

  1. Poproś pomocnika CLI o wygenerowanie wykresu i dodanie go do analizy poawaryjnej: 
    Query GCM for frontend HTTP request error rates over the last 1 hour, generate a line chart, and embed it into postmortem.md.
  2. Pod maską:
    • Agent wywołuje skrypt Pythona monitoring-graphs, aby wysyłać zapytania do Cloud Monitoring.
    • Pobiera dane (np. kubernetes.io/container/restart_count lub loadbalancing.googleapis.com/https/request_count).
    • Wykres jest tworzony przy użyciu parametru matplotlib i zapisywany jako incident_metrics.png.
    • Aktualizuje plik postmortem.md, wstawiając link do zdjęcia: 
      ![Incident Metric Graph](incident_metrics.png)
  3. Otwórz wygenerowany plik incident_metrics.png, aby zobaczyć wykres ilustrujący dokładne momenty, w których klaster przestał działać i kiedy ruch wrócił do normy.

9. Krok 6. Uporządkuj

Aby uniknąć niepotrzebnych opłat za konto Google Cloud, zwalniamy miejsce, usuwając wdrożoną infrastrukturę.

  1. Przejdź do folderu terraform: 
    cd ../../microservices-demo/terraform
  2. Uruchom polecenie usuwania: 
    terraform destroy -auto-approve
  3. Sprawdź, czy wszystkie zasoby GKE w GCP zostały usunięte.

10. Gratulacje!

Udało Ci się ukończyć ćwiczenie praktyczne dotyczące badania awarii i przerw w działaniu klastra GKE.

Omówione zagadnienia:

  • Wdrożono 10-warstwową wersję demonstracyjną mikroserwisów Online Boutique w GKE.
  • Symulacja 3 awarii SRE w rzeczywistym świecie (odmowa zastosowania zasad sieci, wadliwe wdrożenie wersji testowej, odmowa zastosowania reguły zapory sieciowej VPC).
  • Używali rozszerzenia SRE dla Antigravity CLI, aby wykrywać i diagnozować awarie.
  • Wykorzystano wzorzec Safe Executor do sprawdzania i wykonywania poleceń naprawczych.
  • Utworzono profesjonalny raport pośmiertny w formacie Markdown.
  • Wysyłanie zapytań do wskaźników Cloud Monitoring w celu automatycznego generowania i osadzania wykresu incydentu opartego na faktach.

Więcej informacji o rozszerzaniu agenta CLI znajdziesz na stronie rozszerzenia SRE w GitHubie.