תכנון משאבי ה-Fleet

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

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

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

  • כשרוצים ליצור אשכולות חדשים לגמרי.
  • כשרוצים ליצור צי עם אשכולות קיימים.

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

לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את המושגים הבאים:

הגבלות על צי ועל משאבים

המגבלות הכלליות הבאות חלות כשיוצרים צי:

  • פרויקט נתון Google Cloud יכול להיות משויך רק לצי אחד (או לאף צי), אבל הצי הזה יכול לכלול אשכולות מכמה פרויקטים. הפרויקט שמשויך ל-Fleet נקרא פרויקט המארח של ה-Fleet.
  • אפשר להוסיף אשכולות רק לצי אחד בכל זמן נתון.
  • כל האשכולות בפרויקט נתון צריכים להיות באותו צי או לא להיות בצי בכלל. אם פרויקט כבר מכיל חברים בצי, אי אפשר לרשום אשכול מהפרויקט הזה לצי אחר.
  • המגבלה שמוגדרת כברירת מחדל למספר האשכולות בצי היא 250, אבל אפשר לבקש להגדיל את המגבלה אם יש צורך.

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

עקרונות כלליים

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

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

תכנון של צי מכונות עבור אשכולות חדשים

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

אחרי שמזהים את ה-Fleets, אפשר ליצור פרויקט חדש לכל Fleet, ליצור Fleet בכל פרויקט וליצור אשכולות ולרשום אותם ב-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

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

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

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

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