איך חוקרים הפסקת שירות ב-GKE באמצעות Antigravity CLI ותוסף SRE ויוצרים ניתוח לאחר תקלה

1. מבוא

856ff52e60953a92.png

תאריך העדכון האחרון: 2026-05-13

איך חוקרים הפסקת שירות ב-GKE באמצעות תוסף ה-SRE ויוצרים דוח יפהפה על האירוע

ברוכים הבאים לסדנת SRE הזו, שמיועדת לאופרטורים שרוצים להתנסות בשימוש ב-SRE ב-Google Cloud.

ב-Codelab הזה תלמדו איך:

  1. מתקינים אשכול GKE שמבוסס על microservices-demo , הדגמה ידועה של מיקרו-שירותים בקוד פתוח.
  2. ליצור הפסקת חשמל על ידי שבירת המכשיר בדרכים שונות (חלקן בולטות יותר, חלקן פחות).
  3. כדי לבצע את החלק הבא, צריך להתקין ולהשתמש ב-Antigravity CLI (או בכלי דומה) + SRE Extension.
  4. לבדוק את הבעיה ולנסות לפתור אותה.
  5. יצירת ניתוח לאחר אירוע (Post Mortem).
  6. אתם יכולים להשתמש בכישורי יצירת תרשימים כדי ליצור תרשים מבוסס-עובדות שיעזור לצופים להבין מה קרה ומתי.

זהו המבנה של ה-codelab:

תרשים מבנה של Codelab

מטרת הסדנה הזו היא:

  1. להדגים את היכולות של תוסף ה-SRE ולהראות לכם מה אפשר לעשות איתו: הגדרה של OneMCP, ‏ Safe Executor, ‏ Investigation, ‏ Post Mortem Generation, ‏ גרפים ו-CSV gists.
  2. ללמד אתכם את המיומנויות הדרושות כדי לחקור תרחיש של Google Cloud.

שלב 1: הגדרת הסביבה וסימולציה של הפסקת חשמל

המטרה של אבן הדרך הזו היא להגדיר אפליקציית הדגמה של Kubernetes ב-GKE Autopilot, להתקין את Antigravity CLI ולהפעיל באופן מלאכותי תרחישים של שבירת אשכולות GKE כדי לדמות אירועים שקורים בסביבת ייצור.

אבן דרך 2: חקירה וצמצום בעזרת תוסף SRE

אחרי שמשבשים את הסביבה, משתמשים בכלים של סוכן CLI שמצוידים בתוסף SRE כדי לגלות את התשתית באופן שיטתי, לתעדף את הבעיות, להטמיע את דפוס הביצוע הבטוח לתיקונים ולאמת את תקינות האשכול.

אבן דרך 3: ניתוח לאחר מעשה ויצירת גרף

אחרי שהבעיה תיפתר, תיצרו מסמך מובנה של ניתוח לאחר תקרית ותשתמשו בממשקי GCM ‏ (Google Cloud Monitoring) API כדי לשלוף נתוני מדדים בזמן אמת, וליצור תרשימים חזותיים שמתעדים מתי ואיך התרחשה ההשבתה.

מה תפַתחו

ב-Codelab הזה נבדוק ונפתור הפסקות שירות ב-GKE באמצעות תוסף SRE. תצטרכו:

  • הדמיה של הפסקת שירות ב-GKE באמצעות חסימה של מדיניות רשת, פריסות קנרית עם באגים ועדכונים של כללים לחומת האש.
  • מיון של הפסקת פעילות באשכול באמצעות עוזר CLI שמבוסס על תוסף SRE.
  • מיישמים את שלבי התיקון בצורה בטוחה באמצעות התבנית Safe Executor.
  • ליצור מסמך מפורט של ניתוח לאחר אירוע.
  • יצירת תרשים של מדדי אירועים באמצעות שאילתות של סדרות זמן ב-Google Cloud Monitoring.

מה תלמדו

  • איך בודקים משאבים ומדיניות של GKE Kubernetes באמצעות כישורי SRE Extension.
  • איך להשתמש בתבנית Safe Executor כדי להריץ פקודות שהסוכן מציע עם הערכת סיכונים מתאימה.
  • איך משתמשים במיומנות monitoring-graphs כדי ליצור תרשימים של מדדים ישירות מ-GCM.
  • איך לתעד את הממצאים של התקרית בפורמט מובנה של ניתוח לאחר תקרית.

