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

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

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

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

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

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

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

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

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

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

שיטות מומלצות:

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

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

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

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

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

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

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

שימוש בקבוצות Google כדי להקצות ולנהל הרשאות 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 המשותף שמנוהל על ידי צוות הרשת. האפשרות הזו מספקת אבטחה נוספת, אבל היא מורכבת יותר וכוללת מגבלות רבות אחרות. מידע נוסף על קישור בין רשתות VPC שכנות (peering) זמין במאמר שימוש ב-VPC Network Peering. בדוגמה שלמטה, כל הדיירים בחרו לשתף VPC של דייר יחיד (לכל סביבה).

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

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

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

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

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

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

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

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

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

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

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

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

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

    • ‫1,000 צמתים לכל מאגר צמתים
    • ‫1,000 צמתים לכל אשכול (אם משתמשים בבקר GKE Ingress)
    • כברירת מחדל, 5,000 צמתים לכל אשכול. אפשר להגדיל את המגבלה הזו ל-15,000 או ל-65,000 צמתים. מידע נוסף זמין במאמר Clusters with more than 5,000 nodes.
    • ‫256 פודים לכל צומת
    • ‫150,000‏ Pods לכל אשכול ו-300,000 קונטיינרים לכל אשכול

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

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

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

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

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

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

שיטות מומלצות:

שליטה בתקשורת של Pod באמצעות כללי מדיניות רשת.
הרצת עומסי עבודה באמצעות GKE Sandbox.
הגדרת אמצעי בקרה על הרשאות גישה שמבוססים על מדיניות
משתמשים באיחוד זהויות של עומסי עבודה ל-GKE כדי להעניק גישה ל Google Cloud שירותים.
הגבלת הגישה לרשת למישור הבקרה.

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

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

לדוגמה, מדיניות רשת שמגבילה את תעבורת הנתונים הנכנסת (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 תומך בסוגים הבאים של בקרת גישה:

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

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

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

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

הקצאת דיירים

שיטות מומלצות:

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

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

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

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

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

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

קבוצה תפקיד RBAC ב-Kubernetes
 תיאור
אדמין של דייר (tenant) אדמין של מרחב שמות

התפקיד הזה מאפשר לראות פריסות במרחב השמות שלהם.

ההרשאה מאפשרת להוסיף משתמשים לקבוצת הדיירים ולהסיר אותם ממנה.
מפתח של דייר (tenant) עורך מרחב שמות,
צופה במרחב שמות		 התפקיד הזה מאפשר ליצור, לערוך ולמחוק קבוצות Pod, פריסות, שירותים ומפות הגדרות במרחב השמות שלהם.

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

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

שימוש בקבוצות 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 לייצוא רשומות יומן לקטגוריית יומנים שנוצרה בפרויקט Google Cloudשל הדייר.

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

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

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

אזור Tasks
הגדרת הארגון
ניהול זהויות והרשאות גישה
Networking
זמינות ואמינות גבוהות
אבטחה
רישום ביומן ומעקב

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