במאמר הזה מתוארת היררכיית המשאבים של Google Distributed Cloud (GDC) עם בידוד פיזי, ומוסבר איך מנהלים משאבים במופע עם בידוד פיזי. במאמר סקירה כללית על אזורים מרובים מוסבר על ניהול משאבים בכמה אזורים.
להיררכיית המשאבים של GDC יש שתי מטרות:
- הגדרת היררכיית בעלות שמקשרת את מחזור החיים של משאב להורה המיידי שלו בהיררכיה.
- מספקת נקודות חיבור וירושה לבקרת גישה ולמדיניות הארגון.
היררכיית המשאבים של GDC דומה למערכת הקבצים במערכות הפעלה, שנועדה לארגן ולנהל ישויות באופן היררכי. בדרך כלל, לכל משאב יש בדיוק הורה אחד. הארגון ההיררכי הזה של משאבים מאפשר לכם להגדיר מדיניות של בקרת גישה, כמו ניהול זהויות והרשאות גישה (IAM), שעוברת בירושה למשאבי צאצאים.
למידע נוסף על שיטות מומלצות לארגון גבולות הגישה, אפשר לעיין במאמר בנושא תכנון גבולות גישה בין משאבים.
מבנה המשאבים בפירוט
הישויות הבאות הן סוגי משאבים שמזוהים בהיררכיית המשאבים של GDC:
המשאבים ב-GDC מאורגנים בהיררכיה. לרוב המשאבים בהיררכיית המשאבים יש בדיוק הורה אחד. החריג חל רק על המשאב הגבוה ביותר. ברמה הנמוכה ביותר, משאבי השירות הם הרכיבים הבסיסיים שמהם מורכבים כל שירותי GDC.
הארגון נמצא בראש היררכיית המשאבים ב-GDC, וכל המשאבים ששייכים לארגון מקובצים תחת משאב הארגון. כך מקבלים הרשאות גישה מרכזיות ושליטה בכל המשאבים ששייכים לארגון.
הפרויקטים ואשכולות Kubernetes המשותפים הם בהיקף הארגון. אפשר לצרף אותם אחד לשני כדי לארגן משאבי שירות. עם זאת, פרויקטים ואשכולות משותפים פועלים באופן עצמאי. הגמישות הזו מאפשרת לארגן את השירותים ועומסי העבודה בדרכים רבות ושונות. לדוגמה, אתם יכולים להקצות אשכול משותף לפרויקט יחיד. באופן דומה, אפשר לשתף אשכול בין כמה פרויקטים.
משאבי שירות הם ישויות שחייבות להיות שייכות לפרויקט, ואי אפשר לשתף אותן בין פרויקטים. דוגמאות למשאבי שירות כוללות מכונות וירטואליות (VM), אשכולות Kubernetes רגילים, מסדי נתונים, קטגוריות אחסון וגיבויים. לרוב המשאבים ברמה נמוכה יותר בהיררכיה יש משאבי פרויקט כמשאבי אב.
בתרשים הבא מוצגת דוגמה להיררכיית משאבים ב-GDC:
במאמר תכנון הפרדה של עומסי עבודה של משתמשים מוסברות שיטות מומלצות לארגון היררכיית המשאבים כדי לייעל את ניהול עומסי העבודה.
ארגון
משאב הארגון מייצג יחידה אדמיניסטרטיבית או פונקציה עסקית, כמו חברה, והוא המשאב ברמה העליונה בהיררכיית המשאבים של GDC. ארגון מגדיר גבול אבטחה שמקיף משאבי תשתית שמנוהלים יחד, כדי שהמשתמשים יוכלו לפרוס עומסי עבודה של אפליקציות. ארגונים הם גלובליים וכוללים את כל האזורים ביקום. בתוך ארגון, משאבי שירות כמו מכונות וירטואליות ונפחי אחסון מקובצים באופן לוגי לפי פרויקטים.
כל הפרויקטים, האשכולות ומשאבי השירות שייכים לארגון שלכם ולא ליוצרים שלהם. המשמעות היא שסוג משאב של ארגון לא נמחק אם המשתמש שיצר אותו עוזב את הארגון. במקום זאת, כל סוגי המשאבים פועלים לפי מחזור החיים של הארגון ב-GDC.
כללי המדיניות של בקרת הגישה ב-IAM שמוחלים על משאב הארגון חלים גם על כל המשאבים של הארגון בהיררכיה. מידע נוסף על מתן הרשאות וקביעת מדיניות ברמת הארגון זמין בקטעים מדיניות הארגון וIAM.
פרויקט
פרויקט הוא יחידה ייעודית לדייר בענן שכל שירות צריך להשתלב בה. פרויקטים מספקים קיבוץ לוגי של משאבי שירות. פרויקטים הם גלובליים וכוללים את כל האזורים ביקום.
פרויקטים מאפשרים פילוח של משאבי שירות בארגון, ומספקים גבולות של מחזור חיים ומדיניות לניהול משאבים. משאבי שירות בתוך פרויקט לא יכולים להתקיים אחרי שהפרויקט מסתיים או לעבור בין פרויקטים, וכך מובטח שהשליטה תהיה זמינה למשך חיי המשאב. לכן, צריך לפרוס משאבים מכל סוג במרחב שמות של פרויקט.
פרויקט נחשב למרחב שמות מתאים של Kubernetes שמשתרע על פני כמה אשכולות משותפים בארגון. זהות מרחב השמות מתייחסת לכל מרחבי השמות עם שם נתון כאל אותו מרחב שמות לכל האשכולות המשותפים באותו ארגון. למרחב השמות היחיד יש בעלים עקבי בכל קבוצת האשכולות המשותפים. ספקי שירותים יוצרים שירותים בהיקף הפרויקט על ידי יצירת רכיבים של מישור הבקרה ומישור הנתונים במרחב השמות.
מרחב השמות של פרויקט מכיל את הרכיבים הבאים:
- ממשקי API של שירותים בהיקף הפרויקט.
- הגדרות מדיניות ברמת הפרויקט, כמו תפקידים וקישורי תפקידים.
אפשר לצרף פרויקט רק לקבוצת משנה של אשכולות משותפים בארגון. אפשר לפרוס עומסי עבודה בקונטיינרים באשכולות משותפים כאלה במרחב שמות של פרויקט. המושג של זהות מרחב השמות חל על מרחב השמות של הפרויקט באשכולות המשותפים האלה. כללי מדיניות בהיקף מרחב שמות, כמו כללי מדיניות של גישה מבוססת-תפקידים (RBAC), חלים על כל מרחבי השמות האלה.
מידע נוסף על פרויקטים זמין במאמר סקירה כללית על פרויקטים.
אשכול Kubernetes משותף
אשכול Kubernetes הוא קבוצה של צמתים שמריצים עומסי עבודה מבוססי-קונטיינרים כחלק מ-GKE on GDC. אתם יכולים להקצות אשכולות Kubernetes כדי לתמוך בדרישות החישוב של האפליקציות שלכם.
אשכול משותף הוא הגדרת אשכול שמוגבלת לארגון, וצריך לצרף אותו לפרויקט אחד או יותר. אשכול רגיל הוא עוד הגדרת אשכול שפועלת רק בתוך פרויקט אחד, אבל נחשבת משאב שירות בהיררכיית המשאבים. ההגדרות האלה של אשכולות Kubernetes מיועדות ליצירת ארכיטקטורת Kubernetes שמציעה אפשרויות לניהול קונטיינרים בסביבות פיתוח תוכנה, למשל לבדיקות, לפיתוח ולייצור. מידע נוסף על שיטות מומלצות להפרדה בין עומסי עבודה של קונטיינרים זמין במאמר תכנון הפרדה בין עומסי עבודה.
מידע נוסף על סוגי האשכולות השונים ב-GDC זמין במאמר הגדרות של אשכולות Kubernetes.
באמצעות אשכולות משותפים, אפשר לחלק משאבי תשתית למאגרי משאבים מבודדים לשימוש בפרויקטים בארגון. האשכולות מופרדים גם מבחינה לוגית זה מזה כדי לספק תחומים שונים של כשלים והבטחות לבידוד. האכיפה של כללי המדיניות בכל ארגון מבטיחה שאפשר לשתף אשכולות בין צוותים ומשתמשים, תוך שמירה על הביצועים והמשאבים. בנוסף, מדיניות הארגון מאפשרת לעומסי עבודה של מכונות וירטואליות לפעול לצד עומסי עבודה של קונטיינרים בלי להוסיף מורכבות תפעולית.
אשכולות מועילים במקרים שבהם צריך לפרוס עומסי עבודה מבוססי-קונטיינרים. עם זאת, עם האפשרות לפרוס עומסי עבודה מבוססי מכונות וירטואליות, לא נדרש אשכול Kubernetes ב-GDC.
אשכולות הם משאב אזורי בלבד, ולא יכולים להתפרס על פני כמה אזורים. כדי להפעיל אשכולות בפריסה מרובת אזורים, צריך לפרוס אשכולות באופן ידני בכל אזור.
מידע נוסף על אשכולות Kubernetes זמין במאמר סקירה כללית של אשכול Kubernetes.
משאב שירות
משאבי השירות כוללים ישויות רבות, כמו:
- VMs (מכונות וירטואליות)
- אשכולות Kubernetes רגילים
- מסדי נתונים
- קטגוריות אחסון
- עומסי עבודה בקונטיינרים
- גיבויים
משאבי שירות חייבים להיות שייכים לפרויקט, ואי אפשר לשתף אותם בין פרויקטים. מחזור החיים הספציפי לפרויקט הזה אומר שמשאבי שירות בתוך פרויקט אף פעם לא יכולים להתקיים אחרי שהפרויקט עצמו מסתיים, וכך מובטח שהשליטה תהיה זמינה למשך חיי המשאב.
אפשר לפרוס משאבי שירות באופן גלובלי או אזורי, בהתאם לסוג המשאב. מידע על אפשרויות פריסה מרובות אזורים זמין במסמכי התיעוד של השירות הספציפי. משאבי שירות מופעלים כברירת מחדל, ואפשר להשבית אותם באמצעות מדיניות ארגונית.