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