חוזה זמן ריצה של קונטיינר

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

שפות ותמונות נתמכות

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

קבצי ההפעלה בקובץ האימג' של הקונטיינר צריכים להיות מקומפלים ל-Linux בגרסת 64 ביט. ‫Cloud Run תומך באופן ספציפי בפורמט Linux x86_64 ABI.

ב-Cloud Run אפשר להשתמש בקובצי אימג' של קונטיינרים בפורמטים של קובצי אימג' של Docker Image Manifest V2,‏ Schema 1,‏ Schema 2 ו-OCI. ב-Cloud Run אפשר להשתמש גם בקובצי אימג' של קונטיינרים שדחוסים ב-Zstd.

אם פורסים תמונה עם כמה ארכיטקטורות, רשימת המניפסט חייבת לכלול את linux/amd64.

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

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

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

הקונטיינר שנפרס לשירותים צריך להאזין לבקשות ביציאה הנכונה

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

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

קישוריות לרשת VPC

ב-Cloud Run אפשר להתחבר לרשת VPC באמצעות Direct VPC.

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

כל משאב של Cloud Run תומך בהגדרות הבאות של Direct VPC:

• שירותים: תעבורת נתונים יוצאת (egress) בלבד
• משימות: תעבורת נתונים יוצאת בלבד
• מאגרי Worker: תעבורת נתונים יוצאת ונכנסת
• מכונות: תעבורת נתונים יוצאת (egress) ונכנסת (ingress)

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

כשמשתמשים ב-Direct VPC ingress למאגרי Worker או למכונות Cloud Run:

• רק משאבים מרשת ה-VPC יכולים להתחבר לנקודת הקצה של כתובת ה-IP הפרטית של המשאב. למידע נוסף על קבלת כתובות ה-IP הפרטיות של מאגר ה-Workers או המכונה, ראו אחזור כתובות ה-IP הפרטיות באמצעות שרת המטא-נתונים (MDS).

• בחיבורים כמו חיבורים למסדי נתונים או כל פרוטוקול אחר שמבוסס על TCP בהתאמה אישית, הקונטיינר צריך להאזין לחיבורי TCP ביציאה שנחשפת בקובץ האימג' של הקונטיינר דרך קובץ ה-Dockerfile או שצוינה על ידי משתנה הסביבה PORT.

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

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

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

הצפנה של שכבת התעבורה (TLS)

הקונטיינר לא אמור להטמיע אבטחת שכבת תעבורה (TLS) באופן ישיר. ‫Cloud Run מסיים את ה-TLS ל-HTTPS ול-gRPC, ואז הבקשות מועברות כ-HTTP/1 או כ-gRPC לקונטיינר ללא TLS.

אם מגדירים שירות Cloud Run לשימוש ב-HTTP/2 מקצה לקצה, הקונטיינר צריך לטפל בבקשות בפורמט טקסט לא מוצפן של HTTP/2‏ (h2c), כי Cloud Run עדיין מסיים את TLS באופן אוטומטי.

תשובות (שירותים)

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

שמירת תגובות במטמון וקובצי Cookie

אם התגובה של שירות Cloud Run מכילה כותרת Set-Cookie, ‏Cloud Run מגדיר את הכותרת Cache-Control לערך private כדי שהתגובה לא תישמר במטמון. כך משתמשים אחרים לא יכולים לאחזר את קובץ ה-cookie.

משתני סביבה

יש קבוצות שונות של משתני סביבה לשירותים ולמשימות של Cloud Run.

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

משתני הסביבה הבאים מתווספים באופן אוטומטי לכל הקונטיינרים שפועלים, חוץ מ-PORT. המשתנה PORT נוסף רק למאגר התגים של Ingress:

שם	תיאור	דוגמה
PORT	היציאה ששרת ה-HTTP צריך להאזין לה.	8080
K_SERVICE	השם של שירות Cloud Run שפועל.	hello-world
K_REVISION	השם של גרסת Cloud Run שפועלת.	hello-world.1
K_CONFIGURATION	שם ההגדרה של Cloud Run שיצרה את הגרסה.	hello-world

