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