מה תצטרכו

  • פרויקט ב-Google Cloud עם חיוב מופעל.
  • כלי שורת פקודה: gcloud, ‏ kubectl, ‏ terraform.
  • ‫Antigravity CLI מותקן באופן מקומי או ב-Cloud Shell.
  • סביבת פיתוח משולבת (IDE) (לדוגמה, vscode,‏ IntelliJ,‏ RubyMine או Vim).

למה כדאי להשתמש בתוסף SRE + סוכן CLI?

הפסקות פעילות בסביבת הייצור מתרחשות במהירות ודורשות קורלציה בין מספר מערכות משנה (משאבי Kubernetes, רשתות VPC, מדדים של Cloud Monitoring והרשאות IAM). התוסף SRE מאפשר לעוזרים מבוססי-סוכנים ב-CLI (כמו Antigravity CLI) לפעול כטייסים משנה אוטונומיים, להריץ ספרי הפעלה שעברו קומפילציה מראש, לשלוח שאילתות לגרפים של ניטור ולהציע תיקונים בטוחים, תוך שמירה על מעורבות של המפעיל האנושי.

2. תהליך ההגדרה

בוחרים אחת מהאפשרויות הבאות: הגדרת סביבה בקצב אישי אם רוצים להפעיל את

במחשב שלכם, או להפעיל את Cloud Shell אם אתם רוצים להריץ את ה-codelab הזה כולו בענן.

הגדרת סביבה בקצב אישי

  1. נכנסים ל-מסוף Google Cloud ויוצרים פרויקט חדש או משתמשים בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או Google Workspace, אתם צריכים ליצור חשבון.

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • שם הפרויקט הוא השם המוצג למשתתפים בפרויקט. זו מחרוזת תווים שלא נמצאת בשימוש ב-Google APIs. תמיד אפשר לעדכן את המיקום.
  • מזהה הפרויקט הוא ייחודי לכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו אחרי שהוא מוגדר. מסוף Cloud יוצר באופן אוטומטי מחרוזת ייחודית, ובדרך כלל לא צריך לדעת מה היא. ברוב ה-Codelabs, תצטרכו להפנות למזהה הפרויקט (בדרך כלל מסומן כ-PROJECT_ID). אם אתם לא אוהבים את המזהה שנוצר, אתם יכולים ליצור מזהה אקראי אחר. אפשר גם לנסות כתובת משלכם ולבדוק אם היא זמינה. אי אפשר לשנות את ההגדרה הזו אחרי השלב הזה, והיא נשארת לאורך הפרויקט.
  • לידיעתכם, יש ערך שלישי, מספר פרויקט, שחלק מממשקי ה-API משתמשים בו. מידע נוסף על שלושת הערכים האלה מופיע במאמרי העזרה.
  1. בשלב הבא, תצטרכו להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבי Cloud או בממשקי API של Cloud. השלמת ה-codelab הזה לא תעלה לכם הרבה, אם בכלל. כדי להשבית את המשאבים ולמנוע חיובים נוספים אחרי שתסיימו את המדריך הזה, תוכלו למחוק את המשאבים שיצרתם או למחוק את הפרויקט. משתמשים חדשים ב-Google Cloud זכאים לתוכנית תקופת ניסיון בחינם בשווי 300$.

מפעילים את Cloud Shell

אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-Codelab הזה נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת בענן.

ב-מסוף Google Cloud, לוחצים על סמל Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:

הפעלת Cloud Shell

הקצאת המשאבים והחיבור לסביבה יימשכו רק כמה רגעים. בסיום התהליך, אמור להופיע משהו כזה:

צילום מסך של טרמינל Google Cloud Shell שבו מוצג שהסביבה מחוברת

המכונה הווירטואלית הזו כוללת את כל הכלים שדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר מאוד את הביצועים והאימות ברשת. אפשר לבצע את כל העבודה ב-codelab הזה בדפדפן. לא צריך להתקין שום דבר.

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. ‫Antigravity CLI‏ (agy)

