הגדרת בדיקות תקינות של קונטיינרים למאגרי עובדים

בדיקות תקינות מאפשרות לכם לעקוב אחרי סטטוס הקונטיינר ולהפעיל מחדש באופן אוטומטי מופעים לא תקינים במאגרי העובדים של Cloud Run. אתם יכולים להגדיר בדיקות הפעלה של HTTP,‏ TCP ו-gRPC, וגם בדיקות פעילות של HTTP ו-gRPC, בהגדרות חדשות וקיימות.

תרחישים לדוגמה

אפשר להגדיר שני סוגים של בדיקות תקינות:

• בדיקות פעילות קובעות אם להפעיל מחדש קונטיינר.

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

• בדיקות מוכנות להפעלה קובעות אם הקונטיינר הופעל.

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

הערה: אם יש ב-worker pool כשלים חוזרים בהפעלת בדיקות או בבדיקות פעילות, Cloud Run מגביל את ההפעלה מחדש של המופעים כדי למנוע לולאות קריסה לא מבוקרות.

הקצאת מעבד (CPU)

• המעבד תמיד מוקצה כשמריצים בדיקות.
• כל הבדיקות מחויבות על צריכת השימוש במעבד ובזיכרון.

דרישות לגבי בדיקות ודפוסי התנהגות

סוג החיישן	דרישות	התנהגות
הפעלה של TCP	ללא	אם מציינים יציאה, Cloud Run יוצר חיבור TCP כדי לפתוח את שקע ה-TCP ביציאה שצוינה. אם Cloud Run לא מצליח ליצור חיבור, הוא מציין שהפעולה נכשלה. אם בדיקת ההפעלה לא מצליחה בתוך הזמן שצוין, Cloud Run משבית את הקונטיינר. הזמן הוא עד 240 שניות, והוא מחושב לפי failureThreshold * periodSeconds, שמוגדר כשמגדירים את בדיקת ההפעלה של מאגר העובדים.
הפעלה של HTTP	יוצרים נקודת קצה (endpoint) לבדיקת תקינות ב-HTTP שימוש ב-HTTP/1	אחרי שמגדירים את הבדיקה, Cloud Run שולח בקשת GET לנקודת הקצה של בדיקת תקינות מאגר העובדים (לדוגמה, /ready). כל תגובה בין 200 ל-400 נחשבת להצלחה, וכל תגובה אחרת מצביעה על כשל. אם בדיקת ההפעלה לא מצליחה בתוך הזמן שצוין (failureThreshold * periodSeconds), שלא יכול לעלות על 600 שניות (1,800 שניות ל-GPU),‏ Cloud Run משבית את הקונטיינר. אם בדיקת ההפעלה של HTTP מצליחה בתוך הזמן שצוין, והגדרתם בדיקת פעילות של HTTP,‏ Cloud Run מפעיל את בדיקת הפעילות של HTTP.
בדיקת פעילות של HTTP	יוצרים נקודת קצה (endpoint) לבדיקת תקינות ב-HTTP שימוש ב-HTTP/1	בדיקת הפעילות מתחילה רק אחרי שבדיקת ההפעלה מסתיימת בהצלחה. אחרי שמגדירים את הבדיקה, ואחרי שכל בדיקת הפעלה מסתיימת בהצלחה, Cloud Run שולח בקשת HTTP GET לנקודת הקצה של בדיקת תקינות (לדוגמה, /health). כל תגובה בין 200 ל-400 נחשבת להצלחה, וכל תגובה אחרת מצביעה על כשל. אם בדיקת הפעילות לא מסתיימת בהצלחה בתוך הזמן שצוין (failureThreshold * periodSeconds), ‏ Cloud Run משבית את הקונטיינר באמצעות אות SIGKILL. כל הבקשות שנותרו שהמשיכו להיות מוגשות על ידי מאגר התגים מופסקות עם קוד סטטוס של HTTP 503‏. אחרי ש-Cloud Run משבית את הקונטיינר, מתחיל תהליך של התאמה אוטומטית לעומס (automatic scaling) ב-Cloud Run, ונוצרת מופע חדש של הקונטיינר.
הפעלה של gRPC	הטמעה של פרוטוקול בדיקת התקינות של gRPC במאגר העובדים של Cloud Run	אם בדיקת ההפעלה לא מצליחה בתוך פרק הזמן שצוין (failureThreshold * periodSeconds), שלא יכול להיות ארוך מ-600 שניות (1,800 שניות ל-GPU),‏ Cloud Run משבית את הקונטיינר.
מצב הפעילות (liveness) של gRPC	הטמעה של פרוטוקול בדיקת התקינות של gRPC במאגר העובדים של Cloud Run	אם מגדירים בדיקת מוכנות להפעלה של gRPC, בדיקת החיות מתחילה רק אחרי שבדיקת המוכנות להפעלה מסתיימת בהצלחה. אחרי שמגדירים את בדיקת החיות, ואחרי שבדיקת המוכנות להפעלה מסתיימת בהצלחה, Cloud Run שולח בקשה לבדיקת תקינות למאגר העובדים. אם בדיקת החיות לא מסתיימת בהצלחה בתוך הזמן שצוין (failureThreshold * periodSeconds), ‏ Cloud Run משבית את הקונטיינר באמצעות אות SIGKILL. אחרי ש-Cloud Run משבית את הקונטיינר, מתחיל תהליך של התאמה אוטומטית לעומס (automatic scaling) ב-Cloud Run, ונוצרת מופע חדש של הקונטיינר.

