بررسی قطعی GKE با Antigravity CLI و SRE Extension و ساخت یک Post Mortem زیبا

۱. مقدمه

856ff52e60953a92.png

آخرین به‌روزرسانی: 2026-05-13

با افزونه SRE، قطعی GKE را بررسی کنید و یک تحلیل پس از وقوع زیبا بسازید.

به این کارگاه آموزشی SRE خوش آمدید، برای اپراتورهایی که می‌خواهند با مهارهای SRE در Google Cloud آزمایش کنند!

این codelab شما را در این زمینه راهنمایی خواهد کرد:

  1. یک کلاستر GKE مبتنی بر یک microservices-demo متن‌باز و شناخته‌شده نصب کنید.
  2. با ایجاد وقفه در روند کار به روش‌های مختلف (بعضی چشمگیرتر، بعضی ظریف‌تر) یک وقفه ایجاد کنید.
  3. برای بخش بعدی، Antigravity CLI (یا ابزار مشابه) + SRE Extension را نصب و استفاده کنید.
  4. بررسی کنید و امیدواریم مشکل قطعی برق برطرف شود.
  5. یک کالبدشکافی پس از حادثه ایجاد کنید.
  6. از مهارت‌های نمودارسازی برای ایجاد یک نمودار پایه استفاده کنید که به بینندگان اجازه می‌دهد بفهمند چه اتفاقی افتاده و چه زمانی.

ساختار گام به گام codelab به شرح زیر است:

نمودار ساختار Codelab

هدف از این کارگاه آموزشی عبارت است از:

  1. قابلیت‌های افزونه SRE را نشان دهید و به شما نشان دهیم که با آن چه کارهایی می‌توانید انجام دهید: راه‌اندازی OneMCP، اجرای ایمن، بررسی، تولید پس از مرگ، نمودارها و فهرست‌های CSV.
  2. مهارت‌های لازم برای بررسی سناریوی گوگل کلود خودتان را به شما آموزش می‌دهم.

مرحله ۱: راه‌اندازی محیط و شبیه‌سازی قطعی برق

هدف از این مرحله، راه‌اندازی یک برنامه آزمایشی Kubernetes روی GKE Autopilot، نصب Antigravity CLI و راه‌اندازی مصنوعی سناریوهای خرابی کلاستر GKE برای شبیه‌سازی حوادث تولید است.

مرحله دوم: بررسی و کاهش خطر با افزونه SRE

پس از شکستن محیط، شما از ابزارهای واسط خط فرمان (CLI) عامل‌دار مجهز به افزونه SRE برای کشف سیستماتیک زیرساخت، اولویت‌بندی مشکلات، پیاده‌سازی الگوی اجرای ایمن برای رفع آنها و تأیید سلامت کلاستر استفاده خواهید کرد.

مرحله سوم: بررسی‌های پس از اجرا و تولید نمودار

پس از حل مشکل، شما یک سند پس از وقوع حادثه ساختاریافته ایجاد خواهید کرد و از APIهای GCM (Google Cloud Monitoring) برای استخراج داده‌های واقعی استفاده خواهید کرد و نمودارهای بصری برای مستندسازی زمان و نحوه وقوع قطعی ایجاد خواهید کرد.

آنچه خواهید ساخت

در این آزمایشگاه کد، شما قصد دارید با استفاده از افزونه SRE، قطعی‌های GKE را بررسی و رفع کنید. شما:

  • با استفاده از انسداد سیاست‌های شبکه، استقرارهای Canary دارای باگ و به‌روزرسانی‌های قوانین فایروال، قطعی GKE را شبیه‌سازی کنید.
  • با استفاده از یک دستیار CLI که توسط افزونه SRE پشتیبانی می‌شود، قطعی کلاستر را بررسی کنید.
  • مراحل اصلاح را با استفاده از الگوی Safe Executor به صورت ایمن پیاده‌سازی کنید.
  • یک سند جامع پس از مرگ تهیه کنید.
  • نمودار معیارهای حادثه با استفاده از پرس‌وجوهای سری زمانی Google Cloud Monitoring.

آنچه یاد خواهید گرفت

  • نحوه بررسی منابع و سیاست‌های GKE Kubernetes با استفاده از مهارت‌های افزونه SRE.
  • چگونه می‌توان از الگوی Safe Executor برای اجرای دستورات پیشنهادی توسط عامل با ارزیابی ریسک مناسب استفاده کرد.
  • نحوه استفاده از مهارت monitoring-graphs برای تولید نمودارهای پایه از معیارها به طور مستقیم از GCM.
  • چگونه یافته‌های حادثه را در قالبی ساختارمند پس از وقوع حادثه مستند کنیم.

