בדף הזה מוסבר איך להפעיל מופעים בלי פעילות בשירות על ידי הגדרת מספר מינימלי של מופעים באמצעות התנהגות ברירת המחדל של התאמה אוטומטית לעומס ב-Cloud Run. כדי לשנות את קנה המידה של השירות באופן ידני, אפשר לעיין במאמר בנושא שינוי קנה מידה ידני.
אם אתם צריכים שליטה רבה יותר על התנהגות ההתאמה האוטומטית לעומס של השירות, אתם יכולים להגדיר מספר מינימלי של מופעים כדי למנוע זמני הפעלה איטיים של קונטיינרים ולצמצם את זמן האחזור של השירות. בשירותי Cloud Run, המערכת מבצעת סקיילינג באופן אוטומטי למספר המכונות בהתאם למספר הבקשות הנכנסות.
עם זאת, אם השירות שלכם דורש חביון נמוך יותר, במיוחד כשמגדילים את הקיבולת מאפס מופעים פעילים, אתם יכולים לשנות את התנהגות ברירת המחדל הזו על ידי ציון מספר מינימלי של מופעי קונטיינר שצריך לשמור במצב מוכן כדי לטפל בבקשות. מידע נוסף על האופטימיזציה הזו זמין במאמר בנושא טיפים כלליים לפיתוח.
Cloud Run מסיר מופעים שלא מעבדים בקשות (במצב סרק).
אם מגדירים מספר מינימלי של מופעים, Cloud Run מפעיל לפחות את המספר הזה של מופעים, גם אם הם לא מעבדים בקשות. אם לא מתקבלות בקשות במופעים פעילים מעל המספר min-instances, יכול להיות שהם יהפכו ללא פעילים.
לדוגמה, אם min-instances הוא 10 ומספר המופעים הפעילים הוא 0, אז מספר המופעים הלא פעילים הוא 10. כאשר מספר המופעים הפעילים עולה ל-6, מספר המופעים הלא פעילים יורד ל-4.
שימו לב: אם שירות לא הציג תנועה לאחרונה, מדד המופעים הפעילים יכול להצביע על כך שאין מופעים פעילים, גם אם ציינתם מופע מינימלי אחד או יותר.
אפשר להפעיל מחדש את המינימום של המופעים בכל שלב.
חיוב
הפעלת מכונות באמצעות התכונה 'מכונות מינימליות' כרוכה בעלויות חיוב.
בתרשים הבא מוצג אופן החיוב במהלך מחזור החיים של מופע כשמגדירים מופעים מינימליים לשירות או לגרסה:
בהתאם להגדרות החיוב שנקבעו, החיוב על השירות מתבצע באופן הבא:
- בחיוב לפי בקשה, אתם מחויבים בתעריף נמוך יותר כשהמופעים במצב המתנה לטיפול בבקשות. אם הערך של min instances (מספר המופעים המינימלי) מוגדר ל-
0, לא נחייב אתכם כשהמופעים בלי פעילות. - בחיוב לפי מופע, אתם מחויבים בשיעור ברירת המחדל לכל משך החיים של המופע. הזמן שחלף מההפעלה ועד הכיבוי כולל את הזמן שבו מופע מעבד בקשות או נמצא במצב המתנה. במילים אחרות, גם אם הערך של min
instances מוגדר כ-
0, עדיין תחויבו לפי שיעור ברירת המחדל. האפשרות הזו מתאימה אם אתם צריכים CPU מחוץ לבקשות. אם הערך של min instances מוגדר כ-0, החיוב הוא לפי תעריף ברירת המחדל.
החלת מספר מינימלי של מופעים ברמת השירות לעומת ברמת השינוי
אפשר להגדיר את מספר המופעים המינימלי ברמת השירות או ברמת העדכון. Google ממליצה להחיל מכונות מינימליות ברמת השירות ולהימנע משילוב של מכונות מינימליות ברמת השירות וברמת התיקון. מידע נוסף על ההתנהגות כשמגדירים הגדרות קנה מידה ברמת השירות וברמת השינוי
אם מגדירים מספר מינימלי של מופעים ברמת הגרסה, ההגדרות ייכנסו לתוקף עם הפריסה של הגרסה. אם תפעילו את התכונה הזו ברמת השירות, ההגדרה תיכנס לתוקף בלי שתצטרכו לפרוס גרסה חדשה.
עדכונים ומספר מינימלי של מכונות
כשמגדירים את מספר המופעים המינימלי ברמת השירות, הבקשות הנכנסות מופצות לכל הגרסאות שמציגות תנועה באופן יחסי לפי חלוקת התנועה.
כשמגדירים את מספר המופעים המינימלי ברמת התיקון, מופעים מינימליים מופעלים בכל פעם שיש הפניה לתיקון בחלוקת תנועה או כשמוקצה לו תג תנועה. המשמעות היא שהחיוב על המופע מתבצע בזמן עיבוד הבקשות וגם בזמן ההמתנה לבקשות נכנסות.
גרסאות מתויגות ומופעים מינימליים ברמת השירות
אם מתחילים גרסה עם תג שהוקצה, המופע נספר במסגרת המינימום של המופעים ברמת השירות אם הוא חלק מחלוקת התנועה.
ניתוב בקשות עם מספר מופעים מינימלי
כשמגדירים מספר מינימלי של מופעים, Cloud Run מחלק את הבקשות הנכנסות באופן שווה בין כל המופעים שהוקצו. חשוב להבין את ההתנהגות הזו כדי לנהל את העלויות, במיוחד אם החיוב מבוסס על בקשות או אם אתם מתכוונים להשאיר מופעים של hot spare במצב סרק. כדי לצמצם את העלויות, צריך להגדיר את מספר המופעים המינימלי למספר המופעים שנדרשים כדי לטפל בתנועה האופיינית.
התפקידים הנדרשים
כדי לקבל את ההרשאות שדרושות להגדרה ולפריסה של שירותי Cloud Run, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:
-
Cloud Run Developer (
roles/run.developer) בשירות Cloud Run -
משתמש בחשבון שירות (
roles/iam.serviceAccountUser) בזהות השירות
אם אתם פורסים שירות או פונקציה מקוד מקור, אתם צריכים גם לקבל תפקידים נוספים בפרויקט ובחשבון השירות של Cloud Build.
רשימת ההרשאות והתפקידים ב-IAM שמשויכים ל-Cloud Run מופיעה במאמרים תפקידי IAM ב-Cloud Run והרשאות IAM ב-Cloud Run. אם שירות Cloud Run שלכם מתקשר עםGoogle Cloud ממשקי API, כמו ספריות לקוח ב-Cloud, כדאי לעיין במדריך להגדרת זהות שירות. מידע נוסף על מתן תפקידים זמין במאמרים הרשאות פריסה וניהול גישה.
הגדרת מספר מינימלי של מופעים ברמת השירות
כברירת מחדל, המינימום של מופעים ברמת השירות מושבת במופעי קונטיינר, וההגדרה היא 0. אפשר לשנות את ברירת המחדל הזו באמצעותGoogle Cloud המסוף, Google Cloud CLI או קובץ YAML:
המסוף
במסוף Google Cloud , נכנסים לדף Services של Cloud Run:
אם אתם מגדירים שירות חדש, לוחצים על Deploy container (פריסת מאגר) כדי להציג את הטופס Create service (יצירת שירות). מחפשים את הטופס Service scaling (שינוי גודל השירות).
אם אתם מגדירים שירות קיים, לוחצים על השירות כדי להציג את חלונית הפרטים שלו, ואז לוחצים על עריכת הגדרות ההתאמה של רמת השירות בפינה השמאלית העליונה של חלונית הפרטים.
בשדה Minimum number of instances (מספר המופעים המינימלי), מציינים את מספר מופעי הקונטיינר שרוצים לשמור במצב פעיל ומוכן לקבלת בקשות.
לוחצים על יצירה כדי ליצור שירות חדש או על פריסה כדי לפרוס שירות קיים.
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
כל שינוי בהגדרות מוביל ליצירה של גרסה חדשה. גם גרסאות עתידיות יקבלו את הגדרת התצורה הזו באופן אוטומטי, אלא אם תבצעו עדכונים מפורשים כדי לשנות אותה.
אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, מורידים את הגדרות ה-YAML שלו:
gcloud run services describe SERVICE --format export > service.yaml
מעדכנים את המאפיין
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: מספר המופעים שצריך לשמור במצב פעיל, מוכנים לקבל בקשות.
יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה:
gcloud run services replace service.yaml
ספריות לקוח
כדי לעדכן את מספר המינימום של מופעים ברמת השירות בשביל השירות שלכם מקוד:
API ל-REST
כדי לעדכן את מספר המינימום של מופעים ברמת השירות בשירות נתון, שולחים בקשת HTTP לנקודת הקצה של Cloud Run Admin API service.PATCH
לדוגמה, שימוש ב-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:
המסוף
במסוף Google Cloud , נכנסים לדף Services של Cloud Run:
לוחצים על השירות שרוצים לראות כדי לפתוח את החלונית פרטי השירות.
ההגדרה הנוכחית מוצגת בפינה השמאלית העליונה של החלונית עם פרטי השירות, לצד Scaling.
gcloud
משתמשים בפקודה הבאה:
gcloud run services describe SERVICE
מחפשים את הערך של Scaling: Auto (Min: MIN_VALUE, Max: MAX_VALUE) בתצורה שהוחזרה.
הגדרת מספר מופעים מינימלי ברמת השינוי
כל שינוי בהגדרות מוביל ליצירה של גרסה חדשה. גם גרסאות עתידיות יקבלו את הגדרת התצורה הזו באופן אוטומטי, אלא אם תבצעו עדכונים מפורשים כדי לשנות אותה.
כברירת מחדל, האפשרות min-instances מושבתת במופעים של מאגרי תגים, וההגדרה היא 0. אפשר לשנות את ברירת המחדל הזו באמצעות מסוף Google Cloud, Google Cloud CLI או קובץ YAML כשיוצרים שירות חדש או פורסים עדכון חדש: Google Cloud
המסוף
נכנסים ל-Cloud Run במסוף Google Cloud :
בתפריט הניווט של Cloud Run, בוחרים באפשרות Services (שירותים) ולוחצים על Deploy container (פריסת קונטיינר) כדי להגדיר שירות חדש. אם אתם מגדירים שירות קיים, לוחצים על השירות ואז על עריכה ופריסה של עדכון חדש.
אם אתם מגדירים שירות חדש, ממלאים את דף ההגדרות הראשוניות של השירות ואז לוחצים על Container(s), Volumes, Networking, Security (מאגרים, אמצעי אחסון, רשתות, אבטחה) כדי להרחיב את דף הגדרות השירות.
לוחצים על הכרטיסייה מאגר תגים.
- בשדה Minimum number of instances (מספר המופעים המינימלי), מציינים את מספר מופעי הקונטיינר שצריך לשמור במצב פעיל ומוכן לקבלת בקשות.
לוחצים על יצירה או על פריסה.
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
אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, מורידים את הגדרות ה-YAML שלו:
gcloud run services describe SERVICE --format export > service.yaml
מעדכנים את המאפיין
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 תווים
- מתחיל ב-
יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה:
gcloud run services replace service.yaml
Terraform
כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.
מוסיפים את השורות הבאות למשאבgoogle_cloud_run_v2_service בקובץ התצורה של Terraform:במשאב google_cloud_run_v2_service שלמעלה מצוין מספר מינימלי של מופעים של 1 ב-template.scaling.
מחליפים את 1 במספר המינימלי של המכונות שאתם רוצים.
הצגת מספר המינימום של מופעים ברמת הגרסה
כדי לראות את ההגדרות הנוכחיות של מספר המינימום של מופעים ברמת התיקון בשירות Cloud Run:
המסוף
במסוף Google Cloud , נכנסים לדף Services של Cloud Run:
לוחצים על השירות שרוצים לראות כדי לפתוח את החלונית פרטי השירות.
לוחצים על הכרטיסייה עדכונים.
בחלונית הפרטים שמשמאל, ההגדרה Revision min. instances מופיעה בכרטיסייה Container.
gcloud
משתמשים בפקודה הבאה:
gcloud run services describe SERVICE
מחפשים את הערך של Min instances: (מספר המופעים המינימלי) בהגדרה שהוחזרה.
דוגמאות
בקטעים הבאים מוסבר איך השירות מתנהג כשמגדירים מספר מינימלי של מופעים.
שימוש במספר מינימלי או מקסימלי של מופעים ברמת השירות וברמת הגרסה
בטבלה הבאה מוצג אופן הפעולה אם משלבים בין מספר מינימלי או מקסימלי של מופעים ברמת השירות לבין מספר מינימלי או מקסימלי של מופעים ברמת הגרסה. שימו לב שאם יש סתירה בין שתי ההגדרות, ההגדרה של מספר המופעים המקסימלי מגבילה את ההגדרה של מספר המופעים המינימלי ומבטלת אותה.
| הגדרת תצורה | התנהגות |
|---|---|
| מוגדרים גם מקרים מינימליים ברמת השירות וגם מקרים מינימליים ברמת הגרסה. | הערך האפקטיבי של הגרסה הוא הגדול מבין הערכים של המופעים המינימליים ברמת הגרסה והמופעים המינימליים ברמת השירות. |
| הוגדרו גם מקרים מינימליים ברמת השירות וגם מקרים מקסימליים ברמת הגרסה. | הערך האפקטיבי של הגרסה הוא הערך הקטן מבין הערך המקסימלי של המופעים ברמת הגרסה והערך המינימלי של המופעים ברמת השירות. זה נכון גם אם מספר המכונות המקסימלי ברמת התיקון מונע מהשירות להגיע למספר המכונות המינימלי שהוגדר ברמת השירות. |
| הערך של מספר המופעים המקסימלי של השירות קטן ממספר המופעים המינימלי של עדכון. | הערך בפועל של המופעים של השינוי מוגבל למקסימום של השירות. |
| הערך של 'מספר מינימלי של מופעי שירות' גדול מהערך של 'מספר מקסימלי של מופעים' של עדכון. | הערך בפועל של המופעים של הגרסה מוגבל למקסימום של הגרסה. |
שימוש במספר מינימלי של מופעים ברמת השירות עם פיצול תנועה
אם משתמשים בחלוקת התנועה, המינימום של המופעים ברמת השירות מחולק בין הגרסאות על סמך החלק היחסי של חלוקת התנועה. לדוגמה, אם המינימום של רמת השירות instances = 10, חלוקת תנועה של 50/50 מקצה 5 מופעים מינימליים של רמת השירות לכל עדכון.
בטבלה הבאה מוצגים תרחישי הגדרה לדוגמה:
| תרחיש שימוש לדוגמה | הגדרה לדוגמה | התנהגות שמתקבלת |
|---|---|---|
| אין הגדרות ברמת השינוי | מינימום מכונות ברמת השירות: 10
|
גרסה א' מקבלת 6 מופעים מתוך המינימום של המופעים ברמת השירות, באופן יחסי לחלוקת התנועה. גרסה ב' מקבלת 4 מופעים ממינימום המופעים ברמת השירות, באופן יחסי לחלוקת התנועה. |
| מקבלים יותר מהמינימום של המופעים ברמת השירות בגלל המינימום של המופעים ברמת הגרסה | מינימום מכונות ברמת השירות: 10
|
גרסה A מקבלת 6 מופעים מתוך המינימום של מופעים ברמת הגרסה. גרסה ב' מקבלת 5 מופעים ממינימום המופעים ברמת השירות, באופן יחסי לחלוקת התנועה. המספר הזה חורג מהמספר המינימלי של מופעים ברמת השירות, וזו הכוונה. |
| מקבלים פחות ממינימום המופעים ברמת השירות בגלל מקסימום המופעים ברמת התיקון. | מינימום מכונות ברמת השירות: 10
|
גרסה A מקבלת 3 מופעים מהמופעים המינימליים ברמת השירות שמונעים על ידי חלוקת התנועה, אבל מוגבלת למופעים המקסימליים ברמת הגרסה שלה. גרסה B מקבלת 5 מופעים מהמופעים המינימליים ברמת השירות, באופן יחסי לחלוקת התנועה. התוצאה היא 8 מופעים ברמת השירות, כי 2 מופעים אבדו בגלל המקסימום של מופעים ברמת הגרסה של גרסה א'. |
| המספר המינימלי של מופעים ברמת השירות גדול ממספר הגרסאות בחלוקת התנועה, ויש מספר חלקי של מופעים שפרופורציונלי לחלוקת התנועה | מינימום מכונות ברמת השירות: 3
|
גרסה א' מקבלת מכונה אחת לפחות וגרסה ב' מקבלת 2 מכונות לפחות. ספירת המופעים של השירות היא 3. |
קביעת מספר המופעים המינימלי שנדרש
אם הערך של 'מספר מופעים מינימלי' גבוה יותר ממה שנדרש לתנועה הרגילה, יכול להיות שהרבה מופעים יהפכו לפעילים באופן חלקי, וכל אחד מהם יעבד כמה בקשות. לדוגמה, אם בדרך כלל השירות שלכם דורש 200 מופעים לשיא העומס, אבל מספר המופעים המינימלי מוגדר ל-600, הבקשות הנכנסות יפוזרו בין כל 600 המופעים. כתוצאה מכך, הרבה מתוך 600 המקרים האלה הופכים לפעילים במידה מסוימת, וכל אחד מהם מטפל בחלק קטן מהתנועה, במקום ש-200 מקרים יהיו פעילים מאוד ו-400 הנותרים יישארו בלי פעילות לחלוטין.
כדי לצמצם את העלויות (על ידי שימוש יעיל יותר בפחות מקרים), צריך להגדיר את מספר המקרים המינימלי לערך שקרוב למספר המקרים בפועל שנדרשים כדי לטפל בתנועה הרגילה.
בנוסף, כשמנגנון ההתאמה האוטומטית לעומס מקצה מכונות נוספות מעבר למכונות המינימליות שהוגדרו, מערכת Cloud Run מעדיפה להפנות בקשות נכנסות קודם למכונות המינימליות שהוגדרו, ורק אחר כך לשלוח בקשות למכונות שהוקצו על ידי מנגנון ההתאמה האוטומטית לעומס. בחיוב לפי בקשה, הניתוב המועדף הזה למינימום המופעים שהוגדר מפחית את העלות, כי המערכת ממלאת את מינימום המופעים שהוגדר לפני שהיא משתמשת במופעים שגודלם משתנה אוטומטית. שימו לב: הניתוב המועדף הזה יכול גם להוביל לניצול גבוה יותר של מופעים מינימליים שהוגדרו בהשוואה למופעים שמשנים את הגודל באופן אוטומטי, בהתאם לכמות התנועה.