משתני סביבה למשימות

במשימות של Cloud Run, מוגדרים משתני הסביבה הבאים:

שם	תיאור	דוגמה
CLOUD_RUN_JOB	השם של משימת Cloud Run שמופעלת.	hello-world
CLOUD_RUN_EXECUTION	שם ההפעלה של Cloud Run.	hello-world-abc
CLOUD_RUN_TASK_INDEX	האינדקס של המשימה הזו. הערך מתחיל ב-0 במשימה הראשונה וגדל ב-1 בכל משימה עוקבת, עד למספר המקסימלי של המשימות פחות 1. אם מגדירים את --parallelism לערך שגדול מ-1, יכול להיות שהמשימות לא יבוצעו לפי סדר האינדקס. לדוגמה, יכול להיות שמשימה 2 תתחיל לפני משימה 1.	0
CLOUD_RUN_TASK_ATTEMPT	מספר הפעמים שהמשימה הזו בוצעה מחדש. הערך מתחיל ב-0 בניסיון הראשון וגדל ב-1 בכל ניסיון חוזר, עד לערך המקסימלי של ניסיונות חוזרים.	0
CLOUD_RUN_TASK_COUNT	מספר המשימות שמוגדרות בפרמטר --tasks.	1

משתני סביבה למאגרי Worker

‫Cloud Run מגדיר את משתני הסביבה הבאים למאגרי Worker:

שם	תיאור	דוגמה
CLOUD_RUN_WORKER_POOL	השם של מאגר ה-workers הפעיל ב-Cloud Run.	hello-world
CLOUD_RUN_REVISION	השם של גרסת מאגר ה-workers שפועלת ב-Cloud Run.	hello-world.1

דרישות לגבי כותרות של בקשות ותגובות (שירותים)

בשירותים, Cloud Run מגביל את שמות הכותרות לתווי ASCII שניתנים להדפסה, ללא רווחים לבנים וללא נקודתיים. ב-Cloud Run, ערכי הכותרות מוגבלים לתווי ASCII גלויים, כולל רווח וטאב אופקי, בהתאם ל-IETF RFC 7230.

גישה למערכת הקבצים

אפשר לכתוב במערכת הקבצים של כל קונטיינר, והיא כפופה להתנהגות הבאה:

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

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

מחזור החיים של המכונה

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

לשירותים

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

שינוי קנה המידה של השירות

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

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

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

הפעלה

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

הבקשות יישלחו לקונטיינר ה-ingress ברגע שהוא יאזין ליציאה שהוגדרה.

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

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

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

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

עיבוד בקשה

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

לא פעיל/ה כבר כמה זמן

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

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

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

כיבוי

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

לפני השבתת מכונה, Cloud Run שולח אות SIGTERM לכל הקונטיינרים במכונה, שמציין את תחילתה של תקופה של 10 שניות לפני שההשבתה בפועל מתרחשת, ובשלב הזה Cloud Run שולח אות SIGKILL. במהלך התקופה הזו, המכונה מקבלת הקצאה של מעבד (CPU) ומחויבת. בשירותים שמשתמשים בסביבת זמן הריצה מהדור הראשון, אם המכונה לא לוכדת את האות SIGTERM, היא מושבתת באופן מיידי. בשירותים שמשתמשים בסביבת זמן הריצה מהדור השני, מומלץ להתקין handler של SIGTERM בקונטיינר כדי לקבל אזהרה כש-Cloud Run עומד להשבית מכונה.

סגירה מאולצת

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

למשימות

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

קודי יציאה

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

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

