ערכת הכלים מבוססת-AI של Cloud Engineering: הנדסת פלטפורמה ב-GKE באמצעות Gemini

1. מבוא

פתרון בעיות בפריסות של Kubernetes הוא חלק נפוץ, ולעתים קרובות מתסכל, מחיי היום-יום של מהנדס פלטפורמה. בדרך כלל נדרשת חקירה ידנית מקיפה: עיון ביומנים, הפעלת פקודות kubectl describe והשוואה בין קובצי YAML כדי למצוא אי התאמה או הגדרה שגויה.

צ'אטבוטים מבוססי-AI לשימוש כללי יכולים לעזור להסביר מושגים או לכתוב קוד בסיסי, אבל הם פועלים בריק. הם לא יודעים כלום על בסיס הקוד הספציפי שלכם או על המצב הפעיל של האשכול, ולכן צריך לבצע הרבה העתקות והדבקות ידניות ומעברים בין הקשרים.

בשיעור ה-Lab הזה תלמדו איך לגשר על הפער הזה באמצעות כלים מבוססי-AI עם רמות הולכות וגדלות של הקשר. תשתמשו ב-Gemini CLI וב-Model Context Protocol‏ (MCP) כדי לפתור בעיות באפליקציה פגומה ב-GKE. בסיום שיעור ה-Lab הזה תבינו איך להשתמש ב-AI שמודע לקבצים ולתשתית שלכם כדי לפתור בעיות מורכבות מהר יותר, ואיך להפוך את תהליכי העבודה האלה ל'מיומנויות' שניתנות לשימוש חוזר על ידי הצוות שלכם.

מושגי ליבה

• הנדסת פלטפורמות: הנדסת פלטפורמות היא שיטה לבנייה ולתחזוקה של כלים ותהליכי עבודה פנימיים שמאפשרים למפתחי תוכנה לנהל את התשתית שלהם בלי להיות מומחים בכל שירות ענן בסיסי. המטרה היא לצמצם את החיכוך הטכני תוך שמירה על עקביות ועל אבטחה. צוותי פלטפורמה יוצרים נתיב זהב סטנדרטי כדי להבטיח שמפתחי אפליקציות יוכלו לפרוס אפליקציות בצורה בטוחה ומהירה, וצוות הפלטפורמה ישמור על שליטה בניהול ובעלויות.
• ‫Gemini CLI: ממשק שורת פקודה שמאפשר לקיים אינטראקציה עם מודלים של Gemini ישירות מהטרמינל. בניגוד לצ'אטבוט רגיל שמבוסס על אינטרנט, ה-CLI מיועד לפעול בסביבת הפיתוח שלכם, וכך קל יותר לשלב AI בתהליכי עבודה קיימים שמבוססים על מעטפת. הוא מאפשר לכם להעביר פלט מפקודות אחרות ישירות למודל ולהריץ הוראות בלי לצאת מהטרמינל.
• ‫Model Context Protocol‏ (MCP):‏ MCP הוא תקן פתוח שמאפשר למודל AI להתחבר לכלים או למקורות נתונים ספציפיים. בלי MCP, מודל AI יודע רק על מה הוא אומן, והוא לא יכול לראות את המשאבים הספציפיים שלכם. באמצעות GKE MCP server,‏ Gemini CLI יכול לשלוח שאילתות באופן פעיל ל-API של פרויקט Google Cloud, לבדוק את מצב האשכולות ולהריץ פקודות בשמכם. הוא משמש כגשר בין מנוע הנימוקים של המודל לבין ה-API בפועל של GKE.
• מיומנויות של סוכנים: מיומנויות הן חבילות של הוראות, סקריפטים ומשאבים שמרחיבים את היכולות של סוכן AI למשימות מיוחדות. הם מאפשרים לכם לקבוע סטנדרטים ארגוניים ולהפוך תהליכי עבודה מורכבים לאוטומטיים.

מטרות ה-Lab

בשיעור ה-Lab הזה:

1. התקדמות ההקשר: אפשר לראות איך הגדלת ההקשר משפרת את יכולת פתרון הבעיות של ה-AI.
2. פתרון בעיות ידני לעומת פתרון בעיות בעזרת AI: השוואה בין הקושי של ניפוי באגים ידני לבין תהליכי עבודה בעזרת AI.
3. ניפוי באגים בהקשר מלא: אפשר להשתמש ב-Gemini CLI עם שרת GKE MCP כדי לנפות באגים באפליקציות עם מודעות מלאה לתשתית.
4. הרחבת היכולות: לומדים לכתוב מיומנויות בהתאמה אישית כדי להפוך תהליכי עבודה לאוטומטיים.

הערה לגבי פלטים של LLM

