תכנון הפרדה של עומסי עבודה

במסמך הזה מפורטת סקירה כללית על ניהול עומסי עבודה ב-Google Distributed Cloud (GDC) במודל Air-gapped. הנושאים שמוסברים במאמר הזה:

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

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

מידע נוסף מופיע במאמרי העזרה בנושא קהלים ב-GDC עם פער אבטחה.

איפה כדאי לפרוס עומסי עבודה

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

הפרדה של עומסי עבודה במישור הנתונים של הארגון.

עומסי עבודה שמבוססים על מכונות וירטואליות פועלים בתוך מכונה וירטואלית. לעומת זאת, עומסי עבודה של קונטיינרים פועלים באשכול Kubernetes. ההפרדה הבסיסית בין מכונות וירטואליות לבין אשכולות Kubernetes מספקת גבולות בידוד בין עומסי העבודה של המכונות הווירטואליות לבין עומסי העבודה של הקונטיינרים. מידע נוסף מופיע במאמר היררכיית המשאבים.

בקטעים הבאים מפורטים ההבדלים בין כל סוג של עומס עבודה ומחזור החיים של הפריסה שלו.

עומסי עבודה שמבוססים על מכונות וירטואליות

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

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

עומסי עבודה מבוססי קונטיינרים

אפשר לפרוס עומסי עבודה מבוססי-קונטיינר לפוד באשכול Kubernetes. קלאסטר Kubernetes מורכב מסוגי הצמתים הבאים:

  • צומת של רמת הבקרה: מריץ את שירותי הניהול, כמו תזמון, etcd ושרת API.

  • צומת עובד: מריץ את ה-Pod-ים ואת אפליקציות הקונטיינרים.

ארכיטקטורת אשכול Kubernetes

יש שני סוגי הגדרות לאשכולות Kubernetes:

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

מידע נוסף זמין במאמר בנושא הגדרות של אשכול Kubernetes.

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

לצורך תזמון של פודים באשכול Kubernetes,‏ GDC משתמש במושגים הכלליים של Kubernetes בנושא תזמון, קדימות ופינוי. השיטות המומלצות לתזמון פודים באשכול משתנות בהתאם לדרישות של עומס העבודה.

מידע נוסף על אשכולות Kubernetes זמין במאמר סקירה כללית של אשכול Kubernetes. מידע נוסף על ניהול קונטיינרים באשכול Kubernetes זמין במאמר עומסי עבודה של קונטיינרים ב-GDC.

שיטות מומלצות לתכנון אשכולות Kubernetes

בקטע הזה מפורטות שיטות מומלצות לתכנון אשכולות Kubernetes:

כדאי לעיין בכל שיטה מומלצת כדי לתכנן עיצוב אמין של אשכול למחזור החיים של עומס העבודה של הקונטיינר.

יצירת אשכולות נפרדים לכל סביבת פיתוח תוכנה

בנוסף לפרויקטים נפרדים לכל סביבת פיתוח תוכנה, מומלץ לתכנן אשכולות Kubernetes נפרדים לכל סביבת פיתוח תוכנה. סביבת פיתוח תוכנה היא אזור ב-GDC Universe שמיועד לכל הפעולות שמתאימות לשלב מסוים במחזור החיים. לדוגמה, אם יש לכם בארגון שלוש סביבות פיתוח תוכנה בשמות development,‏ staging ו-production, תוכלו ליצור קבוצה נפרדת של אשכולות Kubernetes לכל סביבה ולצרף פרויקטים לכל אשכול בהתאם לצרכים שלכם.

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

הגדרת אשכולות סטנדרטיים לכל סביבת פיתוח תוכנה מניחה שעומסי עבודה לפני הייצור בסביבת פיתוח תוכנה מוגבלים לאשכול הזה. אפשר לחלק אשכול Kubernetes לכמה מאגרי צמתים או להשתמש ב-taints לבידוד עומסי עבודה.

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

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

הגדרת אשכול GDC שמשתרעת על כמה סביבות פיתוח תוכנה.

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

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

  • יש לכם כמה עומסי עבודה שמוצמדים לגרסה ספציפית של Kubernetes, ולכן אתם מתחזקים אשכולות שונים בגרסאות שונות.
  • יש לכם עומסי עבודה מסוימים שדורשים הגדרות שונות של אשכולות, כמו מדיניות גיבוי, ולכן אתם יוצרים כמה אשכולות עם הגדרות שונות.
  • מריצים עותקים של אשכול במקביל כדי לאפשר שדרוגים משבשים של גרסאות או אסטרטגיית פריסת כחול-ירוק (blue-green deployment).
  • אתם יוצרים עומס עבודה ניסיוני שעלול לגרום להגבלת קצב הבקשות בשרת ה-API או לנקודות כשל אחרות באשכול, ולכן אתם מבודדים אותו מעומסי עבודה קיימים.

אתם צריכים להתאים את סביבות פיתוח התוכנה לדרישות שנקבעו על ידי פעולות הקונטיינרים.

יצירת פחות אשכולות

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

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

אם נפח האחסון של אשכול מתקרב למקסימום, מומלץ להוסיף צמתים לאשכול במקום ליצור אשכול חדש.

יצירת פחות מאגרי צמתים באשכול

כדי להשתמש במשאבים בצורה יעילה, מומלץ לתכנן פחות מאגרי צמתים גדולים יותר באשכול Kubernetes.

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

המאמרים הבאים