Antigravity CLI ve SRE uzantısıyla GKE kesintisini inceleme ve güzel bir Post Mortem oluşturma

1. Giriş

856ff52e60953a92.png

Last Updated: 2026-05-13

SRE uzantısıyla GKE kesintisini inceleme ve güzel bir Post Mortem oluşturma

Google Cloud'da SRE koşumlarıyla denemeler yapmak isteyen operatörler için hazırlanan bu SRE atölyesine hoş geldiniz.

Bu codelab'de şu konular ele alınmaktadır:

  1. Tanınmış bir açık kaynak microservices-demo'ya dayalı bir GKE kümesi yükleyin.
  2. Farklı şekillerde (bazıları daha çarpıcı, bazıları daha incelikli) bozarak kesinti oluşturun.
  3. Aşağıdaki bölüm için Antigravity CLI'yı (veya benzer bir koşum) + SRE Uzantısı'nı yükleyip kullanın.
  4. Kesintiyi araştırıp düzeltin.
  5. Olay sonrası analizi oluşturun.
  6. İzleyicilerin neyin ne zaman olduğunu anlamasına olanak tanıyan, temellendirilmiş bir grafik oluşturmak için grafik oluşturma becerilerini kullanın.

Codelab'in adım adım yapısı şu şekildedir:

Codelab Yapısı Diyagramı

Bu atölye çalışmasının amacı:

  1. SRE uzantısının özelliklerini gösterir ve bu uzantıyla neler yapılabileceğini (OneMCP kurulumu, Safe Executor, Investigation, Post Mortem Generation, grafikler ve CSV özetleri) anlatır.
  2. Kendi Google Cloud senaryonuzu inceleme becerilerini öğretir.

1. Aşama: Ortam Kurulumu ve Kesinti Simülasyonu

Bu kilometre taşının amacı, GKE Autopilot'ta bir Kubernetes demo uygulaması oluşturmak, Antigravity CLI'yı yüklemek ve üretimdeki olayları simüle etmek için GKE kümesi arızası senaryolarını yapay olarak tetiklemektir.

2. Ara Hedef: SRE Uzantısı ile İnceleme ve Azaltma

Ortamı bozduktan sonra, altyapıyı sistematik olarak keşfetmek, sorunları önceliklendirmek, düzeltmeler için güvenli yürütme düzenini uygulamak ve küme sağlığını doğrulamak üzere SRE uzantısıyla donatılmış agentic KSA araçlarını kullanacaksınız.

3. Aşama: Değerlendirme ve Grafik Oluşturma

Sorun çözüldükten sonra yapılandırılmış bir olay sonrası analiz belgesi oluşturacak ve gerçek metrik verilerini çekmek için GCM (Google Cloud Monitoring) API'lerini kullanarak kesintinin ne zaman ve nasıl gerçekleştiğini belgelemek için görsel grafikler oluşturacaksınız.

Ne oluşturacaksınız?

Bu codelab'de, SRE uzantısını kullanarak GKE kesintilerini inceleyip düzelteceksiniz. Bu kurstan sonra:

  • Ağ politikası engelleme, hatalı canary dağıtımları ve güvenlik duvarı kuralı güncellemelerini kullanarak GKE kesintisini simüle edin.
  • SRE uzantısı tarafından desteklenen bir KSA asistanını kullanarak küme kesintisini önceliklendirin.
  • Güvenli Yürütücü (Safe Executor) kalıbını kullanarak düzeltme adımlarını güvenli bir şekilde uygulayın.
  • Kapsamlı bir ölüm sonrası dokümanı oluşturun.
  • Google Cloud Monitoring zaman serisi sorgularını kullanarak olay metriklerini grafiğe dönüştürün.

Neler öğreneceksiniz?

  • SRE Uzantısı becerilerini kullanarak GKE Kubernetes kaynaklarını ve politikalarını inceleme.
  • Aracı tarafından önerilen komutları uygun risk değerlendirmesiyle çalıştırmak için Safe Executor kalıbından nasıl yararlanılır?
  • monitoring-graphs becerisini kullanarak doğrudan GCM'den metriklerin temellendirilmiş grafiklerini oluşturma
  • Olay bulgularını yapılandırılmış bir olay sonrası analiz biçiminde nasıl belgeleyeceğinizi öğrenin.

