כמו שלמדתם בסקירה הכללית על ניהול צי, צי הוא מנגנון לקיבוץ שמאפשר לנהל, להגדיר ולאבטח אשכולות Kubernetes בהיקף גדול. Fleets הם כלי רב עוצמה שמבטל את הצורך לבצע פעולות חוזרות בסביבה מרובת אשכולות, ומספק עקביות ויכולת תצפית מקיפה על קבוצות גדולות של אשכולות. חלק מהתכונות של GKE זמינות רק דרך Fleet.
אסטרטגיית הקיבוץ שבה אתם משתמשים כדי ליצור צי של מכשירים יכולה להשתנות בהתאם לצרכים הטכניים והעסקיים של הארגון. לדוגמה, ארגון אחד יכול לקבץ אשכולות לפי סוג האפליקציות שפועלות בהם, בעוד שארגון אחר יכול לקבץ אותם לפי אזור, סביבה או גורמים רלוונטיים אחרים. אם כל שאר התנאים שווים, כדאי שיהיו בארגון כמה שפחות ציודים.
המדריך הזה מיועד למומחי Cloud Architect שרוצים להתחיל להשתמש בציים בארגונים שלהם. הוא כולל הנחיות מעשיות לארגון האשכולות בצי, כולל:
- כשרוצים ליצור אשכולות חדשים לגמרי.
- כשרוצים ליצור צי עם אשכולות קיימים.
התבניות שמתוארות כאן מתאימות לארגונים רבים, אבל הן לא הדרך היחידה לתכנן צי רכבים. הציים גמישים, ואולי תחליטו להשתמש בתבנית קיבוץ שונה עבור האשכולות.
לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את המושגים הבאים:
- המושגים שמפורטים בסקירה הכללית על ניהול צי הרכבים.
- מושגים בסיסיים ב-Kubernetes ו Google Cloud היררכיית המשאבים.
הגבלות על צי ועל משאבים
המגבלות הכלליות הבאות חלות כשיוצרים צי רכבים:
- פרויקט נתון Google Cloud יכול להיות משויך רק לצי אחד (או לא לצי בכלל), אבל הצי הזה יכול לכלול אשכולות מכמה פרויקטים. הפרויקט שמשויך ל-Fleet נקרא פרויקט המארח של ה-Fleet.
- אפשר להוסיף אשכולות רק לצי אחד בכל זמן נתון.
- כל האשכולות בפרויקט נתון צריכים להיות באותו צי או לא להיות בצי בכלל. אם פרויקט כבר מכיל חברים ב-Fleet, אי אפשר לרשום אשכול מהפרויקט הזה ל-Fleet אחר.
- המכסה שמוגדרת כברירת מחדל למספר האשכולות בצי היא 250, אבל אפשר לבקש מכסה גבוהה יותר אם צריך.
יכולות להיות הרבה סיבות לכך שכדאי למקם כמה אשכולות באותו פרויקט. עם זאת, כשמתכננים אילו אשכולות לשלב בפרויקט, כדאי לקחת בחשבון את המגבלות הבאות:
- ברשת ענן וירטואלי פרטי (VPC) יכולים להיות עד 75 אשכולות פרטיים.
- אם אתם מתכננים להשתמש ב-Multi Cluster Ingress או ב-Multi-cluster Gateway, כדאי לעיין במגבלות על משאבי
MultiClusterIngressו-MultiClusterServiceבפרויקט. - קראו את המאמר בנושא מכסות ומגבלות ב-Compute Engine. לדוגמה, ב-Compute Engine יש מכסות הקצאה על משאבי מחשוב שמשמשים אשכול.
עקרונות כלליים
ריכזנו כאן שאלות כלליות שכדאי לשאול כשמחליטים אם לקבץ אשכולות בצי. בקטעים הבאים נסביר איך משתמשים בהם.
- האם המשאבים קשורים זה לזה?
- היתרון הגדול ביותר בניהול משותף של משאבים בצי הוא למשאבים שמתבצעת בהם כמות גדולה של תקשורת בין שירותים.
- מומלץ לנהל משאבים באותה סביבת פריסה (לדוגמה, סביבת הייצור) יחד בצי.
- מי מנהל את המשאבים?
- כדי להבטיח את התקינות של ה-Fleet, חשוב שיהיה לכם שליטה מאוחדת (או לפחות שליטה שמושתתת על אמון הדדי) במשאבים.
תכנון של צי מכונות לאשכולות חדשים
בקטע הזה מוסבר איך לתכנן את צי הרכבים כשאתם יודעים אילו אפליקציות יש לכם, אבל אתם גמישים לגבי המיקום שבו האפליקציות האלה יופעלו. יכול להיות שעדיין לא פיתחתם את האפליקציות האלה, או שאתם מעבירים אותן מפלטפורמת קונטיינרים אחרת. אפשרות אחרת היא שכבר יש לכם אפליקציות שפועלות באשכולות קיימים, אבל אתם מוכנים להעביר אפליקציות לאשכולות חדשים כדי להשיג ארכיטקטורה מועדפת.
אחרי שמזהים את צי הרכבים, אפשר ליצור פרויקט חדש לכל צי, ליצור צי בכל פרויקט וליצור ולרשום אשכולות לצי הרכבים הרצוי.
בדיקת עומסי העבודה
מתחילים עם רשימה של כל עומסי העבודה (workload) של Kubernetes (לדוגמה, Deployments) שרוצים לפרוס. לא חייבים ליצור רשימה מילולית, אפשר פשוט להבין אילו עומסי עבודה תצטרכו. לאחר מכן, פועלים לפי השלבים שבהמשך הקטע הזה כדי לחלק את קבוצת האפליקציות הזו לקבוצות משנה עד שמגיעים לקבוצה המינימלית של קבוצות שנדרשות. כך תוכלו להגדיר אילו ציודים ואשכולות אתם צריכים.
שימוש ביחידות עסקיות
יכול להיות שבארגון שלכם יש מבנה IT מאוחד, שבו יש צוות IT מרכזי אחד לארגון, וגם צוותי IT נפרדים לכל יחידה עסקית. במקרה כזה, כל צוות IT מאוחד יכול לנהל את צי המכשירים שלו. כדאי להשתמש בציים נפרדים אם עומסי העבודה של שתי יחידות עסקיות (לדוגמה, ביקורת ומסחר בבנק) לא יכולים לתקשר זה עם זה בכלל מסיבות רגולטוריות.
הפרדה בין עומסי עבודה לפי סביבה
דפוס נפוץ שמתאים לארגונים רבים הוא קיבוץ אשכולות לפי סביבה. הגדרה טיפוסית כוללת שלוש סביבות עיקריות: פיתוח, לא ייצור (או Staging) וייצור. בדרך כלל, שינויים באפליקציה נפרסים באופן הדרגתי (או מקודמים) לכל סביבה ברשימה. לכן, יש לכם פריסות נפרדות בכל סביבה לאותו יישום בסיסי, כמו אותו שם של קובץ אימג' בסיסי בקונטיינר. בדוגמה של תוכנית הבסיס לארגונים מוסבר איך ליצור סביבות בארגון.
צי צריך להכיל רק אשכולות מסביבה אחת. שלוש סביבות, עם צי אחד בכל סביבה, עשויות להספיק להרבה ארגונים. בתוכנית הפעולה של אפליקציה ארגונית יש דוגמה שבה לכל סביבה יש צי אחד, ומוסבר איך אפשר לפרוס אפליקציות באופן הדרגתי.
שילוב של מופעים מיותרים של עומסי עבודה
כשאפליקציה צריכה זמינות גבוהה, אחת הדרכים להשיג אותה היא להריץ את האפליקציה בשני אזורים או יותר. התהליך הזה כולל שני אשכולות או יותר שמריצים פריסות עם הגדרות דומות מאוד שמנוהלות כיחידה אחת. לרוב יש להם מאזן עומסים שמשתרע על מופעי אפליקציות בכל האשכולות, או שהם משתמשים באיזון עומסים של DNS.
בתרחישים האלה, צריך להציב את כל האשכולות האלה באותו צי. בדרך כלל אין צורך להפריד בין אשכולות באזורים שונים, אלא אם נדרש אחרת מסיבות רגולטוריות או אחרות.
תכנון צי של מכונות עם אשכולות קיימים
בקטע הזה מוסבר איך לתכנן ציי רכבים כשעומסי עבודה פועלים באשכולות קיימים, ואתם לא מתכננים להעביר אותם. יכול להיות שהאשכולות האלה נמצאים בתוך Google Cloudאו מחוץ לה. בתרחיש הזה, המטרה היא ליצור קבוצות של ציוד בארגון ולהקצות להן אשכולות קיימים.
אחרי שמזהים את ה-Fleets, אפשר ליצור פרויקט חדש לכל Fleet, ליצור Fleet בכל פרויקט ולרשום אשכולות ל-Fleet הרצוי.
בדיקת האשכולות
מתחילים עם רשימה של כל אשכולות Kubernetes בארגון. מאגר משאבי ענן הוא אחת הדרכים לחפש בארגון משאבי אשכול Kubernetes.
אחר כך אפשר לפעול לפי השלבים שבהמשך הקטע הזה כדי לחלק את קבוצת האפליקציות הזו לקבוצות משנה עד שמגיעים לקבוצה המינימלית של קבוצות שנדרשות. כך תוכלו להגדיר אילו צי רכבים אתם צריכים.
שימוש ביחידות עסקיות
יכול להיות שבארגון שלכם יש מבנה IT מאוחד, שבו יש צוות IT מרכזי אחד לארגון, וגם צוותי IT נפרדים לכל יחידה עסקית. יכול להיות שצוותי ה-IT האלה יצרו את האוספים הקיימים שלכם. בדרך כלל, במקרה כזה, מחלקים את קבוצת האשכולות לפי יחידה עסקית. לדוגמה, עומסי עבודה של יחידות עסקיות מסוימות (למשל, ביקורת ומסחר בבנק) לא יכולים לתקשר זה עם זה בכלל מסיבות רגולטוריות.
אם היחידות העסקיות קיימות רק למטרות של הנהלת חשבונות, אבל משתמשות בצוות IT משותף, כדאי לשקול לשלב את האשכולות שלהן בצי אחד, במיוחד אם יש תלות משמעותית בין השירותים ביחידות העסקיות.
קיבוץ אשכולות לפי סביבה
לזהות באילו סביבות משתמשים בארגון. שמות הסביבות הנפוצים הם dev, non-production (או staging) ו-prod.
אם כל אשכול נמצא בבירור רק באחת מהסביבות שלכם, צריך להפריד את רשימת האשכולות לפי סביבה. עם זאת, אם חלק מהאשכולות מכילים עומסי עבודה ששייכים באופן לוגי לסביבות שונות, מומלץ לפרוס מחדש את האפליקציות באשכולות שמכילים רק אפליקציות ששייכות לסביבה לוגית אחת.
צמצום מספר הבעלים של האשכול
כשמשלבים פרויקטים קיימים בצי, יכול להיות שיהיו קבוצות שונות של משתמשים שמורשים לפעול כאדמינים באותם אשכולות, בהתחשב במדיניות ה-IAM (container.admin) וב-RBAC (admin ClusterRoleBinding). אם אתם מתכננים להשתמש בתכונות שדורשות אחידות, המטרה צריכה להיות שכל האשכולות יכללו את אותה קבוצת אדמינים, ושהצי יכלול קבוצה קטנה של אדמינים. אם נדרש שלכל אשכול יהיו אדמינים שונים, והמטרה היא להשתמש בתכונות שדורשות זהות, כנראה שהאשכולות לא שייכים לאותו צי.
לדוגמה, אם לאשכולות C1 ו-C2 יש אדמינים שונים שלא סומכים אחד על השני ולא מוכנים לשתף הרשאות אדמין עם צוות פלטפורמה מרכזי שמנהל ציי רכבים, אז הם לא צריכים להיות מקובצים יחד בצי רכבים.
במאמר איך פועלות קבוצות של מכשירים מוסבר מהי זהות ומהן התכונות שדורשות זהות.
תכונות שכדאי להביא בחשבון
לא משנה אם אתם עובדים עם אשכולות חדשים או קיימים, התכונות של הצי שאתם בוחרים יכולות להשפיע גם על הארגון האופטימלי של הצי. לדוגמה, אם בחרתם להשתמש באיחוד שירותי אימות הזהויות של עומסי עבודה בכל צי, יכול להיות שתרצו לארגן את הציים באופן שימזער את הסיכון כשמגדירים אימות של עומסי עבודה בכל הצי, או שאם אתם רוצים להשתמש ב-Cloud Service Mesh, יכול להיות שתצטרכו שקלאסטרים מסוימים יהיו באותו צי. אם אתם משתמשים בענן וירטואלי פרטי (VPC), חלק מהתכונות מחייבות שימוש ב-VPC יחיד לכל צי.
במדריך הבא בסדרה הזו, תכנון תכונות לצי הרכב, אפשר לקרוא מידע נוסף על הטמעה של תכונות לצי הרכב, על הדרישות ועל ההגבלות.
כדאי לשקול שימוש ב-VPC perimeters
בעיה נוספת שכדאי לשקול לגבי אשכולות חדשים וקיימים היא אם בחרתם ליצור רשתות פרטיות משלכם ב- Google Cloud באמצעות ענן וירטואלי פרטי (VPC), או אם אתם רוצים לעשות זאת. אפשר לכלול באותו צי אשכולות שנמצאים בתוך מתחם היקפי של VPC (לדוגמה, ב-VPC משותף עם VPC Service Controls). אם יש לכם גם VPC משותפים מוגבלים וגם לא מוגבלים, מומלץ להוסיף אותם לציים נפרדים.
אם אתם מתכננים להשתמש בגבולות גזרה של VPC Service Controls, בדרך כלל חלק מעומסי העבודה נמצאים בגבולות הגזרה וחלק מחוצה להם. מומלץ לתכנן כך שלכל צי של מכונות יהיו גרסאות עם VPC Service Controls וגרסאות בלי VPC Service Controls בכל סביבה (או לפחות בסביבת הייצור ובסביבה שלפני סביבת הייצור).
כשמתכננים ציי רכבים עם רשתות VPC, חשוב לזכור שלחלק מהתכונות של ציי הרכבים יש דרישות ספציפיות לגבי רשתות VPC, כמו הדרישה שכל האשכולות שמשתמשים בהן יהיו באותה רשת VPC.
המאמרים הבאים
- במאמר תכנון תכונות לצי הרכב מפורטות שיטות מומלצות להוספת תכונות לצי הרכב.
- מידע נוסף על אופן הפעולה של צי הרכבים זמין במאמר איך פועלים צי הרכבים.
- כדי להתחיל ליצור את צי המכשירים, אפשר לעיין בסקירה הכללית על יצירת צי מכשירים