כדי להתקין את Antigravity CLI הרשמי (הפקודה agy), פותחים את הטרמינל ומריצים את קובץ ההתקנה של bootstrap:

ב-macOS וב-Linux:

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

ב-Windows‏ (PowerShell):

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

הסקריפט הזה יזהה באופן דינמי את מערכת ההפעלה והארכיטקטורה שלכם, יוריד את הגרסה המהודרת האחרונה של

agy

‫ binary, וקובעים את הנתיב. כדי שהשינויים ייכנסו לתוקף, צריך להפעיל מחדש את הטרמינל או לטעון מחדש את הגדרות השל.

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

הגדרת סביבת העבודה ופריסת אפליקציית הדגמה של מיקרו-שירותים

בואו נשכפל את אפליקציית ההדגמה של מיקרו-שירותים ונפרוס את התשתית והאפליקציה באמצעות 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

4. שלב 1: הדמיית ההשבתה (תרחישי שבירה)

בשלב הזה, נגרום בכוונה לשבירה של אשכול GKE שנפרס כדי לדמות אירוע ייצור בעולם האמיתי. יש שלוש אפשרויות לבחירה (או שאפשר לנסות את שלושתן ברצף):

תרחיש 1: חסימה של שירות התשלום (רגיל/אוטומטי)

בתרחיש הזה, אנחנו מדמים חיבור שבור בין הקצה הקדמי לבין שירות התשלום באמצעות הפעלת Kubernetes NetworkPolicy שפועל כ "חור שחור" לתעבורת נתונים.

  1. עוברים לתיקיית התרחיש: 
    cd breakage1-checkout
  2. מפעילים את השבירה:
    ‫
    ./break.sh
    הפקודה הזו יוצרת NetworkPolicy בשם update-checkout-from-frontend במרחב השמות default, שמונעת תעבורת נתונים נכנסת (ingress) אל checkoutservice אלא אם היא מגיעה מ-Pod עם התווית app: frontend-checkout-test (שלא קיים).
  3. מנסים לרכוש פריטים בחלק הקדמי של הבוטיק אונליין. דף התשלום יישאר תקוע או שתוצג בו שגיאת HTTP 500.

תרחיש 2: השקה של גרסת קנרית עם באגים (טייס אוטומטי עם Istio)

בתרחיש הזה מתבצעת סימולציה של פריסה לא טובה, שבה גרסה עם באגים של חזית האתר נפרסת באמצעות פריסת קנרית של Kubernetes.

  1. עוברים לתיקיית התרחיש: 
    cd ../breakage2-canary
  2. מפעילים את השבירה:
    ‫
    ./break.sh
    הפקודה הזו מפעילה פריסה של גרסה ראשונית (canary) frontend-canary שיש בה שגיאת הקלדה במשתני הסביבה: PRODUCT_CATALOG_SERVICE_ADDR מוגדר ל-productcatalogservices:3550 במקום ל-productcatalogservice:3550.
  3. טוענים את דף הבית של הקצה הקדמי. הפעולה תיכשל מדי פעם (בהתאם למשקלי הניתוב) כי שירות הקנרי לא מצליח לפתור את קטלוג המוצרים.

תרחיש 3: חסימה של אשכול חומת אש של VPC

התרחיש הזה מדמה טעות בהגדרת חומת האש של ה-VPC שחוסמת את כל תעבורת הנתונים הנכנסת (ingress) לאשכול GKE.

  1. עוברים לתיקיית התרחיש: 
    cd ../breakage3-firewall
  2. מפעילים את השבירה: 
    ./break.sh
    הפקודה הזו יוצרת כלל חומת אש ברמת ה-VPC בשם frontend-ingress-v2 עם priority=1 ופעולה DENY שמטרגטת תעבורת נתונים נכנסת ליציאות 80,‏ 443 ו-8080.
  3. לא תהיה אפשרות לגשת לאתר Online Boutique, והבקשות יפוגו.

