במאמר זה ניחשף לשיתוף של צוות ה-Kubernetes בעליבאבא, בו הם יספרו על בנייה של Hard Multi-Tenancy על גבי Upstream Kubernetes, זאת באמצעות קבוצת תוספים הנקראת "Virtual Cluster", אותה הם מעוניינים לשתף עם הקהל הרחב.
הקדמה
צוות ה-Kubernetes הפנים ארגוני בעליבאבא משתמש ב-Web-scale Cluster בכדי לתת שירות עבור כמות גדולה של עסקים, והם מתייחסים אליהם כמו אל לקוחות קצה. כתוצאה מכך, כל משתמש קצה בעצם נהפך ל-tenant ("דייר") ב-Cluster זה, מה שהופך את הצורך ל-Hard Multi-tenancy לממשי ביותר.
במקום ללכת על הפתרון ה"צפוי" של פריצה לשרת ה-API של Kubernetes (ו/או ל-Resource Model), הצוות החליט לנסות ולבנות שכבת Multi-tenancy שהוגדרה כ"Virtual Cluster", זאת מבלי לשנות קוד כלשהו ב-Kubernetes. באמצעות שימוש בארכיטקטורה זו, כל "דייר" יוצמד למישור בקרה ייעודי של K8 (המורכב מ-kuber-apiserver + kube-controller-manager) ומספר "Virtual Node" (אובייקט API Node טהור, ללא kubelet תואם). כך, אין צורך לדאוג לקונפליקטים בין ה-Nodes השונים, ועומסי ה-tenants עדיין מעורבים ורצים באותו “Super Cluster” – אז אין ספק שיהיה ניצול של משאבים. העיצוב הנ"ל מפורט כאן, וקיבל הרבה מאוד פידבקים.
למרות שהקונספט החדש של "Tenant Master" לוקח חלק פעיל בעיצוב זה, ה-Virtual Cluster הוא לא יותר מתוסף הנבנה על Multi-tenancy מבוסס namespace שכבר היה קיים בקהילת ה-K8s ומוכר בשם "Namespace group". שיטת ה -VC מסתמכת לחלוטין על מכניקות בידוד משאבים של קבוצה זו, ואנו מקווים לראות פיתוחים נוספים בתחום.
אם אתם רוצים ללמוד יותר על העיצוב של ה-VC , אתם מוזמנים לקרוא עוד על הנושא בהמשך. במסמך הנוכחי, אתם תתמקדו ברעיון העמוק מאחורי השיטה, ותוכלו להבין איך להגדיל את קבוצת ה-name space עם view של “Tenant Cluster”, ולמה התוסף הזה יעיל במיוחד עבור תרחישי שימוש הקשורים ל-Multi-tenancy ב-Kubernetes.
רקע
בחלק זה אנו נבחן בקצרה את הארכיטקטורה של הצעת ה-Multi-tenancy של קבוצת ה-namespace . השאלנו דיאגרמה מהמצגת הבאה, וניתן לראות בתרשים 1 את הרעיון העמוק של שימוש ב-namespaces על מנת לארגן את משאבי ה-tenants.
בקבוצת ה-namespace , כל ה-tenants של המשתמשים חולקים את אותה נקודת הגישה, הלא היא ה-apiserver של K8s, וזאת בכדי לנצל את משאבי ה-tenants. החשבונות שלהם, ה-namespaces המוקצים ומדיניות בידוד המשאבים מוגדרים כולם ב- CRD של האובייקטים. מדיניות בידול משאבי ה-tenants מוגדרת בכדי להגביל את התקשורת הישירה בין tenants ולהגן על ה-tenant Pods מפני מתקפות סייבר. כל אלו ממומשים באמצעות מכניקות בידוד משאבים של Kubernetes עצמו - כמו RBAC, מדיניות Pod Security, מדיניות הרשת, בקרת מנהלים ו-Sandbox Runtime. ניתן להגדיר מספר פרופילים שונים של אבטחה, ולהפעיל אותם עבור דרישות בידוד משאבים שונות. בנוסף לכך, מכסות המשאבים, chargeback וגבייה מתרחשים ברמת ה-tenant.
איך VC מוסיף לשכבת ה-View?
כקונספט, ה-VC מוסיף שכבת View נוספת על הפתרון של קבוצת ה-namespace (ניתן למצוא את הפרטים הטכניים כאן). ב-VC, ה-Tenant admin עדיין צריך להשתמש באותו ה-CRD שהשתמשו בו ב-namespace group בכדי להגדיר את חשבונות המשתמשים, את ה-namespaces ואת מדיניות בידוד המשאבים ב-Super master.
כמו שניתן לראות בתרשים 2, הודות ל-View layer החדש של ה-VC, המשתמשים יכולים ליהנות ממספר נקודות גישה שונות ומ-tenant resource views . במקום לגשת ל-Super master ולצפות ב-namespace בצורה ישירה, אותם משתמשים מתקשרים עם masters ייעודיים בכדי לנצל את המשאבים המוצעים להם, ובנוסף לכך הם נהנים מגישה מלאה ל-K8s master views. כל הבקשות מסתנכרנות אל ה -Super master על ידי אשף הסנכרון, היוצר משאבים מותאמים אישית שעוקבים אחר מדיניות בידוד המשאבים הנמצאת ב-CRD. יחד עם זאת, ה-VC בעיקר משנה את ה-user view של ה-tenants מ-namespaces אל APIserver. מנקודת המבט של ה-Super master, אותם הליכי עבודה מופעלים על ידי בקרת ה-tenants ובהתאם ל-CRD.
היתרונות של ה- View Extension ב-VC
שימוש ב-view של VC על view קיים של namespace יכול להקנות לכם מספר יתרונות:
• מדובר בדרך נוחה וגמישה לניהול משאבי ה- tenant עבור המשתמשים. לדוגמא - בהיררכיית namespace (אותה ניתן לראות בתרשים 3 א'), ניתן לפתור בקלות בעיות כמו קונפליקטים הקשורים לשמות, נראות ה-name space , ניהול משאבי ה- tenant בתת-מחיצות ועוד. יחד עם זאת, מאוד בעייתי לשנות את ה- native K8s Master למצב בו הוא יוכל לתמוך ב-namespaces שהם nested. על ידי ה- view של ה-VC , כל ה-namespaces שנוצרו ב-tenant master (ביחד עם קבוצת ה-namespace התואמת ב- super master), יוכלו לתת לכם תוצאות דומות לאלו של שימוש ב-nested namespaces.
כפי שניתן לראות בתרשים 3 ב', המשתמשים יוכלו להשתמש ביצירת namespaces בשירות עצמי ב-tenant master, זאת מבלי לדאוג לקונפליקטים בשמות עם tenants אחרים. הקונפליקט נפתר בזכות מנהל הסנכרון, המוסיף את אותם namespaces אל ה-super master namespace group. ה-tenants בקבוצה א' לא יוכלו לראות את אלו שנמצאים בקבוצה ב', מפני שיש להם מאסטר שונה. כך גם קל ליצור מדיניות בהתאמה אישית עבור משתמשים שונים, שייאכפו רק עבור ה-tenant master הספציפי.
עם ה-View Extension , בידוד המשתמשים והאבטחה נחשבים לטובים יותר, מפני שלכל קבוצה יש את ה-K8s master שלה. בזכות החלוקה הנ"ל, מתקפות DDos, בעיות גישה ל-API , בידוד בקרי tenants ועוד - כבר לא מהווים בעיה.
• ניתן ליצור cluster scope objects ב-tenant masters מבלי להשפיע על tenants אחרים. לדוגמא, משתמש יוכל ליצור CRD, ClusterRole/ClusterRoleBinding, PersistentVolume, ResourceQuota, ServiceAccount, NetworkPolicy בחופשיות, מבלי לדאוג לקונפליקט כלשהו עם ה-tenants האחרים.
• שימוש ב- View Extension מוריד את עומס הסקייליביליטי על ה-super master . כעת תוכלו להעביר את חוקי ה- RBAC, המדיניות ואת המשתמשים המנוהלים- היישר מה- super master אל ה-tenant masters , בהם תוכלו לבצע סקיילינג אינדיווידואלי. בנוסף לכך, ה-tenant controllers וה-operators access מגיעים למספר tenant masters במקום super master אחד, וגם להם ניתן לבצע סקיילינג אינדיווידואלי.
• קל יותר ליצור משתמשים עבור tenant user. בימינו, אם משתמש כזה רוצה לחשוף את המשאבים שלו עבור משתמשים אחרים (למשל, ראש צוות רוצה לתת לחברי הצוות להשתמש במשאבים שהוקצו אליהם), האדמין צריך ליצור את כל המשתמשים, מה שיכול להיות בעייתי במיוחד בארגונים גדולים השימוש ב-VC מונע את עומס זה בקלות.
הגבלות
מכיוון שה-VC בעיקר מוסיף ל- multi-tenancy view option ומונע בעיות הקשורות לחלוקה של ה-apiserver , הוא יורש את אותן המגבלות והאתגרים של פתרון ה-namespace group בכל הקשור להתאמה של ה- kubernetes node components ל- tenant. לכן, צריך לתת להם את השיפורים הבאים:
• תוסף Kubelet and CNI – דאגו לכך שהם יתמכו ב-.tenant כך תוכלו ליהנות מתרחישי בידוד רשת איכותיים כמו VPC.
• Kube-proxy/Kube-dns – עליהם להיות מותאמים ל- tenant בכדי לאפשר cluster-IP, הנחוץ עבור חלק מהשירותים הקשורים לנושא.
• כלים: לדוגמא, כלי ניטור צריכים להיות מתאימים ל- tenant בכדי למנוע דליפה של מידע הקשור אליהם. כלים לשיפור ביצועים צריכים לקבל התאמה גם הם בכדי למנוע הפרעות ביצועים בין tenants שונים.
לסיכום, כל VC זקוק למשאבים נוספים בכדי להריץ את ה- tenant master עבור כל אחד מה-tenants, מה שעלול להוביל להוצאות גדולות יותר.
מסקנות
VC מרחיב את האפשרויות של פתרון ה-namespace באמצעות Cluster view ידידותי למשתמש. הוא ממנף את מכניקות בידוד המשאבים של K8s, את ה-CRD וכלי הבקרה, וגם מציע לכם להשתמש ב-dedicated tenant cluster . בסופו של יום, אנחנו מאמינים שה- VC, ביחד עם namespace המבוסס על multi-tenancy יכול להציע לכם פתרונות מקיפים עבור תרחישי שימוש הקשורים ל-Kubernetes multi-tenancy ב- production clusters, ואנו פועלים לכך שעוד קהילות ומשתמשים ייחשפו לאפשרויות החדשות.
מאת: מערכת IsraelClouds
רוצים להתעדכן בתכנים נוספים בנושאי ארכיטקטורת ענן? הצטרפו לפורום המקצועי של IsraelClouds בתחום > להרשמה
במאמר זה ניחשף לשיתוף של צוות ה-Kubernetes בעליבאבא, בו הם יספרו על בנייה של Hard Multi-Tenancy על גבי Upstream Kubernetes, זאת באמצעות קבוצת תוספים הנקראת "Virtual Cluster", אותה הם מעוניינים לשתף עם הקהל הרחב.
הקדמה
צוות ה-Kubernetes הפנים ארגוני בעליבאבא משתמש ב-Web-scale Cluster בכדי לתת שירות עבור כמות גדולה של עסקים, והם מתייחסים אליהם כמו אל לקוחות קצה. כתוצאה מכך, כל משתמש קצה בעצם נהפך ל-tenant ("דייר") ב-Cluster זה, מה שהופך את הצורך ל-Hard Multi-tenancy לממשי ביותר.
במקום ללכת על הפתרון ה"צפוי" של פריצה לשרת ה-API של Kubernetes (ו/או ל-Resource Model), הצוות החליט לנסות ולבנות שכבת Multi-tenancy שהוגדרה כ"Virtual Cluster", זאת מבלי לשנות קוד כלשהו ב-Kubernetes. באמצעות שימוש בארכיטקטורה זו, כל "דייר" יוצמד למישור בקרה ייעודי של K8 (המורכב מ-kuber-apiserver + kube-controller-manager) ומספר "Virtual Node" (אובייקט API Node טהור, ללא kubelet תואם). כך, אין צורך לדאוג לקונפליקטים בין ה-Nodes השונים, ועומסי ה-tenants עדיין מעורבים ורצים באותו “Super Cluster” – אז אין ספק שיהיה ניצול של משאבים. העיצוב הנ"ל מפורט כאן, וקיבל הרבה מאוד פידבקים.
למרות שהקונספט החדש של "Tenant Master" לוקח חלק פעיל בעיצוב זה, ה-Virtual Cluster הוא לא יותר מתוסף הנבנה על Multi-tenancy מבוסס namespace שכבר היה קיים בקהילת ה-K8s ומוכר בשם "Namespace group". שיטת ה -VC מסתמכת לחלוטין על מכניקות בידוד משאבים של קבוצה זו, ואנו מקווים לראות פיתוחים נוספים בתחום.
אם אתם רוצים ללמוד יותר על העיצוב של ה-VC , אתם מוזמנים לקרוא עוד על הנושא בהמשך. במסמך הנוכחי, אתם תתמקדו ברעיון העמוק מאחורי השיטה, ותוכלו להבין איך להגדיל את קבוצת ה-name space עם view של “Tenant Cluster”, ולמה התוסף הזה יעיל במיוחד עבור תרחישי שימוש הקשורים ל-Multi-tenancy ב-Kubernetes.
רקע
בחלק זה אנו נבחן בקצרה את הארכיטקטורה של הצעת ה-Multi-tenancy של קבוצת ה-namespace . השאלנו דיאגרמה מהמצגת הבאה, וניתן לראות בתרשים 1 את הרעיון העמוק של שימוש ב-namespaces על מנת לארגן את משאבי ה-tenants.
בקבוצת ה-namespace , כל ה-tenants של המשתמשים חולקים את אותה נקודת הגישה, הלא היא ה-apiserver של K8s, וזאת בכדי לנצל את משאבי ה-tenants. החשבונות שלהם, ה-namespaces המוקצים ומדיניות בידוד המשאבים מוגדרים כולם ב- CRD של האובייקטים. מדיניות בידול משאבי ה-tenants מוגדרת בכדי להגביל את התקשורת הישירה בין tenants ולהגן על ה-tenant Pods מפני מתקפות סייבר. כל אלו ממומשים באמצעות מכניקות בידוד משאבים של Kubernetes עצמו - כמו RBAC, מדיניות Pod Security, מדיניות הרשת, בקרת מנהלים ו-Sandbox Runtime. ניתן להגדיר מספר פרופילים שונים של אבטחה, ולהפעיל אותם עבור דרישות בידוד משאבים שונות. בנוסף לכך, מכסות המשאבים, chargeback וגבייה מתרחשים ברמת ה-tenant.
איך VC מוסיף לשכבת ה-View?
כקונספט, ה-VC מוסיף שכבת View נוספת על הפתרון של קבוצת ה-namespace (ניתן למצוא את הפרטים הטכניים כאן). ב-VC, ה-Tenant admin עדיין צריך להשתמש באותו ה-CRD שהשתמשו בו ב-namespace group בכדי להגדיר את חשבונות המשתמשים, את ה-namespaces ואת מדיניות בידוד המשאבים ב-Super master.
כמו שניתן לראות בתרשים 2, הודות ל-View layer החדש של ה-VC, המשתמשים יכולים ליהנות ממספר נקודות גישה שונות ומ-tenant resource views . במקום לגשת ל-Super master ולצפות ב-namespace בצורה ישירה, אותם משתמשים מתקשרים עם masters ייעודיים בכדי לנצל את המשאבים המוצעים להם, ובנוסף לכך הם נהנים מגישה מלאה ל-K8s master views. כל הבקשות מסתנכרנות אל ה -Super master על ידי אשף הסנכרון, היוצר משאבים מותאמים אישית שעוקבים אחר מדיניות בידוד המשאבים הנמצאת ב-CRD. יחד עם זאת, ה-VC בעיקר משנה את ה-user view של ה-tenants מ-namespaces אל APIserver. מנקודת המבט של ה-Super master, אותם הליכי עבודה מופעלים על ידי בקרת ה-tenants ובהתאם ל-CRD.
היתרונות של ה- View Extension ב-VC
שימוש ב-view של VC על view קיים של namespace יכול להקנות לכם מספר יתרונות:
• מדובר בדרך נוחה וגמישה לניהול משאבי ה- tenant עבור המשתמשים. לדוגמא - בהיררכיית namespace (אותה ניתן לראות בתרשים 3 א'), ניתן לפתור בקלות בעיות כמו קונפליקטים הקשורים לשמות, נראות ה-name space , ניהול משאבי ה- tenant בתת-מחיצות ועוד. יחד עם זאת, מאוד בעייתי לשנות את ה- native K8s Master למצב בו הוא יוכל לתמוך ב-namespaces שהם nested. על ידי ה- view של ה-VC , כל ה-namespaces שנוצרו ב-tenant master (ביחד עם קבוצת ה-namespace התואמת ב- super master), יוכלו לתת לכם תוצאות דומות לאלו של שימוש ב-nested namespaces.
כפי שניתן לראות בתרשים 3 ב', המשתמשים יוכלו להשתמש ביצירת namespaces בשירות עצמי ב-tenant master, זאת מבלי לדאוג לקונפליקטים בשמות עם tenants אחרים. הקונפליקט נפתר בזכות מנהל הסנכרון, המוסיף את אותם namespaces אל ה-super master namespace group. ה-tenants בקבוצה א' לא יוכלו לראות את אלו שנמצאים בקבוצה ב', מפני שיש להם מאסטר שונה. כך גם קל ליצור מדיניות בהתאמה אישית עבור משתמשים שונים, שייאכפו רק עבור ה-tenant master הספציפי.
עם ה-View Extension , בידוד המשתמשים והאבטחה נחשבים לטובים יותר, מפני שלכל קבוצה יש את ה-K8s master שלה. בזכות החלוקה הנ"ל, מתקפות DDos, בעיות גישה ל-API , בידוד בקרי tenants ועוד - כבר לא מהווים בעיה.
• ניתן ליצור cluster scope objects ב-tenant masters מבלי להשפיע על tenants אחרים. לדוגמא, משתמש יוכל ליצור CRD, ClusterRole/ClusterRoleBinding, PersistentVolume, ResourceQuota, ServiceAccount, NetworkPolicy בחופשיות, מבלי לדאוג לקונפליקט כלשהו עם ה-tenants האחרים.
• שימוש ב- View Extension מוריד את עומס הסקייליביליטי על ה-super master . כעת תוכלו להעביר את חוקי ה- RBAC, המדיניות ואת המשתמשים המנוהלים- היישר מה- super master אל ה-tenant masters , בהם תוכלו לבצע סקיילינג אינדיווידואלי. בנוסף לכך, ה-tenant controllers וה-operators access מגיעים למספר tenant masters במקום super master אחד, וגם להם ניתן לבצע סקיילינג אינדיווידואלי.
• קל יותר ליצור משתמשים עבור tenant user. בימינו, אם משתמש כזה רוצה לחשוף את המשאבים שלו עבור משתמשים אחרים (למשל, ראש צוות רוצה לתת לחברי הצוות להשתמש במשאבים שהוקצו אליהם), האדמין צריך ליצור את כל המשתמשים, מה שיכול להיות בעייתי במיוחד בארגונים גדולים השימוש ב-VC מונע את עומס זה בקלות.
הגבלות
מכיוון שה-VC בעיקר מוסיף ל- multi-tenancy view option ומונע בעיות הקשורות לחלוקה של ה-apiserver , הוא יורש את אותן המגבלות והאתגרים של פתרון ה-namespace group בכל הקשור להתאמה של ה- kubernetes node components ל- tenant. לכן, צריך לתת להם את השיפורים הבאים:
• תוסף Kubelet and CNI – דאגו לכך שהם יתמכו ב-.tenant כך תוכלו ליהנות מתרחישי בידוד רשת איכותיים כמו VPC.
• Kube-proxy/Kube-dns – עליהם להיות מותאמים ל- tenant בכדי לאפשר cluster-IP, הנחוץ עבור חלק מהשירותים הקשורים לנושא.
• כלים: לדוגמא, כלי ניטור צריכים להיות מתאימים ל- tenant בכדי למנוע דליפה של מידע הקשור אליהם. כלים לשיפור ביצועים צריכים לקבל התאמה גם הם בכדי למנוע הפרעות ביצועים בין tenants שונים.
לסיכום, כל VC זקוק למשאבים נוספים בכדי להריץ את ה- tenant master עבור כל אחד מה-tenants, מה שעלול להוביל להוצאות גדולות יותר.
מסקנות
VC מרחיב את האפשרויות של פתרון ה-namespace באמצעות Cluster view ידידותי למשתמש. הוא ממנף את מכניקות בידוד המשאבים של K8s, את ה-CRD וכלי הבקרה, וגם מציע לכם להשתמש ב-dedicated tenant cluster . בסופו של יום, אנחנו מאמינים שה- VC, ביחד עם namespace המבוסס על multi-tenancy יכול להציע לכם פתרונות מקיפים עבור תרחישי שימוש הקשורים ל-Kubernetes multi-tenancy ב- production clusters, ואנו פועלים לכך שעוד קהילות ומשתמשים ייחשפו לאפשרויות החדשות.
מאת: מערכת IsraelClouds
רוצים להתעדכן בתכנים נוספים בנושאי ארכיטקטורת ענן? הצטרפו לפורום המקצועי של IsraelClouds בתחום > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר