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

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

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

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

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

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

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

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

  • בדיקות מוכנות

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

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

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

הגדרת בדיקות מוכנות להפעלה

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

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

המסוף

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

    כניסה ל-Cloud Run

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

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

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

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

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

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

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

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

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

    • אם אתם משתמשים בבדיקות gRPC:

    • ביציאה, מציינים את יציאת הקונטיינר שמשמשת את השירות.

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

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

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

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

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

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

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

gcloud

הפעלה של TCP

מריצים את הפקודה הבאה:

  gcloud run deploy SERVICE \
      --image=IMAGE_URL \
      --startup-probe tcpSocket.port=CONTAINER_PORT,initialDelaySeconds=DELAY,failureThreshold=THRESHOLD,timeoutSeconds=TIMEOUT,periodSeconds=PERIOD

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE: השם של שירות Cloud Run.
  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא מהצורה LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות.
  • ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר התחיל לפעול לפני שמבצעים את הבקשה לבדיקת תקינות (probe) הראשונה. מציינים ערך בין 0 שניות ל-240 שניות. ערך ברירת המחדל הוא 0 שניות.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שהבדיקה תגיע לזמן קצוב לתפוגה. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-240. ערך ברירת המחדל הוא 1.
  • ‫THRESHOLD: מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
  • ‫PERIOD: תקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין שנייה אחת ל-240 שניות. ערך ברירת המחדל הוא 10 שניות.

הפעלה של HTTP

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

מריצים את הפקודה הבאה:

  gcloud run deploy SERVICE \
      --image=IMAGE_URL \
      --startup-probe httpGet.path=PATH,httpGet.port=CONTAINER_PORT,initialDelaySeconds=DELAY,failureThreshold=THRESHOLD,timeoutSeconds=TIMEOUT,periodSeconds=PERIOD

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE: השם של שירות Cloud Run.
  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • ‫PATH: נתיב יחסי לנקודת הקצה ב-HTTP, לדוגמה, /health.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: מוגדר ליציאת הקונטיינר שמשמשת את השירות.
  • זה שינוי אופציונלי. ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-240 שניות. ערך ברירת המחדל הוא 0 שניות.
  • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין ב-periodSeconds. מציינים ערך בין 1 ל-240. ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין שנייה אחת ל-240 שניות. ערך ברירת המחדל הוא 10 שניות.

הפעלת gRPC

מוודאים שקובץ אימג' של קונטיינר מטמיע את פרוטוקול בדיקת התקינות של gRPC.

מריצים את הפקודה הבאה:

  gcloud run deploy SERVICE \
      --image=IMAGE_URL \
      --startup-probe grpc.port=CONTAINER_PORT,grpc.service=GRPC_SERVICE,initialDelaySeconds=DELAY,failureThreshold=THRESHOLD,timeoutSeconds=TIMEOUT,periodSeconds=PERIOD

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE: השם של שירות Cloud Run.
  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • זה שינוי אופציונלי. ‫GRPC_SERVICE: אם הערך מוגדר, הוא משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-grpc.health.v1.Health.Check rpc.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות.
  • זה שינוי אופציונלי. ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-240 שניות. ערך ברירת המחדל הוא 0 שניות.
  • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין ב-periodSeconds. מציינים ערך בין 1 ל-240. ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין שנייה אחת ל-240 שניות. ערך ברירת המחדל הוא 10 שניות.

YAML

הפעלה של TCP

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, מורידים את הגדרות ה-YAML שלו: 
    gcloud run services describe SERVICE --format export > service.yaml

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

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: SERVICE
spec:
 template:
   metadata:
   spec:
     containers:
     - image: IMAGE_URL
       startupProbe:
         tcpSocket:
           port: CONTAINER_PORT
         initialDelaySeconds: DELAY
         timeoutSeconds: TIMEOUT
         failureThreshold: THRESHOLD
         periodSeconds: PERIOD

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE: השם של שירות Cloud Run.
    • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא מהצורה LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות.
    • ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר התחיל לפעול לפני שמבצעים את הבקשה לבדיקת תקינות (probe) הראשונה. מציינים ערך בין 0 שניות ל-240 שניות. ערך ברירת המחדל הוא 0 שניות.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שהבדיקה תגיע לזמן קצוב לתפוגה. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-240. ערך ברירת המחדל הוא 1.
    • ‫THRESHOLD: מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
    • ‫PERIOD: תקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין שנייה אחת ל-240 שניות. ערך ברירת המחדל הוא 10 שניות.
  3. יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה: 
    gcloud run services replace service.yaml