آنچه نیاز دارید

  • یک پروژه ابری گوگل با قابلیت پرداخت صورتحساب.
  • ابزارهای خط فرمان: gcloud ، kubectl ، terraform .
  • رابط خط فرمان ضد جاذبه (Antigravity CLI) به صورت محلی یا در Cloud Shell نصب شده است.
  • یک IDE (مثلاً vscode، IntelliJ، RubyMine یا Vim).

چرا افزونه SRE + رابط خط فرمان Agentic؟

قطع شدن تولید به سرعت اتفاق می‌افتد و نیاز به همبستگی بین چندین زیرسیستم (منابع Kubernetes، شبکه‌های VPC، معیارهای نظارت بر ابر، مجوزهای IAM) دارد. افزونه SRE به کمک‌کننده‌های CLI عامل (مانند Antigravity CLI) اجازه می‌دهد تا به عنوان کمک‌خلبان‌های خودکار عمل کنند، کتاب‌های راهنمای از پیش کامپایل شده را اجرا کنند، نمودارهای نظارت را جستجو کنند و اصلاحات ایمن را پیشنهاد دهند، در حالی که اپراتور انسانی را در حلقه نگه می‌دارند.

۲. راه‌اندازی

یکی از گزینه‌های زیر را انتخاب کنید: اگر می‌خواهید این را اجرا کنید، تنظیم محیط خودتنظیم

codelab را روی دستگاه خودتان اجرا کنید، یا اگر می‌خواهید این codelab را کاملاً در فضای ابری اجرا کنید ، Cloud Shell را شروع کنید .

تنظیم محیط خودتنظیم

  1. وارد کنسول گوگل کلود شوید و یک پروژه جدید ایجاد کنید یا از یک پروژه موجود دوباره استفاده کنید. اگر از قبل حساب جیمیل یا گوگل ورک اسپیس ندارید، باید یکی ایجاد کنید .

۲۹۵۰۰۴۸۲۱bab6a87.png

37d264871000675d.png

۹۶d86d3d5655cdbe.png

  • نام پروژه، نام نمایشی برای شرکت‌کنندگان این پروژه است. این یک رشته کاراکتری است که توسط APIهای گوگل استفاده نمی‌شود. شما همیشه می‌توانید آن را به‌روزرسانی کنید.
  • شناسه پروژه در تمام پروژه‌های گوگل کلود منحصر به فرد است و تغییرناپذیر است (پس از تنظیم، قابل تغییر نیست). کنسول کلود به طور خودکار یک رشته منحصر به فرد تولید می‌کند؛ معمولاً برای شما مهم نیست که چه باشد. در اکثر آزمایشگاه‌های کد، باید شناسه پروژه خود را (که معمولاً با عنوان PROJECT_ID شناخته می‌شود) ارجاع دهید. اگر شناسه تولید شده را دوست ندارید، می‌توانید یک شناسه تصادفی دیگر ایجاد کنید. به عنوان یک جایگزین، می‌توانید شناسه خودتان را امتحان کنید و ببینید که آیا در دسترس است یا خیر. پس از این مرحله قابل تغییر نیست و در طول پروژه باقی می‌ماند.
  • برای اطلاع شما، یک مقدار سوم، شماره پروژه ، وجود دارد که برخی از APIها از آن استفاده می‌کنند. برای کسب اطلاعات بیشتر در مورد هر سه این مقادیر، به مستندات مراجعه کنید.
  1. در مرحله بعد، برای استفاده از منابع/API های ابری، باید پرداخت صورتحساب را در کنسول ابری فعال کنید . اجرای این آزمایشگاه کد هزینه زیادی نخواهد داشت، اگر اصلاً هزینه‌ای داشته باشد. برای خاموش کردن منابع به منظور جلوگیری از پرداخت صورتحساب پس از این آموزش، می‌توانید منابعی را که ایجاد کرده‌اید یا پروژه را حذف کنید. کاربران جدید Google Cloud واجد شرایط برنامه آزمایشی رایگان ۳۰۰ دلاری هستند.

شروع پوسته ابری

اگرچه می‌توان از راه دور و از طریق لپ‌تاپ، گوگل کلود را مدیریت کرد، اما در این آزمایشگاه کد، از گوگل کلود شل ، یک محیط خط فرمان که در فضای ابری اجرا می‌شود، استفاده خواهید کرد.

