ריבוי דיירים באשכול

טייס אוטומטי רגילה

בדף הזה מוסבר על ריבוי דיירים באשכולות ב-Google Kubernetes Engine ‏ (GKE). זה כולל אשכולות שמשותפים בין משתמשים שונים בארגון יחיד, ואשכולות שמשותפים בין מופעים לכל לקוח של אפליקציית תוכנה כשירות (SaaS). ריבוי דיירים באשכול הוא חלופה לניהול של אשכולות רבים עם דייר יחיד.

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

מהי ארכיטקטורת מולטי-טננט?

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

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

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

הדיירים באשכול של דירות שותפים חולקים:

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

להפעלת אשכול מרובה דיירים יש כמה יתרונות בהשוואה להפעלת כמה אשכולות של דייר יחיד:

הפחתת תקורה ניהולית
צמצום הפיצול של המשאבים
אין צורך להמתין ליצירת אשכול לדיירים חדשים

תרחישים לדוגמה לשימוש ב-Multi-tenancy

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

ריבוי דיירים ב-Enterprise

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

המשתמשים באשכול מחולקים לשלושה תפקידים שונים, בהתאם להרשאות שלהם:

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

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

ריבוי דיירים אצל ספק SaaS

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

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

אכיפת מדיניות של דירות שותפים

‫GKE ו-Kubernetes מספקות כמה תכונות שאפשר להשתמש בהן כדי לנהל אשכולות מרובי דיירים. בקטעים הבאים מופיעה סקירה כללית של התכונות האלה.

בקרת גישה

ל-GKE יש שתי מערכות בקרת גישה: ניהול זהויות והרשאות גישה (IAM) ובקרת גישה מבוססת-תפקידים (RBAC). ‫IAM היא מערכת בקרת הגישה של Google Cloudלניהול אימות והרשאות למשאבים ב- Google Cloud. משתמשים ב-IAM כדי להעניק למשתמשים גישה למשאבי GKE ולמשאבי Kubernetes. מערכת RBAC מובנית ב-Kubernetes ומעניקה הרשאות מפורטות למשאבים ולפעולות ספציפיות באשכולות.

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

במדריך בנושא RBAC ובמדריך בנושא IAM מוסבר איך להשתמש במערכות האלה של בקרת גישה.

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

כללי מדיניות הרשת

מדיניות רשת באשכול מאפשרת לכם לשלוט בתקשורת בין ה-Pods באשכול. מדיניות קובעת עם אילו מרחבי שמות, תוויות וטווחים של כתובות IP יכול Pod לתקשר.

הוראות להפעלת אכיפת המדיניות בנושא התנהלות פוגעת ברשת ב-GKE מופיעות במאמר בנושא המדיניות בנושא התנהלות פוגעת ברשת.

כדי ללמוד איך לכתוב כללי מדיניות לרשת, אפשר לעיין במדריך בנושא מדיניות לרשת.

מכסות משאבים

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

מידע נוסף מופיע במאמר בנושא מכסות משאבים.

בקרת גישה מבוססת-מדיניות ל-Pod

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

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

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

אנטי-זיקה של Pod

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

אפשר להשתמש ב-Pod anti-affinity כדי למנוע תזמון של Pods מדיירים שונים באותו צומת. הגבלות אנטי-אפיניות מבוססות על תוויות של Pod. לדוגמה, מפרט ה-Pod שבהמשך מתאר Pod עם התווית "team": "billing", וכלל נגד זיקה שמונע את התזמון של ה-Pod לצד Pods ללא התווית.

apiVersion: v1
kind: Pod
metadata:
  name: bar
  labels:
    team: "billing"
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: "kubernetes.io/hostname"
        labelSelector:
          matchExpressions:
          - key: "team"
            operator: NotIn
            values: ["billing"]

החיסרון בטכניקה הזו הוא שמשתמשים זדוניים יכולים לעקוף את הכלל על ידי החלת התווית team: billing על Pod שרירותי. אי אפשר לאכוף מדיניות בצורה מאובטחת באשכולות עם דיירים לא מהימנים רק באמצעות תכונת ה-anti-affinity של ה-Pods.

מידע נוסף מופיע במאמר בנושא Pod anti-affinity.

צמתים ייעודיים עם דחיות (taints) וטולרנטיות

כתמי צבע של צמתים הם דרך נוספת לשלוט בתזמון של עומסי עבודה. אפשר להשתמש ב-taints של צמתים כדי לשריין צמתים מיוחדים לשימוש של דיירים מסוימים. לדוגמה, אפשר להקצות צמתים עם GPU לדיירים ספציפיים שעומסי העבודה שלהם דורשים GPU. ב-Autopilot clusters, תמיכה ב-node tolerations זמינה רק עבור workload separation. הקצאת צמתים אוטומטית (NAP) מוסיפה באופן אוטומטי כתמי צמתים לפי הצורך.

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

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

מידע נוסף זמין במאמר בנושא Taints and Tolerations במאמרי העזרה של Kubernetes.