הגדרת מספר מינימלי של מופעים לשירותים

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

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

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

‫Cloud Run מסיר מופעים שלא מעבדים בקשות (במצב סרק). אם מגדירים מספר מינימלי של מופעים, Cloud Run שומר על מספר המופעים המינימלי הזה, גם אם הם לא מעבדים בקשות. אם יש יותר מ-min-instances מופעים פעילים, יכול להיות שהם יעברו למצב בלי פעילות אם הם לא מקבלים בקשות.

לדוגמה, אם min-instances הוא 10, ומספר המופעים הפעילים הוא 0, אז מספר המופעים הלא פעילים הוא 10. כאשר מספר המופעים הפעילים עולה ל-6, מספר המופעים הלא פעילים יורד ל-4.

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

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

שיטות מומלצות לזמינות גבוהה

כדי לוודא שהשירות שלכם יישאר זמין מאוד, כדאי להגדיר לפחות 3 מופעים מינימליים.

מגבלות של מספר מכונות מינימלי

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

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

חיוב

הפעלת מכונות באמצעות התכונה 'מכונות מינימליות' כרוכה בעלויות חיוב.

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

הפעלת Cloud Run Admin API ממסוף Google Cloud .
איור 1. דוגמה למופע שמקבל ומעבד שלוש בקשות.

בהתאם להגדרות החיוב שנקבעו, החיוב על השירות מתבצע באופן הבא:

  • בחיוב לפי בקשה, אתם מחויבים בתעריף נמוך יותר כשהמופעים במצב המתנה ולא מעבדים בקשות. אם הערך של min instances (מספר המופעים המינימלי) מוגדר ל-0, לא נחייב אתכם כשהמופעים לא פעילים.
  • בחיוב לפי מופע, אתם מחויבים לפי התעריף שמוגדר כברירת מחדל למשך כל מחזור החיים של המופע. הזמן שחלף בין ההפעלה לבין ההשבתה כולל את הזמן שבו מופע מעבד בקשות או נמצא במצב המתנה. במילים אחרות, גם אם הערך של min instances מוגדר כ-0, עדיין תחויבו בתעריף ברירת המחדל. האפשרות הזו מתאימה אם אתם צריכים CPU מחוץ לבקשות. אם הערך של min instances מוגדר כ-0, החיוב הוא לפי שיעור ברירת המחדל.
מכיוון שאפשר לצפות את החיובים האלה, Google ממליצה לרכוש הנחה תמורת התחייבות לשימוש.

החלת מספר מופעים מינימלי ברמת השירות לעומת ברמת השינוי

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

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

שינויים ומכונות מינימליות

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

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

גרסאות מתויגות ומופעים מינימליים ברמת השירות

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

ניתוב בקשות עם מספר מופעים מינימלי

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

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות להגדרה ולפריסה של שירותי Cloud Run, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

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

רשימת ההרשאות והתפקידים ב-IAM שמשויכים ל-Cloud Run מופיעה במאמרים תפקידי IAM ב-Cloud Run והרשאות IAM ב-Cloud Run. אם שירות Cloud Run שלכם מתקשר עםGoogle Cloud ממשקי API, כמו ספריות לקוח ב-Cloud, כדאי לעיין במדריך להגדרת זהות שירות. מידע נוסף על מתן תפקידים זמין במאמרים הרשאות פריסה וניהול גישה.

הגדרת מספר מינימלי של מופעים ברמת השירות

כברירת מחדל, המינימום של המופעים ברמת השירות מושבת במופעי קונטיינר, וההגדרה היא 0. אפשר לשנות את ברירת המחדל הזו באמצעות מסוףGoogle Cloud , Google Cloud CLI או קובץ YAML:

המסוף

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

    כניסה ל-Cloud Run

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

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

  4. בקטע Service scaling (שינוי קנה מידה של שירות), מציינים את המספר המינימלי של מופעי מאגר התגים בשדה Minimum number of instances (מספר המופעים המינימלי).

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

gcloud

כדי לעדכן את המספר המינימלי של מופעים בשירות מסוים, משתמשים בפקודה הבאה:

gcloud run services update SERVICE --min MIN-VALUE

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

  • ‫SERVICE: השם של השירות.
  • ‫MIN-VALUE: מספר מופעי הקונטיינרים שצריך לשמור במצב מוכן לקבלת בקשות. מציינים default כדי לנקות את ההגדרה של ערך מינימלי של מופעים.

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

gcloud run deploy --image IMAGE_URL --min MIN-VALUE

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

  • ‫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 .
  • ‫MIN-VALUE: מספר המקרים של קונטיינרים שצריך לשמור במצב מוכן לקבלת בקשות. מציינים default כדי לנקות את הגדרת המינימום של המופע.

YAML

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

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

    gcloud run services describe SERVICE --format export > service.yaml

  2. מעדכנים את המאפיין run.googleapis.com/minScale:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
  annotations:
    run.googleapis.com/minScale: 'MIN_INSTANCE'

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

    • ‫SERVICE: השם של שירות Cloud Run
    • ‫MIN-INSTANCE: מספר המופעים שצריך לשמור במצב פעיל, מוכנים לקבל בקשות.

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

    gcloud run services replace service.yaml

    אם קיים קובץ service.yaml, הפקודה gcloud run services replace משתמשת בו כברירת מחדל.

ספריות לקוח

כדי לעדכן את מספר המינימום של מופעים ברמת השירות בשביל השירות שלכם מקוד:

‫API בארכיטקטורת REST

כדי לעדכן את מספר המינימום של מופעים ברמת השירות בשירות נתון, שולחים PATCHבקשת HTTP לנקודת הקצה service של Cloud Run Admin API.

לדוגמה, באמצעות curl:

curl -H "Content-Type: application/json" \
-H "Authorization: Bearer ACCESS_TOKEN" \
-X PATCH \
-d '{ "scaling": { "minInstanceCount": MIN-VALUE }}' \
https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE?update_mask=scaling.minInstanceCount

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

  • ‫ACCESS_TOKEN: אסימון גישה תקין לחשבון שיש לו הרשאות IAM לעדכון שירות. לדוגמה, אם אתם מחוברים ל-gcloud, אתם יכולים לאחזר טוקן גישה באמצעות gcloud auth print-access-token. מתוך מופע קונטיינר של Cloud Run, אפשר לאחזר אסימון גישה באמצעות שרת המטא-נתונים של מופע הקונטיינר.
  • ‫MIN-VALUE: מספר המקרים של קונטיינרים שצריך לשמור במצב פעיל, מוכנים לקבל בקשות.
  • ‫SERVICE: שם השירות.
  • ‫REGION: Google Cloud האזור של השירות.
  • ‫PROJECT-ID: מזהה הפרויקט ב- Google Cloud .

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

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

המסוף

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

    כניסה ל-Cloud Run

  2. לוחצים על השירות שרוצים לראות כדי לפתוח את החלונית פרטי השירות.

  3. לוחצים על הכרטיסייה התאמה.

  4. בקטע Service scaling (שינוי קנה מידה של שירות), מוצאים את ההגדרה Minimum number of instances (מספר המופעים המינימלי).

gcloud

  1. משתמשים בפקודה הבאה:

    gcloud run services describe SERVICE

  2. מחפשים את הערך של Scaling: Auto (Min: MIN_VALUE, Max: MAX_VALUE) בהגדרה שמוחזרת.

הגדרת מספר מינימלי של מופעים ברמת השינוי

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

כברירת מחדל, האפשרות min-instances מושבתת במופעים של מאגרי תגים, וההגדרה היא 0.

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

המסוף

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

    כניסה ל-Cloud Run

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

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

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

  5. בקטע Revision scaling (שינוי קנה מידה של עדכון), מציינים את המספר המינימלי של מופעי מאגר התגים בשדה Minimum number of instances (מספר המופעים המינימלי).

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

gcloud

כדי לעדכן min-instance של שירות מסוים, משתמשים בפקודה הבאה:

gcloud run services update SERVICE --min-instances MIN-VALUE

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

  • ‫SERVICE: השם של השירות.
  • ‫MIN-VALUE: מספר מופעי הקונטיינרים שצריך לשמור במצב מוכן לקבלת בקשות. מציינים default כדי לנקות את ההגדרה של ערך מינימלי של מופעים.

