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

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

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

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

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

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

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

    • הפעלה מחדש של קונטיינר במקרה כזה יכולה לשפר את זמינות השירות במקרה של באגים.
    • בדיקות פעילות נועדו להפעיל מחדש מופעים בודדים שלא ניתן לשחזר בדרך אחרת. השימוש בהם מיועד בעיקר למקרים של כשלים שלא ניתן לשחזר במכונה, כמו מצב של חסימה הדדית (deadlock) שבו שירות פועל אבל לא יכול להתקדם. אתם יכולים לדרוש בדיקת פעילות לכל מאגר באמצעות מדיניות ארגונית בהתאמה אישית.
    • כששירות חווה כשלים חוזרים בבדיקות, 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. בתפריט הניווט של Cloud Run, לוחצים על Services (שירותים).

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

  4. אם אתם מגדירים שירות קיים, לוחצים על השירות ואז על הכרטיסייה Containers (מאגרי תגים).

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

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

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

    • אם אתם משתמשים בבדיקות תקינות של אתרים מסוג 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, מציינים את מספר השניות להמתנה עד שזמן האחזור של הבדיקה יפוג. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-240. ערך ברירת המחדל הוא 1.

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

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

כדי למחוק בקשה לבדיקת תקינות (probe), לוחצים על סמל המחיקה של בדיקת תקינות שרוצים למחוק, ואז לוחצים על אישור. כדי לפרוס גרסה חדשה של שירות Cloud Run, לוחצים על View diff & redeploy (הצגת ההבדלים ופריסה מחדש) ואז על Deploy changes (פריסת שינויים).

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: אם הערך מוגדר, הוא משמש בשדה 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

  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 שניות.

הפעלה של HTTP

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

  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 שניות.

הפעלת gRPC

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

  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: אם הערך מוגדר, הוא משמש בשדה 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 שניות.

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. בתפריט הניווט של Cloud Run, לוחצים על Services (שירותים).

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

  4. אם אתם מגדירים שירות קיים, לוחצים על השירות ואז על הכרטיסייה Containers (מאגרי תגים).

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

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

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

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

    • אם אתם משתמשים בבדיקות תקינות של אתרים מסוג 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, מציינים את מספר השניות להמתנה עד שזמן האחזור של הבדיקה יפוג. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-3,600. ערך ברירת המחדל הוא 1.

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

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

כדי למחוק בקשה לבדיקת תקינות (probe), לוחצים על סמל המחיקה של בדיקת תקינות שרוצים למחוק, ואז לוחצים על אישור. כדי לפרוס גרסה חדשה של שירות Cloud Run, לוחצים על View diff & redeploy (הצגת ההבדלים ופריסה מחדש) ואז על Deploy changes (פריסת שינויים).

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: אם הערך מוגדר, הוא משמש בשדה 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 שחשופות חיצונית.

  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 שניות.

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

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

  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: אם הערך מוגדר, הוא משמש בשדה 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 שניות.

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		 בדיקת הפעילות מתחילה רק אחרי שבדיקת ההפעלה מסתיימת בהצלחה. אחרי הגדרת הבקשה לבדיקת תקינות (probe), ואחרי שכל בקשה לבדיקת תקינות (probe) של אתחול מסתיימת בהצלחה, Cloud Run שולח בקשת GET לנקודת הקצה של בדיקת תקינות (לדוגמה, /health). כל תגובה מסוג 2XX או 3XX נחשבת להצלחה, וכל תגובה אחרת מצביעה על כשל.

אם בקשה לבדיקת תקינות (probe) של מצב פעילות (liveness) לא מסתיימת בהצלחה בתוך הזמן שצוין (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. בתפריט הניווט של Cloud Run, לוחצים על Services (שירותים).

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

  4. אם אתם מגדירים שירות קיים, לוחצים על השירות ואז על הכרטיסייה Containers (מאגרי תגים).

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

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

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

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

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

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

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

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

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

כדי למחוק בקשה לבדיקת תקינות (probe), לוחצים על סמל המחיקה של בדיקת תקינות שרוצים למחוק, ואז לוחצים על אישור. כדי לפרוס גרסה חדשה של שירות Cloud Run, לוחצים על View diff & redeploy (הצגת ההבדלים ופריסה מחדש) ואז על Deploy changes (פריסת שינויים).

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: מספר ההצלחות המינימלי ברצף שנדרש כדי שהבקשה לבדיקת תקינות (probe) תיחשב מוצלחת אחרי שהיא נכשלה. ערך ברירת המחדל הוא 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: אם הערך מוגדר, הוא משמש בשדה 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 שחשופות חיצונית.

  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: מספר ההצלחות המינימלי ברצף שנדרש כדי שהבקשה לבדיקת תקינות (probe) תיחשב מוצלחת אחרי שהיא נכשלה. ערך ברירת המחדל הוא 2.
    • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שהמערכת תנסה לבצע את הבקשה לבדיקת תקינות (probe) לפני שתדווח על כשל, מה שיגרום להפסקת קבלת תעבורת נתונים במכונה. ערך ברירת המחדל הוא 3.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות להמתנה עד שזמן הקצוב לתפוגה של הבדיקה יגיע. הערך הזה לא יכול להיות גבוה מהערך שצוין עבור periodSeconds. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: התקופה (בשניות) שבה תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבקשה לבדיקת תקינות (probe) כל 2 שניות. מציינים ערך בין 1 ל-300. ערך ברירת המחדל הוא 10 שניות.

מוכנות ל-gRPC

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

  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: אם הערך מוגדר, הוא משמש בשדה 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 שניות.

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: מספר ההצלחות המינימלי ברצף שנדרש כדי שהבקשה לבדיקת תקינות (probe) תיחשב מוצלחת אחרי שהיא נכשלה. ערך ברירת המחדל הוא 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: אם הערך מוגדר, הוא משמש בשדה 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 ושימוש בזיכרון, אבל אין חיוב לפי בקשה.

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