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

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

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

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

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

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

סוג החיישן דרישות התנהגות
הפעלה של TCP ללא אם Cloud Run לא מצליח ליצור חיבור, הוא מציין שהפעולה נכשלה.

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

אם בדיקת החיות של ההפעלה לא מצליחה בתוך הזמן שצוין (failureThreshold * periodSeconds), שלא יכול לעלות על 600 שניות (1,800 עבור GPU), הקונטיינר מושבת
הפעלה של gRPC הטמעה של פרוטוקול בדיקת התקינות של gRPC במשימת Cloud Run אם בדיקת ההפעלה לא מצליחה בתוך הזמן שצוין (failureThreshold * periodSeconds), שלא יכול להיות יותר מ-600 שניות (1,800 שניות ל-GPU), הקונטיינר נסגר.

הגדרת בדיקות

מגדירים בדיקות HTTP,‏ TCP ו-gRPC באמצעות מסוף Google Cloud או YAML:

המסוף

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

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

    כניסה ל-Cloud Run

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

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

    • אם אתם משתמשים בבדיקות תקינות של האתר כשכתובת ה-URL היא מסוג HTTP:
      • בשדה Path (נתיב) מציינים את הנתיב היחסי אל נקודת הקצה, לדוגמה, /.
      • מסמנים את תיבת הסימון HTTP Headers (כותרות HTTP) כדי לציין כותרות מותאמות אישית אופציונליות. אחר כך מציינים את שם הכותרת בשדה Name (שם) ואת ערך הכותרת בשדה Value (ערך). כדי לציין עוד כותרות, לוחצים על הוספת כותרת HTTP.
    • בשדה Port (יציאה), מציינים את היציאה שבה מאזין קובץ ה-container של המשימה לבדיקה.
    • בקטע השהיה ראשונית, מציינים כמה שניות להמתין אחרי שהקונטיינר מתחיל לפעול לפני שמבצעים את הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
    • בקטע Period, מציינים את מרווח הזמן (בשניות) שבו תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. מציינים ערך בין שנייה אחת ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 10 שניות.
    • בקטע Failure threshold (סף כשל), מציינים כמה פעמים לנסות מחדש את הבדיקה לפני כיבוי המאגר. ערך ברירת המחדל הוא 3.
    • בקטע Timeout, מציינים כמה שניות להמתין עד שהבדיקה תסתיים. הערך הזה לא יכול להיות גדול מהערך שצוין עבור periodSeconds. מציינים ערך מ-1 עד 600 (או 1,800 אם משתמשים ב-GPU). ערך ברירת המחדל הוא 1.

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

YAML

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

הפעלה של TCP

  1. אם אתם יוצרים משרה חדשה, דלגו על השלב הזה. אם אתם מעדכנים משימה קיימת, אתם צריכים להוריד את הגדרת ה-YAML שלה:

    gcloud run jobs describe JOB_NAME --format export > job.yaml

  2. מגדירים את מאפיין startupProbe כמו שמוצג כאן:

    apiVersion: run.googleapis.com/v1
kind: Job
metadata:
 name: JOB
spec:
 template:
   metadata:
   spec:
     containers:
     - image: IMAGE_URL
       startupProbe:
         tcpSocket:
           port: CONTAINER_PORT
         initialDelaySeconds: DELAY
         timeoutSeconds: TIMEOUT
         failureThreshold: THRESHOLD
         periodSeconds: PERIOD

    מחליפים את המשתנים הבאים:

    • ‫JOB מחליפים בשם של משימת Cloud Run.
    • ‫IMAGE_URL עם כתובת ה-URL של קובץ אימג' של קונטיינר המשימות, לדוגמה: us-docker.pkg.dev/cloudrun/container/job:latest.
    • אופציונלי: CONTAINER_PORT עם היציאה שבה קונטיינר העבודה מאזין לבדיקה.
    • ‫DELAY עם מספר השניות להמתנה אחרי שהמאגר התחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
    • אופציונלי: TIMEOUT עם מספר השניות להמתנה עד שהבדיקה תסתיים. הערך הזה לא יכול להיות גדול מהערך שצוין עבור periodSeconds. מציינים ערך מ-1 עד 600 (או 1,800 אם משתמשים ב-GPU). ערך ברירת המחדל הוא 1.
    • ‫THRESHOLD עם מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
    • ‫PERIOD עם התקופה (בשניות) שבה צריך לבצע את הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. מציינים ערך בין שנייה אחת ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 10 שניות.

  3. יוצרים או מעדכנים את העבודה באמצעות הפקודה הבאה:

    gcloud run jobs replace job.yaml

הפעלה של HTTP

  1. אם אתם יוצרים משרה חדשה, דלגו על השלב הזה. אם אתם מעדכנים משימה קיימת, אתם צריכים להוריד את הגדרת ה-YAML שלה:

    gcloud run jobs describe JOB_NAME --format export > job.yaml

  2. מגדירים את מאפיין startupProbe כמו שמוצג כאן:

    apiVersion: run.googleapis.com/v1
