בסדרת המדריכים הזו, חלק מהשיקולים לתכנון פשוטים יותר כדי שתוכלו להתמקד בלימוד התכונות והשירותים העיקריים של Google Kubernetes Engine (GKE). לפני שמתחילים ליצור סביבת Google Kubernetes Engine משלכם, בדומה לזו שמתוארת בסדרת המדריכים הזו, יש כמה שיקולי תכנון נוספים שכדאי לזכור. השיקולים האלה כוללים את רמת הניהול של האשכול, את סוגי הרשתות ואת סוגי הזמינות.
Networking
באשכולות GKE צריך לתכנן בקפידה את כתובות ה-IP. אפשרויות הרשת שתבחרו ישפיעו על הארכיטקטורה של אשכולות ה-GKE. אי אפשר לשנות חלק מהאפשרויות האלה אחרי שמגדירים אותן, בלי ליצור מחדש את האשכול.
בסדרת המדריכים הזו, משתמשים באשכולות במצב אוטומטי, שתמיד משתמשים ברשת במצב VPC-native. אשכולות מקוריים של VPC משתמשים בטווחים של כתובות IP של כינוי בצמתי GKE, והם נדרשים ליצירת אשכולות ב-VPC משותף. קל יותר לשנות את הגודל של אשכולות מקוריים של VPC מאשר של אשכולות מבוססי-נתיבים, בלי שהם יצרכוGoogle Cloud נתיבים, ולכן הם פחות רגישים להגעה למגבלות הניתוב.
לפני שיוצרים סביבת GKE משלכם ומפריסים עומסי עבודה, כדאי לעיין בהנחיות הבאות בנושא רישות:
מצבי אשכולות
במדריכים האלה תיצרו אשכול GKE אזורי במצב Autopilot. אשכולות Autopilot מוגדרים מראש עם הגדרת אשכול אופטימלית שמוכנה לעומסי עבודה בסביבת הייצור. לחלופין, אפשר להשתמש באשכולות במצב רגיל כדי לקבל גמישות רבה יותר בהגדרות המתקדמות של התשתית הבסיסית.
לסקירה מקיפה יותר, כדאי לעיין במסמכי התכנון שמתחילים באפשרויות להגדרת אשכולות.
מרחבי שמות
מרחבי שמות מאפשרים לארגן את האפליקציות ולבודד רכיבים אחד מהשני. לכל מרחב שמות יש קבוצת משאבים משלו, כמו Pods, Services ו-Deployments. לדוגמה, אפשר ליצור מרחב שמות לכל שירותי הקצה הקדמי ומרחב שמות לשירותי הקצה העורפי. הקיבוץ הזה מקל על ניהול השירותים ועל שליטה בגישה אליהם.
בסדרת המדריכים הזו תפרסו את ה-Pods והשירותים של האפליקציה לדוגמה Cymbal Bank במרחב שמות אחד. הגישה הזו מפשטת את הפריסה, אבל לא מאפשרת להשתמש במרחבי שמות כדי להקצות משאבים לצוותים ולמשתמשים שונים, כמו שאפשר לעשות בסביבת ייצור. במאמר ארכיטקטורת האפליקציה של Cymbal Bank תוכלו לקרוא דוגמה מאובטחת יותר ומוכנה לייצור של האפליקציה לדוגמה Cymbal Bank, שמשתמשת בכמה מרחבי שמות.
תקציבים לשיבוש Pod
מדיניות של תקציב לשיבוש Pod (PDB) עוזרת להבטיח את ביצועי האפליקציה על ידי מניעת השבתה של Pods בו-זמנית כשמבצעים שינוי במערכת, והגבלת מספר ה-Pods שלא זמינים בו-זמנית באפליקציה משוכפלת.
בסדרת המדריכים הזו לא מגדירים ולא משתמשים ב-PDB. כשתסיימו את המדריך לסימולציה של כשל, כל השירותים והצמתים אמורים להגיב כצפוי. כשפורסים עומסי עבודה משלכם, יכול להיות ש-PDB בצמתים יחסום את ניקוי הצמתים.
אם אתם משתמשים ב-PDB, כדאי לבדוק את ההגדרות לפני שמנסים לבודד את הצמתים ולנקז מהם את העומס. אם הצמתים לא מצליחים לנקז את הנתונים, יכול להיות שתיתקלו בבעיות באירועי תחזוקה מתוזמנים.
המאמרים הבאים
כדי להתחיל, כדאי להשלים את המדריך הראשון לפריסת אשכול GKE יחיד שמריץ אפליקציה שמבוססת על מיקרו-שירותים.