בגלל האופי של שיעור ה-Lab הזה והאופן שבו מודלי שפה גדולים (LLM) פועלים, סביר להניח שהפלט שתקבלו יהיה שונה מהפלט לדוגמה שמוצג כאן. זו התנהגות צפויה של AI גנרטיבי. חשוב להבין את השלבים ואת החשיבה הרציונלית שהמודל מספק, ולא לנסות לשחזר את הטקסט או העיצוב המדויקים בדוגמאות.

2. הגדרת הפרויקט

לפני שמתחילים את שיעור ה-Lab, צריך להכין את הסביבה. פותחים את Cloud Shell, בוחרים את הפרויקט ומריצים את סקריפטים ההגדרה. קדימה, מתחילים!

פתיחת Cloud Shell

בשיעור ה-Lab הזה תשתמשו ב-Cloud Shell, סביבת טרמינל מבוססת-דפדפן שמסופקת על ידי Google Cloud. הוא מגיע עם כל הכלים שאתם צריכים, כולל Google Cloud CLI ‏ (gcloud),‏ kubectl ו-Gemini CLI, כך שאתם לא צריכים להתקין אותם במחשב המקומי.

1. נכנסים אל מסוף Google Cloud.
2. בפינה השמאלית העליונה של המסוף, לוחצים על הלחצן Activate Cloud Shell (הוא נראה כמו שורת פקודה של טרמינל >_).
3. סשן טרמינל ייפתח בחלק התחתון של חלון הדפדפן. אם מוצגת בקשה לעשות זאת, לוחצים על המשך.

בחירת פרויקט

בטרמינל של Cloud Shell, מוודאים שאתם עובדים בפרויקט הנכון.

1. בוחרים פרויקט קיים או יוצרים פרויקט חדש במיוחד למעבדה הזו במסוף.
2. רושמים את מזהה הפרויקט. כדי להגדיר את הפרויקט בשורת הפקודה הנוכחית, מריצים את הפקודה: gcloud config set project [YOUR_PROJECT_ID]

הגדרת מעבדה

עכשיו מריצים את סקריפטים ההגדרה כדי להכין את הסביבה ולהוסיף את הבאגים לשיעור ה-Lab.

1. משכפלים את המאגר:
   👉💻 מריצים את הפקודות הבאות כדי לשכפל רק את ספריית ה-Lab:

   git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos ~/devrel-demos
   cd ~/devrel-demos
   git sparse-checkout set codelabs/ai-toolkit-lab-1
   

2. מנווטים לספריית ה-Labs:
   👉💻 מריצים:

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
   

3. הגדרת משתני סביבה:
   👉💻 מריצים את הפקודות הבאות כדי להגדיר את הפרויקט והאזור:

   export PROJECT_ID=$(gcloud config get-value project)
   export REGION=us-central1
   

4. מריצים את סקריפט ההגדרה:
   הסקריפט הזה מפעיל את ממשקי ה-API שמפורטים בהמשך, יוצר אשכול GKE Autopilot ומוודא שהכלים הנדרשים מותקנים.
   👉💻 מריצים את הסקריפט מהספרייה הבסיסית:
   ‫

   ./setup.sh
   

   הערה: יצירת אשכול עשויה להימשך 5-10 דקות.
5. מאפסים את המצב הפגום:
   כדי לדמות את התרחיש שבו עמיתים השאירו אתכם עם סביבה פגומה, מריצים את הסקריפט break.sh. הסקריפט מעתיק את המניפסטים הפגומים לספריית בסיס הקוד הפעילה.
   👉💻 מריצים את הסקריפט:

   ./break.sh
   

6. הכנה לתרגילים בשיעור ה-Lab:
   כדי למנוע מה-AI לרמות (לראות את הפתרונות), צריך לעבור לספרייה cymbal-bank למשך שאר שיעור ה-Lab.
   👉💻 מריצים את הפקודה:

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank
   

ממשקי API שהופעלו

סקריפט ההגדרה מפעיל כמה ממשקי Google Cloud API. אלה הפעולות שהם מבצעים:

• ‫container.googleapis.com:‏ Google Kubernetes Engine API. נדרש לכל פעולה ברמת האשכול.
• ‫generativelanguage.googleapis.com: ה-API שמאפשר ל-Gemini CLI לתקשר עם מודלים של Gemini.
• ‫cloudresourcemanager.googleapis.com: נדרש לבדיקת מטא-נתונים ברמת הפרויקט ולניהול הרשאות.
• ‫logging.googleapis.com: חיוני לפתרון בעיות, כי הוא מאפשר לאחזר ולנתח יומנים מהמאגרי נתונים שלכם.

