שיטות מומלצות לשימוש ב-multi-tenancy בארגונים

ב-Google Kubernetes Engine ‏ (GKE), דיירות מרובה מתייחסת לאשכול אחד או יותר שמשותפים בין דיירים. ב-Kubernetes, אפשר להגדיר דייר באחת מהדרכים הבאות:

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

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

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

הנחות ודרישות

השיטות המומלצות במדריך הזה מבוססות על תרחיש לדוגמה של Multi-tenancy בסביבה ארגונית, עם ההנחות והדרישות הבאות:

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

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

הגדרת תיקיות, פרויקטים ואשכולות

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

הגדרת היררכיה של תיקיות ופרויקטים

כדי לתעד את האופן שבו הארגון שלכם מנהל Cloud de Confiance משאבים וכדי לאכוף הפרדה בין תחומים, כדאי להשתמש בתיקיות ובפרויקטים. תיקיות מאפשרות לצוותים שונים להגדיר מדיניות שמוחלת על כמה פרויקטים, ואילו פרויקטים יכולים לשמש להפרדה בין סביבות (לדוגמה, סביבת ייצור לעומת סביבת Staging) ובין צוותים. לדוגמה, ברוב הארגונים יש צוות שמנהל את תשתית הרשת וצוות אחר שמנהל את האשכולות. כל טכנולוגיה נחשבת לחלק נפרד מהמערך, ונדרשת רמה משלה של מומחיות, פתרון בעיות וגישה.

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

הקצאת תפקידים באמצעות IAM

אפשר לשלוט בגישה למשאבים Cloud de Confiance באמצעות כללי מדיניות של IAM. מתחילים בזיהוי הקבוצות שנדרשות לארגון והיקף הפעולות שלהן, ואז מקצים לקבוצה את תפקיד ה-IAM המתאים.

שליטה מרכזית על הרשת

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

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

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

אלה כמה גורמים שכדאי לקחת בחשבון כשמגדירים את הרשת:

• המספר המקסימלי של פרויקטים של שירות שאפשר לצרף לפרויקט מארח הוא 1,000, והמספר המקסימלי של פרויקטים מארחים של VPC משותף בארגון יחיד הוא 100.
• טווח כתובות ה-IP של הצומת, ה-Pod והשירותים חייב להיות ייחודי. אי אפשר ליצור רשת משנה שבה יש חפיפה בין טווחי כתובות ה-IP הראשיות והמשניות.
• מספר ה-Pods והשירותים המקסימלי עבור אשכול GKE נתון מוגבל על ידי הגודל של הטווחים המשניים של האשכול.
• המספר המקסימלי של צמתים באשכול מוגבל על ידי הגודל של טווח כתובות ה-IP הראשי של רשת המשנה של האשכול וטווח כתובות ה-Pod של האשכול.
• כדי להשיג גמישות ושליטה רבה יותר בניהול כתובות IP, אתם יכולים להגדיר את המספר המקסימלי של יחידות Pod שיכולות לפעול בצומת. כשמפחיתים את מספר ה-Pods בכל צומת, מצמצמים גם את טווח ה-CIDR שמוקצה לכל צומת, ולכן נדרשות פחות כתובות IP.

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

דיירים שנדרשת להם רמת בידוד גבוהה יותר למשאבים שפועלים מחוץ לאשכולות המשותפים (כמו מכונות וירטואליות ייעודיות של Compute Engine) יכולים להשתמש ב-VPC משלהם, שמקושר ל-VPC המשותף שמנוהל על ידי צוות הרשת. הפעולה הזו מספקת אבטחה נוספת, אבל היא גם מגדילה את המורכבות ומגבילה את האפשרויות. מידע נוסף על peering זמין במאמר שימוש ב-VPC Network Peering. בדוגמה שלמטה, כל הדיירים בחרו לשתף VPC של דייר יחיד (לכל סביבה).

יצירת אשכולות מהימנים עם זמינות גבוהה

כדי לתכנן את ארכיטקטורת האשכול לזמינות ומהימנות גבוהות, צריך להטמיע את ההמלצות הבאות:

• כדי להקטין את הסיכון להשפעה שלילית של הגדרות ברמת הפרויקט (לדוגמה, קשרי IAM) על הרבה אשכולות, וכדי לספק הפרדה למכסת השימוש ולחיוב, כדאי ליצור פרויקט אדמין אחד לכל אשכול. פרויקטים של אדמינים של אשכולות נפרדים מפרויקטים של דיירים, שדיירים בודדים משתמשים בהם כדי לנהל, לדוגמה, את המשאבים שלהם ב- Cloud de Confiance .
• מגדירים את בידוד הרשת כדי להשבית את הגישה לצמתים ולנהל את הגישה למישור הבקרה. מומלץ גם להגדיר את בידוד הרשת עבור סביבות פיתוח וסביבות ביניים.
• כדי לספק זמינות גבוהה לריבוי דיירים, צריך לוודא שרמת הבקרה של האשכול היא אזורית. כל שיבוש ברמת הבקרה ישפיע על הדיירים. חשוב לזכור שיש השלכות על העלויות בהפעלת אשכולות אזוריים. אשכולות במצב Autopilot מוגדרים מראש כאשכולות אזוריים.
• כדי להשיג מהימנות אזורית, צריך לוודא שהצמתים באשכול משתרעים על פני שלושה אזורים לפחות. מידע על עלות תעבורת הנתונים היוצאת בין תחומים באותו אזור זמין במאמרי העזרה בנושא תמחור רשת.

התאמה אוטומטית של מספר הצמתים והמשאבים באשכול

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

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

באשכולות Autopilot, מאגרי הצמתים מותאמים אוטומטית לצרכים של עומסי העבודה.

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

משתמשים בהתאמה אוטומטית לעומס של Pod כדי לשנות את גודל ה-Pods באופן אוטומטי על סמך דרישות המשאבים. ‫Horizontal Pod Autoscaler‏ (HPA) משנה את מספר הרפליקות של ה-Pod בהתאם לניצול ה-CPU או הזיכרון או למדדים מותאמים אישית. אפשר להשתמש ב-התאמה אנכית של קבוצות Pod לעומס (VPA) כדי לשנות באופן אוטומטי את דרישות המשאבים של קבוצות ה-Pod. אין להשתמש בו עם HPA אלא אם יש מדדים מותאמים אישית, כי שני כלי ההתאמה האוטומטית יכולים להתחרות זה בזה. לכן, מומלץ להתחיל עם HPA ורק אחר כך עם VPA, אם יש צורך.

קביעת הגודל של האשכול

כשקובעים את גודל האשכול, חשוב לקחת בחשבון את הגורמים הבאים:

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

• הערכים המקסימליים הבאים חלים על צמתים בכל אשכול:

  • ‫2,000 צמתים לכל אזור לכל מאגר צמתים.
  • עם בקר הכניסה של Google Kubernetes Engine, ‏ 1,000 צמתים לכל אזור לכל אשכול.
  • עד 5,000, 15,000 או 65,000 צמתים לכל אשכול. לא כל העלייה במספר הצמתים היא אוטומטית. בהתאם למספר הצמתים שאתם רוצים להגדיר, יש דרישות תשתית ספציפיות, ויכול להיות שתצטרכו לפנות ל-Cloud Customer Care. מידע מפורט זמין במאמר מגבלות ודרישות לגבי גודל האשכול.
  • עד 512 פודים לכל צומת באשכולות רגילים (מוגדר באופן דינמי עד 256 באשכולות Autopilot).
  • ‫200,000 פודים לכל אשכול ו-400,000 קונטיינרים לכל אשכול.

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

קביעת חלונות זמן לתחזוקה

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

הגדרה של מאזן עומסים חיצוני של אפליקציות (ALB) עם Ingress

כדי לנהל את השירותים שפורסמו בדיירים ואת התנועה הנכנסת לשירותים האלה, צריך ליצור מאזן עומסים של HTTP(s) כדי לאפשר כניסה אחת לכל אשכול, כשכל השירותים של הדיירים רשומים במשאב הכניסה של האשכול. אפשר ליצור ולאזן עומסים ב-HTTP(S) על ידי יצירת משאב Kubernetes Ingress, שמגדיר איך התנועה מגיעה לשירותים ואיך היא מנותבת לאפליקציה של הדייר. כשרושמים שירותים במשאב Ingress, המוסכמות למתן שמות לשירותים הופכות עקביות, ומוצג Ingress יחיד, כמו tenanta.example.com ו-tenantb.example.com.