הפעלה של HTTP

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

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, מורידים את הגדרות ה-YAML שלו: 
    gcloud run services describe SERVICE --format export > service.yaml

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

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
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

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE: השם של שירות Cloud Run.
    • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • ‫PATH: נתיב יחסי לנקודת הקצה ב-HTTP, לדוגמה, /health.
    • זה שינוי אופציונלי. ‫CONTAINER_PORT: מוגדר ליציאת הקונטיינר שמשמשת את השירות.
    • זה שינוי אופציונלי. ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-240 שניות. ערך ברירת המחדל הוא 0 שניות.
    • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
    • אופציונלי: אפשר להשתמש ב-httpHeaders כדי לספק כותרות מותאמות אישית מרובות או חוזרות באמצעות השדות HEADER_NAME ו-HEADER_VALUE כמו שמוצג.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין ב-periodSeconds. מציינים ערך בין 1 ל-240. ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין שנייה אחת ל-240 שניות. ערך ברירת המחדל הוא 10 שניות.
  3. יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה: 
    gcloud run services replace service.yaml

הפעלת gRPC

מוודאים שקובץ אימג' של קונטיינר מטמיע את פרוטוקול בדיקת התקינות של gRPC.

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, אתם צריכים להוריד את הגדרות ה-YAML שלו: 
    gcloud run services describe SERVICE --format export > service.yaml

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

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
    spec:
      containers:
      - image: IMAGE_URL
        startupProbe:
          grpc:
            service: GRPC_SERVICE
            port: CONTAINER_PORT
          initialDelaySeconds: DELAY
          timeoutSeconds: TIMEOUT
          failureThreshold: THRESHOLD
          periodSeconds: PERIOD

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE: השם של שירות Cloud Run.
    • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • זה שינוי אופציונלי. ‫GRPC_SERVICE: אם הערך מוגדר, הוא משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-grpc.health.v1.Health.Check rpc.
    • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות.
    • זה שינוי אופציונלי. ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-240 שניות. ערך ברירת המחדל הוא 0 שניות.
    • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין ב-periodSeconds. מציינים ערך בין 1 ל-240. ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין שנייה אחת ל-240 שניות. ערך ברירת המחדל הוא 10 שניות.
  3. יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה: 
    gcloud run services replace service.yaml

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

הפעלה של TCP

מגדירים את שירות Cloud Run עם מאפיין startup_probe כמו שמוצג:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        tcp_socket {
          port = 8080
        }
      }
    }
  }
}

הפעלה של HTTP

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

מגדירים את שירות Cloud Run עם מאפיין startup_probe כמו שמוצג:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        http_get {
          path = "/"
          # Custom headers to set in the request
          # https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service#http_headers
          http_headers {
            name  = "Access-Control-Allow-Origin"
            value = "*"
          }
        }
      }
    }
  }
}

הפעלת gRPC

מוודאים שקובץ אימג' של קונטיינר מטמיע את פרוטוקול בדיקת התקינות של gRPC.

מגדירים את שירות Cloud Run עם מאפיין startup_probe כמו שמוצג:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      # Note: Change to the name of your image
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        grpc {
          # Note: Change to the name of your pre-existing grpc health status service
          service = "grpc.health.v1.Health"
        }
      }
    }
  }
}

בדיקת התקינות של ה-TCP שמוגדרת כברירת מחדל

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

startupProbe:
          timeoutSeconds: 240
          periodSeconds: 240
          failureThreshold: 1

אפשר לשנות את ערכי ברירת המחדל האלה לפי ההוראות שבקטע הגדרת בקשה לבדיקת תקינות (probe) בדף הזה.

דרישות ופעולות של בדיקת מוכנות להפעלה

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

אם בדיקת ההפעלה לא מצליחה בתוך הזמן שצוין (failureThreshold * periodSeconds), שלא יכול לעלות על 240 שניות, הקונטיינר מושבת. אפשר לעיין גם במאמר בנושא ברירות מחדל של TCP.
הפעלה של HTTP יצירת נקודת קצה (endpoint) לבדיקת תקינות ב-HTTP
שימוש ב-HTTP/1		 אחרי שמגדירים את בדיקת המוכנות, Cloud Run שולח בקשת HTTP GET לנקודת הקצה של בדיקת תקינות (לדוגמה, /health). כל תגובה מסוג 2XX או 3XX נחשבת להצלחה, וכל תגובה אחרת מצביעה על כשל.