3. שלב 0: פתרון בעיות ידני (ללא AI)

עכשיו, כשאתם בספרייה cymbal-bank, ננסה למצוא את השגיאות באופן ידני. זו הדרך הקשה. כדאי לחוות את התוצאות הבסיסיות לפני שנותנים ל-AI לעשות את העבודה הקשה. פתרון בעיות ידני כולל שימוש בכלים סטנדרטיים כמו kubectl כדי לבדוק את מצב האשכול, לאחזר יומנים ולעיין בקובצי YAML כדי לזהות חוסר עקביות. לרוב התהליך איטי, מייגע ודורש מומחיות כדי לקשר בין הנקודות. התמונות האלה משמשות כנקודת התייחסות מושלמת לכלים מבוססי-AI שבהם תשתמשו בהמשך.

1. מנסים לפרוס: בודקים מה דעתה של Kubernetes על המניפסטים האלה.
   👉💻 מריצים את הפקודה הבאה כדי להחיל את המניפסטים:

   kubectl apply -f kubernetes-manifests/
   

   יכול להיות שיעברו כמה שניות עד שה-pods יתחילו לפעול. אפשר להשתמש בפקודה watch kubectl get pods כדי לראות מתי הם יופעלו. אחרי שהם יופעלו, משתמשים ב-Ctrl+c כדי לצאת מהצפייה.ברשימה יופיעו שני פודים שנכשלו:
   • בתרמיל frontend מוצגת השגיאה CreateContainerConfigError. בדרך כלל, שגיאה מהסוג הזה מצביעה על כך שיש בעיה בטעינת ההגדרה הנדרשת של מאגר התגים. כדאי לחשוב אילו משאבים חיצוניים יכולים להיות נחוצים להפעלת קונטיינר – האם יש משתני סביבה, סודות או ConfigMaps שאולי לא הוגדרו נכון או חסרים? כדאי לבדוק את ההגדרה של ה-pod כדי למצוא את הגורם הספציפי לבעיה.
   • ה-pod‏ userservice נמצא במצב ImagePullBackOff. כשמצב כזה מתרחש, בדרך כלל זה אומר שהאשכול לא יכול לאחזר את קובץ האימג' של הקונטיינר שהוא קיבל הוראה להשתמש בו. כדאי לבדוק את פרטי בקשת התמונה: האם שם התמונה והתג מדויקים? האם יש בעיות אפשריות בהרשאות של המאגר? כדאי לבדוק מאיפה התמונה נמשכת כדי לראות למה הבקשה נכשלת.
2. בודקים את הנזק: משתמשים בפקודות Kubernetes רגילות כדי לראות מה נכשל.
   • ‫👈💻 בודקים את הסטטוס של ה-pods ואת השמות שלהם:

     kubectl get pods
     

     • תצפית: אתם רואים תרמילים ב-ImagePullBackOff,‏ CrashLoopBackOff,‏ Pending או CreateContainerConfigError.
     • הערה: אם הפוד במצב Running, זה לא אומר שהוא פועל בצורה תקינה. לדוגמה, יכול להיות שחסרים בו מספיק בדיקות תקינות (פעילות/מוכנות), ולכן הוא מסומן כפועל גם אם האפליקציה שבתוכו נכשלת. היומנים יכולים להראות לנו שגיאות, למרות שנראה שה-pod פועל. יש 11 שגיאות שונות שצריך לתקן.
   • ‫👈💻 כדי לראות אירועים, מתארים פוד שנכשל (מחליפים את [POD_NAME] בשם פוד בפועל):

     kubectl describe pod [POD_NAME]
     

   • ‫👈💻 בודקים את היומנים של ה-pod שנכשל כדי לראות שגיאות באפליקציה:

     kubectl logs [POD_NAME]
     

3. העבודה הבלשית: פותחים את קובצי המניפסט ב-kubernetes-manifests/ באמצעות Cloud Shell Editor או cat בטרמינל. נסו למצוא קשר בין השגיאות שמופיעות ביומנים ובאירועים לבין ההגדרות בקובצי ה-YAML.אתגר: נסו לתקן רק שגיאה אחת באופן ידני. שימו לב שצריך לעבור בין קבצים כדי להבין את שאר שרשרת הכשלים.

4. שלב 1: חיפוש באינטרנט (ממשק האינטרנט של Gemini)

פתרון בעיות ידני הוא תהליך איטי, לכן ננסה להשתמש בעוזר דיגיטלי מבוסס-AI. אפליקציית האינטרנט של Gemini היא ממשק צ'אט רב-עוצמה לשימוש כללי. הוא מצטיין בהסברת מושגים וביצירת קטעי קוד. עם זאת, הוא פועל עם אפס הקשר של הסביבה הספציפית שלכם. הוא לא יכול לראות את הקבצים שלכם, לבדוק את האשכול או להריץ פקודות. צריך להעתיק ולהדביק באופן ידני את הודעות השגיאה ואת תוכן הקובץ.

1. עוברים אל Gemini: פותחים את gemini.google.com בכרטיסייה חדשה. תצטרכו להיכנס באמצעות חשבון Google שלכם.
2. לבקש עזרה בשגיאה ספציפית: נניח שמוצגת לכם השגיאה ImagePullBackOff ב-pod‏ userservice.
   👉💬 מזינים את ההנחיה הבאה בממשק האינטרנט של Gemini:
   My Kubernetes deployment for 'userservice' is failing with ImagePullBackOff. Here is the image name: us-central1-docker.pkg.dev/bank-of-anthos-ci/bank-of-anthos/user-service:v0.6.9. What is wrong?
3. התשובה של ה-AI: Gemini נותן לכם רשימה של סיבות נפוצות:
   • התמונה לא קיימת.
   • אין לך הרשאות לשלוף אותו.
   • יש שגיאת הקלדה.
   מומלץ לבדוק את הרישום או את ההרשאות ב-IAM. אבל הוא לא יכול לדעת ששם התמונה בפועל הוא userservice (בלי המקף) אלא אם הוא רואה את הפרויקט שלכם.

הבעיה העיקרית כאן היא של-Gemini אין גישה לסביבה המקומית שלכם. כדי לקבל את ההקשר שהוא צריך, תצטרכו לספק אותו באופן ידני (על ידי כתיבת הנחיות והעתקה והדבקה של טקסט), וזה תהליך שגוזל זמן ועלול להוביל לשגיאות.

5. שלב 2: עוצמת הטרמינל (Gemini CLI)

עכשיו עוברים לטרמינל באמצעות Gemini CLI. ‫Gemini CLI מאפשר לכם לנצל את היכולות של מודלי Gemini ישירות בטרמינל. ממשק ה-CLI נמצא במקום שבו אתם עובדים. הוא קורא קבצים מקומיים, מקבל קלט מצינורות ואפילו מריץ פקודות של מעטפת בשמכם (באישורכם). התכונה הזו שימושית מאוד לשילוב של AI בתהליכי העבודה בלי להחליף הקשר. לקבלת מידע מפורט יותר על שימוש מתקדם, אפשר לעיין במסמכים הרשמיים של Gemini CLI.

הערה: נכון לעכשיו, Antigravity CLI הושק באופן רשמי והוא מחליף את Gemini CLI. ב-Lab הזה ממשיכים להשתמש ב-Gemini CLI. פרטים נוספים על Antigravity CLI זמינים במסמכי התיעוד הרשמיים של Antigravity CLI.

הקשר והחשיפה

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

הפעלת Gemini CLI

‫Gemini CLI כלול ב-Cloud Shell כברירת מחדל. פשוט מפעילים אותו כדי להתחיל להשתמש בו עם הקבצים המקומיים.

1. עוברים לספרייה Cymbal Bank:
   👉💻 מריצים את הפקודה הבאה כדי לוודא שאתם בספרייה הנכונה:

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank
   

2. מפעילים את Gemini CLI:
   👉💻 מריצים את הפקודה הבאה כדי להפעיל את Gemini CLI:

   gemini
   

שימוש ב-Gemini CLI

כל מה שאתם יודעים על האפליקציה הזו הוא איפה נמצא הקוד, ושהיא נכשלת. בואו נלמד עוד על Gemini ונראה איך הוא יכול לעזור לכם לתקן את האפליקציה. קודם כל, כדאי לבדוק את היכולת שלו לחקור את ההקשר על ידי שאילת שאלה לגבי קבצי האפליקציה שהוא אמור לראות.

1. בדיקת בסיס הקוד: יש לך שאלה ל-Gemini? בקש מ-Gemini להסביר מה האפליקציה הזו ומה היא עושה.
   👉💬 מזינים את ההנחיה הבאה ב-Gemini CLI:
   What is this application and what does it do?
   Gemini CLI קורא את הקבצים בספרייה הנוכחית ומספק סקירה כללית של הפרויקט.
2. מנסים למצוא בעיה בבסיס הקוד: מכיוון ש-Gemini CLI רואה את הקבצים, אפשר לבקש ממנו למצוא אי התאמה.
   מזינים את ההנחיה הבאה ב-Gemini CLI:
   The contacts service pod is running, but I can't reach the service. Review kubernetes-manifests/contacts.yaml and check for common issues
   Gemini CLI קורא את הקבצים ומזהה את אי ההתאמה בין app: contacts-backend לבין app: contacts. זהו שיפור משמעותי לעומת השלבים הקודמים.