از کنسول گوگل کلود ، روی آیکون Cloud Shell در نوار ابزار بالا سمت راست کلیک کنید:

فعال کردن پوسته ابری

آماده‌سازی و اتصال به محیط فقط چند لحظه طول می‌کشد. وقتی تمام شد، باید چیزی شبیه به این را ببینید:

تصویر صفحه ترمینال Google Cloud Shell که نشان می‌دهد محیط متصل شده است

این ماشین مجازی با تمام ابزارهای توسعه‌ای که نیاز دارید، مجهز شده است. این ماشین مجازی یک دایرکتوری خانگی پایدار ۵ گیگابایتی ارائه می‌دهد و روی فضای ابری گوگل اجرا می‌شود که عملکرد شبکه و احراز هویت را تا حد زیادی بهبود می‌بخشد. تمام کارهای شما در این آزمایشگاه کد را می‌توان در یک مرورگر انجام داد. نیازی به نصب چیزی ندارید.

۳. پیش‌نیازها (نصب)

برای این آموزش، باید موارد زیر را نصب کنید:

۱. پایتون و یووی

python و uv (مدیر بسته برای پایتون ). مطمئن شوید که uv را نصب کرده‌اید:

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

چرا uv؟ در حالی که می‌توانید از هر مدیر پایتونی که ترجیح می‌دهید استفاده کنید، استفاده از uv تضمین می‌کند که تنظیمات ENV/PATH برای پایتون برای شما و برای Antigravity CLI یکسان خواهد بود، بنابراین تجربه پوسته شما تقریباً مشابه Antigravity CLI خواهد بود. به عنوان مثال، اگر از virtualenv استفاده می‌کنید، Antigravity CLI مجبور می‌شود کارهایی مانند "source .env/venv/bin/activate && my-original-command" را برای تقلید از محیط شما انجام دهد.

۲. رابط خط فرمان ضد جاذبه ( agy )

برای نصب رابط خط فرمان رسمی Antigravity (دستور agy )، ترمینال خود را باز کرده و نصب‌کننده‌ی بوت‌استرپ را اجرا کنید:

برای macOS و لینوکس:

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

برای ویندوز (پاورشل):

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

این اسکریپت به صورت پویا سیستم عامل و معماری شما را شناسایی می‌کند، آخرین نسخه کامپایل شده را دانلود می‌کند.

agy

باینری را تغییر دهید و PATH خود را پیکربندی کنید. برای اعمال تغییرات، ترمینال خود را مجدداً راه‌اندازی کنید یا پیکربندی پوسته خود را مجدداً بارگذاری کنید.

efade99623113f1.png

احراز هویت

شما به یک کلید API گوگل هوش مصنوعی استودیو نیاز دارید.

کلید 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 ADDRESS] دسترسی پیدا کرده و برنامه online-boutique را بارگیری کنید.

محیط کاری خود را برای 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

۴. مرحله ۱: شبیه‌سازی قطعی برق (سناریوهای قطعی برق)

در این مرحله، ما عمداً کلاستر GKE مستقر شده را از کار می‌اندازیم تا یک حادثه تولید در دنیای واقعی را شبیه‌سازی کنیم. شما سه سناریو برای انتخاب دارید (یا هر سه را به ترتیب امتحان کنید):

سناریو ۱: انسداد شبکه خدمات پرداخت (استاندارد/خودکار)

این سناریو با اعمال یک Kubernetes NetworkPolicy که به عنوان یک "سیاهچاله" ترافیکی عمل می‌کند، یک اتصال قطع شده بین frontend و سرویس پرداخت را شبیه‌سازی می‌کند.

  1. به پوشه سناریو بروید: 
    cd breakage1-checkout
  2. باعث شکستگی شود:
    ./break.sh
    این دستور یک NetworkPolicy با نام update-checkout-from-frontend در فضای نام default ایجاد می‌کند که ترافیک ورودی به checkoutservice را رد می‌کند، مگر اینکه از یک pod با برچسب app: frontend-checkout-test (که وجود ندارد) بیاید.
  3. سعی کنید اقلام را از طریق صفحه اصلی فروشگاه آنلاین خریداری کنید. صفحه پرداخت هنگ می‌کند یا خطای HTTP 500 نمایش می‌دهد.

سناریوی ۲: راه‌اندازی باگی کنری (اتوپایلوت با Istio)

