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

בדף הזה מפורטות הדרישות העיקריות וההתנהגויות של קונטיינרים ב-Knative serving.

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

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

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

האזנה לבקשות ביציאה הנכונה

הקונטיינר צריך להאזין לבקשות בכתובת 0.0.0.0 ביציאה שאליה נשלחות הבקשות. כברירת מחדל, הבקשות נשלחות אל 8080, אבל אפשר להגדיר את Knative serving כך שהבקשות יישלחו אל היציאה שתבחרו.

בתוך מופעי קונטיינר של Knative serving, הערך של משתנה הסביבה PORT תמיד משקף את היציאה שאליה נשלחות הבקשות. ברירת המחדל היא 8080.

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

מאגר התגים לא אמור להטמיע אבטחה בשכבת התעבורה באופן ישיר. ה-TLS מסתיים ב-Knative serving עבור HTTPS ו-gRPC, ואז הבקשות מועברות כ-HTTP או כ-gRPC אל הקונטיינר ללא TLS.

תשובות

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

משתני סביבה

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

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

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

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

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

מחזור החיים של מופע קונטיינר

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

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

הפעלה

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

החישוב מתבצע בהיקף של בקשה

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

כיבוי

אפשר לכבות מופע של מאגר בכל שלב.

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

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

משאבים של מופע קונטיינר

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

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

לדוגמה, אם הקציתם 512MiB של זיכרון לקונטיינר, והקונטיינר הזה פועל ב-Pod היחיד בצומת עם 8GiB של זיכרון, אז הקונטיינר הזה יכול לנסות להשתמש ביותר זיכרון RAM.

CPU

כברירת מחדל, ה-sidecar של פרוקסי התור שומר 25 אלפיות של ליבת CPU, ואין הגבלה על כמות ה-vCPU ששירותי Knative serving יכולים להשתמש בהן. השימוש במשאבים של ה-proxy של התור תלוי במספר הבקשות שמוכנסות לתור ובגודל הבקשות.

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

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

זיכרון

כברירת מחדל, ה-queue proxy sidecar לא שומר זיכרון, ואין הגבלה על כמות הזיכרון ששירותי Knative serving יכולים להשתמש בה. אם רוצים, אפשר להגדיר מגבלות זיכרון לשירותי Knative Serving. מידע נוסף על האופן שבו GKE מטפל בזיכרון זמין במאמר משאבי זיכרון ומעבד (CPU) שניתנים להקצאה.

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

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

בו-זמניות

כברירת מחדל, כל מופע של מאגר תגים ב-Knative Serving מוגדר למקביליות מרובה, כך שכל מופע של מאגר תגים יכול לקבל יותר מבקשה אחת בו-זמנית. אפשר לשנות את זה על ידי הגדרת מקביליות.

ארגז חול של מופע מארח

‫Knative serving לא משתמש ב-container sandbox.

שרת מטא-נתונים של מופע מאגר תגים

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

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

בטבלה הבאה מפורט מידע על שרת המטא-נתונים שזמין:

נתיב	תיאור
/computeMetadata/v1/project/project-id	מזהה הפרויקט של שירות Knative Serving הזה
/computeMetadata/v1/instance/region	האזור של שירות מילוי הבקשות מסוג Knative
/computeMetadata/v1/instance/id	מזהה ייחודי של מופע מאגר התגים (זמין גם ביומנים).
/computeMetadata/v1/instance/service-accounts/default/token	יצירת אסימון לחשבון השירות של זמן הריצה של שירות Knative serving הזה