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

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

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

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

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

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

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

• הארגון הוא חברה אחת עם הרבה דיירים (שני צוותים או יותר של אפליקציות/שירותים) שמשתמשים ב-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 והשירותים שהם צפויים להפעיל, ואת הגודל המקסימלי והממוצע של ה-Pod. חישוב של קיבולת האשכול הכוללת הנדרשת מאפשר להבין את גודל המופע הרצוי, ומספק את מספר הצמתים הכולל. אפשר לחשב את סך מרחב כתובות ה-IP שנצרך לפי המספר הכולל של הצמתים, וכך לקבל את גודל רשת המשנה הרצוי.

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

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

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

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

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

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

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

התאמה אוטומטית של גודל הצמתים והמשאבים באשכול

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

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

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

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

כדי לשנות באופן אוטומטי את קנה המידה של Pods על סמך דרישות המשאבים, אפשר להשתמש בהתאמה אוטומטית לעומס של Pods. ‫Horizontal Pod Autoscaler ‏(HPA) משנה את מספר הרפליקות של ה-Pod בהתאם לניצול ה-CPU או הזיכרון או למדדים מותאמים אישית. אפשר להשתמש ב-Vertical Pod Autoscaling (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 Pods לכל אשכול ו-400,000 קונטיינרים לכל אשכול.

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

תזמון חלונות זמן לתחזוקה

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

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

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

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

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

כדי לשלוט בתקשורת הרשת בין Pods בכל אחד ממרחבי השמות של האשכול, יוצרים מדיניות רשת ב-Kubernetes על סמך הדרישות של הדיירים. ההמלצה הראשונית היא לחסום תנועה בין מרחבי שמות שמארחים אפליקציות של דיירים שונים. אדמין האשכול יכול להחיל 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 שמפירים את גבולות האבטחה באשכול, צריך להשתמש בבקר הרשאות. בקרי קבלה יכולים לבדוק את המפרטים של Pod בהשוואה למדיניות שאתם מגדירים, ויכולים למנוע הפעלה של Pod שמפר את המדיניות הזו באשכול.

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

• ‫Policy Controller: הצהרה על מדיניות מוגדרת מראש או מותאמת אישית ואכיפה שלה באשכולות בקנה מידה גדול באמצעות צי. ‫Policy Controller הוא הטמעה של Gatekeeper open policy agent בקוד פתוח, והוא תכונה של 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 לקבוצות הדיירים, מגדירים תפקידים וקישורים של Kubernetes RBAC ברמת מרחב השמות לכל קבוצת דיירים.

קודם לכן זיהינו שתי קבוצות של דיירים: אדמינים של דיירים ומפתחים של דיירים. לקבוצות האלה אנחנו מגדירים את תפקידי ה-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.

בדוגמה הבאה מוגדרת מכסת משאבים שבה אפשר לבקש עד 16 ליבות CPU ו-64GB של זיכרון עבור Pods במרחב השמות tenant-a, והמקסימום של ליבות ה-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.

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

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

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

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

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

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

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