این سناریو یک استقرار بد را شبیه‌سازی می‌کند که در آن یک نسخه دارای باگ از رابط کاربری از طریق استقرار Kubernetes Canary منتشر می‌شود.

  1. به پوشه سناریو بروید: 
    cd ../breakage2-canary
  2. باعث شکستگی شود:
    ./break.sh
    این یک frontend-canary برای استقرار canary مستقر می‌کند که در متغیرهای محیطی خود دارای یک غلط املایی است: PRODUCT_CATALOG_SERVICE_ADDR به جای productcatalogservice productcatalogservices:3550 productcatalogservice:3550 پیکربندی شده است.
  3. صفحه اصلی frontend را بارگذاری کنید. گاهی اوقات (بسته به وزن‌های مسیریابی) با شکست مواجه می‌شود زیرا سرویس canary در حل کاتالوگ محصول ناموفق است.

سناریو ۳: انسداد خوشه فایروال VPC

این سناریو، خطایی در پیکربندی فایروال VPC را شبیه‌سازی می‌کند که تمام ترافیک ورودی به کلاستر GKE را مسدود می‌کند.

  1. به پوشه سناریو بروید: 
    cd ../breakage3-firewall
  2. باعث شکستگی شود:
    ./break.sh
    این یک قانون فایروال در سطح VPC به نام frontend-ingress-v2 با priority=1 و عملکرد DENY ایجاد می‌کند که ترافیک ورودی به پورت‌های 80 ، 443 و 8080 را هدف قرار می‌دهد.
  3. وب‌سایت بوتیک آنلاین کاملاً غیرقابل دسترس خواهد شد و درخواست‌ها با تأخیر مواجه می‌شوند.

۵. مرحله ۲: بررسی قطعی برق با افزونه SRE

حالا که برنامه از دسترس خارج شده، بیایید با استفاده از دستیار CLI شما (Antigravity CLI) بررسی را شروع کنیم.

  1. به پوشه اصلی سناریوهای خرابی برگردید و کمک‌کننده CLI خود را اجرا کنید: 
    cd ..
agy
  2. از دستیار بخواهید که یک بررسی کشف و تشخیص زیرساخت انجام دهد: 
    Investigate my GKE cluster for outages. Are all services healthy?
  3. کاری که نماینده انجام می‌دهد:
    • این مهارت‌ها، investigation-entrypoint و gcp-playbooks را فعال می‌کند.
    • این ابزار، پادها، پیاده‌سازی‌ها و سرویس‌های Kubernetes را فهرست می‌کند تا اهداف ناموفق را پیدا کند.
    • این ابزار سیاست‌های شبکه (برای سناریوی ۱) یا پیکربندی‌های پیاده‌سازی (برای سناریوی ۲) یا قوانین فایروال (برای سناریوی ۳) را بررسی می‌کند.
  4. برای سناریوی ۱، عامل باید گزارش دهد: 🔴 حادثه شناسایی شد : یک NetworkPolicy با نام update-checkout-from-frontend در حال ایزوله کردن podهای checkoutservice است.
  5. برای سناریوی ۲، عامل باید گزارش دهد: 🔴 حادثه شناسایی شد : Deployment frontend-canary با یک نقطه پایانی سرویس نامعتبر productcatalogservices:3550 به جای productcatalogservice:3550 پیکربندی شده است.
  6. برای سناریوی ۳، عامل باید گزارش دهد: 🔴 حادثه شناسایی شد : یک قانون فایروال VPC frontend-ingress-v2 ترافیک ورودی روی پورت‌های 80 ، 443 و 8080 را مسدود می‌کند.

۶. مرحله ۳: کاهش و رفع قطعی برق

بیایید از الگوی Safe Executor در CLI برای رفع قطعی استفاده کنیم.

  1. از دستیار CLI خود بخواهید که یک راه حل پیشنهاد دهد و اعمال کند: 
    Propose a fix for the outage and apply it.
  2. مجری ایمن در عمل:
    • قبل از اجرای پیشنهادات دستور، افزونه SRE با استفاده از مهارت safe-sre-investigator یک ممیزی ایمنی اجرا می‌کند.
    • این ابزار دستور دقیقی که قصد اجرا دارد را به شما نشان می‌دهد و میزان ریسک (مثلاً کم، متوسط، زیاد) را ارزیابی می‌کند.
    • برای سناریوی ۱، پیشنهاد خواهد شد: 
      kubectl delete networkpolicy update-checkout-from-frontend
    • برای سناریوی ۲، پیشنهاد خواهد شد: 
      kubectl delete deployment frontend-canary
    • برای سناریوی ۳، پیشنهاد خواهد شد: 
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. اجرای دستور را در صورت درخواست CLI تأیید کنید.
  4. با رفرش کردن صفحه اصلی فروشگاه آنلاین، مطمئن شوید که وب‌سایت پشتیبان‌گیری شده و کاملاً کاربردی است.
  5. در پوسته خود، می‌توانید اسکریپت بررسی سناریوی مربوطه را برای تأیید سلامت اجرا کنید: 
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

