תכונות התוכנית לכלל המכשירים בארגון

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

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

שיטות מומלצות לאימוץ תכונות

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

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

הטמעה של תכונות עם סיכון נמוך

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

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

הפעלת תכונות מתקדמות של כמה אשכולות

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

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

בדיקה אם מרחבי השמות זהים

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

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

  • בכל אשכול, אותם כללי RBAC נמצאים באשכול, ולגורמים המורשים במרחב השמות יש גישה למרחב השמות.
  • קבוצת התמונות שמשמשת את ה-Pods (ללא הגיבוב או התג) זהה.
  • קבוצת הסודות שבהם נעשה שימוש ב-Pods זהה.

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

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

בדיקה אם השירותים זהים

אם אתם רוצים להשתמש ב-Cloud Service Mesh כדי לנהל את האפליקציות שמבוססות על מיקרו-שירותים, כדאי לשקול גם את הבעיה של דמיון בין שירותים. כלומר, לכל שילוב של מרחב שמות ושם שירות, Cloud Service Mesh יתייחס אליהם כשירות לוגי זהה מבחינת:

  • זהות (במיוחד לאבטחה של Cloud Service Mesh): אם ל-namespace1/service1 יש הרשאה לבצע פעולה מסוימת, עומסי עבודה עם הזהות הזו מכל אשכול מורשים.
  • ניהול תנועה: כברירת מחדל, התנועה מאוזנת בין שירותי namespace1/service1 בכל אשכול.
  • יכולת צפייה: המדדים של namespace1/service1 בכל האשכולות מצטברים יחד.

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

חשוב במיוחד לוודא ששירותים שונים מבחינה לוגית (לדוגמה, API של הנהלת חשבונות של תשלומים ו-API של טרנזקציות תשלום) לא משתמשים באותו צמד [מרחב שמות, שם] (לדוגמה payments/api), כי הם ייחשבו כשירות זהה ברגע שהם יהיו ב-Service mesh. האיחוד הזה מתרחש גם בין גבולות אזוריים. בנוסף, יכול להיות שהפונקציונליות של השירותים תושפע.

שירותים מרובי אשכולות (MCS) ושערים מרובי אשכולות (MCG) מניחים גם הם שמרחב השמות או השם של השירות זהים כשמפנים תנועה לשירותים בכמה אשכולות, אבל רק לשירותים שחשופים מחוץ לאשכולות.

שימוש ב-Workload Identity

תכונה חשובה של צי היא איחוד שירותי אימות הזהות של עומסי עבודה בכל הצי. התכונה הזו מרחיבה את היכולות שזמינות ב-Workload Identity Federation ל-GKE, שמאפשרת לעומסי העבודה באשכול שלכם לבצע אימות ב-Google בלי שתצטרכו להוריד, להחליף באופן ידני ולנהל באופן כללי Google Cloud מפתחות של חשבונות שירות. במקום זאת, עומסי העבודה עוברים אימות באמצעות טוקנים לזמן קצר שנוצרים על ידי האשכולות, כאשר כל אשכול מתווסף כספק זהויות למאגר זהויות מיוחד של עומסי עבודה. עומסי עבודה שפועלים במרחב שמות ספציפי יכולים לחלוק את אותה זהות לניהול זהויות והרשאות גישה (IAM) באשכולות שונים.

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

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

הגדרות ברירת מחדל ברמת הצי

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

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

דרישות לגבי תכונות

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

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

תכונה
 סוגי אשכולות
 דרישות הפרויקט
 דרישות לגבי VPC
סנכרון תצורות כל האשכולות הנתמכים ב-GKE ללא ללא
Policy Controller כל האשכולות הנתמכים ב-GKE ללא ללא
Cloud Service Mesh מידע נוסף על מגבלות כל האשכולות שמשמשים עם Cloud Service Mesh שנמצאים באותו פרויקט חייבים להיות רשומים לאותו צי. מידע נוסף זמין במאמר בנושא דרישות לצי Cloud Service Mesh. אשכולות GKE צריכים להיות באותה רשת VPC.
שירותים מרובי אשכולות (MCS) ‫GKE ב- Google Cloud ללא מידע נוסף על MCS ב-VPC משותף
Multi Cluster Ingress ו-Multi Cluster Gateway ‫GKE ב- Google Cloud משאבי Ingress/Gateway, אשכולות GKE וצי צריכים להיות באותו פרויקט. משאבי Ingress/Gateway ואשכולות GKE צריכים להיות באותה רשת VPC.
מאגר זהויות של כוח עבודה מותאם ל-GKE ב- Google Cloud ול-Google Distributed Cloud ב-VMware. יש תמיכה באשכולות Kubernetes אחרים, אבל נדרשת עבודת הגדרה נוספת. ללא ללא
Binary Authorization ‫GKE on Google Cloud, ‏ Google Distributed Cloud on VMware,‏ Google Distributed Cloud on bare metal ללא ללא
Advanced Vulnerability Insights ‫GKE ב- Google Cloud ללא ללא
מצב אבטחה ‫GKE ב- Google Cloud ללא ללא
סטטוס העמידה בהוראות הדין ‫GKE ב- Google Cloud ללא ללא
מדדי ניצול משאבים של צי הרכבים ‫GKE ב- Google Cloud ללא ללא
רישום ביומן של כלל המכשירים בארגון הכול ללא ללא
חיבור שער הכול ללא ללא
ניהול צוותים ב-Fleet הכול ללא ללא
כללי מדיניות הרשת של Pod FQDN ‫GKE ב- Google Cloud ללא ללא
הצפנה שקופה בין צמתים ‫GKE ב- Google Cloud ללא ללא
Config Controller לא רלוונטי ללא ללא
השקה מדורגת ‫GKE ב- Google Cloud ללא ללא

דרישות של ענן וירטואלי פרטי (VPC)

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

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

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

אם רוצים להשתמש ב-Multi Cluster Ingress או ב-Gateways מרובי-אשכולות לניהול תנועה, חשוב לדעת שבשני המקרים בקר ה-Gateway לא יכול לפעול בכמה פרויקטים. כלומר, כל האשכולות שרוצים להשתמש בהם בתכונות האלה צריכים להיות באותו פרויקט ובאותו צי. אם אתם צריכים ליצור צי של מכונות שכולל אשכולות מכמה פרויקטים, אתם יכולים להשתמש במקום זאת בשערי כניסה של אשכול יחיד, ולהפנות את התנועה לשער הכניסה הנכון בדרך אחרת (לדוגמה, באמצעות DNS). גם האשכולות שמשתמשים בתכונות האלה צריכים להיות באותה רשת VPC.

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