אם בדיקת המוכנות להפעלה לא מצליחה בתוך הזמן שצוין (failureThreshold * periodSeconds), שלא יכול לעלות על 240 שניות, מאגר התמונות מושבת.

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

הגדרת בדיקות תקינות (liveness probes)

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

אפשר להגדיר בדיקות HTTP ו-gRPC באמצעות Google Cloud מסוף, YAML או Terraform:

המסוף

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

    כניסה ל-Cloud Run

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

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

  4. בתפריט Select health check type (בחירת סוג בדיקת תקינות), בוחרים באפשרות Liveness check (בדיקת פעילות).

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

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

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

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

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

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

    • אם אתם משתמשים בבדיקות gRPC:

    • ביציאה, מציינים את יציאת הקונטיינר שמשמשת את השירות.

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

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

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

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

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

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

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

gcloud

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

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

מריצים את הפקודה הבאה:

  gcloud run deploy SERVICE \
      --image=IMAGE_URL \
      --liveness-probe httpGet.path=PATH,httpGet.port=CONTAINER_PORT,initialDelaySeconds=DELAY,failureThreshold=THRESHOLD,timeoutSeconds=TIMEOUT,periodSeconds=PERIOD

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE: השם של שירות Cloud Run.
  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • ‫PATH: נתיב יחסי לנקודת הקצה ב-HTTP, לדוגמה, /health.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: מוגדר ליציאת הקונטיינר שמשמשת את השירות.
  • זה שינוי אופציונלי. ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-240 שניות. ערך ברירת המחדל הוא 0 שניות.
  • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-3,600.ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין שנייה אחת ל-3,600 שניות. ערך ברירת המחדל הוא 10 שניות.

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

מוודאים שקובץ אימג' של קונטיינר מטמיע את פרוטוקול בדיקת התקינות של gRPC.

מריצים את הפקודה הבאה:

  gcloud run deploy SERVICE \
      --image=IMAGE_URL \
      --liveness-probe grpc.port=CONTAINER_PORT,grpc.service=GRPC_SERVICE,initialDelaySeconds=DELAY,failureThreshold=THRESHOLD,timeoutSeconds=TIMEOUT,periodSeconds=PERIOD

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE: השם של שירות Cloud Run.
  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • זה שינוי אופציונלי. ‫GRPC_SERVICE: אם הערך מוגדר, הוא משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-grpc.health.v1.Health.Check rpc.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות.
  • זה שינוי אופציונלי. ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-240 שניות. ערך ברירת המחדל הוא 0 שניות.
  • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-3,600.ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין שנייה אחת ל-3,600 שניות. ערך ברירת המחדל הוא 10 שניות.

YAML

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

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

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, מורידים את הגדרות ה-YAML שלו: 
    gcloud run services describe SERVICE --format export > service.yaml

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

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
    spec:
      containers:
      - image: IMAGE_URL
        livenessProbe:
          httpGet:
            path: PATH
            port: CONTAINER_PORT
            httpHeaders:
              - name: HEADER_NAME
                value: HEADER_VALUE
          initialDelaySeconds: DELAY
          timeoutSeconds: TIMEOUT
          failureThreshold: THRESHOLD
          periodSeconds: PERIOD

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE: השם של שירות Cloud Run.
    • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • ‫PATH: נתיב יחסי לנקודת הקצה ב-HTTP, לדוגמה, /health.
    • זה שינוי אופציונלי. ‫CONTAINER_PORT: מוגדר ליציאת הקונטיינר שמשמשת את השירות.
    • זה שינוי אופציונלי. ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-240 שניות. ערך ברירת המחדל הוא 0 שניות.
    • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
    • אופציונלי: אפשר להשתמש ב-httpHeaders כדי לספק כותרות מותאמות אישית מרובות או חוזרות באמצעות השדות HEADER_NAME ו-HEADER_VALUE כמו שמוצג.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-3,600.ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין שנייה אחת ל-3,600 שניות. ערך ברירת המחדל הוא 10 שניות.
  3. יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה: 
    gcloud run services replace service.yaml

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

