בדרך כלל מומלץ להשתמש בכמה שפחות אשכולות, אבל ארגונים בוחרים לפרוס כמה אשכולות כדי להשיג את היעדים הטכניים והעסקיים שלהם מסיבות שונות. לפחות, רוב הארגונים מפרידים בין שירותים שאינם שירותי ייצור לבין שירותי ייצור, וממקמים אותם באשכולות שונים. בתרחישים מורכבים יותר, ארגונים עשויים לבחור כמה אשכולות כדי להפריד בין שירותים ברמות שונות, באזורים שונים, בצוותים שונים או בספקי תשתית שונים.
רוב הסיבות להטמעת כמה אשכולות מתחלקות לשלוש קטגוריות של דרישות:
- בידוד: הפרדה בין רמת הבקרה לבין רמת הנתונים של השירותים, בעיקר כדי לשפר את המהימנות או לתת מענה לצרכי אבטחה
- מיקום: הצבת שירותים במיקומים ספציפיים כדי לתת מענה לצרכים של זמינות, זמן אחזור ומקומיות
- התאמה לגודל: במיוחד בהקשר של אשכולות Kubernetes, שירותי קנה מידה מעבר למגבלות המעשיות שמוטלות על אשכול יחיד
בנוסף לשלוש הקטגוריות האלה, צי של מכוניות יכול גם לשפר את המהימנות הכוללת. בקטעים הבאים נרחיב על כך.
במקרים רבים, ארגונים צריכים לאזן בין כמה מהדרישות האלה בו-זמנית. כשחושבים על הארגון שלכם, חשוב לזכור שההמלצה הכללית שלנו היא להשתמש בכמה שפחות אשכולות. קובעים אילו מהצרכים של ריבוי אשכולות הם בעדיפות הכי גבוהה בארגון ואי אפשר להתפשר עליהם, ואז מבצעים את ההתאמות הנדרשות כדי ליצור ארכיטקטורה של ריבוי אשכולות.
אם אתם רואים שהארגון שלכם שוקל להשתמש במודל של אשכול לכל שירות או במודל של אשכול לכל צוות, כדאי לשקול את עומס הניהול שמוטל על המפעילים של מערכת כזו. Fleets ו Google Cloud התכונות והרכיבים שתומכים בהם נועדו להקל ככל האפשר על ניהול של כמה אשכולות, אבל תמיד יש מורכבות נוספת בניהול של יותר אשכולות.
בידוד
בהקשר הזה, בידוד מתייחס להפרדה של רמת הבקרה או רמת הנתונים, או של שתיהן. אפשר להשיג את זה על ידי הפעלת כמה אשכולות. עם זאת, בהתאם להטמעה, ההפרדה הזו כנראה חלה גם על בידוד מישור הנתונים. הבידוד בדרך כלל נכנס לתמונה כשחושבים על הדברים הבאים:
סביבה
ברוב המקרים, ארגונים מריצים את שירותי הפיתוח, ה-staging/הבדיקה והייצור שלהם באשכולות נפרדים, שלעתים קרובות פועלים ברשתות ובפרויקטים שונים בענן. ההפרדה הזו נעשית כדי למנוע שיבוש מקרי של שירותי ייצור ולמנוע גישה לנתונים רגישים במהלך פיתוח או בדיקה.הגדרת רמות לעומסי עבודה
בדרך כלל, ארגונים שיש להם הרבה אפליקציות מורכבות מגדירים רמות לשירותים שלהם, ובוחרים להריץ את השירותים הקריטיים יותר באשכולות נפרדים מהשירותים הקריטיים פחות. בסביבה כזו, השירותים הקריטיים האלה והאשכולות שלהם מקבלים התייחסות מיוחדת בכל הנוגע לגישה, לאבטחה, לשדרוגים, למדיניות ועוד. דוגמה לסיווג כזה היא הפרדה בין שירותים חסרי מצב לבין שירותים בעלי מצב על ידי הצבתם באשכולות נפרדים.הפחתת ההשפעה של כשלים
כדי להגביל את ההשפעות של טעות של מפעיל, של כשל באשכול או של כשל בתשתית קשורה, ארגונים יכולים לפצל את השירותים שלהם בין כמה אשכולות.שדרוגים
אם בארגון חוששים מבעיות פוטנציאליות בשדרוג במקום (כלומר, כשל באוטומציה של השדרוג, חוסר יציבות של האפליקציה או חוסר אפשרות לבצע שחזור), אפשר לבחור לפרוס עותק של השירותים באשכול חדש. כדי לבצע שדרוג כזה, צריך לתכנן או להשתמש באוטומציה, ולוודא שמתייחסים לניהול התנועה ולשכפול המצב במהלך תהליך השדרוג.הפרדה לצורכי אבטחה או לצורכי רגולציה
ארגונים יכולים לבחור לבודד שירותים מסיבות רבות, כולל שמירה על עומסי עבודה שחלים עליהם דרישות רגולטוריות בנפרד מעומסי עבודה פחות רגישים, או הפעלת שירותים של צד שלישי (פחות מהימנים) בתשתית נפרדת משירותים של צד ראשון (מהימנים) (אשכולות).הפרדה בין דיירים
הפרדה בין דיירים למספר אשכולות מתבצעת לעיתים קרובות ממגוון סיבות, כולל בידוד אבטחה, בידוד ביצועים, הנהלת חשבונות ואפילו בעלות.
מיקום
זמן אחזור
לשירותים מסוימים יש דרישות לגבי זמן אחזור, שצריך לעמוד בהן על ידי מיקום פיזי של עומס העבודה במיקום ספציפי (או באזור גיאוגרפי ספציפי). הצורך הזה יכול להתעורר אם שירותים במעלה הזרם או משתמשי קצה רגישים לזמן אחזור, אבל הוא יכול להתעורר גם בקלות אם עומס העבודה עצמו רגיש לזמן אחזור של שירות במורד הזרם.זמינות
הפעלת אותו שירות בכמה אזורי זמינות אצל ספק ענן יחיד (או אצל כמה ספקים) יכולה לספק זמינות כוללת גבוהה יותר.סמכות שיפוט
דרישות עיבוד שקשורות למיקום הנתונים ולסמכות שיפוט אחרת עשויות לחייב אחסון ועיבוד של נתונים באזור מסוים, ולכן נדרש פריסת תשתית בכמה מרכזי נתונים או ספקי ענן.כוח המשיכה של הנתונים
יכול להיות שיהיה קשה, בלתי אפשרי או אפילו לא מומלץ לאחד מאגר גדול של נתונים, או אפילו מקרים מסוימים של מסדי נתונים, אצל ספק ענן או באזור יחיד. בהתאם לדרישות העיבוד וההצגה, יכול להיות שיהיה צורך לפרוס אפליקציה קרוב לנתונים שלה.תשתית או שירותים מדור קודם
כמו שקשה להעביר נתונים לענן, כך קשה להעביר תשתית מדור קודם. למרות שהשירותים מהגרסה הקודמת לא ניתנים להעברה, פריסה של אשכולות נוספים לצורך פיתוח שירותים חדשים מאפשרת לארגונים להגדיל את מהירות הפיתוח.בחירה למפתחים
לארגונים יש לרוב יתרון בכך שהם יכולים לאפשר למפתחים לבחור את השירותים המנוהלים בענן שבהם הם משתמשים. באופן כללי, האפשרות לבחור מאפשרת לצוותים להתקדם מהר יותר עם כלים שהכי מתאימים לצרכים שלהם, אבל הם צריכים לנהל משאבים נוספים שהוקצו בכל ספק.צרכים של מחשוב מקומי/קצה
לבסוף, כשהארגונים רוצים לאמץ שיטות מודרניות של אפליקציות בסביבות עבודה מסורתיות יותר, כמו מחסנים, רצפות ייצור, חנויות קמעונאיות וכו', הם צריכים לנהל הרבה יותר עומסי עבודה בהרבה יותר חלקי תשתית.
להתכונן להתרחבות
מכיוון שאפשר להגדיל את אשכולות GKE ליותר מ-5,000 צמתים, המגבלות האלה הן בדרך כלל לא סיבה להפעיל כמה אשכולות. לפני שקלאסטר מגיע למגבלות המדרגיות, ארגונים לרוב מחליטים לפזר את השירותים על פני כמה קלאסטרים. באשכולות שמגיעים למגבלות של יכולת ההתאמה לגודל, הפעלת אפליקציה בכמה אשכולות יכולה להקל על חלק מהבעיות, אבל היא מוסיפה מורכבות בניהול של כמה אשכולות.
אמינות
השימוש ב-Fleets תורם למהימנות על ידי הפעלת אוטומציה משופרת ויכולת חזרה, ומאפשר להחליף בין אשכולות. במקום לבזבז זמן בניסיון לאתר את מקור הבעיה באשכול שנכשל, אפשר ליצור אשכול חדש ולהוסיף אותו לצי.
בנוסף, Multi-cluster Gateway ו-Multi Cluster Ingress נועדו לשפר את הזמינות והמהימנות במקרה של הפסקות חשמל אזוריות, על ידי ניתוב תעבורה לאשכולות תקינים בצי.
לפרטים נוספים על מהימנות התשתית, אפשר לעיין במדריך למהימנות התשתית של Google Cloud.