במסמך הזה מוסברות שיטות מומלצות לתכנון ההיררכיה וההפרדה של עומסי עבודה ב-Google Distributed Cloud (GDC) עם בידוד פיזי באמצעות ארגונים, פרויקטים ואשכולות Kubernetes. ההנחיות האלה מאזנות בין שימוש יעיל במשאבים, בידוד של עומסי עבודה וקלות הפעולות.
תכנון ארגונים לבידוד פיזי ולוגי בין לקוחות
המשאב Organization הוא הבסיס לכל המשאבים שבבעלות לקוח יחיד. אפשר להגדיר בקרת גישה מפורטת בין עומסי עבודה בארגון באמצעות קישורי תפקידים ומדיניות רשת. מידע נוסף זמין במאמר בנושא ניהול זהויות והרשאות גישה.
כל ארגון באזור GDC מספק בידוד פיזי לתשתית המחשוב, ובידוד לוגי לרשתות, לאחסון ולשירותים אחרים. למשתמשים בארגון אחד אין גישה למשאבים בארגון אחר, אלא אם הוענקה להם גישה מפורשת. כברירת מחדל, לא ניתן להתחבר לרשת מארגון אחד לארגון אחר, אלא אם הוגדר במפורש לאפשר העברת נתונים מארגון אחד והעברת נתונים לארגון אחר.
הגדרת ההיקף של עומסי עבודה שיכולים לשתף ארגון
ההיקף של ארגון בהקשר של החברה שלכם עשוי להשתנות בהתאם לאופן שבו החברה מגדירה את גבולות האמון. חלק מהחברות מעדיפות ליצור כמה משאבי ארגון לישויות שונות בחברה. לדוגמה, כל מחלקה בחברה יכולה להיות לקוח עצמאי של GDC עם ארגון עצמאי, אם המחלקות דורשות הפרדה פיזית ואדמיניסטרטיבית מלאה של עומסי העבודה שלהן.
באופן כללי, מומלץ לקבץ כמה עומסי עבודה בארגון אחד על סמך האותות הבאים:
- עומסי עבודה יכולים לחלוק תלות. לדוגמה, מקור נתונים משותף, קישוריות בין עומסי עבודה או כלי ניטור משותף.
- עומסי עבודה יכולים לחלוק בסיס אדמיניסטרטיבי של אמון. לאותו אדמין אפשר לתת גישה עם הרשאות לכל עומסי העבודה בארגון.
- לעומסי עבודה מותר לשתף תשתית פיזית בסיסית עם עומסי עבודה אחרים באותו ארגון, כל עוד יש הפרדה לוגית מספקת.
- אותו בעל תקציב אחראי לתקציבים של עומסי העבודה באופן מצטבר. פרטים על הצגת עלויות מצטברות של הארגון או ניתוח מפורט לכל עומס עבודה זמינים בדף חיוב.
- דרישות הזמינות של עומסי העבודה צריכות להתאים לדרישות הזמינות הגבוהה שלכם למרחק בין אזורים.
תכנון פרויקטים לבידוד לוגי בין עומסי עבודה
בתוך ארגון, מומלץ להקצות כמה פרויקטים כדי ליצור הפרדה לוגית בין המשאבים. יכול להיות שפרויקטים באותו ארגון ישתמשו באותה תשתית פיזית בסיסית, אבל הפרויקטים משמשים להפרדה של עומסי עבודה באמצעות גבול לוגי שמבוסס על כללי מדיניות של ניהול זהויות והרשאות גישה (IAM) ועל כללי מדיניות של רשת.
כשמתכננים את הגבולות של הפרויקט, כדאי לחשוב על קבוצת הפונקציות הגדולה ביותר שאפשר לשתף בין המשאבים, כמו קישורי תפקידים, מדיניות רשת או דרישות לניטור. כדאי לקבץ את המשאבים שיכולים לחלוק את הפונקציונליות הזו בפרויקט, ולהעביר את המשאבים שלא יכולים לחלוק את הפונקציונליות הזו לפרויקט אחר.
במונחים של Kubernetes, פרויקט הוא מרחב שמות של Kubernetes ששמור לשימוש בכל האשכולות בארגון. למרות שמרחב שמות שמור בכמה אשכולות, זה לא אומר שתהיה הקצאה אוטומטית של פוד בכל האשכולות. פוד שתוזמן לאשכול מסוים יישאר מתוזמן לאשכול הזה.
בתרשים הבא מוצג אופן ההחלה של קישור תפקיד על פרויקט שמתפרש על פני כמה אשכולות.
הקצאות תפקידים מוגדרות ברמת הפרויקט כדי לקבוע מי יכול לבצע פעולות מסוימות על משאבים מסוג מסוים. עומסי עבודה כמו מכונות וירטואליות או פודים נפרסים בפרויקט, והגישה לעומסי העבודה האלה כפופה לשיוך התפקידים. הקשר בין התפקיד לבין המשאב חל באופן עקבי על עומסי עבודה מבוססי מכונות וירטואליות ועל עומסי עבודה מבוססי קונטיינרים, ללא קשר לאיזה אשכול הם נפרסים.
בתרשים הבא מוצג אופן ניהול הגישה בין פרויקטים באמצעות מדיניות רשת.
התקשורת בין הפרויקטים Backend Project, Frontend Project ו-Database Project מושבתת. עם זאת, משאבים בכל פרויקט יכולים לתקשר זה עם זה.
מדיניות רשת מוגדרת ברמת הפרויקט כדי לאפשר גישה לרשת בין משאבים באופן סלקטיבי. כברירת מחדל, לכל המשאבים בפרויקט אחד יש הרשאה לתקשר ביניהם ברשת הפנימית, ולמשאב בפרויקט אחד אין הרשאה לתקשר עם משאב בפרויקט אחר. ההתנהגות הזו של מדיניות הרשת חלה גם אם המשאבים נפרסים באותו אשכול וגם אם לא.
אפשר גם להגדיר ProjectNetworkPolicy משאב בהתאמה אישית כדי לאפשר תקשורת בין פרויקטים. המדיניות הזו מוגדרת לכל פרויקט כדי לאפשר תעבורת נתונים נכנסת (ingress) מפרויקטים אחרים. בתרשים הבא מוצג משאב מותאם אישית של ProjectNetworkPolicy שהוגדר עבור Backend Project כדי לאפשר העברת נתונים מ-Frontend Project ומ-Database Project.
בנוסף, מחסנית המעקב אוספת מדדים בכל הארגון, אבל אפשר לסנן ולשאול שאילתות ברמות שונות של היררכיית המשאבים. אפשר לשלוח שאילתות למדדים עם ישויות כמו אשכול או מרחב שמות.
יצירת פרויקטים לכל סביבת פיתוח תוכנה
לכל עומס עבודה, מומלץ ליצור פרויקטים נפרדים לכל סביבת פיתוח תוכנה. סביבת פיתוח תוכנה היא אזור ב-GDC Universe שמיועד לכל הפעולות שמתאימות לשלב מסוים במחזור החיים. לדוגמה, יכולות להיות לכם סביבות פיתוח תוכנה לבדיקה, לפיתוח ולייצור. הפרדה בין סביבות פיתוח תוכנה מאפשרת להגדיר את הקישורים בין תפקידים ומדיניות הרשת בצורה מדויקת, כך ששינויים שבוצעו בפרויקט שמשמש לסביבה שאינה סביבת ייצור לא ישפיעו על סביבת הייצור.
הענקת קישורי תפקידים ברמת המשאב בפרויקטים
בהתאם למבנה ולדרישות של הצוות, יכול להיות שתאפשרו למפתחים לשנות כל משאב בפרויקט שהם מנהלים, או שתדרשו בקרת גישה מפורטת יותר. בתוך פרויקט, אתם יכולים להעניק הרשאות פרטניות כדי לאפשר למפתחים ספציפיים גישה לחלק מהמשאבים בפרויקט, אבל לא לכולם. לדוגמה, יכול להיות שבצוות יש אדמין של מסד נתונים שצריך לנהל את מסד הנתונים אבל לא לשנות משאבים אחרים, בעוד שמפתחי התוכנה בצוות לא צריכים לקבל הרשאה לשנות את מסד הנתונים.
תכנון אשכולות לבידוד לוגי של פעולות Kubernetes
אשכול Kubernetes לא מהווה גבול קשיח בין דיירים כי קישורי תפקידים וכללי מדיניות של רשת חלים על פרויקטים ולא על אשכולות Kubernetes. יש יחס רבים-לרבים בין אשכולות Kubernetes ופרויקטים. יכול להיות שיש לכם כמה אשכולות Kubernetes בפרויקט אחד, או אשכול Kubernetes אחד שמשתרע על כמה פרויקטים.