מוודאים שקובץ אימג' של קונטיינר מטמיע את פרוטוקול בדיקת התקינות של gRPC.

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, מורידים את הגדרות ה-YAML שלו: 
    gcloud run services describe SERVICE --format export > service.yaml

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

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
    spec:
      containers:
      - image: IMAGE_URL
        livenessProbe:
          grpc:
            port: CONTAINER_PORT
            service: GRPC_SERVICE
          initialDelaySeconds: DELAY
          timeoutSeconds: TIMEOUT
          failureThreshold: THRESHOLD
          periodSeconds: PERIOD

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE: השם של שירות Cloud Run.
    • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • זה שינוי אופציונלי. ‫GRPC_SERVICE: אם הערך מוגדר, הוא משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-grpc.health.v1.Health.Check rpc.
    • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות.
    • זה שינוי אופציונלי. ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-240 שניות. ערך ברירת המחדל הוא 0 שניות.
    • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים לניסיון חוזר של הבדיקה לפני כיבוי הקונטיינר. ערך ברירת המחדל הוא 3.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-3,600.ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין שנייה אחת ל-3,600 שניות. ערך ברירת המחדל הוא 10 שניות.

  3. יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה: 
    gcloud run services replace service.yaml

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

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

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

מגדירים את שירות Cloud Run עם מאפיין liveness_probe כמו שמוצג:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      liveness_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        http_get {
          path = "/"
          # Custom headers to set in the request
          # https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service#http_headers
          http_headers {
            name  = "Access-Control-Allow-Origin"
            value = "*"
          }
        }
      }
    }
  }
}

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

מוודאים שקובץ אימג' של קונטיינר מטמיע את פרוטוקול בדיקת התקינות של gRPC.

מגדירים את שירות Cloud Run עם מאפיין liveness_probe כמו שמוצג:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      # Note: Change to the name of your image
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      liveness_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        # Note: Change to the name of your pre-existing grpc health status service
        grpc {
          service = "grpc.health.v1.Health"
        }
      }
    }
  }
}

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

סוג הבדיקה דרישות התנהגות
בדיקת פעילות של HTTP יצירת נקודת קצה (endpoint) לבדיקת תקינות ב-HTTP
שימוש ב-HTTP/1		 בדיקת החיות מתחילה רק אחרי שבדיקת ההפעלה מסתיימת בהצלחה. אחרי הגדרת הבדיקה, ואחרי שכל בדיקת הפעלה מסתיימת בהצלחה, Cloud Run שולח בקשת HTTP GET לנקודת הקצה של בדיקת תקינות (לדוגמה, /health). כל תגובה מסוג 2XX או 3XX מציינת הצלחה, וכל תגובה אחרת מציינת כשל.

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

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

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

הגדרת בדיקות מוכנות

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

המגבלות הבאות חלות על בדיקות מוכנות:

  • אם מפעילים את התכונה 'זיקה לסשן (session affinity)', Cloud Run ממשיך לשלוח בקשות לאותה מכונה, גם אם בדיקת המוכנות (readiness) שלה נכשלת.

  • אם הגדרתם בעבר בדיקת מוכנות לשירות Cloud Run באמצעות Cloud Run Admin API v1 לפני נובמבר 2025, בדיקות המוכנות לא ייכנסו לתוקף גם אחרי שתפרסו הגדרה חדשה לשירות הזה. הסיבה לכך היא שהשירות שומר הגדרה ישנה יותר. השירותים שתיצרו אחרי נובמבר 2025, או אלה שלא נעשה בהם שימוש בבדיקת מוכנות, לא יושפעו. כדי להפעיל בדיקות מוכנות נתמכות בשירותים המושפעים:

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

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

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

אפשר להגדיר בדיקת מוכנות באמצעות מסוף Google Cloud , Google Cloud CLI או YAML:

המסוף

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

    כניסה ל-Cloud Run

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

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

  4. בתפריט Select health check type (בחירת סוג בדיקת תקינות), בוחרים באפשרות Readiness check (בדיקת מוכנות).

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

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

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

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

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

    • אם אתם משתמשים בבדיקות gRPC:

    • בשדה Port (יציאה), מציינים את יציאת המאגר של השירות. יציאת ברירת המחדל היא יציאת הכניסה הראשית.

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

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

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

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

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

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

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

gcloud

מוכנות ל-HTTP

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

