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

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

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

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

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

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

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

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

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

הקצאת CPU

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

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

סוג הבדיקה	דרישות	התנהגות
הפעלה של TCP	ללא	אם מציינים יציאה, Cloud Run יוצר חיבור TCP כדי לפתוח את שקע ה-TCP ביציאה שצוינה. אם Cloud Run לא מצליח ליצור חיבור, הוא מציין שהפעולה נכשלה. אם בדיקת ההפעלה לא מצליחה בתוך הזמן שצוין, Cloud Run משבית את הקונטיינר. הזמן הוא עד 240 שניות, שמחושב לפי failureThreshold * periodSeconds, שהגדרתם כשקבעתם את תצורת בדיקת ההפעלה של מאגר העובדים.
הפעלה של HTTP	יצירה של נקודת קצה (endpoint) לבדיקת תקינות HTTP שימוש ב-HTTP/1	אחרי שמגדירים את בדיקת המוכנות, Cloud Run שולח בקשת HTTP GET לנקודת הקצה של בדיקת תקינות מאגר העובדים (לדוגמה, /ready). כל תגובה בין 200 ל-400 נחשבת להצלחה, וכל תגובה אחרת מציינת כשל. אם בדיקת המוכנות להפעלה לא מצליחה בתוך הזמן שצוין (failureThreshold * periodSeconds), שלא יכול לעלות על 240 שניות, 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 משבית את הקונטיינר, מתחיל תהליך של שינוי גודל אוטומטי ב-Cloud Run, ומופעלת מופע קונטיינר חדש.
הפעלת gRPC	הטמעה של פרוטוקול בדיקת תקינות gRPC במאגר העובדים של Cloud Run	אם בדיקת ההפעלה לא מצליחה במסגרת הזמן שצוין (failureThreshold * periodSeconds), שלא יכול להיות גדול מ-240 שניות, Cloud Run משבית את הקונטיינר.
מצב פעילות (liveness) של gRPC	הטמעה של פרוטוקול בדיקת תקינות gRPC במאגר העובדים של Cloud Run	אם מגדירים בדיקת מוכנות להפעלה של gRPC, בדיקת החיות מתחילה רק אחרי שבדיקת המוכנות להפעלה מסתיימת בהצלחה. אחרי שמגדירים את בדיקת החיות, ואחרי שבדיקת המוכנות להפעלה מסתיימת בהצלחה, Cloud Run שולח בקשה לבדיקת תקינות למאגר העובדים. אם בדיקת החיות לא מסתיימת בהצלחה בתוך הזמן שצוין (failureThreshold * periodSeconds), ‏ Cloud Run משבית את הקונטיינר באמצעות אות SIGKILL. אחרי ש-Cloud Run משבית את הקונטיינר, מתחיל תהליך של שינוי גודל אוטומטי ב-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. מגדירים את הגדרות הבקשה לבדיקת תקינות (probe), שמשתנות בהתאם לסוג הבקשה לבדיקת תקינות (probe):

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

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

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

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

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

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

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

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

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

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

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

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

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

הפעלה של HTTP

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

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

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

הפעלת gRPC

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

מצב פעילות (liveness) של gRPC

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

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

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

startupProbe:
  httpGet:
    path: /ready

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