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

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

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

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

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

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

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

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

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

הקצאת CPU

  • המעבד תמיד מוקצה כשמריצים בדיקות.
  • כל הבקשות לבדיקת תקינות (probe) מחויבות על צריכת המעבד (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), שלא יכול לעלות על 240 שניות, Cloud Run משבית את הקונטיינר.

אם בדיקת ההפעלה מסוג HTTP מצליחה בתוך הזמן שצוין, והגדרתם בדיקת פעילות מסוג HTTP, ‏ Cloud Run מפעיל את בדיקת הפעילות מסוג HTTP.
בדיקת פעילות HTTP יצירה של נקודת קצה (endpoint) לבדיקת תקינות HTTP
שימוש ב-HTTP/1		 בקשה לבדיקת תקינות מצב פעילות מתחילה רק אחרי שבקשה לבדיקת תקינות ההפעלה מסתיימת בהצלחה. אחרי שמגדירים את הבדיקה, ואחרי שכל בדיקת הפעלה מסתיימת בהצלחה, Cloud Run שולח בקשת GET לנקודת הקצה של בדיקת תקינות (לדוגמה, /health). כל תגובה בין 200 ל-400 נחשבת להצלחה, וכל תגובה אחרת מצביעה על כשל.

אם בדיקת הפעילות לא מסתיימת בהצלחה בתוך הזמן שצוין (failureThreshold * periodSeconds), ‏ Cloud Run משבית את הקונטיינר באמצעות אות SIGKILL. כל הבקשות שנותרו שעדיין מוגשות על ידי הקונטיינר מסתיימות עם קוד הסטטוס 503‏ HTTP. אחרי ש-Cloud Run משבית את הקונטיינר, התאמה אוטומטית לעומס ב-Cloud Run מפעילה מכונת קונטיינר חדשה.
הפעלה של gRPC הטמעה של פרוטוקול בדיקת התקינות של gRPC במאגר העובדים של Cloud Run אם בקשה לבדיקת תקינות (probe) של הפעלה לא מצליחה במסגרת הזמן שצוין (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 (מאגרי עובדים).

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

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

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

  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), צריך לציין את הפרטים הבאים:

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

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

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

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

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

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

API ל-REST

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

הפעלה של HTTP

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

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

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

הפעלה של gRPC

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

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

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

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

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

startupProbe:
  httpGet:
    path: /ready

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