מריצים את הפקודה הבאה:

gcloud run deploy SERVICE \
    --image=IMAGE_URL \
    --readiness-probe httpGet.path=PATH,httpGet.port=CONTAINER_PORT,successThreshold=SUCCESS_THRESHOLD,failureThreshold=FAILURE_THRESHOLD,timeoutSeconds=TIMEOUT,periodSeconds=PERIOD

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE: השם של שירות Cloud Run.
  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • זה שינוי אופציונלי. ‫PATH: הנתיב היחסי לנקודת הקצה ב-HTTP, לדוגמה, /are_you_ready. נתיב ברירת המחדל הוא /.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות. יציאת ברירת המחדל היא יציאת הכניסה הראשית.
  • זה שינוי אופציונלי. ‫SUCCESS_THRESHOLD: מספר ההצלחות המינימלי ברצף שנדרש כדי שהבדיקה תיחשב מוצלחת אחרי כשל. ערך ברירת המחדל הוא 2.
  • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שהבקשה לבדיקת תקינות (probe) תנסה להתבצע לפני שהמערכת תדווח על כשל, מה שיגרום להפסקת קבלת תעבורת נתונים במכונה. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 10 שניות.

מוכנות ל-gRPC

מוודאים שקובץ אימג' של קונטיינר מטמיע את פרוטוקול בדיקת התקינות של gRPC.

מריצים את הפקודה הבאה:

gcloud run deploy SERVICE \
    --image=IMAGE_URL \
    --readiness-probe grpc.port=CONTAINER_PORT,grpc.service=GRPC_SERVICE,successThreshold=SUCCESS_THRESHOLD,failureThreshold=FAILURE_THRESHOLD,timeoutSeconds=TIMEOUT,periodSeconds=PERIOD

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE: השם של שירות Cloud Run.
  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות. יציאת ברירת המחדל היא יציאת הכניסה הראשית.
  • זה שינוי אופציונלי. ‫GRPC_SERVICE: אם הערך מוגדר, הוא משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-grpc.health.v1.Health.Check rpc.
  • זה שינוי אופציונלי. ‫SUCCESS_THRESHOLD: מספר ההצלחות המינימלי ברצף שנדרש כדי שהבקשה לבדיקת תקינות (probe) תיחשב מוצלחת אחרי שהיא נכשלה. ערך ברירת המחדל הוא 2.
  • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שהבקשה לבדיקת תקינות (probe) תנסה להתבצע לפני שהמערכת תדווח על כשל, מה שיגרום להפסקת קבלת תעבורת נתונים במכונה. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 10 שניות.

YAML

מוכנות ל-HTTP

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

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, מורידים את הגדרות ה-YAML שלו: 
    gcloud run services describe SERVICE --format export > service.yaml

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

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
    spec:
      containers:
      - image: IMAGE_URL
        readinessProbe:
          httpGet:
            path: PATH
            port: CONTAINER_PORT
          successThreshold: SUCCESS_THRESHOLD
          failureThreshold: FAILURE_THRESHOLD
          timeoutSeconds: TIMEOUT
          periodSeconds: PERIOD

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE: השם של שירות Cloud Run.
    • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • זה שינוי אופציונלי. ‫PATH: הנתיב היחסי לנקודת הקצה ב-HTTP, לדוגמה, /are_you_ready. נתיב ברירת המחדל הוא /.
    • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות. יציאת ברירת המחדל היא יציאת הכניסה הראשית.
    • זה שינוי אופציונלי. ‫SUCCESS_THRESHOLD: מספר ההצלחות המינימלי ברצף שנדרש כדי שהבדיקה תיחשב מוצלחת אחרי כשל. ערך ברירת המחדל הוא 2.
    • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שהבקשה לבדיקת תקינות (probe) תנסה להתבצע לפני שהמערכת תדווח על כשל, מה שיגרום להפסקת קבלת תעבורת נתונים במכונה. ערך ברירת המחדל הוא 3.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 10 שניות.
  3. יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה: 
    gcloud run services replace service.yaml

מוכנות ל-gRPC

מוודאים שקובץ אימג' של קונטיינר מטמיע את פרוטוקול בדיקת התקינות של gRPC.

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, מורידים את הגדרות ה-YAML שלו: 
    gcloud run services describe SERVICE --format export > service.yaml

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

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
  annotations:
    run.googleapis.com/launch-stage: BETA
