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

בידוד עומסי עבודה ב-Google Distributed Cloud (GDC)‎ עם air gap מאפשר להפריד בין אפליקציות של קונטיינרים ומכונות וירטואליות (VM) בפרויקטים ובאשכולות של Kubernetes. תכנון גבולות הסביבה עוזר לכם לשלוט במדיניות הגישה, להכיל את ההשפעה של התחזוקה ולשפר את קיבולת הצמתים. אתם יכולים להתאים את דפוסי הארכיטקטורה האלה לדרישות הספציפיות של כל סביבת GDC.

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

איפה פורסים את עומסי העבודה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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