שירותים מרובי אשכולות

בדף הזה מוסבר איך פועלים שירותים מרובי אשכולות (MCS) ב-GKE. במאמר הגדרת שירותים מרובי אשכולות מוסבר איך להשתמש ב-MCS.

סקירה כללית של MCS

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

‫MCS הוא מנגנון להפעלת שירותים ולזיהוי שירותים בין אשכולות ב-Google Kubernetes Engine‏ (GKE), שמסתמך על אובייקט השירות הקיים. אפשר לגלות שירותים שמופעלים באמצעות התכונה הזו ולגשת אליהם באשכולות עם כתובת IP וירטואלית, בהתאם להתנהגות של שירות ClusterIP שאפשר לגשת אליו באשכול. בדומה לשירותים הקיימים שלכם, MCS תואם לממשקי API מבוססי-קהילה ופתוחים, וכך מבטיח שעומסי העבודה שלכם יישארו ניידים.

‫MCS היא תכונה של GKE. ‫MCS מגדיר תחום DNS ורשומות של Cloud DNS לכל שירות שמיוצא באשכולות של ה-Fleet. בעזרת Fleet אפשר לקבץ באופן לוגי ולנרמל את אשכולות GKE, וכך לנהל את התשתית בקלות רבה יותר ולהשתמש בתכונות של כמה אשכולות, כמו MCS. במסמכי הניהול של צי הרכבים יש מידע נוסף על היתרונות של צי רכבים ועל אופן היצירה שלו.

לשירותים מיוצאים, ללא קשר לסוג, תמיד יש רשומת DNS אחת של Cloud DNS, ולשירותים מיוצאים מסוג Headless יש רשומות לכל Pod של backend עם שם מארח, כולל Pods ב-StatefulSets. השימוש ב-Cloud DNS כרוך בחיובים נוספים. החיוב מתבצע בהתאם לתמחור של Cloud DNS.

כדי לייצא שירות באמצעות MCS, יוצרים משאב מותאם אישית מסוג ServiceExport באמצעות אותו מרחב שמות ואותו שם כמו השירות. ‫MCS מייבא באופן אוטומטי את השירות לכל אשכול ב-fleet. כש-MCS מייבא שירות, הוא יוצר:

  • משאב מותאם אישית מסוג ServiceImport שמשתמש באותו מרחב שמות ובאותו שם כמו השירות.
  • אובייקט Endpoints שמשתמש באותו מרחב שמות כמו השירות ובשם אקראי.

היתרונות של שימוש ב-MCS

השימוש ב-MCS מספק לכם את היתרונות הבאים:

  • זמינות גבוהה: הרצת אותו שירות באשכולות בכמה אזורים מספקת עמידות משופרת בפני תקלות. אם שירות באשכול לא זמין, הבקשה יכולה לעבור לשירות אחר באשכולות אחרים. באמצעות MCS אפשר לנהל את התקשורת בין שירותים באשכולות שונים, כדי לשפר את הזמינות של האפליקציות בקונטיינרים.
  • שירותים עם שמירת מצב (stateful) וללא שמירת מצב (stateless): לשירותים עם שמירת מצב וללא שמירת מצב יש יחסי תלות תפעוליים ומורכבויות שונות, והם מציגים פשרות תפעוליות שונות. בדרך כלל, היעדר ניהול מצב מקל על הרחבת עומס עבודה, שדרוג שלו והעברה שלו עם זמינות גבוהה יותר. באמצעות MCS אפשר להפריד בין אשכולות של עומסי עבודה עם שמירת מצב (stateful) וללא שמירת מצב (stateless), ולהפוך אותם לעצמאיים, מבודדים וקלים יותר לניהול.
  • שירותים משותפים: נהוג ליצור אשכולות נפרדים של Kubernetes כדי להשיג זמינות גבוהה יותר, ניהול טוב יותר של שירותים עם מצב (stateful) ושירותים ללא מצב (stateless), וקלות רבה יותר בתאימות לדרישות של ריבונות נתונים. עם זאת, הרבה שירותים כמו מעקב באמצעות Prometheus או שימוש בניהול סודות באמצעות Vault משותפים בדרך כלל לכל האשכולות. במקום שכל אשכול ידרוש רפליקה מקומית משלו של Service, בעזרת MCS קל יותר להגדיר שירותים משותפים נפוצים באשכול נפרד שכל האשכולות הפונקציונליים משתמשים בו.
  • העברה: מודרניזציה של אפליקציה קיימת לארכיטקטורה מבוססת מיקרו-שירותים בקונטיינרים מחייבת לעיתים קרובות פריסה של שירותים בכמה אשכולות Kubernetes. ‫MCS מספק מנגנון שעוזר לגשר על התקשורת בין השירותים האלה, וכך קל יותר להעביר את האפליקציות. זה שימושי במיוחד כי אפשר לפרוס את אותו שירות בשני אשכולות שונים, והתנועה יכולה לעבור מאשכול או מאפליקציה אחת לאחרת.

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