Google Kubernetes Engine (GKE) מספק כמה אסטרטגיות שיעזרו לכם לצמצם את זמן האחזור של הפעלת Pod כשעומסי העבודה גדלים. הפחתת העיכובים בהקצאת צמתים, בשליפת קובצי אימג' של קונטיינרים ובאתחול אפליקציות יכולה לעזור לשפר את מהירות התגובה של השירות במהלך עליות חדות בתנועה ולאזן את עלויות התשתית.
תוכלו להיעזר במסמך הזה כדי להשוות בין אסטרטגיות להפחתת זמן האחזור של הפעלת GKE לאורך מחזור החיים של הפעלת ה-Pod, ולבחור אסטרטגיה אחת או שילוב של כמה אסטרטגיות שמתאימות לדרישות של עומס העבודה שלכם.
הסבר על מחזור החיים של הפעלת Pod
כשעומס עבודה עובר התאמה ב-GKE ולצמתים הקיימים אין מספיק קיבולת להקצאה עבור ה-Pods החדשים, זמן האחזור של ההפעלה מקצה לקצה מתפרס על פני שלושה שלבים רציפים:
- במהלך הקצאת הצומת ותזמון ה-Pod, הכלי לשינוי גודל האשכול מקצה מכונה וירטואלית חדשה ב-Compute Engine, מאתחל את הצומת ורושם אותו במישור הבקרה, כדי שהמתזמן של Kubernetes יוכל למקם את ה-Pod בהמתנה.
- בשלב של משיכת קובץ האימג' של הקונטיינר, הרכיב
kubeletבצומת מוריד ופורק את קובצי האימג' של הקונטיינר שנדרשים ל-Pod מ-Container Registry. - בשלב האתחול של האפליקציה, סביבת זמן הריצה של הקונטיינר מפעילה את תהליך האפליקציה, טוענת יחסי תלות או משקלי מודלים לזיכרון, ומעבירה בדיקות הפעלה ומוכנות של Kubernetes.
תכונות שונות של GKE מיועדות לשלבים ספציפיים במחזור החיים הזה. כדי לגלות איזה שלב תורם הכי הרבה לזמן ההפעלה של עומס העבודה, עיינו במאמר מעקב אחרי מדדי זמן האחזור של ההפעלה.
השוואה בין אסטרטגיות להפחתת זמן האחזור בהפעלה
בטבלה הבאה מוצגות השוואה בין אסטרטגיות להפחתת זמן האחזור של הפעלת GKE לאורך מחזור החיים של הפעלת ה-Pod:
| האסטרטגיה | שלב במחזור החיים | פרופיל זמן אחזור | פרופיל עלות ומכסות | מצב אשכול ותמיכה בחומרה | מתאים במיוחד בשביל |
|---|---|---|---|---|---|
| מאגרי קיבולת פעילים (תצוגה מקדימה) | הקצאת צמתים ותזמון של Pod | תזמון מיידי של ה-Pod כי הצמתים כבר פועלים. |
תעריפי מחשוב רגילים מבוססי-צמתים להרצת מכונות וירטואליות. צורך מכסות של vCPU, זיכרון, דיסק וכתובת IP ב-Compute Engine, וגם מכסות של משאבים ב-Kubernetes במרחב השמות. |
אשכולות רגילים ואשכולות במצב Autopilot עם ComputeClasses מותאמים אישית (חיוב לפי צומת). תמיכה במעבדי CPU, מעבדי GPU ומעבדי TPU. |
ספיגה של פרצי תנועה פתאומיים והרחבה של עומסי עבודה (workloads) של GPU, TPU או CPU שרגישים לזמן האחזור. |
| מאגרי קיבולת במצב המתנה (גרסת טרום-השקה) | הקצאת צמתים ותזמון של Pod | הפעולה מחזירה את הצמתים המושעים לפעולה תוך כ-30 עד 35 שניות, שזה מהר יותר מהקצאת צומת חדש. |
לא יחולו חיובים על מחשוב של מכונות וירטואליות בזמן ההשעיה. חיובים על אחסון ב-Persistent Disk לדיסקים של אתחול ולמצב הזיכרון המאוחסן. בזמן ההשעיה, המשאבים מנצלים את מכסות הדיסקים וכתובות ה-IP, וגם את מכסות המשאבים של Kubernetes במרחב השמות. |
אשכולות רגילים (עם הקצאת צמתים אוטומטית) ואשכולות במצב Autopilot עם ComputeClasses בהתאמה אישית. תמיכה במעבדים (CPU) בלבד (לא ב-GPU, ב-TPU או ב-SSD מקומי). |
שמירה על יכולת התפרצות חסכונית לצורך גידול מתמשך בתנועה. |
| צמתים שמופעלים במהירות | הקצאת צמתים ותזמון של Pod | מקצר את זמן ההפעלה של צומת קר על בסיס המאמץ המרבי, באמצעות חומרה שעברה אתחול מראש. | האפשרות מסופקת ללא עלות נוספת. |
אשכולות במצב Autopilot ועומסי עבודה במצב Autopilot באשכולות במצב Standard. תמיכה בסדרות מכונות לשימוש כללי וסדרות מכונות GPU שעומדות בדרישות, בלי כונני SSD מקומיים או VM במודל Spot. |
האצת הקצאת צומת בסיסית ללא עלות של הגדרה או קיבולת לא פעילה. |
| פודים של פלייסהולדרים בעדיפות נמוכה | הקצאת צמתים ותזמון של Pod | תזמון Pod מיידי אחרי פינוי Pods של פלייסהולדרים בעדיפות נמוכה יותר. |
תעריפי המחשוב הרגילים להפעלת צמתים. נדרש פריסה ידנית וניהול של PriorityClass. |
אשכולות רגילים ואשכולות במצב Autopilot. | שמירת קיבולת פנויה באשכולות שמשתמשים בחיוב מבוסס-Pod או בגרסאות קודמות ל-1.35. |
| סטרימינג של תמונות | משיכת קובץ אימג' של קונטיינר | מאפשרת לקונטיינרים להתחיל לפעול בלי לחכות להורדה של כל קובץ האימג'. |
השירות ניתן ללא תשלום נוסף. נדרש Artifact Registry או מאגרי Docker Hub שעומדים בדרישות. |
אשכולות במצב Autopilot (מופעל כברירת מחדל) ובמצב Standard. | קיצור זמני השליפה של קובצי אימג' גדולים של קונטיינרים. |
| דיסקי אתחול משניים | משיכת קובץ אימג' של קונטיינר | מצרף דיסק אחסון מתמיד (persistent disk) שאוכלס מראש לצמתים חדשים במקביל לאספקת הצמתים. | חיוב על ה-Persistent Disk המצורף בכל צומת ועל אחסון קובץ האימג'. | אשכולות רגילים ואשכולות במצב Autopilot. | טעינה מראש של תמונות גדולות של קונטיינרים או של מערכי נתונים סטטיים, כמו משקלים של מודלים של למידת מכונה. |
| תמונות מצב של פודים | אתחול האפליקציה | משחזר עותקים חדשים של Pod ישירות מנקודת ביקורת שמורה של זיכרון התהליך ומצב מערכת הקבצים. | חיוב על אחסון של תמונת מצב ב-Cloud Storage. |
אשכולות Standard ו-Autopilot שבהם פועלים Pods ב-GKE Sandbox. תמיכה בסוגי מכונות מתאימים של מעבדי CPU ו-GPU (ללא מעבדי TPU). |
מעקף של תהליך האתחול הארוך של מודלי היסק (inference) של AI ואפליקציות עם שגרות הפעלה כבדות. |
| האצת המעבד בזמן אתחול (תצוגה מקדימה) | אתחול האפליקציה | מגדילה באופן זמני את הבקשות והמגבלות של המעבד (CPU) במהלך הפעלת Pod, ואז משנה את הגודל שלהן במקום. | צריכה זמנית של קיבולת נוספת של מעבד הצומת במהלך חלון ההפעלה. | אשכולות Standard ו-Autopilot עם התאמה אנכית של קבוצות Pod לעומס. | האצת אתחול שקשור למעבד (CPU) בסביבות זמן ריצה כמו Java, Python או Node.js. |
בחירת אסטרטגיה לפי שלב ההפעלה של ה-Pod
בקטעים הבאים מפורטות האפשרויות הזמינות בכל שלב במחזור החיים של הפעלת ה-Pod.
האצת הקצאת הצמתים ותזמון ה-Pods
כשאי אפשר להתאים Pods בהמתנה לצמתים קיימים, ההמתנה להפעלה של צומת חדש היא בדרך כלל הגורם העיקרי לעיכוב בהרחבה. כדי לקצר את משך העיכוב הזה או לבטל אותו, אפשר להשתמש בשיטות הבאות:
- כדי להצהיר על הקצאת קיבולת עודפת של צמתים, משתמשים במאגרי קיבולת:
- מגדירים מאגר פעיל (אסטרטגיה
buffer.x-k8s.io/active-capacity) כדי לשמור על הפעלת הצמתים שהוקצו מראש ועל מוכנותם לתזמון של Pods באופן מיידי. מאגרים פעילים תומכים בעומסי עבודה של CPU, GPU ו-TPU. - הגדרת מאגר המתנה (אסטרטגיית
buffer.gke.io/standby-capacity) כדי לשמור על צומתי מעבד (CPU) שהוקצו מראש במצב מושהה. כשעומסי העבודה גדלים, GKE מפעיל מחדש את הצמתים במצב המתנה תוך כ-30 עד 35 שניות, וכך נמנעת העלות המלאה של מחשוב מכונות וירטואליות במצב סרק.
- מגדירים מאגר פעיל (אסטרטגיה
- להסתמך על צמתים שמופעלים במהירות כדי לבצע אתחול מראש של חומרה באופן אוטומטי, ככל האפשר, בעומסי עבודה מתאימים של Autopilot ובסדרות של מכונות GPU. כש-GKE מקצה צמתים חדשים לעומס עבודה שעומד בדרישות, הוא משתמש אוטומטית בצמתים עם הפעלה מהירה. זה כולל צמתים שנוצרו כדי למלא מאגר קיבולת ב-ComputeClass מותאם אישית תואם של Autopilot.
- אם עומסי העבודה שלכם משתמשים במודל התמחור מבוסס-ה-Pod של Autopilot או פועלים בגרסאות GKE מוקדמות יותר מגרסה 1.35, תוכלו לפרוס Pods של placeholder בעדיפות נמוכה באמצעות PriorityClasses של Kubernetes. באשכולות שבהם נעשה שימוש בחיוב מבוסס-צמתים בגרסאות נתמכות של GKE, מומלץ להשתמש במאגרי קיבולת הצהרתית כי הם לא דורשים ניהול של פריסות placeholder או של לולאות פינוי של Pod.
האצה של שליפת קובצי אימג' של קונטיינרים
אחרי שהמתזמן ממקם Pod בצומת, הצומת צריך למשוך את תמונת הקונטיינר לפני הפעלת הקונטיינר. כדי לצמצם את זמן האחזור של שליפת תמונות, אפשר להשתמש באסטרטגיות הבאות:
- מפעילים את האפשרות סטרימינג של קובצי אימג' כדי לאפשר לקונטיינרים להתחיל לפעול ברגע שהקבצים הנדרשים מועברים בסטרימינג ברשת, בזמן ששאר קובץ האימג' יורד ברקע. באשכולות Autopilot, סטרימינג של תמונות מופעל כברירת מחדל לתמונות שעומדות בדרישות ב-Artifact Registry.
- אפשר להגדיר דיסקי אתחול משניים כדי לטעון מראש שכבות בסיס גדולות של קונטיינרים או מערכי נתונים סטטיים על קובץ אימג' בהתאמה אישית. כש-GKE יוצר צומת, הוא מצרף Persistent Disk שנוצר ממופע של קובץ אימג' של הדיסק במקביל להקצאת הצומת.
- מריצים DaemonSet כדי לטעון מראש קובצי אימג' של קונטיינרים במאגרי המתנה במהלך חלון האתחול של הצומת (הערה
buffer.gke.io/standby-capacity-init-time). לפני ש-GKE משעה צומת במצב המתנה, ה-DaemonSet שולף את קובצי האימג' של עומס העבודה לדיסק האתחול של הצומת, כדי שהם כבר יהיו במטמון כשהצומת יופעל מחדש.
האצת האתחול של האפליקציה
גם אחרי שהצומת פועל וקובץ אימג' של קונטיינר קיימת, יכול לעבור זמן רב עד שהאפליקציות יטענו את ה-frameworks, יקמפלו קוד בזמן ריצה (JIT) או יטענו משקלים של מודלים לזיכרון. כדי לקצר את זמן ההפעלה, אפשר להשתמש בשיטות הבאות:
- הגדרת תמונות מצב של Pod כדי לתעד נקודת ביקורת של מצב הזיכרון ומערכת הקבצים של Pod שפועל ב-GKE Sandbox. כשעומס העבודה מתרחב אופקית, GKE משחזר רפליקות חדשות מהתמונה המצב ב-Cloud Storage, כך שה-Pod ממשיך את ההרצה מהנקודה שבה צולמה תמונת המצב, במקום לאתחל ממצב חדש.
- מגדירים האצת המעבד בזמן אתחול ב-VerticalPodAutoscaler כדי להקצות מעבד נוסף ל-Pod במהלך ההרשאה והאתחול. אחרי שה-Pod מגיע לסטטוס
Readyומשך ההגברה שהוגדר מסתיים, GKE מצמצם את בקשת ה-CPU של ה-Pod בחזרה לרמת הבסיס שלו במקום, בלי להפעיל מחדש את הקונטיינר.
שילוב של אסטרטגיות לאופטימיזציה מקצה לקצה
האסטרטגיות האלה פועלות בשלבים שונים במחזור החיים של הפעלת ה-Pod, ולכן אפשר לשלב אותן כדי לבצע אופטימיזציה של זמן ההרחבה מקצה לקצה:
- לשלב מאגר קטן של קיבולת פעילה עם מאגר גדול יותר של קיבולת במצב המתנה. במהלך עלייה פתאומית בתנועה, המאגר הפעיל סופג מיד את העלייה הראשונית ב-Pods. בינתיים, GKE מחדש את הצמתים ממאגר ההמתנה תוך כ-30 עד 35 שניות כדי למלא את המאגר הפעיל ולטפל בצמיחה המתמשכת. ברקע, מנגנון המידרוג האוטומטי של האשכול מקצה ומשהה צמתים חדשים כדי למלא מחדש את מאגר ההמתנה.
- כדי להכין מאגרי קיבולת למצב המתנה, צריך להפעיל Image streaming או טעינה מראש של קובצי אימג' של קונטיינרים באמצעות DaemonSet לפני שהצומת מושעה, כדי שהצומת לא יבזבז זמן על הורדה של קובצי אימג' גדולים של קונטיינרים כשהוא יחזור לפעולה.
- אפשר להשתמש ב-CPU startup boost או בתמונות מצב של Pod על גבי מאגרי קיבולת או צמתים עם הפעלה מהירה, כך שאחרי ש-GKE מתזמן Pod בצומת שהוקצה מראש או שאותחל מראש, ה-Pod לא עובר ויסות של ה-CPU במהלך ההפעלה או משוחזר ישירות מתמונת מצב שנשמרה.
כדי למדוד את ההשפעה של כל אסטרטגיה בנפרד או של שילוב של אסטרטגיות על עומסי העבודה, אפשר לעיין בתרשימים Pod Startup Latency Distribution ו-Pod First Ready Latency ב-Cloud Monitoring ולבדוק את יומני השהיות של התזמון ב-Cloud Logging. הוראות מפורטות מופיעות במאמר בנושא מעקב אחרי מדדי חביון של הפעלה.