קוד יציאה	אות	תיאור
0		המשימה הושלמה בהצלחה.
4	SIGILL	המשימה ניסתה לגשת לזיכרון בכתובת שגויה.
7	SIGBUS	המשימה ניסתה לגשת לזיכרון מחוץ לגבולות שהוקצו לה.
9	SIGKILL	המשימה מסתיימת באופן מאולץ, על ידי פעולת משתמש או התערבות ידנית.
11	SIGSEGV	המשימה ניסתה לגשת לזיכרון לא מורשה.
15	SIGTERM	אם משימה חורגת מהזמן הקצוב לתפוגה שהוגדר לה או אם היא מבוטלת, היא מקבלת אות SIGTERM. שרת האפליקציה שולח את האות SIGTERM כדי לסגור את המכונה של מאגר התגים. אם המכונה לא נכבית מעצמה תוך כמה שניות אחרי קבלת SIGTERM, ‏Cloud Run שולח אות SIGKILL לסיום מאולץ. אם המכונה יוצאת בצורה תקינה עם SIGTERM, יכול להיות שהיא תדווח על קוד שגיאה אחר. אחרת, היא מחזירה את הערך SIGTERM.

סגירה מאולצת

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

אם משימה חורגת מזמן הקצוב לתפוגה, Cloud Run שולח אות SIGTERM שמציין את תחילת התקופה של 10 שניות לפני שהכיבוי בפועל מתרחש. בשלב הזה Cloud Run שולח אות SIGKILL, שמכבה את המכונה של מאגר הנתונים. בקטע השבתה מפורטים פרטים והמלצות לטיפול במצב כזה.

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

למאגרי Worker

המאפיינים הבאים רלוונטיים רק למאגרי Worker.

התאמה לעומס (scaling)

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

הפעלה

מכונות של מאגרי Worker ב-Cloud Run מפעילות את הקונטיינר עם נקודת הכניסה שציינתם בקובץ האימג' של הקונטיינר או בהגדרות של מאגר ה-Worker. כל הקונטיינרים במכונה צריכים להיות תקינים.

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

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

הקצאת משאבים

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

כיבוי

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

לפני השבתת מכונה, Cloud Run שולח אות SIGTERM לכל הקונטיינרים במכונה. האות הזה מציין את תחילתה של תקופה של 10 שניות לפני שהכיבוי בפועל מתרחש, ובשלב הזה Cloud Run שולח אות SIGKILL. במהלך תקופת ההשבתה, המכונה מקבלת הקצאת מעבד (CPU) ומחויבת. מומלץ להתקין בקונטיינר handler של SIGTERM כדי לקבל אזהרה כש-Cloud Run עומד להשבית מכונה.

סגירה מאולצת

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

משאבים של מכונות קונטיינרים

הקונטיינר פועל תחת בקר cgroup שמגביל את המעבד (CPU), ה-RAM ומשאבים אחרים לאלה שהוגדרו לקונטיינר.

בקטעים הבאים מתוארים המשאבים של מכונת הקונטיינר:

• מעבד (CPU)
• זיכרון
• GPU
• בו-זמניות (concurrency)

CPU

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

‫vCPU מיושם כהפשטה של החומרה הבסיסית, כדי לספק זמן CPU שווה ערך בקירוב ל-hyper-thread של חומרה אחת בפלטפורמות CPU משתנות. כל פלטפורמות המעבדים שמשמשות את Cloud Run תומכות בסט הפקודות AVX2. שימו לב שהחוזה של הקונטיינר לא מכיל פרטים נוספים על פלטפורמת המעבד (CPU).

יכול להיות שהקונטיינר יופעל בכמה ליבות בו-זמנית.

בשירותי Cloud Run, הקצאת המעבד (CPU) תלויה בחיוב שנבחר.

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

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

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

זיכרון

כברירת מחדל, לכל קונטיינר של Cloud Run מוקצה הזיכרון שהוגדר (כברירת מחדל, ‎512MiB). אפשר להגדיר מגבלות זיכרון לכל קונטיינר בנפרד.

השימושים הנפוצים בזיכרון כוללים:

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

GPU

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

ספריות NVIDIA