spec:
  template:
    metadata:
    spec:
      containers:
      - image: IMAGE_URL
        readinessProbe:
          grpc:
            port: CONTAINER_PORT
            service: GRPC_SERVICE
          successThreshold: SUCCESS_THRESHOLD
          failureThreshold: FAILURE_THRESHOLD
          timeoutSeconds: TIMEOUT
          periodSeconds: PERIOD

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE: השם של שירות Cloud Run.
    • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות. יציאת ברירת המחדל היא יציאת הכניסה הראשית.
    • זה שינוי אופציונלי. ‫GRPC_SERVICE: אם הערך מוגדר, הוא משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-grpc.health.v1.Health.Check rpc.
    • זה שינוי אופציונלי. ‫SUCCESS_THRESHOLD: מספר ההצלחות המינימלי ברצף שנדרש כדי שהבקשה לבדיקת תקינות (probe) תיחשב מוצלחת אחרי שהיא נכשלה. ערך ברירת המחדל הוא 2.
    • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שהבקשה לבדיקת תקינות (probe) תנסה להתבצע לפני שהמערכת תדווח על כשל, מה שיגרום להפסקת קבלת תעבורת נתונים במכונה. ערך ברירת המחדל הוא 3.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 10 שניות.
  3. יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה: 
    gcloud run services replace service.yaml

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

מוכנות ל-HTTP

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

מגדירים את שירות Cloud Run עם המאפיין readiness_probe כמו שמוצג:

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "IMAGE_URL"

      readiness_probe {
        timeout_seconds   = TIMEOUT
        period_seconds    = PERIOD
        success_threshold = SUCCESS_THRESHOLD
        failure_threshold = FAILURE_THRESHOLD

        http_get {
          path = "PATH"
          port = CONTAINER_PORT
        }
      }
    }
  }
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫REGION: האזור Google Cloud . לדוגמה: us-central1.
  • ‫SERVICE: השם של שירות Cloud Run.
  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • זה שינוי אופציונלי. ‫PATH: הנתיב היחסי לנקודת הקצה ב-HTTP, לדוגמה, /are_you_ready. נתיב ברירת המחדל הוא /.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות. יציאת ברירת המחדל היא יציאת הכניסה הראשית.
  • זה שינוי אופציונלי. ‫SUCCESS_THRESHOLD: מספר ההצלחות המינימלי ברצף שנדרש כדי שהבדיקה תיחשב מוצלחת אחרי כשל. ערך ברירת המחדל הוא 2.
  • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שהבקשה לבדיקת תקינות (probe) תנסה להתבצע לפני שהמערכת תדווח על כשל, מה שיגרום להפסקת קבלת תעבורת נתונים במכונה. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 10 שניות.

מוכנות ל-gRPC

מוודאים שקובץ אימג' של קונטיינר מטמיע את פרוטוקול בדיקת התקינות של gRPC.

מגדירים את שירות Cloud Run עם המאפיין readiness_probe כמו שמוצג:

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  deletion_protection = "true"

  template {
    containers {
      image = "IMAGE_URL"

      readiness_probe {
        timeout_seconds   = TIMEOUT
        period_seconds    = PERIOD
        success_threshold = SUCCESS_THRESHOLD
        failure_threshold = FAILURE_THRESHOLD

        grpc {
          service = "GRPC_SERVICE"
          port = CONTAINER_PORT
        }
      }
    }
  }
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫REGION: האזור Google Cloud . לדוגמה: us-central1.
  • ‫SERVICE: השם של שירות Cloud Run.
  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות. יציאת ברירת המחדל היא יציאת הכניסה הראשית.
  • זה שינוי אופציונלי. ‫GRPC_SERVICE: אם הערך מוגדר, הוא משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-grpc.health.v1.Health.Check rpc.
  • זה שינוי אופציונלי. ‫SUCCESS_THRESHOLD: מספר ההצלחות המינימלי ברצף שנדרש כדי שהבקשה לבדיקת תקינות (probe) תיחשב מוצלחת אחרי שהיא נכשלה. ערך ברירת המחדל הוא 2.
  • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שהבקשה לבדיקת תקינות (probe) תנסה להתבצע לפני שהמערכת תדווח על כשל, מה שיגרום להפסקת קבלת תעבורת נתונים במכונה. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 10 שניות.

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

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

המאמרים הבאים