kind: Job
metadata:
  name: JOB
spec:
  template:
    metadata:
    spec:
      containers:
      - image: IMAGE_URL
        startupProbe:
          httpGet:
            path: PATH
            port: CONTAINER_PORT
            httpHeaders:
              - name: HEADER_NAME
                value: HEADER_VALUE
          initialDelaySeconds: DELAY
          timeoutSeconds: TIMEOUT
          failureThreshold: THRESHOLD
          periodSeconds: PERIOD

    מחליפים את המשתנים הבאים:

    • ‫JOB מחליפים בשם של משימת Cloud Run.
    • ‫IMAGE_URL עם כתובת ה-URL של קובץ אימג' של קונטיינר המשימות, לדוגמה: us-docker.pkg.dev/cloudrun/container/job:latest.
    • ‫PATH עם הנתיב היחסי אל נקודת הקצה של HTTP, לדוגמה, /ready.
    • אופציונלי: CONTAINER_PORT עם היציאה שבה קונטיינר העבודה מאזין לבדיקה.
    • אופציונלי: אפשר להשתמש ב-httpHeaders כדי לספק כמה כותרות מותאמות אישית או כותרות חוזרות באמצעות השדות HEADER_NAME ו-HEADER_VALUE, כמו שמוצג.
    • אופציונלי: DELAY עם מספר השניות להמתנה אחרי שהקונטיינר התחיל לפעול לפני שמבצעים את הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
    • אופציונלי: TIMEOUT עם מספר השניות להמתנה עד שהבדיקה תסתיים. הערך הזה לא יכול להיות גדול מהערך שצוין עבור periodSeconds. מציינים ערך מ-1 עד 600 (או 1,800 אם משתמשים ב-GPU). ערך ברירת המחדל הוא 1.
    • אופציונלי: THRESHOLD עם מספר הפעמים לניסיון חוזר של הבדיקה לפני השבתת הקונטיינר. ערך ברירת המחדל הוא 3.
    • אופציונלי: PERIOD עם התקופה (בשניות) שבה יתבצע הניסיון. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. מציינים ערך בין שנייה אחת ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 10 שניות.

  3. יוצרים או מעדכנים את העבודה באמצעות הפקודה הבאה:

    gcloud run jobs replace job.yaml

הפעלה של gRPC

  1. אם אתם יוצרים משרה חדשה, דלגו על השלב הזה. אם אתם מעדכנים משימה קיימת, אתם צריכים להוריד את הגדרת ה-YAML שלה:

    gcloud run jobs describe JOB_NAME --format export > job.yaml

  2. מגדירים את מאפיין startupProbe כמו שמוצג כאן:

    apiVersion: run.googleapis.com/v1
kind: Job
metadata:
  name: JOB
spec:
  template:
    metadata:
    spec:
      containers:
      - image: IMAGE_URL
        startupProbe:
          grpc:
            service: GRPC_SERVICE
            port: CONTAINER_PORT
          initialDelaySeconds: DELAY
          timeoutSeconds: TIMEOUT
          failureThreshold: THRESHOLD
          periodSeconds: PERIOD

    מחליפים את המשתנים הבאים:

    • ‫JOB מחליפים בשם של משימת Cloud Run.
    • ‫IMAGE_URL עם כתובת ה-URL של קובץ אימג' של קונטיינר המשימות, לדוגמה: us-docker.pkg.dev/cloudrun/container/job:latest.
    • אופציונלי: GRPC_SERVICE. אם המדיניות מוגדרת, היא משמשת בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-RPC של grpc.health.v1.Health.Check.
    • אופציונלי: CONTAINER_PORT עם היציאה שבה קונטיינר העבודה מאזין לבדיקה.
    • אופציונלי: DELAY מספר השניות להמתנה אחרי שהקונטיינר התחיל לפעול לפני שמבצעים את הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
    • אופציונלי: TIMEOUT עם מספר השניות להמתנה עד שזמן התפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גדול מהערך שצוין ב-periodSeconds. מציינים ערך מ-1 עד 600 (או 1,800 אם משתמשים ב-GPU). ערך ברירת המחדל הוא 1.
    • אופציונלי: THRESHOLD עם מספר הפעמים לניסיון חוזר של הבדיקה לפני סגירת הקונטיינר. ערך ברירת המחדל הוא 3.
    • אופציונלי: PERIOD עם התקופה (בשניות) שבה יתבצע הניסיון. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. מציינים ערך בין שנייה אחת ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 10 שניות.

  3. יוצרים או מעדכנים את העבודה באמצעות הפקודה הבאה:

    gcloud run jobs replace job.yaml

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

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

startupProbe:
  httpGet:
    path: /ready