אפשר גם להגדיר את min-instance במהלך הפריסה באמצעות הפקודה:

gcloud run deploy --image IMAGE_URL --min-instances MIN-VALUE

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

  • ‫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 .
  • ‫MIN-VALUE: מספר מופעי הקונטיינרים שצריך לשמור במצב מוכן לקבלת בקשות. מציינים default כדי לנקות את ההגדרה של ערך מינימלי של מופעים.

YAML

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

    gcloud run services describe SERVICE --format export > service.yaml

  2. מעדכנים את המאפיין autoscaling.knative.dev/minScale::

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: 'MIN-INSTANCE'
      name: REVISION

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

    • ‫SERVICE: השם של שירות Cloud Run
    • ‫MIN-INSTANCE: מספר המופעים שצריך לשמור במצב פעיל, מוכנים לקבל בקשות.
    • ‫REVISION: שם חדש לגרסה או מחיקה של השם (אם קיים). אם מספקים שם חדש לגרסה, חובה שהוא יעמוד בקריטריונים הבאים:
      • מתחיל ב-SERVICE-
      • מכיל רק אותיות קטנות, מספרים ו-
      • לא מסתיים ב--
      • לא חורג מ-63 תווים

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

    gcloud run services replace service.yaml

    אם קיים קובץ service.yaml, הפקודה gcloud run services replace משתמשת בו כברירת מחדל.

Terraform

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

מוסיפים את השורות הבאות למשאב google_cloud_run_v2_service בתצורת Terraform:

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

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    scaling {
      # Min instances
      min_instance_count = 1
    }
  }
}

במשאב google_cloud_run_v2_service שלמעלה מצוין מספר מינימלי של מופעים של 1 ב-template.scaling. מחליפים את 1 במספר המינימלי של המכונות שאתם רוצים.

הצגת מופעי מינימום ברמת השינוי

התכונה 'שינוי קנה מידה ברמת הגרסה' זמינה רק לשירותים שהתכונה הזו הוגדרה בהם בעבר.

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

המסוף

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

    כניסה ל-Cloud Run

  2. לוחצים על השירות שרוצים לראות כדי לפתוח את החלונית פרטי השירות.

  3. לוחצים על הכרטיסייה התאמה.

  4. מחפשים את ההגדרה Minimum number of instances (מספר המופעים המינימלי) בקטע Revision scaling (שינוי קנה מידה של עדכון).

gcloud

  1. משתמשים בפקודה הבאה:

    gcloud run services describe SERVICE

  2. מחפשים את הערך של Min instances:‎ בהגדרה שמוחזרת.

דוגמאות

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

שימוש במינימום או במקסימום מופעים ברמת השירות וברמת הגרסה

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

  • מגבלות מקסימליות תמיד מגבילות מגבלות מינימליות: כל מגבלה מקסימלית שתגדירו ברמת השירות או ברמת הגרסה תמנע מהמערכת להגדיל את המכסה מעבר לערך הזה, בלי קשר להגדרות המינימום.
  • במגבלות מינימום, המגבלה הגדולה ביותר היא זו שמוגדרת: אם מוגדרות כמה מגבלות מינימום והן לא נחסמות על ידי מגבלת מקסימום, המערכת להגדלת הקיבולת האוטומטית תפעל לפי מגבלת המינימום הגבוהה ביותר.
שירות גרסה קודמת כלל פתרון התנהגות שמתקבלת
מינימום מינימום הכי הרבה זכיות במינימום אם הערך המינימלי של השירות הוא 10 והערך המינימלי של הגרסה הוא 5, הגרסה מפעילה 10 מופעים כדי לעמוד בדרישה המינימלית הגבוהה יותר.
מינימום מקסימום הערך המקסימלי של הגרסה הקודמת מבטל את הערך המינימלי של השירות אם הערך של service min הוא 10 אבל הערך של revision max הוא 5, מספר המופעים של התיקון מוגבל ל-5.
מקסימום מינימום הערך המקסימלי של השירות מבטל את הערך המינימלי של הגרסה אם הערך המקסימלי של השירות הוא 5 אבל הערך המינימלי של הגרסה הוא 10, הגרסה מוגבלת ל-5 מופעים בלבד.
מקסימום מקסימום המספר המקסימלי הנמוך ביותר של זכיות אם המקסימום של השירות הוא 5 והמקסימום של הגרסה הוא 10, הגרסה מוגבלת ל-5 מופעים.

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

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