Gerekenler

  • Faturalandırmanın etkin olduğu bir Google Cloud projesi.
  • Komut satırı araçları: gcloud, kubectl, terraform.
  • Antigravity CLI'nın yerel olarak veya Cloud Shell'de yüklü olması gerekir.
  • Bir IDE (ör. vscode, IntelliJ, RubyMine veya Vim).

Neden SRE Extension + Agentic CLI?

Üretim kesintileri hızlı bir şekilde gerçekleşir ve birden fazla alt sistem (Kubernetes kaynakları, VPC ağları, Cloud Monitoring metrikleri, IAM izinleri) arasında korelasyon gerektirir. SRE Uzantısı, Antigravity CLI gibi ajan tabanlı CLI yardımcılarının bağımsız yardımcı pilotlar gibi davranmasına, önceden derlenmiş playbook'ları yürütmesine, izleme grafiklerini sorgulamasına ve insan operatörü sürece dahil ederek güvenli çözümler önermesine olanak tanır.

2. Hazırlanma

Aşağıdaki seçeneklerden birini belirleyin: Bu

makinenizde çalıştırabilir veya bu codelab'i tamamen bulutta çalıştırmak istiyorsanız Cloud Shell'i başlatabilirsiniz.

Yönlendirmesiz ortam kurulumu

  1. Google Cloud Console'da oturum açın ve yeni bir proje oluşturun veya mevcut bir projeyi yeniden kullanın. Gmail veya Google Workspace hesabınız yoksa hesap oluşturmanız gerekir.

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • Proje adı, bu projenin katılımcıları için görünen addır. Google API'leri tarafından kullanılmayan bir karakter dizesidir. Dilediğiniz zaman güncelleyebilirsiniz.
  • Proje kimliği, tüm Google Cloud projelerinde benzersizdir ve sabittir (ayarlandıktan sonra değiştirilemez). Cloud Console, benzersiz bir dizeyi otomatik olarak oluşturur. Genellikle bu dizenin ne olduğuyla ilgilenmezsiniz. Çoğu codelab'de proje kimliğinize (genellikle PROJECT_ID olarak tanımlanır) başvurmanız gerekir. Oluşturulan kimliği beğenmezseniz başka bir rastgele kimlik oluşturabilirsiniz. Dilerseniz kendi adınızı deneyerek kullanılabilir olup olmadığını kontrol edebilirsiniz. Bu adım tamamlandıktan sonra değiştirilemez ve proje süresince geçerli kalır.
  • Bazı API'lerin kullandığı üçüncü bir değer olan Proje Numarası da vardır. Bu üç değer hakkında daha fazla bilgiyi belgelerde bulabilirsiniz.
  1. Ardından, Cloud kaynaklarını/API'lerini kullanmak için Cloud Console'da faturalandırmayı etkinleştirmeniz gerekir. Bu codelab'i tamamlamak neredeyse hiç maliyetli değildir. Bu eğitimin ötesinde faturalandırılmayı önlemek için kaynakları kapatmak üzere oluşturduğunuz kaynakları veya projeyi silebilirsiniz. Yeni Google Cloud kullanıcıları 300 ABD doları değerinde ücretsiz deneme programından yararlanabilir.

Cloud Shell'i başlatma

Google Cloud, dizüstü bilgisayarınızdan uzaktan çalıştırılabilir ancak bu codelab'de Cloud'da çalışan bir komut satırı ortamı olan Google Cloud Shell'i kullanacaksınız.

Google Cloud Console'da sağ üstteki araç çubuğunda Cloud Shell simgesini tıklayın:

Cloud Shell'i etkinleştirme

Ortamın temel hazırlığı ve bağlantı kurulması yalnızca birkaç dakikanızı alır. İşlem tamamlandığında aşağıdakine benzer bir sonuç görürsünüz:

Ortamın bağlandığını gösteren Google Cloud Shell terminalinin ekran görüntüsü

