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

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

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

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

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

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

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

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

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

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

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

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

הגדרת בדיקות סטארט-אפ

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

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

המסוף

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

    כניסה ל-Cloud Run

  2. בתפריט הניווט של Cloud Run, לוחצים על Services:

    1. אם אתם מגדירים שירות חדש, לוחצים על Deploy container וממלאים את דף הגדרות השירות הראשוני. לאחר מכן לוחצים על Containers, Networking, Security כדי להרחיב את דף הגדרת השירות.

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

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

  4. בתפריט Select health check type, בוחרים באפשרות Startup check.

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

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

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

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

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

    • בשדה Initial delay, מציינים את מספר השניות שצריך להמתין אחרי שהקונטיינר התחיל, לפני שמבצעים את הבדיקה הראשונה. צריך לציין ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.

    • בשדה Period, מציינים את משך הזמן (בשניות) שבו תתבצע הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין שנייה אחת ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 10 שניות.

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

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

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

  7. כדי ליצור שירות חדש, לוחצים על יצירה. לוחצים על View diff & redeploy ואז על Deploy changes בשירות קיים.

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

הפעלת HTTP

מוסיפים נקודת קצה מסוג HTTP/1 (ברירת המחדל של Cloud Run, לא HTTP/2) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי 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 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
  • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני סגירת הקונטיינר. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גדול מהערך שצוין ב-periodSeconds. צריך לציין ערך בין 1 ל-600 (1,800 ל-GPU). ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין שנייה אחת ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 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 כשמתבצעת קריאה ל-RPC של grpc.health.v1.Health.Check.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת הקונטיינר שמשמשת לשירות.
  • זה שינוי אופציונלי. DELAY: מספר השניות שצריך להמתין אחרי שהקונטיינר התחיל, לפני ביצוע הבדיקה הראשונה. צריך לציין ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
  • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני סגירת הקונטיינר. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גדול מהערך שצוין ב-periodSeconds. צריך לציין ערך בין 1 ל-600 (1,800 ל-GPU). ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין שנייה אחת ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 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: מספר השניות שצריך להמתין אחרי שהקונטיינר התחיל, לפני ביצוע הבדיקה הראשונה. צריך לציין ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך בין 1 ל-600 (1,800 ל-GPU). ערך ברירת המחדל הוא 1.
    • ‫THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני סגירת הקונטיינר. ערך ברירת המחדל הוא 3.
    • ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין שנייה אחת ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 10 שניות.

הפעלת HTTP

מוסיפים נקודת קצה מסוג HTTP/1 (ברירת המחדל של Cloud Run, לא HTTP/2) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי 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 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
    • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני סגירת הקונטיינר. ערך ברירת המחדל הוא 3.
    • אופציונלי: אפשר להשתמש ב-httpHeaders כדי לספק כמה כותרות בהתאמה אישית או כותרות חוזרות באמצעות השדות HEADER_NAME ו-HEADER_VALUE, כמו שמוצג.
    • זה שינוי אופציונלי. TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גדול מהערך שצוין ב-periodSeconds. צריך לציין ערך בין 1 ל-600 (1,800 ל-GPU). ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין שנייה אחת ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 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: אם מוגדר, משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-RPC של grpc.health.v1.Health.Check.
    • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת הקונטיינר שמשמשת לשירות.
    • זה שינוי אופציונלי. DELAY: מספר השניות שצריך להמתין אחרי שהקונטיינר התחיל, לפני ביצוע הבדיקה הראשונה. צריך לציין ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
    • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני סגירת הקונטיינר. ערך ברירת המחדל הוא 3.
    • זה שינוי אופציונלי. TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גדול מהערך שצוין ב-periodSeconds. צריך לציין ערך בין 1 ל-600 (1,800 ל-GPU). ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין שנייה אחת ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 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) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי 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, המערכת מגדירה באופן אוטומטי בדיקת TCP להפעלה עם ערכי ברירת המחדל הבאים:

startupProbe:
          timeoutSeconds: 240
          periodSeconds: 240
          failureThreshold: 1

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

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

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

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

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

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

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

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

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

המסוף

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

    כניסה ל-Cloud Run

  2. בתפריט הניווט של Cloud Run, לוחצים על Services:

    1. אם אתם מגדירים שירות חדש, לוחצים על Deploy container וממלאים את דף הגדרות השירות הראשוני. לאחר מכן לוחצים על Containers, Networking, Security כדי להרחיב את דף הגדרת השירות.

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

  3. בקטע 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) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי HTTP שחשופות מבחוץ.
      • בשדה Path מציינים את הנתיב היחסי לנקודת הקצה, לדוגמה /.
      • מסמנים את התיבה כותרות HTTP כדי לציין כותרות אופציונליות בהתאמה אישית. מציינים את שם הכותרת בשדה Name ואת ערך הכותרת בשדה Value. לוחצים על הוספת כותרת HTTP כדי לציין כותרות נוספות.

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

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

    • בשדה Initial delay, מציינים את מספר השניות שצריך להמתין אחרי שהקונטיינר התחיל, לפני שמבצעים את הבדיקה הראשונה. צריך לציין ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.

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

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

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

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

  8. כדי ליצור שירות חדש, לוחצים על יצירה. לוחצים על View diff & redeploy ואז על Deploy changes בשירות קיים.

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

gcloud

בדיקת תקינות של HTTP

מוסיפים נקודת קצה מסוג HTTP/1 (ברירת המחדל של Cloud Run, לא HTTP/2) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי 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 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
  • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני סגירת הקונטיינר. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך מ-1 עד 3,600.ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין שנייה אחת ל-3,600 שניות. ערך ברירת המחדל הוא 10 שניות.

בדיקת החיוּת של 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 כשמתבצעת קריאה ל-RPC של grpc.health.v1.Health.Check.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת הקונטיינר שמשמשת לשירות.
  • זה שינוי אופציונלי. DELAY: מספר השניות שצריך להמתין אחרי שהקונטיינר התחיל, לפני ביצוע הבדיקה הראשונה. צריך לציין ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
  • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני סגירת הקונטיינר. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך מ-1 עד 3,600.ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין שנייה אחת ל-3,600 שניות. ערך ברירת המחדל הוא 10 שניות.

YAML

בדיקת חיות HTTP

מוסיפים נקודת קצה מסוג HTTP/1 (ברירת המחדל של Cloud Run, לא HTTP/2) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי 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 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
    • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני סגירת הקונטיינר. ערך ברירת המחדל הוא 3.
    • אופציונלי: אפשר להשתמש ב-httpHeaders כדי לספק כמה כותרות בהתאמה אישית או כותרות חוזרות באמצעות השדות HEADER_NAME ו-HEADER_VALUE, כמו שמוצג.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך מ-1 עד 3,600.ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 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: אם מוגדר, משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-RPC של grpc.health.v1.Health.Check.
    • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת הקונטיינר שמשמשת לשירות.
    • זה שינוי אופציונלי. DELAY: מספר השניות שצריך להמתין אחרי שהקונטיינר התחיל, לפני ביצוע הבדיקה הראשונה. צריך לציין ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 0 שניות.
    • זה שינוי אופציונלי. ‫THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני סגירת הקונטיינר. ערך ברירת המחדל הוא 3.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך מ-1 עד 3,600.ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין שנייה אחת ל-3,600 שניות. ערך ברירת המחדל הוא 10 שניות.

Terraform

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

בדיקת חיות ב-HTTP

מוסיפים נקודת קצה מסוג HTTP/1 (ברירת המחדל של Cloud Run, לא HTTP/2) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי 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 = "*"
          }
        }
      }
    }
  }
}

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

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

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

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

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

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

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

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

    1. אם אתם מגדירים שירות חדש, לוחצים על Deploy container וממלאים את דף הגדרות השירות הראשוני. לאחר מכן לוחצים על Containers, Networking, Security כדי להרחיב את דף הגדרת השירות.

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

  3. בקטע 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) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי HTTP שחשופות מבחוץ.

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

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

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

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

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

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

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

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

  8. כדי ליצור שירות חדש, לוחצים על יצירה. לוחצים על View diff & redeploy ואז על Deploy changes בשירות קיים.

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

