אפשר להשתמש ב-Knative serving כדי לנהל באופן אוטומטי את התשתית שנדרשת לאירוח תוכנה ב-Google Kubernetes Engine (GKE). כדי לנהל את האפליקציות, Knative serving משתמש במבנה ארגוני שנקרא מודל משאבים. מודל המשאבים הזה מורכב משלושה חלקים עיקריים: שירותים, עדכונים ומופעי קונטיינר.
בתרשים הבא מוצגים הרכיבים האלה והאינטראקציות ביניהם: פרויקט Google Cloud מכיל שני שירותים של Knative Serving, שירות א' ושירות ב', שלכל אחד מהם יש כמה עדכונים. שירות א' מעבד בקשות עם כמה מופעים של קונטיינרים שפועלים, ושירות ב' לא פעיל.
שירותים של מילוי בקשות מסוג Knative
השירות הוא המשאב העיקרי של Knative serving. כל שירות ממוקם במרחב שמות ספציפי של אשכול GKE.
פרויקט Google Cloud נתון יכול להריץ שירותים רבים באזורים שונים או באשכולות GKE שונים.
כל שירות חושף נקודת קצה ייחודית ומשנה את התשתית הבסיסית באופן אוטומטי כדי לטפל בבקשות נכנסות.
גרסאות של מילוי בקשות מסוג Knative
כל פריסה לשירות יוצרת גרסה. גרסה כוללת קובץ אימג' של קונטיינר ספציפי, יחד עם הגדרות סביבה כמו משתני סביבה, מגבלות זיכרון או ערך בו-זמניות (concurrency).
אי אפשר לשנות גרסאות: אחרי שיוצרים גרסה, אי אפשר לשנות אותה. לדוגמה, כשפורסים קובץ אימג' של קונטיינר לשירות חדש של Knative Serving, נוצרת הגרסה הראשונה. אם לאחר מכן פורסים קובץ אימג' אחר של קונטיינר לאותו שירות, נוצרת גרסה שנייה. אם לאחר מכן מגדירים משתנה סביבה, נוצרת גרסה שלישית. כל שינוי בהגדרות יוצר גרסה חדשה.
הבקשות מנותבות אוטומטית בהקדם האפשרי לגרסה האחרונה של השירות שפועלת בצורה תקינה. אפשר לפצל את תנועת הגולשים בין גרסאות שונות לפי הצורך.
Knative serving container instances
כל גרסה שמקבלת בקשות עוברת התאמה אוטומטית לעומס, למספר מופעי הקונטיינר שנדרשים כדי לטפל בכל הבקשות האלה. שימו לב שמופע של מאגר תגים יכול לקבל הרבה בקשות בו-זמנית. הגדרת הבו-זמניות מאפשרת להגדיר את המספר המקסימלי של בקשות שאפשר לשלוח במקביל למופע נתון של מאגר תגים.