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

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

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

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

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

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

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

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

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

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

הפעלה של HTTP

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

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

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

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

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

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

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

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

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

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

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

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

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

gRPC liveness

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

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

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

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

  • ‫SERVICE: השם של שירות Cloud Run.
  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, מאגר המידע REPO_NAME צריך להיות כבר קיים. כתובת ה-URL היא מהצורה LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • זה שינוי אופציונלי. ‫GRPC_SERVICE: אם הערך מוגדר, הוא משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-grpc.health.v1.Health.Check rpc.
  • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות.
  • זה שינוי אופציונלי. ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך מ-0 שניות עד 600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 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 בהגדרת הבדיקה. נקודות קצה (endpoints) של בדיקות תקינות ב-HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו נקודות קצה (endpoints) של כל שירות 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 כדי לבצע את הבקשה לבדיקת תקינות (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: אם הערך מוגדר, הוא משמש בשדה השירות של grpc.health.v1.HealthCheckRequest כשמתבצעת קריאה ל-grpc.health.v1.Health.Check rpc.
    • זה שינוי אופציונלי. ‫CONTAINER_PORT: יציאת המאגר שמשמשת את השירות.
    • זה שינוי אופציונלי. ‫DELAY: מספר השניות להמתנה אחרי שהקונטיינר מתחיל לפעול, לפני ביצוע הבדיקה הראשונה. מציינים ערך בין 0 שניות ל-600 שניות (1,800 ל-GPU). ערך ברירת המחדל הוא 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 בהגדרת הבדיקה. נקודות קצה (endpoints) של בדיקות תקינות ב-HTTP נגישות מבחוץ, והן פועלות לפי אותם עקרונות כמו נקודות קצה (endpoints) של כל שירות 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 ממשיך לשלוח בקשות לאותו מופע, גם אם בדיקת המוכנות שלו נכשלת.

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

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