Bu sanal makine, ihtiyaç duyacağınız tüm geliştirme araçlarıyla birlikte gelir. 5 GB boyutunda kalıcı bir ana dizin sunar ve Google Cloud üzerinde çalışır. Bu sayede ağ performansı ve kimlik doğrulama önemli ölçüde güçlenir. Bu codelab'deki tüm çalışmalarınızı tarayıcıda yapabilirsiniz. Herhangi bir şey yüklemeniz gerekmez.

3. Ön koşullar (yükleme)

Bu eğitim için yüklemeniz gerekenler:

1. Python ve uv

python ve uv (Python için paket yöneticisi). uv'nin yüklü olduğundan emin olun:

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

Neden UV? Tercih ettiğiniz Python yöneticisini kullanabilirsiniz ancak uv kullanmak, Python için ENV/PATH kurulumunun sizin ve Antigravity CLI için eşit olmasını sağlar. Böylece kabuk deneyiminiz, Antigravity CLI'nın deneyimiyle büyük ölçüde aynı olur. Örneğin , virtualenv kullanıyorsanız Antigravity CLI, ortamınızı taklit etmek için "source .env/venv/bin/activate && my-original-command" gibi işlemler yapmaya zorlanır.

2. Antigravity CLI (agy)

Resmi Antigravity CLI'yı (agy komutu) yüklemek için terminalinizi açın ve bootstrap yükleyiciyi çalıştırın:

macOS ve Linux için:

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

Windows (PowerShell) için:

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

Bu komut dosyası, işletim sisteminizi ve mimarinizi dinamik olarak algılar, derlenmiş en son

agy

ikili programı indirin ve PATH'inizi yapılandırın. Değişikliklerin geçerli olması için terminalinizi yeniden başlatın veya kabuk yapılandırmanızı yeniden yükleyin.

efade99623113f1.png

Kimlik doğrulama

Google AI Studio API anahtarı gerekir.

API anahtarınızı dışa aktarın:

export GEMINI_API_KEY="your-api-key"

gcloud ile kimlik doğrulama:

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

Çalışma ortamınızı ayarlama ve mikro hizmetler demo uygulamasını dağıtma

microservices-demo uygulamasını klonlayalım ve altyapı ile uygulamayı Terraform aracılığıyla dağıtalım.

Bu aşamada IDE'nizi (Visual Studio Code, IntelliJ, RubyMine vb.) açıp klasörü açabilirsiniz.

# 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

Ayarlarınızı test etmek için http://[IP ADRESİ] adresine erişip online-boutique uygulamasını yükleyebilirsiniz.

sre-antigravity-cli-extension için çalışma ortamınızı ayarlama

# 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. adım: Kesintiyi simüle edin (Arıza senaryoları)

Bu adımda, gerçek dünyadaki bir üretim olayını simüle etmek için dağıtılan GKE kümesini kasıtlı olarak bozacağız. Aralarından seçim yapabileceğiniz üç senaryo vardır (veya üçünü de sırayla deneyebilirsiniz):

1. Senaryo: Ödeme hizmeti ağının engellenmesi (Standart/Otomatik Pilot)

Bu senaryoda, trafik "kara deliği" görevi gören bir Kubernetes NetworkPolicy uygulanarak ön uç ile ödeme hizmeti arasındaki bağlantının bozulması simüle edilir.

  1. Senaryo klasörüne gidin: 
    cd breakage1-checkout
  2. Bozulmayı tetikleyin: 
    ./break.sh
    Bu komut, default ad alanında update-checkout-from-frontend adlı bir NetworkPolicy oluşturur. Bu politika, checkoutservice için giriş trafiğini, app: frontend-checkout-test etiketine sahip bir pod'dan gelmediği sürece (bu etiket mevcut değildir) reddeder.
  3. Online Butik ön ucunda ürün satın almayı deneyin. Ödeme sayfası kilitlenir veya HTTP 500 hatası gösterir.

2. Senaryo: Hatalı Canary Yayınlama (Istio ile Otomatik Pilot)