כברירת מחדל, כל ספריות הדרייברים של NVIDIA RTX PRO 6000 Blackwell GPU ו-NVIDIA L4 GPU מותקנות ב-/usr/local/nvidia/lib64. ‫Cloud Run מוסיף באופן אוטומטי את הנתיב הזה למשתנה הסביבה LD_LIBRARY_PATH (כלומר ${LD_LIBRARY_PATH}:/usr/local/nvidia/lib64) של הקונטיינר עם ה-GPU. כך המקשר הדינמי יכול למצוא את ספריות מנהלי ההתקנים של NVIDIA. המקשר מחפש ופותר נתיבים לפי הסדר שמופיע במשתנה הסביבה LD_LIBRARY_PATH. כל ערך שתציינו במשתנה הזה יקבל עדיפות על פני נתיב ברירת המחדל של ספריות הדרייברים של Cloud Run, שהוא /usr/local/nvidia/lib64.

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

בו-זמניות (שירותים)

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

הגבלות אבטחה על קונטיינרים

ההגבלות הבאות חלות על קונטיינרים שפועלים ב-Cloud Run. הן חלות בלי קשר למשתמש Linux שצוין להפעלה בקובץ האימג' של הקונטיינר.

הרשאות מצומצמות

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

• הוספה או הסרה של יכולות ליבה של Linux
• שימוש ביכולות ספציפיות של הליבה
• שינוי מכשירים
• גישה למשאבי חומרה מסוימים

גם הסלמת הרשאות מושבתת במאגרים שלכם. אי אפשר להשתמש בקבצים בינאריים של sudo ו-setuid ב-Cloud Run.

לקונטיינרים לא תהיה גישת כתיבה לרוב הקבצים והספריות ב-/dev, ב-/proc וב-/sys.

אין ב-Cloud Run מקבילה למצב --privileged של Docker.

בידוד קונטיינרים

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

טעינה מוגבלת של מערכות קבצים מתוך קונטיינרים

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

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

• הפעלת תהליך טעינה בתוך הקונטיינר כדי לטעון את אחד מהבאים: NFS,‏ Filestore,‏ SMB/CIFS או כל מערכת קובצי רשת אחרת.
• קריאה לקריאות מערכת שיבצעו פעולות מקבילות.

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

לא לשנות את זמן המערכת

אי אפשר לשנות את זמן המערכת באמצעות קריאות המערכת adjtimex ו-adjtime, וגם לא באמצעות כלים שמאפשרים למאגר לעשות זאת.

הגבלות על תהליכים וקריאות מערכת

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

השימוש ב-eBPF ובאמצעי אבטחה אחרים ברמת הליבה (kernel) שלא מוגנים או מוגבלים על ידי מרחבי שמות של Linux מושבת, ואין תמיכה בשימוש בהם בתוך קונטיינרים.

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

ארגז חול של מאגרים

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

אם אתם משתמשים בסביבת ההפעלה מהדור השני, יש לכם תאימות מלאה ל-Linux. משימות ב-Cloud Run תמיד משתמשות בסביבת ההפעלה מהדור השני. בסביבת ההפעלה מהדור השני, הערך של /sys/class/dmi/id/product_name מוגדר ל-Google Compute Engine.

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

מגבלות על תיאורי קבצים

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

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

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

לדוגמה, המגבלות על מספר תיאורי הקבצים שאפשר לפתוח (כפי שמתועד ב-/proc/sys/fs/file-max) משתמשות בערך ברירת המחדל של כ-10% מהזיכרון. לפרטים נוספים, אפשר לעיין במאמרים file-max ו-file-nr במסמכי התיעוד של הליבה.

באופן דומה, הערך של max_map_count (כפי שמופיע ב-/proc/sys/vm/max_map_count), שמגדיר את מספר אזורי הזיכרון שיכולים להיות לתהליך, משתמש בברירת המחדל של 65535. פרטים נוספים זמינים במאמר max-map-count במסמכי התיעוד של הליבה.

מאגרי תגים מורשים וקובצי setuid בינאריים

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

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

לדוגמה, בקובץ Docker, מסירים את ההוראה USER, ובסקריפט של נקודת הכניסה משתמשים ברצף הבא:

gcsfuse ...                 # Run gcsfuse as root
su myuser -c "/yourapp.sh"  # Switch to 'myuser' and run 'yourapp.sh'

המשתמש שמפעיל את הפעולה

אם שם המשתמש לא קיים, Cloud Run מריץ את הקונטיינר בתור משתמש Root‏ (uid=0).

תקשורת בין קונטיינרים של אותו מכונה

‫Cloud Run מוסיף רשומה לקובץ /etc/hosts בכל קונטיינר. הרשומה הזו ממפה את שמות השירותים לכתובת ה-IP של המארח המקומי (127.0.0.1). כך הקונטיינרים יכולים לתקשר זה עם זה באמצעות שם הקונטיינר שלהם.

שרת מטא-נתונים של מכונה

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

כדי לגשת לנתונים של שרת המטא-נתונים, צריך לשלוח בקשות HTTP לנקודת הקצה http://metadata.google.internal/ עם הכותרת Metadata-Flavor: Google. לא נדרשות ספריות לקוח. מידע נוסף זמין במאמר קבלת מטא-נתונים.

בטבלה הבאה מפורטים חלק מהפרטים שזמינים בשרת המטא-נתונים:

נתיב	תיאור
/computeMetadata/v1/project/project-id	מזהה הפרויקט שהמשאב של Cloud Run שייך אליו.
/computeMetadata/v1/project/numeric-project-id	מספר הפרויקט שאליו שייך המשאב של Cloud Run.
/computeMetadata/v1/instance/region	האזור של המשאב הזה ב-Cloud Run, מחזיר את הערך projects/PROJECT-NUMBER/regions/REGION
/computeMetadata/v1/instance/id	המזהה הייחודי של המכונה (זמין גם ביומנים).
/computeMetadata/v1/instance/service-accounts/default/email	כתובת האימייל של זהות השירות של המשאב הזה ב-Cloud Run.
/computeMetadata/v1/instance/service-accounts/default/token	יוצרת אסימון גישה מסוג OAuth2 בשביל חשבון השירות של המשאב הזה ב-Cloud Run. סוכן השירות של Cloud Run משמש לאחזור אסימון. נקודת הקצה הזו תחזיר תגובת JSON עם מאפיין access_token. מידע נוסף על חילוץ טוקן הגישה הזה והשימוש בו.
/computeMetadata/v1/instance/network-interfaces/0/ip	כתובת IPv4 של מכונה של מאגר עובדים ברשת VPC.
/computeMetadata/v1/instance/network-interfaces/0/ipv6	כתובת IPv6 של מכונה במאגר עובדים. חשוב ליצור את המכונה ברשת משנה בשני פרוטוקולים.
/computeMetadata/v1/instance/network-interfaces/ /computeMetadata/v1/instance/network-interfaces/0/	נתיב הספרייה של ממשק הרשת למאגרי עובדים.

ב-Cloud Run לא מופיעים פרטים על Google Cloud האזור שבו המכונות פועלות. לכן, מאפיין המטא-נתונים /computeMetadata/v1/instance/zone תמיד מחזיר את הערך projects/PROJECT-NUMBER/zones/REGION-1.

שמות הקבצים

שמות הקבצים שבהם אתם משתמשים בקונטיינרים חייבים להיות תואמים ל-UTF-8, כלומר להיות בקידוד UTF-8 או בקידוד שאפשר להמיר באופן אוטומטי ובטוח ל-UTF-8. אם שמות הקבצים שלכם משתמשים בקידודים שונים, הפעילו את ה-build של Docker במכונה עם שמות קבצים שתואמים ל-UTF-8, והימנעו מהעתקת קבצים למאגר שמכיל שמות שלא תואמים ל-UTF-8.

פריסת הקונטיינר תיכשל אם שמות הקבצים לא תואמים ל-UTF-8. שימו לב שאין הגבלה על קידוד התווים שבו אתם משתמשים בקובץ.

זמנים קצובים לתפוגה של בקשות יוצאות

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

איפוסים של חיבורים יוצאים

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