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