3. מבקשים מ-Gemini לתקן את הקוד:
   👉💬 מזינים את ההנחיה הזו ב-Gemini CLI:
   Fix the label mismatch in contacts.yaml so the service matches the deployment.
   Gemini CLI יציג את קובץ ה-YAML המתוקן או אפילו יחיל את השינוי אם תאשרו את הפקודה.
4. המגבלה: למרות שהכלי רואה את הקבצים, הוא עדיין לא יודע מה באמת פועל באשכול. אם הפוד נכשל בגלל שגיאת זמן ריצה שלא ברורה מ-YAML סטטי, אי אפשר לעזור בלי יומנים או מצב האשכול.

הערה: כשמריצים פקודות או מבצעים שינויים בקבצים, Gemini CLI יבקש מכם אישור. כך תוכלו לשמור על שליטה בסביבה שלכם. כשמופיעה בקשה כמו זו שבהמשך, אתם יכולים להקיש על Enter כדי לבחור באפשרות '1. אישור חד-פעמי' לכל בקשת פעולה. אתם יכולים גם להקיש על מקש החץ למטה ואז על Enter כדי לבחור באפשרות '2. אישור להפעלה הנוכחית'. במקרה כזה, Gemini CLI תמיד יבצע את הפעולה באופן עצמאי, בלי לבקש את האישור שלכם, למשך השיחה הנוכחית. עם זאת, אם תסגרו את Gemini CLI ותפתחו אותו מחדש, לא יהיה לו יותר אישור והוא שוב יבקש מכם אישור לפני ביצוע פעולה כלשהי.

הערה: אם נתקעתם או שאתם רוצים לנסות שוב מההתחלה, אתם יכולים לאפס את מניפסטים של Kubernetes למצב השבור הראשוני שלהם בכל שלב על ידי הפעלת ../break.sh מהספרייה cymbal-bank.

הערה: אם הגעתם למגבלת השימוש, בוחרים באפשרות 'הפסקה' ואז מריצים את הפקודה ‎ /model כדי לראות אילו מודלים הגיעו למגבלות שלהם, וכדי לעבור למודל אחר, כמו gemini-2.5-flash-lite. לאחר מכן, מזינים את ההנחיה continue (המשך) כדי להמשיך את השימוש במעבדה באמצעות המודל החדש.

6. שלב 3: ניפוי באגים בהקשר מלא (Gemini CLI + GKE MCP)

בשלב 2 ראינו כמה חזק יכול להיות ה-AI כשהוא יכול לראות את הקבצים שלכם, אבל הוא גם היה רועש. הייתם צריכים לאשר ידנית כל קריאת קובץ וכל פעולה של כלי, מה שיצר חיכוך משמעותי במהלך סשן מורכב של ניפוי באגים. בשלב 3 אנחנו מציגים את שרת ה-GKE MCP כדי לפתור את הבעיה הזו, ומספקים ל-AI 'מודעות לתשתית' ישירה. כך Gemini יכול לפתור בעיות ביומנים, באירועים ובמטא-נתונים עם פחות הפרעות ידניות, וליצור תהליך אוטומטי יותר של פתרון בעיות.

מה זה MCP?

כדי להבין את MCP, כדאי קודם להבין את המושג כלים בעולם ה-AI. כלי הוא בעצם פונקציה או אפליקציה חיצונית שמודל LLM יכול להשתמש בהן כדי לבצע פעולות או לאחזר נתונים שהוא לא יכול לגשת אליהם בדרך אחרת – כמו בדיקת מזג האוויר, הפעלת סקריפט ספציפי או שליחת שאילתה למסד נתונים. כל כלי בנפרד הוא עוצמתי, אבל תמיד היה קשה לשתף אותם בצורה מאובטחת ועקבית בין סביבות וסוכני AI שונים. פלטפורמת MCP פותרת את הבעיה הזו בכך שהיא פועלת כפלטפורמה סטנדרטית שיכולה לארח את הכלים האלה ולחשוף אותם לכל לקוח AI תואם.

‫Model Context Protocol‏ (MCP) הוא פרוטוקול קוד פתוח שמאפשר למודלים של AI לגשת בצורה מאובטחת למקורות נתונים ולכלים חיצוניים. במקום לקודד שילובים לכל כלי או מסד נתונים ספציפיים, MCP מספק דרך סטנדרטית למודלים ליצור אינטראקציה עם הסביבה שלהם.

כדי לראות את הכלים הזמינים ב-Gemini CLI, מריצים את הפקודה /mcp בתוך Gemini CLI.

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