הגדרת בדיקות

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

אפשר להגדיר בדיקות HTTP,‏ TCP ו-gRPC באמצעות המסוף Google Cloud או Cloud Run API בארכיטקטורת REST:

המסוף

1. נכנסים ל-Cloud Run במסוף Google Cloud :

   כניסה ל-Cloud Run

2. בתפריט, בוחרים באפשרות Worker pools (מאגרי עובדים).

   • אם אתם מגדירים מאגר עובדים חדש, לוחצים על Deploy container (פריסת קונטיינר).
   • אם אתם מגדירים מאגר עובדים קיים, בוחרים את מאגר העובדים ולוחצים על Edit and deploy new revision (עריכה ופריסה של גרסה חדשה).

3. אם אתם מגדירים מאגר עובדים חדש, ממלאים את הדף הראשוני של מאגר העובדים ולוחצים על Containers, Networking, Security כדי להרחיב את דף ההגדרות של מאגרי העובדים.

4. בקטע Container(s), עוברים אל Health checks ולוחצים על Add health check כדי לפתוח את חלונית ההגדרות Add health check.

5. בתפריט Select health check type (בחירת סוג בדיקת תקינות), בוחרים את סוג בדיקת התקינות שרוצים להוסיף.

6. בתפריט Select probe type (בחירת סוג בדיקה), בוחרים את סוג הבדיקה שרוצים להשתמש בו, לדוגמה, HTTP או gRPC. יוצג טופס הגדרת הבדיקה.

7. מגדירים את הגדרות הבדיקה, שמשתנות בהתאם לסוג הבדיקה:

   • אם אתם משתמשים בבדיקות תקינות של אתרים מסוג HTTP:

     • בשדה Path (נתיב) מציינים את הנתיב היחסי אל נקודת הקצה, לדוגמה, /.

     • מסמנים את תיבת הסימון HTTP Headers (כותרות HTTP) כדי לציין כותרות מותאמות אישית אופציונליות. מציינים את שם הכותרת בשדה Name (שם) ואת ערך הכותרת בשדה Value (ערך). כדי לציין עוד כותרות, לוחצים על הוספת כותרת HTTP.

   • אם אתם משתמשים בבדיקות gRPC, ודאו שקובץ האימג' של הקונטיינר מטמיע את פרוטוקול בדיקת תקינות של gRPC. מידע נוסף זמין במאמר בנושא פרוטוקול בדיקת התקינות של GRPC.

   • לשני סוגי הבדיקות (HTTP ו-gRPC), צריך לציין את הפרטים הבאים:

     • השהיה ראשונית: מציינים את מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול לפני שמבצעים את הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.

     • תקופה, מציינים את התקופה (בשניות) שבה יתבצע הניסיון. לדוגמה, מציינים 2 כדי לבצע את הבדיקה כל 2 שניות. מציינים ערך בין שנייה אחת ל-600 שניות (1,800 שניות ל-GPU). ערך ברירת המחדל הוא 10 שניות.

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

     • פסק זמן: מציינים את מספר השניות להמתנה עד שפסק הזמן של הבדיקה יחול. צריך לציין ערך מ-1 עד הערך הקטן מבין 600 (1,800 ל-GPU) ו-periodSeconds. ערך ברירת המחדל הוא 1.

8. לוחצים על הוספה כדי להוסיף את ערך הסף החדש.

9. לוחצים על יצירה או על פריסה.

‫API בארכיטקטורת REST

חשוב: אם אתם מגדירים את מאגר העובדים של Cloud Run לבדיקות HTTP, אתם צריכים גם להוסיף נקודת קצה לבדיקת תקינות HTTP בקוד של מאגר העובדים כדי להגיב לבדיקה. אם מגדירים בדיקת תקינות של gRPC, צריך להטמיע גם את פרוטוקול בדיקת התקינות של gRPC במאגר העובדים של Cloud Run.

הפעלה של HTTP

כדי להגדיר את זה, משתמשים ב-REST API.

בדיקת פעילות של HTTP

כדי להגדיר את זה, משתמשים ב-REST API.

הפעלה של gRPC

כדי להגדיר את זה, משתמשים ב-REST API.

gRPC liveness

כדי להגדיר את זה, משתמשים ב-REST API.

יצירת נקודות קצה של בדיקות תקינות ב-HTTP

אם מגדירים את מאגר העובדים של Cloud Run לבדיקת הפעלה או לבדיקת סטטוס ב-HTTP, צריך להוסיף נקודת קצה בקוד של מאגר העובדים כדי להגיב לבדיקה. אפשר לתת לנקודת הקצה כל שם שרוצים, למשל /startup או /ready, אבל השם חייב להיות זהה לערך שמציינים עבור path בהגדרת הבדיקה. לדוגמה, אם מציינים /ready לבדיקת הפעלה של HTTP, צריך לציין path בהגדרות הבדיקה כמו שמוצג כאן:

startupProbe:
  httpGet:
    path: /ready

נקודות קצה (endpoints) לבדיקת תקינות ב-HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות ב-HTTP שחשופות מבחוץ.