gcloud

מוכנות ל-HTTP

מוסיפים נקודת קצה מסוג HTTP/1 (ברירת המחדל של Cloud Run, לא HTTP/2) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי 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: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני שמדווחים על כשל, שגורם למכונה להפסיק לקבל תנועה. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 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 כשמתבצעת קריאה ל-RPC של grpc.health.v1.Health.Check.
  • זה שינוי אופציונלי. ‫SUCCESS_THRESHOLD: מספר ההצלחות המינימלי ברצף כדי שהבדיקה תיחשב כמוצלחת אחרי כישלון. ערך ברירת המחדל הוא 2.
  • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני שמדווחים על כשל, שגורם למכונה להפסיק לקבל תנועה. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין 1 ל-300. ערך ברירת המחדל הוא 10 שניות.

YAML

מוכנות ל-HTTP

מוסיפים נקודת קצה מסוג HTTP/1 (ברירת המחדל של Cloud Run, לא HTTP/2) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי 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: מספר ההצלחות המינימלי ברצף כדי שהבדיקה תיחשב כמוצלחת אחרי כישלון. ערך ברירת המחדל הוא 2.
    • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני שמדווחים על כשל, שגורם למכונה להפסיק לקבל תנועה. ערך ברירת המחדל הוא 3.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 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: אם מוגדר, משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-RPC של grpc.health.v1.Health.Check.
    • זה שינוי אופציונלי. ‫SUCCESS_THRESHOLD: מספר ההצלחות המינימלי ברצף כדי שהבדיקה תיחשב כמוצלחת אחרי כישלון. ערך ברירת המחדל הוא 2.
    • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני שמדווחים על כשל, שגורם למכונה להפסיק לקבל תנועה. ערך ברירת המחדל הוא 3.
    • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
    • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין 1 ל-300. ערך ברירת המחדל הוא 10 שניות.

Terraform

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

מוכנות ל-HTTP

מוסיפים נקודת קצה מסוג HTTP/1 (ברירת המחדל של Cloud Run, לא HTTP/2) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup,‏ /health או /are_you_ready) חייב להיות זהה ל-path בהגדרת הבדיקה. נקודות הקצה של בדיקות התקינות של HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירותי 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: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני שמדווחים על כשל, שגורם למכונה להפסיק לקבל תנועה. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 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 כשמתבצעת קריאה ל-RPC של grpc.health.v1.Health.Check.
  • זה שינוי אופציונלי. ‫SUCCESS_THRESHOLD: מספר ההצלחות המינימלי ברצף כדי שהבדיקה תיחשב כמוצלחת אחרי כישלון. ערך ברירת המחדל הוא 2.
  • זה שינוי אופציונלי. ‫FAILURE_THRESHOLD: מספר הפעמים שבהן צריך לנסות שוב את הבדיקה לפני שמדווחים על כשל, שגורם למכונה להפסיק לקבל תנועה. ערך ברירת המחדל הוא 3.
  • זה שינוי אופציונלי. ‫TIMEOUT: מספר השניות שצריך להמתין עד שהזמן הקצוב לתפוגה של הבדיקה יסתיים. הערך הזה לא יכול להיות גבוה מהערך שצוין בשדה periodSeconds. צריך לציין ערך בין 1 ל-300. ערך ברירת המחדל הוא 1.
  • זה שינוי אופציונלי. ‫PERIOD: פרק הזמן (בשניות) שבו מתבצעת הבדיקה. לדוגמה, 2 כדי לבצע את הבדיקה כל 2 שניות. צריך לציין ערך בין 1 ל-300. ערך ברירת המחדל הוא 10 שניות.

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

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

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

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

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

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

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