הגדרת תוסף GKE MCP

כברירת מחדל, Gemini CLI הוא כלי לשימוש כללי. מגדירים את שרת ה-MCP של GKE על ידי יצירת קובץ תצורה.

1. ‫👉💻 קודם כל, אם אתם עדיין ב-Gemini CLI, הקלידו /quit כדי לצאת.
2. ‫👉💻 מריצים את הפקודה הבאה כדי ליצור את ספריית התוסף:

   mkdir -p ~/.gemini/extensions/gke
   

3. ‫👉💻 מריצים את הפקודה הבאה כדי ליצור את קובץ התצורה. הפקודה הזו מוסיפה אוטומטית את PROJECT_ID לקובץ:

   cat << EOF > ~/.gemini/extensions/gke/gemini-extension.json
   {
     "name": "gke",
     "version": "1.0.0",
     "mcpServers": {
       "container": {
         "httpUrl": "https://container.googleapis.com/mcp",
         "authProviderType": "google_credentials",
         "oauth": {
           "scopes": ["https://www.googleapis.com/auth/container"]
         },
         "timeout": 30000,
         "headers": {
           "x-goog-user-project": "$PROJECT_ID"
         }
       }
     }
   }
   EOF
   

4. ‫👉💻 מפעילים את Gemini CLI:

   gemini
   

5. כדי לוודא ששרת ה-MCP מופעל, מקלידים /mcp ב-Gemini CLI.

איך מבקשים מ-Gemini לנפות באגים באמצעות מצב האשכול

1. ניפוי באגים בפריסה שנכשלה: עכשיו אפשר לבקש מ-Gemini לבדוק את האשכול ולתקן את המניפסטים על סמך מה שהוא מוצא.
   👉💬 מזינים את ההנחיה הבאה ב-Gemini CLI:
   The frontend deployment is failing. Can you use your tools to check the logs and events of the pods, and then fix it?
   Gemini משתמש בכלי MCP כדי להפעיל פקודות kubectl ברקע. הוא מזהה את השגיאה ImagePullBackOff, מסביר את הסיבה לה, ומציע את התיקון הנכון.
2. תיקון בעיות מורכבות: אפשר לבקש ממנו לבדוק יומנים כדי למצוא שגיאות ברמת האפליקציה.
   👉💬 מזינים את ההנחיה הזו ב-Gemini CLI:
   Check the logs for the 'contacts' pod. Why is it failing to connect to the database?
   הוא יזהה את השגיאה 'החיבור נדחה' ויאתר את מקור הבעיה: חוסר התאמה בין היציאה או בין שם השירות ב-config.yaml!
3. חוזרים על הפעולה: ממשיכים לבקש מ-Gemini לתקן את הבעיות האחרות שמצאתם בשלב 0.
   👉💬 מזינים את ההנחיה הזו ב-Gemini CLI:
   Check if the service 'contacts' is correctly routing traffic to its pods
   👉💬 מזינים את ההנחיה הזו ב-Gemini CLI:
   Are there any pods failing due to resource limits?

הערה: אם נתקעתם או שאתם רוצים לנסות שוב מההתחלה, אתם יכולים לאפס את מניפסטים של Kubernetes למצב השבור הראשוני שלהם בכל שלב על ידי הפעלת ../break.sh מהספרייה cymbal-bank.

7. שלב 4: העצמת הצוות (כישורי נציגים)

לבסוף, אפשר להרחיב את היכולות של ה-AI בהתאם לצרכים הספציפיים שלכם על ידי יצירת כישורי סוכן בהתאמה אישית.

מהן מיומנויות של סוכנים?

מיומנויות של סוכני AI הן חבילות של הוראות, סקריפטים ומשאבים שמרחיבים את היכולות של סוכן AI למשימות מיוחדות. הם מאפשרים לכם לקבוע סטנדרטים ארגוניים ולהפוך תהליכי עבודה מורכבים לאוטומטיים. מיומנות נמצאת בספרייה ספציפית ומכילה קובץ SKILL.md שמגדיר את ההתנהגות שלה. כשיוצרים מיומנויות, מוודאים שה-AI יפעל לפי תהליך עקבי וניתן לחזרה, במקום לאלתר.

ספריית מיומנויות טיפוסית נראית כך:

my-skill/
├── SKILL.md          # Main instruction file (Required)
├── scripts/           # Helper scripts (Optional)
└── resources/         # Templates or data files (Optional)

יצירת מיומנות לפתרון בעיות ב-Kubernetes

במקום ליצור את הקבצים האלה באופן ידני, Gemini CLI מספק דרך יעילה ליצור תבנית של מיומנויות באמצעות שפה טבעית.

