בדף הזה מוסבר איך צי של מכונות עוזר לכם לנהל פריסות של כמה אשכולות, כולל כמה מונחים ומושגים חשובים שקשורים לצי. Fleets הם Google Cloud קונספט לארגון לוגי של אשכולות ומשאבים אחרים, שמאפשר לכם להשתמש ביכולות של ריבוי אשכולות ולנהל אותן, ולהחיל מדיניות עקבית על המערכות שלכם. הציים הם חלק חיוני באופן הפעולה של פונקציונליות מרובת אשכולות ב- Google Cloud.
המדריך הזה מיועד לקוראים טכניים, כולל מומחי ארכיטקטורת מערכות, מפעילים של פלטפורמות ומפעילים של שירותים, שרוצים להשתמש בכמה אשכולות ובתשתית קשורה. המושגים האלה שימושיים בכל מקום שבו הארגון מפעיל כמה אשכולות, בין אם ב-Google Cloud, אצל כמה ספקי ענן או במקום.
לפני שקוראים את הדף הזה, חשוב לוודא שמכירים מושגי יסוד ב-Kubernetes כמו אשכולות ומרחבי שמות. אם לא, אפשר לעיין במאמר יסודות Kubernetes, במסמכי GKE ובמאמר הכנת אפליקציה ל-Cloud Service Mesh.
הסברים על המונחים
בהמשך מפורטים כמה מונחים חשובים שבהם אנחנו משתמשים כשמדברים על צי רכבים.
משאבים שמודעים לצי
משאבים שמודעים ל-Fleet הם Google Cloud משאבים ברמת הפרויקט שאפשר לקבץ ולנהל באופן לוגי כ-Fleets. נכון לעכשיו, רק אשכולות Kubernetes יכולים להיות חברים ב-Fleet.
פרויקט המארח של ה-Fleet
ההטמעה של Fleet, כמו של משאבים רבים אחרים של Google Cloud , מתבססת על Google Cloud פרויקט, שאנחנו מכנים אותו פרויקט המארח של ה-Fleet. לפרויקט Google Cloud מסוים יכול להיות משויך רק צי אחד (או שלא יהיה משויך לו צי בכלל). ההגבלה הזו מחזקת את השימוש ב Google Cloud פרויקטים כדי לספק הפרדה חזקה יותר בין משאבים שלא מנוהלים או נצרכים יחד.
קיבוץ תשתיות
הקונספט הראשון והחשוב של ציוד הוא קיבוץ – כלומר, בחירה של חלקי משאבים קשורים שמכירים את הציוד שצריכים להיות חלק מהציוד. כדי להחליט מה לקבץ, צריך לענות על השאלות הבאות:
- האם המשאבים קשורים זה לזה?
- הכי כדאי לנהל יחד במערך משאבים שכוללים כמויות גדולות של תקשורת בין שירותים.
- משאבים באותה סביבת פריסה (לדוגמה, סביבת הייצור) צריכים להיות מנוהלים יחד בצי.
- מי מנהל את המשאבים?
- שליטה מאוחדת (או לפחות מהימנה הדדית) במשאבים היא חיונית כדי להבטיח את תקינות הצי.
כדי להמחיש את הנקודה הזו, נניח שיש ארגון עם כמה קווי עסקים (LOB). במקרה כזה, השירותים כמעט אף פעם לא מתקשרים בין קווי המוצרים, השירותים בקווי מוצרים שונים מנוהלים בצורה שונה (לדוגמה, מחזורי השדרוג שונים בין קווי המוצרים), ויכול להיות שיהיה להם אפילו סט שונה של אדמינים לכל קו מוצרים. במקרה כזה, יכול להיות שכדאי להגדיר צי רכבים לכל קו עסקי. בנוסף, סביר להניח שכל קו עסקי יאמץ כמה ציודים כדי להפריד בין שירותי הייצור לבין שירותים אחרים.
בקטעים הבאים נסביר על מושגים נוספים שקשורים לצי מכוניות, ואולי תמצאו סיבות נוספות ליצירת כמה ציודים בהתאם לצרכים הספציפיים של הארגון שלכם.
דמיון
מושג חשוב בציים הוא מושג הדמיון. המשמעות היא שכאשר משתמשים בתכונות מסוימות שמופעלות בצי, אובייקטים מסוימים של Kubernetes, כמו מרחבי שמות עם אותו שם באשכולות שונים, נחשבים לאותו דבר. הנורמליזציה הזו מתבצעת כדי להקל על ניהול משאבי הצי. אם אתם משתמשים בתכונות שמסתמכות על זהות, ההנחה הזו מספקת הנחיות חשובות לגבי הגדרת מרחבי שמות, שירותים וזהויות. עם זאת, הוא גם תואם למה שגילינו שרוב הארגונים כבר מיישמים בעצמם.
סוגים שונים של דמיון מספקים יתרונות שונים, כפי שמוצג בטבלה הבאה:
| מאפיין הזהות | אפשרות ל... |
|---|---|
| מרחב שמות נחשב זהה בכמה אשכולות. |
|
| שילוב של מרחב שמות ושם שירות נחשב זהה בכמה אשכולות. שירותים עם אותו שם באותו מרחב שמות משתמשים באותו בורר תוויות. |
|
| שילוב של מרחב שמות וחשבון שירות (זהות) נחשב זהה בכמה אשכולות. |
|
כפי שאפשר להבין, תכונות שונות של צי הרכבים מסתמכות על סוגים שונים של זהות. יש מספר קטן יותר של תכונות שלא משתמשות בכלל במושג הזה. מידע נוסף על הנושא הזה זמין במאמר באילו תכונות נעשה שימוש בדמיון?, כולל באילו תכונות אפשר להשתמש בלי להתייחס לדמיון בכל הצי ובאילו תכונות נדרש תכנון קפדני יותר.
דמיון במרחב השמות
דוגמה בסיסית לזהות בצי היא זהות מרחב שמות. מרחבי שמות עם אותו שם באשכולות שונים נחשבים זהים על ידי הרבה תכונות של צי. דרך נוספת לחשוב על המאפיין הזה היא שמרחב שמות מוגדר באופן לוגי בכל צי הרכבים, גם אם מופע של מרחב השמות קיים רק בקבוצת משנה של משאבי צי הרכבים.
הנה דוגמה למרחב שמות backend. למרות שמרחב השמות מופעל רק באשכולות A ו-B, הוא שמור באופן מרומז באשכול C (הוא מאפשר לתזמן שירות במרחב השמות backend גם באשכול C אם יש צורך בכך).
המשמעות היא שהמרחבים לשמות מוקצים לכל צי המכונות ולא לכל אשכול. לכן, כדי שמרחבי השמות יהיו זהים, הבעלות על מרחבי השמות צריכה להיות עקבית בכל הצי.
דמיון בין שירותים
Cloud Service Mesh ו-Multi Cluster Ingress משתמשים במושג של זהות השירותים במרחב שמות. בדומה לזהות מרחב השמות, זה מרמז ששירותים עם אותו מרחב שמות ואותו שם שירות נחשבים לאותו שירות.
במקרה של Cloud Service Mesh, אפשר למזג את נקודות הקצה של השירות ברשת. ב-Multi Cluster Ingress, משאב MultiClusterService (MCS) הופך את מיזוג נקודות הקצה למפורש יותר. עם זאת, מומלץ להשתמש בשיטות דומות לגבי מתן שמות. לכן, חשוב לוודא ששירותים עם שמות זהים באותו מרחב שמות הם באמת אותו דבר.
בדוגמה הבאה, איזון העומסים של תעבורת האינטרנט מתבצע בשירות בעל אותו שם במרחב השמות frontend שקיים באשכולות ב' ו-ג'. באופן דומה, באמצעות המאפיינים של Service mesh בתוך הצי, השירות במרחב השמות frontend יכול להגיע לשירות באותו שם במרחב השמות auth שקיים באשכולות א' ו-ג'.
זהות זהה כשניגשים למשאבים חיצוניים
בעזרת איחוד זהויות של עומסי עבודה בצי, שירותים בצי יכולים להשתמש בזהות משותפת כשהם יוצאים כדי לגשת למשאבים חיצוניים כמו Google Cloud שירותים, מאגרי אובייקטים וכו'. הזהות המשותפת הזו מאפשרת לתת לשירותים בצי גישה למשאב חיצוני פעם אחת במקום בכל אשכול בנפרד.
כדי להמחיש את הנקודה הזו, נביא את הדוגמה הבאה. אשכולות A, B ו-C רשומים לזהות משותפת בצי שלהם. כששירותים במרחב השמות backend ניגשים למשאבים, הזהויות שלהם ממופות לחשבון שירות משותף Google Cloud שנקרא back. Google Cloud אפשר לתת הרשאה לGoogle Cloud חשבון השירות back בכל מספר של שירותים מנוהלים, מ-Cloud Storage ועד Cloud SQL. כשמוסיפים משאבים חדשים לצי, כמו אשכולות, במרחב השמות backend, הם מקבלים בירושה באופן אוטומטי את מאפייני הזהות של כוח העבודה.
בגלל הזהות הזהה, חשוב שכל המשאבים בצי יהיו מהימנים ומנוהלים היטב. נחזור לדוגמה הקודמת: אם אשכול ג' נמצא בבעלות של צוות נפרד שלא מהימן, גם הצוות הזה יכול ליצור מרחב שמות backend ולגשת לשירותים מנוהלים כאילו הם backend באשכול א' או ב'.
זהות זהה בצי
בצי, המערכת משתמשת בזהות זהה באופן דומה לזהות זהה חיצונית שדיברנו עליה קודם. בדיוק כמו ששירותים לניהול צי רכבים מקבלים הרשאה פעם אחת לשירות חיצוני, הם יכולים לקבל הרשאה גם לשירות פנימי.
בדוגמה הבאה, אנחנו משתמשים ב-Cloud Service Mesh כדי ליצור רשת שירותים מרובת אשכולות שבה לשירות frontend יש גישה לשירות backend.
עם Cloud Service Mesh ועם fleets, לא צריך לציין ש-frontend באשכולות ב' ו-ג' יכול לגשת ל-backend באשכולות א' ו-ב'. במקום זאת, אנחנו מציינים רק שמשתמשים ב-frontend יכולים לגשת ל-backend. המאפיין הזה לא רק מפשט את ההרשאה, אלא גם הופך את גבולות המשאבים לגמישים יותר. עכשיו אפשר להעביר בקלות עומסי עבודה מאשכול לאשכול בלי להשפיע על אופן ההרשאה שלהם. בדומה לזהות של עומסי עבודה, ניהול המשאבים של הצי הוא חיוני כדי להבטיח את התקינות של התקשורת בין שירותים.
באילו תכונות נעשה שימוש במושג 'זהות'?
חלק מהתכונות של צי הרכבים לא מסתמכות על דמיון בכלל, ואפשר להפעיל אותן ולהשתמש בהן בלי לחשוב אם רוצים להניח דמיון כלשהו בצי הרכבים. תכונות אחרות (כולל סנכרון תצורות ו-Policy Controller) יכולות להשתמש בתכונה 'זהות' – לדוגמה, אם רוצים לבחור מרחב שמות בכמה אשכולות של חברי צי, לצורך הגדרה ממקור אמת יחיד – אבל הן לא מחייבות אותה לכל תרחישי השימוש. לבסוף, יש תכונות כמו Multi Cluster Ingress ואיחוד שירותי אימות הזהות של עומסי עבודה בכל האוסף, שתמיד מניחות שיש מידה מסוימת של דמיון בין האשכולות, ויכול להיות שיהיה צורך להשתמש בהן בזהירות בהתאם לצרכים ולעומסי העבודה הקיימים.
חלק מהתכונות של צי השרתים (כמו איחוד שירותי אימות הזהות של עומסי עבודה בצי השרתים) מחייבות שכל צי השרתים יהיה מוכן להנחות של זהות שמשמשות אותן. תכונות אחרות, כמו ניהול צוותים, מאפשרות לכם להצטרף בהדרגה לאחידות ברמת מרחב השמות או היקף הצוות.
בטבלה הבאה מפורטות התכונות שדורשות אחד או יותר מהמושגים שקשורים לדמיון שמתוארים בקטע הזה.
| תכונה | תמיכה בהטמעה הדרגתית של תכונת הדמיון ההדרגתי | תלוי בדמיון של מרחב השמות | תלוי אם השירותים זהים | תלוי בדמיון הזהות |
|---|---|---|---|---|
| ציים | לא רלוונטי | לא | לא | לא |
| Binary Authorization | לא רלוונטי | לא | לא | לא |
| הצפנה שקופה בין צמתים | לא רלוונטי | לא | לא | לא |
| מדיניות רשת שמבוססת על שם דומיין שמוגדר במלואו | לא רלוונטי | לא | לא | לא |
| חיבור שער | לא רלוונטי | לא | לא | לא |
| סנכרון תצורות | לא רלוונטי | לא | לא | לא |
| Policy Controller | לא רלוונטי | לא | לא | לא |
| GKE Security Posture | לא רלוונטי | לא | לא | לא |
| Advanced Vulnerability Insights | לא רלוונטי | לא | לא | לא |
| סטטוס העמידה בהוראות הדין | לא רלוונטי | לא | לא | לא |
| רצף השקה | לא רלוונטי | לא | לא | לא |
| ניהול צוותים | כן | כן | כן | לא |
| Multi Cluster Ingress | כן | כן | כן | כן |
| Multi Cluster Services | כן | כן | כן | כן |
| איחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet | לא | כן | כן | כן |
| Cloud Service Mesh | לא | כן | כן | כן |
בלעדיות
משאבים שמודעים לצי יכולים להיות חברים בצי אחד בלבד בכל זמן נתון. ההגבלה הזו נאכפת על ידי כלים ורכיבים של Google Cloud . המגבלה הזו מבטיחה שיהיה רק מקור אמת אחד ששולט באשכול. בלי בלעדיות, אפילו הרכיבים הפשוטים ביותר יהפכו למסובכים לשימוש, וידרשו מהארגון שלכם להבין ולהגדיר איך רכיבים מצי מכוניות שונים יפעלו יחד.
מהימנות גבוהה
התכונות 'זהות שירות זהה', 'זהות עומס עבודה זהה' ו'זהות רשת זהה' מבוססות על עיקרון של אמון גבוה בין חברי צי. האמון הזה מאפשר לנהל את המשאבים האלה ברמת הצי, במקום לנהל אותם ברמת המשאב (כלומר, ברמת האשכול למשאבי Kubernetes), ובסופו של דבר הופך את הגבול בין האשכולות לפחות חשוב.
במילים אחרות, בצי של מכונות, אשכולות מספקים הגנה מפני בעיות שקשורות לרדיוס הפיצוץ, זמינות (של מישור הבקרה והתשתית הבסיסית), שכנים רועשים וכן הלאה. עם זאת, הם לא מהווים גבול בידוד חזק למדיניות ולניהול, כי אדמינים של כל חבר בצי יכולים להשפיע על הפעולות של שירותים בחברים אחרים בצי.
לכן מומלץ למקם אשכולות שלא מהימנים על ידי מנהל הצי בצי משלהם כדי לבודד אותם. לאחר מכן, לפי הצורך, אפשר לתת הרשאה לשירותים ספציפיים מעבר לגבולות הצי.
Team scopes
היקף צוות הוא מנגנון לחלוקה נוספת של צי המחשבים לקבוצות של אשכולות, שמאפשר לכם להגדיר את המשאבים שמודעים לצי המחשבים שהוקצו לצוות אפליקציה ספציפי. בהתאם לתרחיש השימוש, אפשר לשייך קלאסטר של חבר צי שלם לאף צוות, לצוות אחד או לכמה צוותים, וכך לאפשר לכמה צוותים לשתף קלאסטרים. אפשר גם להשתמש בהיקפי צוות כדי לנהל את הפריסה של שדרוגי אשכולות בכל הצי, אבל בשביל זה כל אשכול צריך להיות משויך רק לצוות אחד.
היקף צוות יכול לכלול מרחבי שמות של צי מכשירים שהוגדרו באופן מפורש ומשויכים אליו, כאשר מרחב השמות נחשב זהה בהיקף. כך מקבלים שליטה טובה ומפורטת יותר במרחבי שמות מאשר השוואה בין מרחבי שמות שמוגדרת כברירת מחדל ב-Fleets.
רכיבים שמופעלים בכל המכשירים בארגון
כל הרכיבים הבאים מסתמכים על מושגים של Fleet, כמו מרחב שמות וזהות זהה, כדי לספק דרך פשוטה לעבודה עם האשכולות והשירותים. בדרישות הרכיבים מפורטות הדרישות או המגבלות הנוכחיות לשימוש בציים עם כל רכיב.
מאגרי זהויות של עומסי עבודה
בצי יש מאגר זהויות של עומסי עבודה משותף שאפשר להשתמש בו כדי לאמת ולאשר עומסי עבודה באופן אחיד בתוך Service mesh ולשירותים חיצוניים.Cloud Service Mesh
Cloud Service Mesh היא חבילת כלים שעוזרת לכם לנטר ולנהל רשת Service mesh אמינה ב- Google Cloud, בתשתית מקומית ובסביבות נתמכות אחרות. אפשר ליצור Service mesh בין אשכולות ששייכים לאותו צי.סנכרון תצורות
סנכרון תצורות מאפשר לפרוס ולנטר חבילות של הגדרות הצהרתיות למערכת שמאוחסנות במקור מרכזי של נתונים מהימנים, כמו מאגר Git, תוך שימוש במושגי ליבה של Kubernetes כמו מרחבי שמות, תוויות והערות. בעזרת סנכרון תצורות, ההגדרות מוגדרות בכל צי המכונות, אבל הן מוחלות ונאכפות באופן מקומי בכל אחד מהמשאבים החברים.Policy Controller
Policy Controller מאפשר להחיל ולאכוף מדיניות הצהרתית עבור אשכולות Kubernetes. המדיניות הזו פועלת כהגנה ועוזרת לכם ליישם שיטות מומלצות, לשמור על האבטחה ולנהל את התאימות של האשכולות והצי שלכם.Multi Cluster Ingress
Multi Cluster Ingress משתמש ב-Fleet כדי להגדיר את קבוצת האשכולות ונקודות הקצה של השירותים שאפשר לבצע איזון עומסים של תעבורת הנתונים ביניהם, וכך מאפשר שירותים עם זמן אחזור נמוך וזמינות גבוהה.
מה השלב הבא?
- במאמר תרחישי שימוש בריבוי אשכולות אפשר לקרוא מידע נוסף על המקרים שבהם כדאי להשתמש בכמה אשכולות כדי לענות על הצרכים הטכניים והעסקיים שלכם.
- מוכנים לחשוב על יישום של המושגים האלה במערכות שלכם? מידע נוסף על תכנון משאבים לצי הרכבים