שיטות מומלצות לשימוש ב-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

אפשר לשלוט בגישה למשאבים באמצעות כללי מדיניות של IAM. Cloud de Confiance מתחילים בזיהוי הקבוצות שנדרשות לארגון והיקף הפעולות שלהן, ואז מקצים לקבוצה את תפקיד ה-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, אתם יכולים להגדיר את המספר המקסימלי של יחידות 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 כדי לשנות את גודל ה-Pod באופן אוטומטי על סמך דרישות המשאבים. ‫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. מידע מפורט זמין במאמר מגבלות ודרישות לגבי גודל האשכול.
  • ‫256 פודים לכל צומת.
  • ‫200,000 פודים לכל אשכול ו-400,000 קונטיינרים לכל אשכול.

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

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

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

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

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

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

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

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

לדוגמה, מדיניות הרשת הבאה מגבילה את התנועה הנכנסת מכל מרחבי השמות האחרים למרחב השמות 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 open policy agent בקוד פתוח, והוא תכונה של GKE Enterprise.

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

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

כדי להעניק לעומסי עבודה גישה מאובטחת לשירותים, צריך להפעיל איחוד זהויות של עומסי עבודה ל-GKE באשכול. Cloud de Confiance איחוד זהויות של עומסי עבודה ל-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, אבל בפועל יש הרבה גורמים שיכולים למנוע מכם להגיע למגבלה הזו. לדוגמה, יכול להיות שתגיעו למספר המקסימלי של פודים (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.