סקירה כללית על הארכיטקטורה של Knative serving

בדף הזה יש סקירה כללית של הארכיטקטורה של Knative serving, ומוסבר בו על השינויים שמתרחשים כשמפעילים את Knative serving באשכול Google Kubernetes Engine.

המידע הזה שימושי עבור סוגי המשתמשים הבאים:

• משתמשים שמתחילים להשתמש במילוי בקשות מסוג Knative.
• אופרטורים עם ניסיון בהפעלת אשכולות GKE.
• מפתחי אפליקציות שרוצים לדעת איך Knative Serving משתלב עם אשכולות Kubernetes כדי לתכנן אפליקציות טובות יותר או להגדיר את אפליקציית Knative Serving שלהם.

רכיבים בהתקנת ברירת המחדל

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

ב-Knative serving נעשה שימוש ב-Cloud Service Mesh כדי לנתב את התעבורה. כברירת מחדל, Cloud Service Mesh מתקין רכיבים במרחב השמות istio-system.

בהמשך מפורטים הרכיבים שמוגדרים על ידי Knative serving ו-Cloud Service Mesh:

• רכיבים שמוגדרים על ידי Knative serving במרחב השמות knative-serving:

  • Activator: כשמבצעים הקטנת קנה מידה של pods לאפס או כשמתקבלות יותר מדי בקשות לגרסה, Activator מכניס את הבקשות לתור באופן זמני ושולח מדדים ל-Autoscaler כדי להתחיל הרצה של עוד pods. אחרי שהמידרוג האוטומטי משנה את גודל הגרסה בהתאם למדדים המדווחים ול-Pod-ים הזמינים, רכיב ההפעלה מעביר את הבקשות שבהמתנה לגרסה. ה-Activator הוא רכיב של מישור הנתונים. רכיבים של מישור הנתונים מנהלים את כל הפונקציות והתהליכים של העברת תעבורת משתמשים.
  • Autoscaler: מצטבר ומעבד מדדים מ-Activator ומ-queue proxy sidecar container, רכיב במישור הנתונים שמחיל מגבלות על מספר הבקשות בו-זמנית. לאחר מכן, מידרוג אוטומטי מחשב את הבו-זמניות שנצפתה בגרסה ומשנה את גודל ה-Deployment בהתאם למספר ה-Pod-ים הרצוי. כשפודים זמינים בגרסה, Autoscaler הוא רכיב של מישור הבקרה. אחרת, כשפודים מוקטנים לאפס, Autoscaler הוא רכיב של מישור הנתונים.
  • Controller: יוצר ומעדכן את משאבי הצאצא של Autoscaler ואת אובייקטים של Service. ה-Controller הוא רכיב של מישור הבקרה. רכיבי מישור הבקרה מנהלים את כל הפונקציות והתהליכים שקובעים את נתיב הבקשה של תנועת המשתמשים.
  • Metrics Collector: אוסף מדדים מרכיבי Knative serving ואז מעביר אותם ל-Cloud Monitoring.
  • ‫Webhook: מגדיר ערכי ברירת מחדל, דוחה אובייקטים לא עקביים ולא תקינים, ומאמת ומשנה קריאות ל-Kubernetes API ביחס למשאבי Knative serving. ‫Webhook הוא רכיב של מישור הבקרה.

• רכיבים שמותקנים על ידי Cloud Service Mesh שפועל במרחב השמות istio-system:

  • שער מקומי לאשכול: מאזן עומסים במישור הנתונים שאחראי לטיפול בתעבורה פנימית שמגיעה משירות אחד של Knative Serving לשירות אחר. אפשר לגשת ל-Cluster Local Gateway רק מתוך אשכול GKE, והוא לא רושם דומיין חיצוני כדי למנוע חשיפה מקרית של מידע פרטי או תהליכים פנימיים.
  • ‫Istio Ingress Gateway: מאזן עומסים במישור הנתונים שאחראי לקבלת תעבורה נכנסת מחוץ לאשכול ולטיפול בה, כולל תעבורה מרשתות חיצוניות או פנימיות.
  • ‫Istiod: מגדיר את Cluster Local Gateway ואת Istio Ingress Gateway לטיפול בבקשות HTTP בנקודות הקצה הנכונות. ‫Istiod הוא רכיב של מישור הבקרה. מידע נוסף זמין במאמר בנושא Istiod.

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

שימוש במשאבים באשכול