Bu senaryoda, ön ucun hatalı bir sürümünün Kubernetes Canary dağıtımı aracılığıyla kullanıma sunulduğu kötü bir dağıtım simüle edilir.

  1. Senaryo klasörüne gidin: 
    cd ../breakage2-canary
  2. Bozulmayı tetikleyin: 
    ./break.sh
    Bu komut, ortam değişkenlerinde yazım hatası olan bir canary dağıtımı frontend-canary dağıtır: PRODUCT_CATALOG_SERVICE_ADDR, productcatalogservice:3550 yerine productcatalogservices:3550 olarak yapılandırılır.
  3. Ön uç ana sayfasını yükleyin. Kanarya hizmeti ürün kataloğunu çözemediğinden, yönlendirme ağırlıklarına bağlı olarak zaman zaman başarısız olur.

3. Senaryo: VPC güvenlik duvarı kümesi engellemesi

Bu senaryo, VPC güvenlik duvarı yapılandırmasında GKE kümesine gelen tüm trafiği engelleyen bir hatayı simüle eder.

  1. Senaryo klasörüne gidin: 
    cd ../breakage3-firewall
  2. Bozulmayı tetikleyin: 
    ./break.sh
    Bu işlem, 80, 443 ve 8080 bağlantı noktalarına gelen trafiği hedefleyen priority=1 ve DENY işlemiyle birlikte frontend-ingress-v2 adlı bir VPC düzeyinde güvenlik duvarı kuralı oluşturur.
  3. Online Boutique web sitesine tamamen erişilemez ve isteklerin zaman aşımı gerçekleşir.

5. 2. adım: SRE uzantısıyla kesinti incelemesi

Uygulama kapalı olduğuna göre, KSA yardımcınızı (Antigravity KSA) kullanarak incelemeye başlayalım.

  1. Ana bozulma senaryoları klasörüne geri dönün ve KSA yardımcınızı başlatın: 
    cd ..
agy
  2. Asistan'dan altyapı keşfi ve teşhis kontrolü yapmasını isteyin: 
    Investigate my GKE cluster for outages. Are all services healthy?
  3. Ajanın Yaptığı İşlemler:
    • Bu işlem, investigation-entrypoint ve gcp-playbooks becerilerini etkinleştirir.
    • Başarısız olan hedefleri bulmak için Kubernetes kapsüllerini, dağıtımlarını ve hizmetlerini listeler.
    • Ağ politikalarını (Senaryo 1 için), dağıtım yapılandırmalarını (Senaryo 2 için) veya güvenlik duvarı kurallarını (Senaryo 3 için) inceler.
  4. 1. senaryoda temsilcinin bildirmesi gerekenler: 🔴 Olay Belirlendi: NetworkPolicy adlı update-checkout-from-frontend, checkoutservice pod'larını yalıtıyor.
  5. 2. senaryoda temsilci şunları bildirmelidir: 🔴 Olay tespit edildi: frontend-canary dağıtımı, productcatalogservice:3550 yerine geçersiz bir hizmet uç noktası productcatalogservices:3550 ile yapılandırılmış.
  6. 3. senaryoda temsilci şunları bildirmelidir: 🔴 Olay Belirlendi: Bir VPC güvenlik duvarı kuralı frontend-ingress-v2, 80, 443 ve 8080 bağlantı noktalarındaki giriş trafiğini engelliyor.

6. 3. adım: Kesintiyi azaltma ve düzeltme

Kesintiyi düzeltmek için CLI'nın Safe Executor (Güvenli Yürütücü) kalıbını kullanalım.

  1. CLI asistanınızdan bir düzeltme önermesini ve uygulamasını isteyin: 
    Propose a fix for the outage and apply it.
  2. Safe Executor'ın İşleyişi:
    • SRE uzantısı, komut önerilerini yürütmeden önce safe-sre-investigator becerisini kullanarak bir güvenlik denetimi gerçekleştirir.
    • Çalıştırmayı planladığı komutu tam olarak gösterir ve riski değerlendirir (ör. düşük, orta, yüksek).
    • 1. senaryo için şu önerilerde bulunur: 
      kubectl delete networkpolicy update-checkout-from-frontend
    • 2. senaryo için şu önerilerde bulunur: 
      kubectl delete deployment frontend-canary
    • 3. senaryo için şu önerilerde bulunulur: 
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. CLI tarafından istendiğinde komut yürütme işlemini onaylayın.
  4. Online Butik ana sayfasını yenileyerek web sitesinin tekrar çalıştığını ve tüm işlevlerinin kullanılabildiğini doğrulayın.
  5. Kabuğunuzda, durumu doğrulamak için ilgili senaryo kontrol komut dosyasını çalıştırabilirsiniz: 
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

