ב-Knative serving, כל revision מותאם אוטומטית למספר מופעי הקונטיינר שנדרשים כדי לטפל בכל הבקשות הנכנסות. אם גרסה לא מקבלת תנועה, כברירת מחדל היא מותאמת לאפס מופעים של מאגרי תגים. עם זאת, אם רוצים, אפשר לשנות את ברירת המחדל הזו כדי לציין מופע שייישאר במצב בלי פעילות או במצב 'חם' באמצעות ההגדרה minimum instances (מופעים מינימליים).
מספר המופעים המתוזמנים מושפע מהגורמים הבאים:
- כמות המעבד שנדרשת לעיבוד בקשה
- הגדרת הבו-זמניות
- ההגדרה של מספר מופעי מאגר התגים המקסימלי
- ההגדרה של מספר מינימלי של מופעי קונטיינר
במקרים מסוימים, יכול להיות שתרצו להגביל את המספר הכולל של מופעי מאגר שאפשר להפעיל, מסיבות של בקרת עלויות או כדי לשפר את התאימות למשאבים אחרים שמשמשים את השירות שלכם. לדוגמה, יכול להיות ששירות Knative Serving שלכם יבצע אינטראקציה עם מסד נתונים שיכול לטפל רק במספר מסוים של חיבורים פתוחים בו-זמנית.
מידע על מספר מקסימלי של מופעי קונטיינר
אתם יכולים להשתמש בהגדרה 'מספר מקסימלי של מופעי קונטיינר' כדי להגביל את המספר הכולל של מופעים שאפשר להפעיל במקביל, כפי שמתואר במאמר הגדרת מספר מקסימלי של מופעי קונטיינר.
חריגה ממספר המכונות המקסימלי
בנסיבות רגילות, המערכת מרחיבה את הגרסה על ידי יצירת מופעים חדשים כדי לטפל בעומס התנועה הנכנסת. אבל כשמגדירים מגבלה על מספר המופעים, בתרחישים מסוימים לא יהיו מספיק מופעים כדי לעמוד בעומס התנועה הזה. במקרה כזה, הבקשות הנכנסות נכנסות לתור למשך עד 60 שניות. במהלך חלון הזמן של 60 שניות, אם מופע מסיים לעבד בקשות, הוא הופך לזמין לעיבוד בקשות שהוכנסו לתור. אם אף מופע לא יהיה זמין במהלך חלון הזמן של 60 שניות, הבקשה תיכשל ותוצג שגיאת קוד 429 ב-Cloud Run.
התחייבויות להרחבת היקף הפעילות
המגבלה המקסימלית של המופעים היא מגבלה עליונה. הגדרת מגבלה גבוהה לא אומרת שהגרסה תתרחב למספר המקרים של קונטיינרים שצוין. המשמעות היא שמספר המקרים של מאגרי תגים בכל נקודת זמן לא יכול לחרוג מהמגבלה.
עליות חדות בתנועת הגולשים
במקרים מסוימים, כמו עלייה מהירה בתנועה, יכול להיות שבמהלך תקופה קצרה, Knative Serving ייצור קצת יותר מופעים של קונטיינרים מהערך המקסימלי של המופעים שצוין. אם השירות שלכם לא יכול לסבול את ההתנהגות הזמנית הזו, כדאי להגדיר ערך נמוך יותר של מספר המופעים המקסימלי, כדי להשאיר מרווח ביטחון.
פריסות
כשפורסים גרסה חדשה, Knative serving מעביר בהדרגה את תעבורת הנתונים מהגרסה הישנה לגרסה החדשה. מכיוון שמגבלות על מספר המופעים מוגדרות לכל עדכון, יכול להיות שתהיה חריגה זמנית מהמגבלה שצוינה בתקופה שאחרי הפריסה.
מכונות במצב סרק וצמצום הפעלות במצב התחלתי (cold start)
משאבי Kubernetes נצרכים רק כשמופע מטפל בבקשה, אבל זה לא אומר ש-Knative Serving משבית באופן מיידי מופעים אחרי שהם טיפלו בכל הבקשות. כדי לצמצם את ההשפעה של הפעלות במצב התחלתי (cold start), יכול להיות ש-Knative serving ישמור חלק מהמכונות בלי פעילות. המופעים האלה מוכנים לטפל בבקשות במקרה של עלייה חדה בתעבורת הנתונים.
לדוגמה, כשמופע של מאגר סיים לטפל בבקשות, הוא עשוי להישאר בלי פעילות למשך זמן מסוים למקרה שיהיה צורך לטפל בבקשה נוספת. יכול להיות שמופעים של מאגרי תגים במצב לא פעיל ישמרו משאבים, כמו חיבורים פתוחים למסד נתונים. עם זאת, ב-Cloud Run, ה-CPU לא יהיה זמין
כדי שמכונות בלי פעילות יהיו זמינות לתמיד, משתמשים בהגדרה min-instance.
המאמרים הבאים
- כדי לנהל את המספר המקסימלי של מופעים של שירותי Knative serving, אפשר לעיין במאמר בנושא הגדרת מספר מקסימלי של מופעי קונטיינר.
- במאמר הגדרת מקביליות מוסבר איך לנהל את המספר המקסימלי של בקשות בו-זמניות שמטופלות על ידי כל מופע של מאגר תגים.
- כדי לבצע אופטימיזציה של הגדרת הבו-זמניות, אפשר לעיין בטיפים למפתחים בנושא התאמת הבו-זמניות.
- כדי לציין מופע לא פעיל שיוסיף לפעול כדי לצמצם את זמן האחזור או את ההפעלה הקרה בבקשות הראשונות, אפשר לעיין במאמר בנושא שימוש ב-
min-instanceכדי להפעיל מופעים לא פעילים.