ההתקנה הראשונית של Knative serving דורשת בערך 1.5 מעבדים וירטואליים ו-1GB של זיכרון לאשכול. מספר הצמתים באשכול לא משפיע על דרישות המקום והזיכרון להתקנה של Knative serving.

כל רכיב Activator יכול לצרוך בקשות עד 1,000 מילי-CPU ו-600MiB RAM. אם מפעיל קיים לא יכול לתמוך במספר הבקשות הנכנסות, מופעל מפעיל נוסף שדורש הקצאה של 300 מילי-CPU ו-60MB של RAM.

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

יצירת שירות

ארכיטקטורת שירות של Knative serving (לחצו כדי להגדיל)

‫Knative serving מרחיב את Kubernetes על ידי הגדרה של קבוצה של הגדרות משאבים בהתאמה אישית (CRD):‏ Service,‏ Revision,‏ Configuration ו-Route. ה-CRD האלה מגדירים ושולטים באופן הפעולה של האפליקציות באשכול:

• ‫Knative serving Service הוא משאב מותאם אישית ברמה העליונה שמוגדר על ידי Knative serving. זו אפליקציה אחת שמנהלת את כל מחזור החיים של עומס העבודה. השירות שלכם מוודא שלכל עדכון של השירות יש מסלול, הגדרה וגרסה חדשה.
• עדכון הוא תמונת מצב של הקוד וההגדרות בנקודת זמן מסוימת, שלא ניתן לשנות אותה.
• ההגדרה שומרת את ההגדרות הנוכחיות של הגרסה האחרונה שלכם ומתעדת את ההיסטוריה של כל הגרסאות הקודמות. שינוי של הגדרה יוצר גרסה חדשה.
• Route מגדיר נקודת קצה של HTTP ומקשר את נקודת הקצה לגרסה אחת או יותר שאליהן מועברות הבקשות.

כשמשתמש יוצר שירות Knative serving, מתרחשים הדברים הבאים:

1. אובייקט השירות של Knative serving מגדיר:

   1. הגדרה של אופן הצגת השינויים.
   2. גרסה שלא ניתן לשנות של הגרסה הזו של השירות.
   3. נתיב לניהול הקצאת תנועה ספציפית לגרסה.

2. אובייקט המסלול יוצר VirtualService. אובייקט VirtualService מגדיר את Ingress Gateway ואת Cluster Local Gateway לניתוב תנועת שער לגרסה הנכונה.

3. אובייקט הגרסה יוצר את רכיבי מישור הבקרה הבאים: אובייקט Kubernetes Service ואובייקט Deployment.

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

טיפול בבקשות

בתרשים הבא מוצגת סקירה כללית של נתיב בקשה אפשרי לתעבורת משתמשים דרך רכיבי מישור הנתונים של Knative Serving באשכול לדוגמה של Google Kubernetes Engine:

ארכיטקטורת אשכול של Knative serving (לחצו כדי להגדיל)

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

נתיב הבקשה של Knative serving (לחצו כדי להגדיל)

לנתיב בקשה של Knative serving:

1. התנועה מגיעה דרך:

   • שער Ingress לתנועה מחוץ לאשכולות
   • שער מקומי של אשכול לתנועה בתוך אשכולות

2. רכיב VirtualService, שמציין כללי ניתוב תנועה, מגדיר את השערים כך שתנועת המשתמשים תנותב לגרסה הנכונה.

3. שירות Kubernetes, רכיב של מישור הבקרה, קובע את השלב הבא בנתיב הבקשה בהתאם לזמינות של קבוצות ה-Pod לטיפול בתעבורה:

   • אם אין תרמילים בגרסה:

     1. ה-Activator מעביר באופן זמני את הבקשה שהתקבלה לתור ודוחף מדד למידרוג אוטומטי כדי להרחיב עוד Podים.
     2. המידרוג האוטומטי משנה את גודל הפודים בהתאם למצב הרצוי ב-Deployment.
     3. הפריסה יוצרת עוד פודים כדי לקבל בקשות נוספות.
     4. ה-Activator מנסה שוב לשלוח בקשות ל-sidecar של שרת ה-proxy של התור.

   • אם השירות מורחב (קבוצות Pod זמינות), שירות Kubernetes שולח את הבקשה ל-sidecar של פרוקסי התור.

4. ה-sidecar של תור הבקשות אוכף פרמטרים של תור הבקשות, בקשות עם שרשור יחיד או מרובה, שהקונטיינר יכול לטפל בהן בכל פעם.

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

6. ה-sidecar של פרוקסי התור שולח תנועה למאגר המשתמשים.