אבטחת האשכול לשימוש של כמה דיירים

שליטה בתקשורת של Pod באמצעות כללי מדיניות רשת

כדי לשלוט בתקשורת ברשת בין רכיבי Pod בכל אחד ממרחבי השמות של האשכול, יוצרים מדיניות רשת על סמך הדרישות של הדיירים. כהמלצה ראשונית, כדאי לחסום תנועה בין מרחבי שמות שמארחים אפליקציות של דיירים שונים. אדמין האשכול יכול להחיל deny-all מדיניות רשת ב-Kubernetes כדי לדחות את כל תעבורת הנתונים הנכנסת (ingress), וכך למנוע מ-Pods במרחב שמות אחד לשלוח בטעות תעבורת נתונים לשירותים או למסדי נתונים במרחבי שמות אחרים.

לדוגמה, מדיניות רשת ב-Kubernetes הבאה מגבילה את תעבורת הנתונים הנכנסת (ingress) מכל מרחבי השמות האחרים למרחב השמות tenant-a:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

הפעלת עומסי עבודה באמצעות GKE Sandbox

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

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

‫GKE Sandbox מספק שני גבולות בידוד בין הקונטיינר לבין מערכת ההפעלה של המארח:

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

הגדרת אמצעי בקרה על אישור בקשות שמבוססים על מדיניות

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

‫GKE תומך בסוגים הבאים של בקרת כניסה:

• ‫Policy Controller: הצהרה על מדיניות מוגדרת מראש או מותאמת אישית ואכיפה שלה באשכולות בקנה מידה גדול באמצעות fleets. ‫Policy Controller הוא הטמעה של סוכן המדיניות הפתוח Gatekeeper בקוד פתוח, והוא תכונה של GKE Enterprise.

• בקרת קבלה של PodSecurity: אכיפה של מדיניות מוגדרת מראש שתואמת לתקני האבטחה של Pod באשכולות נפרדים או במרחבי שמות ספציפיים.

שימוש באיחוד זהויות של עומסי עבודה ל-GKE כדי להעניק גישה לשירותים Cloud de Confiance

כדי להעניק לעומסי עבודה גישה מאובטחת ל Cloud de Confiance שירותים, צריך להפעיל איחוד זהויות של עומסי עבודה ל-GKE באשכול. איחוד זהויות של עומסי עבודה ל-GKE עוזר לאדמינים לנהל חשבונות שירות של Kubernetes שעומסי עבודה של Kubernetes משתמשים בהם כדי לגשת לשירותים. Cloud de Confiance כשיוצרים אשכול עם איחוד זהויות של עומסי עבודה ל-GKE, נוצר מרחב שמות של זהויות לפרויקט שבו נמצא האשכול. מרחב השמות של הזהויות מאפשר לאשכול לבצע אימות אוטומטי של חשבונות שירות עבור אפליקציות GKE על ידי מיפוי של שם חשבון השירות של Kubernetes לטיפול וירטואלי בחשבון שירות של Google, שמשמש לקישור IAM של חשבונות שירות של Kubernetes בדייר.

הגבלת הגישה לרשת למישור הבקרה

כדי להגן על מישור הבקרה, צריך להגביל את הגישה לרשתות מורשות. ב-GKE, כשמפעילים רשתות מורשות, אפשר לאשר עד 50 טווחי CIDR ולאפשר גישה למישור הבקרה רק לכתובות IP בטווחים האלה. ב-GKE כבר נעשה שימוש ב-Transport Layer Security‏ (TLS) ובאימות כדי לספק גישה מאובטחת לנקודת הקצה של מישור הבקרה מהאינטרנט הציבורי. באמצעות רשתות מורשות, אפשר להגביל עוד יותר את הגישה לקבוצות ספציפיות של כתובות IP.

הקצאת משאבים לדייר

יצירת פרויקטים של דייר

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

שימוש ב-RBAC כדי לשפר את הגישה לדייר

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

קודם לכן זיהינו שתי קבוצות של דיירים: אדמינים של דיירים ומפתחים של דיירים. לקבוצות האלה אנחנו מגדירים את תפקידי ה-RBAC והגישה הבאים:

בנוסף ליצירת תפקידים וקשרים של RBAC שמקצים לקבוצות ב-Google Workspace או ב-Cloud Identity הרשאות שונות במרחב השמות שלהן, אדמינים של דיירים צריכים לעיתים קרובות את היכולת לנהל משתמשים בכל אחת מהקבוצות האלה. בהתאם לדרישות הארגון, אפשר להקצות הרשאות Google Workspace או Cloud Identity לאדמין הדייר כדי לנהל את חברות הקבוצה שלו, או שאדמין הדייר יכול לפנות לצוות בארגון שיש לו הרשאות Google Workspace או Cloud Identity כדי לטפל בשינויים האלה.

שימוש בקבוצות Google כדי לקשר הרשאות

כדי לנהל ביעילות את ההרשאות של הדיירים באשכול, אפשר לקשר הרשאות RBAC לקבוצות Google. האדמינים של Google Workspace אחראים על חברות המשתמשים בקבוצות האלה, ולכן לאדמינים של האשכול לא נדרש מידע מפורט על המשתמשים.

לדוגמה, אם יש קבוצה ב-Google בשם tenant-admins@mydomain.com ומשתמש בשם admin1@mydomain.com הוא חבר בקבוצה הזו, הקישור הבא מעניק למשתמש הרשאת אדמין למרחב השמות tenant-a:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

יצירת מרחבי שמות

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

איך נמנעים מהגעה למגבלות של מרחב שמות

מספר מרחבי השמות המקסימלי התיאורטי באשכול הוא 10,000, אבל בפועל יש הרבה גורמים שיכולים למנוע מכם להגיע למגבלה הזו. לדוגמה, יכול להיות שתגיעו למספר המקסימלי של Pods (150,000) וצמתים (5,000) ברמת האשכול לפני שתגיעו למספר המקסימלי של מרחבי שמות. גורמים אחרים (כמו מספר הסודות) יכולים להקטין עוד יותר את המגבלות בפועל. לכן, כלל אצבע טוב להתחלה הוא לנסות להתקרב למגבלה התיאורטית של אילוץ אחד בכל פעם, ולהישאר בערך בסדר גודל אחד מתחת למגבלות האחרות, אלא אם ניסויים מראים שהתרחישים שלכם פועלים היטב. אם אתם צריכים יותר משאבים ממה שאפשר לתמוך בו באשכול יחיד, אתם צריכים ליצור עוד אשכולות. מידע על יכולת ההתאמה של Kubernetes זמין במאמר סכומי הסף של יכולת ההתאמה של Kubernetes.

ביצוע סטנדרטיזציה של שמות מרחבי השמות

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

יצירת חשבונות שירות לעומסי עבודה בדייר

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

אכיפה של מכסות משאבים

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

בדוגמה הבאה מוגדרת מכסת משאבים שבה ל-Pods במרחב השמות tenant-a יש אפשרות לבקש עד 16 ליבות CPU ו-64GB של זיכרון, והמקסימום של ליבות ה-CPU הוא 32 והמקסימום של הזיכרון הוא 72GB.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

מעקב, רישום ביומן ושימוש

מעקב אחר מדדי שימוש

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

כשמפעילים את הקצאת העלויות ב-GKE, שם האשכול ומרחב השמות של עומסי העבודה ב-GKE מופיעים בשדה התוויות בייצוא נתוני החיוב ל-BigQuery.

איך מספקים יומנים ספציפיים לדייר

כדי לספק לדיירים נתוני יומן שספציפיים לעומסי העבודה בפרויקט שלהם, צריך להשתמש בLog Router של Cloud Logging. כדי ליצור יומנים ספציפיים לדייר, האדמין של האשכול יוצר sink לייצוא רשומות יומן לקטגוריה ביומן שנוצרה בפרויקט של הדייר ב- Cloud de Confiance by S3NS.

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

סיכום רשימת המשימות

בטבלה הבאה מפורטות המשימות המומלצות ליצירת אשכולות מרובי דיירים בארגון:

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

• מידע נוסף על אבטחה זמין במאמר הקשחת האבטחה באשכול.
• מידע נוסף על רשתות VPC זמין במאמר שיטות מומלצות ודוגמאות לארכיטקטורות לתכנון VPC.
• לשיטות מומלצות נוספות לארגונים, אפשר לעיין בCloud de Confiance by S3NS Well-Architected Framework.