7. 4. adım: Olay sonrası inceleme raporunu oluşturma

SRE yaşam döngüsünün önemli bir parçası, ekibin olaydan ders çıkarabilmesi için olayı belgelemesidir. Bu işlemi postmortem-create becerisini kullanarak otomatikleştirelim.

  1. KSA yardımcınızdan olay sonrası dokümanı yazmasını isteyin: 
    Create a postmortem for the checkout service network policy outage.
  2. Temsilci, aşağıdakilerle ilgili ayrıntıları toplar:
    • Olayın başlangıç zamanı (KSA komut geçmişinizden/günlüklerinizden alınır).
    • Kök neden (engelleme NetworkPolicy).
    • Etkilerini azaltmak için yapılan işlemler.
  3. Çalışma alanınızda postmortem.md adlı yeni bir Markdown dosyası oluşturulur.
  4. Ayrıntıları incelemek için postmortem.md simgesini açın. Şu gibi bölümler görürsünüz:
    • Olay Özeti
    • Etkinliklerin Zaman Çizelgesi
    • Temel Neden Analizi (RCA)
    • İşlem Öğeleri / Önleyici Önlemler

8. 5. adım: Temellendirilmiş metrik grafikleri ekleme

Olay sonrası analizinin profesyonel olması için olayın görsel kanıtı gerekir. Google Cloud Monitoring'den (GCM) zaman serisi verilerini getirmek ve hata artışını gösteren bir PNG grafiği oluşturmak için monitoring-graphs becerisini kullanacağız.

  1. KSA yardımcınızdan grafiği oluşturup postmortem raporuna eklemesini isteyin: 
    Query GCM for frontend HTTP request error rates over the last 1 hour, generate a line chart, and embed it into postmortem.md.
  2. Testlerin İşleyiş Şekli:
    • Aracı, Cloud Monitoring'e sorgu göndermek için monitoring-graphs Python komut dosyasını çağırır.
    • Metrikleri (ör. kubernetes.io/container/restart_count veya loadbalancing.googleapis.com/https/request_count) getirir.
    • Grafiği matplotlib kullanarak çizer ve incident_metrics.png olarak kaydeder.
    • Resim bağlantısı ekleyerek postmortem.md dosyasını günceller: 
      ![Incident Metric Graph](incident_metrics.png)
  3. Kümenin tam olarak ne zaman çöktüğünü ve trafiğin ne zaman normale döndüğünü gösteren grafiği görmek için oluşturulan incident_metrics.png dosyasını açın.

9. 6. adım: Temizleme

Google Cloud hesabınızın gereksiz ücretlere tabi olmaması için dağıtılan altyapıyı temizleyelim.

  1. terraform klasörüne gidin: 
    cd ../../microservices-demo/terraform
  2. Yok etme komutunu çalıştırın: 
    terraform destroy -auto-approve
  3. Tüm GCP GKE kaynaklarının başarıyla silindiğini doğrulayın.

10. Tebrikler!

GKE Kümesi Arızası ve Kesintisi İnceleme Codelab'ini tamamladınız.

İşlediğiniz konular:

  • 10 katmanlı Online Boutique mikro hizmet demosunu GKE'ye dağıttı.
  • Üç gerçek SRE kesintisi (ağ politikası reddi, hatalı canary dağıtımı, VPC güvenlik duvarı kuralı reddi) simüle edildi.
  • Kesintileri tespit etmek ve teşhis etmek için Antigravity CLI'ın SRE uzantısını kullandık.
  • Düzeltme komutlarını incelemek ve yürütmek için Safe Executor (Güvenli Yürütücü) kalıbından yararlanıldı.
  • Profesyonel bir Markdown postmortem oluşturdu.
  • Temellendirilmiş bir olay grafiğini otomatik olarak oluşturup yerleştirmek için Cloud Monitoring metriklerini sorgulayın.

CLI aracınızı genişletme hakkında daha fazla bilgi için SRE Extension GitHub sayfasını inceleyin.