בסדרת המדריכים הזו, חלק מהשיקולים לתכנון פשוטים יותר כדי שתוכלו להתמקד בלימוד התכונות והשירותים העיקריים של Google Kubernetes Engine (GKE). לפני שמתחילים ליצור סביבת Google Kubernetes Engine משלכם, בדומה לזו שמתוארת בסדרת המדריכים הזו, יש כמה שיקולי תכנון נוספים שכדאי לזכור. השיקולים האלה כוללים את רמת ניהול האשכול, הרשת וסוגי הזמינות.
Networking
אשכולות GKE מחייבים תכנון קפדני של כתובות ה-IP. אפשרויות הרשת שאתם בוחרים משפיעות על הארכיטקטורה של אשכולות GKE. אי אפשר לשנות חלק מהאפשרויות האלה אחרי שמגדירים אותן, בלי ליצור מחדש את האשכול.
בסדרת המדריכים הזו, אתם משתמשים באשכולות במצב Autopilot שתמיד משתמשים ברשת במצב 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 יחיד שמריץ אפליקציה שמבוססת על מיקרו-שירותים.