۷. مرحله ۴: تهیه گزارش پس از حادثه

بخش اساسی چرخه حیات SRE، مستندسازی حادثه است تا تیم بتواند از آن درس بگیرد. بیایید این کار را با استفاده از مهارت postmortem-create خودکار کنیم.

  1. در دستیار CLI خود، از او بخواهید سند پس از مرگ را بنویسد: 
    Create a postmortem for the checkout service network policy outage.
  2. نماینده جزئیات مربوط به موارد زیر را جمع‌آوری خواهد کرد:
    • زمان شروع حادثه (از تاریخچه/گزارش‌های دستورات CLI شما بازیابی می‌شود).
    • علت اصلی (سیاست مسدودکننده شبکه).
    • اقداماتی که برای کاهش آن انجام شده است.
  3. این یک فایل Markdown جدید با نام postmortem.md در فضای کاری شما ایجاد خواهد کرد.
  4. برای بررسی جزئیات postmortem.md را باز کنید. بخش‌هایی مانند موارد زیر را مشاهده خواهید کرد:
    • خلاصه حادثه
    • گاهشمار رویدادها
    • تحلیل ریشه‌ای علل (RCA)
    • موارد اقدام / اقدامات پیشگیرانه

۸. مرحله ۵: اضافه کردن نمودارهای معیارهای پایه

برای حرفه‌ای کردن بررسی پس از حادثه، به مدرک بصری از حادثه نیاز داریم. ما از مهارت monitoring-graphs برای دریافت داده‌های سری زمانی از Google Cloud Monitoring (GCM) استفاده خواهیم کرد و یک نمودار PNG ایجاد می‌کنیم که میزان خطا را نشان می‌دهد.

  1. از کمک‌کننده‌ی CLI خود بخواهید که نمودار را تولید کند و آن را به postmortem اضافه کند: 
    Query GCM for frontend HTTP request error rates over the last 1 hour, generate a line chart, and embed it into postmortem.md.
  2. زیر کاپوت:
    • عامل، اسکریپت پایتون 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 تولید شده را باز کنید تا نموداری را ببینید که لحظات دقیق از کار افتادن کلاستر و بازگشت ترافیک به حالت عادی را نشان می‌دهد.

۹. مرحله ۶: پاکسازی

برای اطمینان از اینکه حساب Google Cloud شما هزینه‌های غیرضروری را متحمل نمی‌شود، بیایید زیرساخت مستقر شده را پاکسازی کنیم.

  1. به پوشه terraform بروید: 
    cd ../../microservices-demo/terraform
  2. دستور destroy را اجرا کنید: 
    terraform destroy -auto-approve
  3. تأیید کنید که تمام منابع GCP GKE با موفقیت حذف شده‌اند.

۱۰. تبریک می‌گویم!

شما آزمایشگاه کد بررسی خرابی و قطعی کلاستر GKE را به پایان رسانده‌اید!

آنچه پوشش داده‌اید:

  • نسخه آزمایشی میکروسرویس ۱۰ لایه Online Boutique را روی GKE مستقر کردیم.
  • سه قطعی SRE در دنیای واقعی شبیه‌سازی شد (انکار سیاست شبکه، راه‌اندازی Canary باگ‌دار، انکار قانون فایروال VPC).
  • از افزونه SRE برای Antigravity CLI برای کشف و تشخیص قطعی‌ها استفاده شد.
  • از الگوی Safe Executor برای بررسی و اجرای دستورات اصلاحی استفاده شد.
  • یک کالبدشکافی حرفه‌ای از Markdown ایجاد کرد.
  • معیارهای نظارت بر ابر مورد پرسش قرار گرفته تا به طور خودکار یک نمودار حادثه مبتنی بر داده تولید و جاسازی شود.

برای جزئیات بیشتر در مورد گسترش عامل CLI خود، به صفحه SRE Extension GitHub مراجعه کنید.