נניח שאתם רוצים ליצור מיומנות שנקראת k8s-troubleshooter כדי להפוך את השלבים שביצעתם עכשיו לאוטומטיים.

1. יצירת מיומנות באמצעות הנחיה: אתם יכולים לבקש מ-Gemini CLI ליצור את המיומנות בשבילכם, על סמך מה שלמדתם היום.
   👉💬 מזינים את ההנחיה הבאה ב-Gemini CLI:
   Create a new skill called 'k8s-troubleshooter' that helps diagnose issues with Kubernetes manifests and cluster state. It should be able to analyze pod logs, events, and resource descriptions to identify common deployment problems and configuration errors.
   בדומה למצב שבו הוא מפעיל כלי או מבצע פעולה, Gemini CLI אמור להודיע לכם שההנחיה שלכם הפעילה את היכולת שלו ליצור מיומנויות. זוהי מיומנות שהוגדרה מראש ב-Gemini CLI, שמאפשרת ל-Gemini ליצור מיומנויות של סוכנים.‫
   Gemini צריך לבקש מכם הרשאה ליצור את ספריית הכישורים. לוחצים על 1. התרה פעם אחת".‫
   Gemini באופן אוטומטי:
   • יוצר ספרייה בנתיב ~/.gemini/skills/k8s-troubleshooter/.
   • המערכת יוצרת קובץ SKILL.md עם הוראות על סמך ההנחיה שלכם.
   • יוצרת ספריות משאבים רגילות.
2. מפעילים מחדש את Gemini CLI:
   👉💻 סוגרים את Gemini CLI (/quit) ומפעילים אותו מחדש:

   gemini
   

3. מוודאים שהמיומנות נטענה:
   👉💻 כדי לוודא שהמיומנות פעילה, מקלידים /skills ב-Gemini CLI. k8s-troubleshooter אמור להופיע ברשימה.
4. איך זה עובד בפועל: עכשיו מפעילים את המיומנות:
   👉💬 מזינים את ההנחיה הבאה ב-Gemini CLI:
   Use the k8s-troubleshooter skill to find out why the contacts service is failing.
   ה-AI פועל לפי התוכנית המובנית ב-SKILL.md במקום לאלתר, וכך משיג תוצאות עקביות יותר.

תרגיל: יצירת קונספט למיומנויות שלכם

תחשבו על תהליך העבודה היומי שלכם. איזו משימה שחוזרת על עצמה תוכלו להפוך לאוטומטית באמצעות מיומנות?

• רעיון: מיומנות לביקורת של קובצי מניפסט כדי לוודא שהם עומדים בשיטות המומלצות לאבטחה לפני הפריסה.
• רעיון: מיומנות ליצירת הגדרות מורכבות של אשכולות GKE על סמך סוג עומס העבודה.

8. סיכום

בשיעור ה-Lab הזה נדגים דרך חדשה ליצור אינטראקציה עם תשתית ענן באמצעות התקדמות ברמות שונות של הקשר AI. כשעוברים מאפס הקשר להקשר מלא של התשתית (Gemini CLI + GKE MCP), אפשר לראות כמה העוזר הדיגיטלי מבוסס-AI הופך ליעיל יותר כשהוא רואה את הקבצים ואת מצב האשכול.

סיכום המעבדה

• הקשר חשוב: אפשר לראות איך כלי AI ללא הקשר לא יכולים לעזור בבעיות ספציפיות בבסיס הקוד.
• הקשר בטרמינל: אתם יכולים להשתמש ב-Gemini CLI כדי לנתח קבצים מקומיים ולזהות שגיאות בהגדרות ישירות מתוך סביבת העבודה.
• ניפוי באגים בהקשר מלא: אתם יכולים להשתמש ב-Gemini CLI עם MCP כדי לאפשר ל-AI לאבחן ולתקן בעיות מורכבות על ידי שילוב של קבצי בסיס קוד עם מצב חי של אשכול.
• הרחבה: אתם לומדים על מיומנויות ואיך להשתמש בהן כדי לקודד ידע ארגוני.

הסרת המשאבים

כדי למנוע חיובים שוטפים, מריצים את סקריפט הפירוק. שימו לב: השלב הזה לא נדרש אם אתם מריצים את ה-Lab ב-Qwiklabs.

‫👈💻 מריצים את הפקודה הבאה מהספרייה של הסדנה:

cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
./teardown.sh

השלבים הבאים

ריכזנו כאן כמה המלצות לקריאה נוספת:

• משאבי עזרה ל-Gemini CLI: משאבי העזרה הרשמיים ל-Gemini CLI.
• מסמכי GKE: דף הנחיתה של כל מסמכי GKE.
• הנדסת פלטפורמות ב-Google Cloud: הנחיות לגבי הגישה להנדסת פלטפורמות ב-Google Cloud.
• AI and machine learning on GKE: מסמכים על הרצת עומסי עבודה של AI/ML ב-GKE.
• מרכז הארכיטקטורה של Google Cloud: מדריכים ושיטות מומלצות ליצירת עומסי עבודה ב-Google Cloud.

9. נספח: פתרון לבעיות בקובץ המניפסט

אם נתקלתם בבעיה או שאתם רוצים לאמת את השגיאות, הנה רשימת השינויים שבוצעו בספרייה manifests-broken/ והסבר איך לתקן אותם:

1. כתובות URL בפורמט שגוי בconfig.yaml:
   • שגיאה: TRANSACTIONS_API_ADDR: "ledgerwriter::8080" (נקודתיים כפולות).
   • למה: האפליקציה לא מצליחה לנתח את הכתובת, ולכן מתרחשות שגיאות בחיבור.
   • תיקון: מחזירים את הערך ל-"ledgerwriter:8080".
2. תוויות לא תואמות בcontacts.yaml:
   • שגיאה: סלקטור השירות מוגדר ל-app: contacts-backend במקום ל-contacts.
   • למה: השירות לא יכול למצוא את ה-Pods (שעדיין יש להם app: contacts), ולכן התנועה לא תנותב.
   • פתרון: משנים את הבחירה ל-app: contacts.
3. אי התאמות ביציאות בuserservice.yaml:
   • שגיאה: השירות targetPort הוגדר לערך 8081 במקום 8080.
   • למה: התנועה שנשלחת לשירות תועבר ליציאת קונטיינר שגויה, ולכן החיבור יידחה.
   • פתרון: מחליפים את targetPort בחזרה ל-8080.
4. שמות שירותים לא תואמים בconfig.yaml:
   • שגיאה: BALANCES_API_ADDR: "balance-reader:8080" (במקום balancereader).
   • למה: שם המארח לא יפוענח ב-DNS כי השירות נקרא balancereader.
   • תיקון: מחזירים את הערך ל-"balancereader:8080".
5. מדיניות שליפת תמונות ב-contacts.yaml:
   • שגיאה: imagePullPolicy: Never.
   • למה: מערכת K8s לא תמשוך את התמונה מהרישום, כי היא מניחה שהיא מקומית. היא תיכשל עם השגיאה ErrImagePull.
   • פתרון: מסירים את השורה או מגדירים אותה לערך IfNotPresent.
6. כשלים בבדיקת המוכנות ב-userservice.yaml:
   • שגיאה: הנתיב השתנה ל-/healthz במקום ל-/ready.
   • למה: הקונטיינר לא מציג את /healthz, לכן הבדיקה נכשלת וה-Pod אף פעם לא מסומן כ'מוכן'.
   • פתרון: מחזירים את הנתיב ל-/ready.
7. מגבלות משאבים ב-contacts.yaml:
   • שגיאה: מגבלת הזיכרון הוגדרה ל-10Mi במקום ל-128Mi.
   • למה: האפליקציה צריכה יותר זיכרון כדי להתחיל לפעול, ולכן היא נסגרת בגלל חוסר זיכרון (OOM).
   • פתרון: משחזרים את מגבלת הזיכרון.
8. חסרים משתני סביבה ב-frontend.yaml:
   • שגיאה: הוסר משתנה הסביבה REGISTERED_OAUTH_CLIENT_ID.
   • למה: יכול להיות שהאפליקציה תיכשל או תשבית תכונות אם חסרים משתני סביבה צפויים.
   • פתרון: משחזרים את ההגדרה של משתנה הסביבה.
9. אי התאמה של מפתח ConfigMap בfrontend.yaml:
   • שגיאה: key: DEMO_USER במקום DEMO_LOGIN_USERNAME.
   • למה: מערכת K8s לא יכולה למצוא את המפתח ב-ConfigMap, ולכן הקונטיינר לא מצליח להתחיל.
   • התיקון: מחזירים את המקש ל-DEMO_LOGIN_USERNAME.
10. שגיאת כתיב בשם התמונה בuserservice.yaml:
    • שגיאה: user-service במקום userservice.
    • למה: התמונה לא קיימת במאגר, ולכן מתקבלת השגיאה ImagePullBackOff.
    • איך פותרים את הבעיה: מתקנים את שם התמונה.
11. בעיות בחשבון שירות ב-contacts.yaml:
    • שגיאה: bank-of-anthos-sa במקום bank-of-anthos.
    • למה: חשבון השירות לא קיים או שאין לו הרשאות.
    • פתרון: משתמשים בשם הנכון של חשבון השירות.