5. שלב 2: חקירת הפסקת שירות באמצעות התוסף 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 כדי לאתר יעדים שנכשלו.
    • הכלי בודק את מדיניות הרשת (בתרחיש 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 של CLI כדי לפתור את ההשבתה.

  1. מבקשים מהעוזר של CLI להציע תיקון וליישם אותו: 
    Propose a fix for the outage and apply it.
  2. Safe Executor בפעולה:
    • לפני שמריצים הצעות לפקודות, תוסף ה-SRE מריץ ביקורת אבטחה באמצעות מיומנות safe-sre-investigator.
    • יוצגו לכם הפקודה המדויקת שהיא מתכוונת להריץ ודירוג הסיכון (למשל: נמוך, בינוני, גבוה).
    • בתרחיש 1, ההצעה תהיה: 
      kubectl delete networkpolicy update-checkout-from-frontend
    • בתרחיש 2, יוצעו האפשרויות הבאות: 
      kubectl delete deployment frontend-canary
    • בתרחיש 3, ההצעה תהיה: 
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. מאשרים את הפעלת הפקודה כשמוצגת בקשה לעשות זאת ב-CLI.
  4. כדי לוודא שהאתר חזר לפעולה ופועל באופן מלא, מרעננים את דף הבית של Online Boutique.
  5. במעטפת, אפשר להריץ את סקריפט הבדיקה של התרחיש המתאים כדי לאמת את התקינות: 
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

7. שלב 4: יצירת סיכום האירוע

חלק חשוב במחזור החיים של SRE הוא תיעוד האירוע כדי שהצוות יוכל ללמוד ממנו. נשתמש במיומנות postmortem-create כדי להפוך את התהליך הזה לאוטומטי.

  1. בצ'אטבוט של ה-CLI, מבקשים לכתוב את מסמך סיכום האירוע: 
    Create a postmortem for the checkout service network policy outage.
  2. הנציג יאסוף פרטים על:
    • שעת ההתחלה של האירוע (מאוחזרת מההיסטוריה או מהיומנים של פקודות ה-CLI).
    • שורש הבעיה (NetworkPolicy שחוסם).
    • הפעולות שננקטו כדי לצמצם את הסיכון.
  3. הוא ייצור קובץ Markdown חדש בשם postmortem.md בסביבת העבודה.
  4. פותחים את postmortem.md כדי לבדוק את הפרטים. יוצגו קטעים כמו:
    • סיכום האירוע
    • ציר זמן של אירועים
    • ניתוח הגורם הבסיסי (RCA)
    • פעולות לביצוע / אמצעי מניעה

8. שלב 5: הוספה של תרשימים של מדדים מבוססי-הארקה

כדי שהניתוח שלאחר המוות יהיה מקצועי, אנחנו צריכים הוכחה חזותית של האירוע. נשתמש בmonitoring-graphs כדי לאחזר נתונים של סדרות זמן מ-Google Cloud Monitoring ‏ (GCM) וליצור תרשים PNG שמציג את העלייה החדה במספר השגיאות.

  1. מבקשים מהעוזר של ה-CLI ליצור את הגרף ולהוסיף אותו לניתוח שלאחר המוות: 
    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. מריצים את הפקודה destroy: 
    terraform destroy -auto-approve
  3. מוודאים שכל משאבי GCP GKE נמחקו בהצלחה.

10. מעולה!

סיימתם את ה-Codelab בנושא חקירת תקלות והפסקות שירות באשכול GKE.

מה נכלל:

  • פריסת ההדגמה של מיקרו-שירותים של Online Boutique עם 10 רמות ב-GKE.
  • סימולציה של שלוש הפסקות שירות אמיתיות של SRE (דחייה של מדיניות רשת, השקה של קנרית עם באגים, דחייה של כלל חומת אש של VPC).
  • השתמשנו בתוסף SRE ל-Antigravity CLI כדי לגלות ולאבחן את ההפסקות הזמניות בשירות.
  • השתמשנו בתבנית Safe Executor כדי לבדוק ולהריץ פקודות לתיקון.
  • יצרת פוסט מקצועי של ניתוח לאחר מעשה ב-Markdown.
  • שאילתות על מדדים של Cloud Monitoring כדי ליצור ולהטמיע באופן אוטומטי תרשים של אירוע מבוסס.

לפרטים נוספים על הרחבת סוכן ה-CLI, אפשר לעיין בדף ה-GitHub של SRE Extension.