שימוש במספר מינימלי של מופעים ברמת השירות עם חלוקת תנועה

אם משתמשים בפיצול תנועה, המינימום של המופעים ברמת השירות מחולק בין הגרסאות על סמך שיעור פיצול התנועה. לדוגמה, אם המינימום של רמת השירות instances = 10, פיצול תנועה של 50/50 מקצה 5 מופעים מינימליים של רמת השירות לכל עדכון.

בטבלה הבאה מוצגים תרחישי הגדרה לדוגמה:

תרחיש שימוש לדוגמה שירות מינימלי גרסה א' גרסה ב' חלוקת התנועה התנהגות שמתקבלת
אין הגדרות ברמת השינוי 10 מינימום: 0 מינימום: 0 60/40 גרסה א' מקבלת 6 מופעים מתוך המינימום של המופעים ברמת השירות, באופן יחסי לחלוקת התנועה. גרסה B מקבלת 4 מופעים מהמופעים המינימליים ברמת השירות, באופן יחסי לפי חלוקת התנועה.
מקבלים יותר מהמינימום של המקרים ברמת השירות בגלל המינימום של המקרים ברמת הגרסה 10 מינימום: 6 מינימום: 0 50/50 גרסה א' מקבלת 6 מופעים מהמינימום של מופעים ברמת הגרסה. גרסה ב' מקבלת 5 מופעים מהמינימום של רמת השירות, באופן יחסי לפי חלוקת התנועה. המספר הזה חורג מהמספר המינימלי של מופעים ברמת השירות, וזה מכוון.
מקבלים פחות מופעים מהמינימום ברמת השירות בגלל המקסימום ברמת השינוי 10 מינימום: 0
מקסימום: 3		 מינימום: 0 50/50 גרסה א' מקבלת 3 מופעים מהמופעים המינימליים ברמת השירות, שנקבעים לפי חלוקת התנועה, אבל מוגבלת למופעים המקסימליים ברמת הגרסה.

גרסה ב' מקבלת 5 מופעים מהמופעים המינימליים ברמת השירות, באופן יחסי לחלוקת התנועה. התוצאה היא 8 מופעים ברמת השירות, כי 2 מופעים אבדו בגלל המקסימום של מופעים ברמת העדכון של עדכון A.
המספר המינימלי של מופעים ברמת השירות גדול ממספר הגרסאות בחלוקת התנועה, ויש כמות חלקית של מופעים שפרופורציונלית לחלוקת התנועה 3 מינימום: 0 מינימום: 0 50/50 הקצאות חלקיות (1.5 מופעים כל אחת) מעוגלות. הגרסה הראשונה שמופיעה בקטע התנועה מקבלת את הערך המעוגל כלפי מעלה: גרסה ב' (שמופיעה ראשונה) מקבלת 2 מופעים, וגרסה א' מקבלת 1. המספר הכולל של המופעים הוא 3.

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

אם הערך של minimum instances (מספר מופעים מינימלי) גבוה יותר ממה שנדרש לתנועת הגולשים הרגילה, יכול להיות שהרבה מופעים יהפכו לפעילים באופן חלקי, וכל אחד מהם יעבד כמה בקשות. לדוגמה, אם השירות שלכם בדרך כלל דורש 200 מופעים בעומס שיא, אבל מספר המופעים המינימלי מוגדר ל-600, הבקשות הנכנסות יפוזרו בין כל 600 המופעים. כתוצאה מכך, הרבה מ-600 המקרים האלה הופכים לפעילים במידה מסוימת, וכל אחד מהם מטפל בחלק קטן מתעבורת הנתונים, במקום ש-200 מקרים יהיו פעילים מאוד ו-400 הנותרים יישארו בלי פעילות לחלוטין.

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

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