במאמר הזה מוסבר איך לתכנן את כתובות ה-IP להתקנה של Google Distributed Cloud שכוללת אשכולות משתמשים שמשתמשים ב-kubeception.
מה זה kubeception?
המונח kubeception משמש לתיאור הרעיון שאשכול Kubernetes משמש ליצירה ולניהול של אשכולות Kubernetes אחרים. במסגרת Google Distributed Cloud, המונח kubeception מתייחס למצב שבו מישור הבקרה של אשכול משתמשים פועל בצומת אחד או יותר באשכול אדמין.
אנחנו לא ממליצים להשתמש ב-kubeception. במקום זאת, מומלץ להשתמש ב-Controlplane V2. ב-Controlplane V2, הצמתים של מישור הבקרה עבור אשכול המשתמשים נמצאים באשכול המשתמשים עצמו.
לפני שמתחילים
קריאת הסקירה הכללית על Google Distributed Cloud והסקירה הכללית על ההתקנה.
דוגמה להקצאת כתובת IP
בקטע הזה מופיעה דוגמה להקצאת כתובות IP סטטיות בהתקנה שכוללת את הרכיבים הבאים:
תחנת עבודה של אדמין
קלאסטר אדמין
אחד: אשכול משתמשים עם זמינות גבוהה (HA) שכולל חמישה צמתי עובדים
קלאסטר משתמשים אחד ללא זמינות גבוהה עם ארבעה צמתי עובדים
צמתים של אשכול אדמין
ב-admin cluster יש שבעה צמתים:
- צומת אחד שמריץ את מישור הבקרה של אשכול האדמין
- שני צמתים שמריצים תוספים לאשכול האדמין
- שלושה צמתים שמריצים את מישור הבקרה של אשכול המשתמשים עם זמינות גבוהה
- צומת אחד שמריץ את מישור הבקרה עבור אשכול המשתמשים שאינו HA
איזון עומסים
בדוגמה הזו, ההנחה היא שהאשכולות משתמשים במאזן העומסים MetalLB. מאזן העומסים הזה פועל בצמתי האשכול, כך שלא נדרשים מכונות וירטואליות נוספות לאיזון עומסים.
תת-רשתות
בדוגמה הזו, נניח שכל אשכול נמצא ברשת VLAN משלו, והאשכולות נמצאים בתתי-הרשתות הבאות:
| VMs (מכונות וירטואליות) | תת-רשת | שער ברירת מחדל |
|---|---|---|
| תחנת עבודה לאדמין ואשכול אדמין | 172.16.20.0/24 | 172.16.20.1 |
| אשכול משתמש 1 | 172.16.21.0/24 | 172.16.21.1 |
| אשכול משתמש 2 | 172.16.22.0/24 | 172.16.22.1 |
התרשים הבא ממחיש את שלושת ה-VLAN ותתי הרשתות. שימו לב שמשתמשי VIP לא מוצגים כמשויכים לצומת מסוים באשכול. הסיבה לכך היא שמאזן העומסים של MetalLB יכול לבחור איזה צומת יפרסם את ה-VIP עבור שירות מסוים. לדוגמה, באשכול משתמשים 1, צומת עובד אחד יכול להכריז על 172.16.21.31, וצומת עובד אחר יכול להכריז על 172.16.21.32.
כתובת IP לדוגמה: תחנת עבודה של אדמין
בדוגמה הזו, תחנת העבודה של האדמין נמצאת באותה רשת משנה כמו אשכול האדמין: 172.16.20.0/24. כתובת שקרובה לכתובות הצמתים תתאים לתחנת העבודה של האדמין. לדוגמה, 172.16.20.20.
דוגמאות לכתובות IP: צמתים של אשכול אדמין
לצורך אשכול אדמין עם שבעה צמתים, צריך להקצות שמונה כתובות IP. הכתובת הנוספת נדרשת, כי צריך אותה במהלך שדרוג, עדכון ותיקון אוטומטי של האשכול. לדוגמה, אפשר להקצות את כתובות ה-IP הבאות לצמתים באשכול האדמין:
| כתובות IP של צמתים באשכול הניהול |
|---|
| 172.16.20.2 - 172.16.20.9 |
דוגמאות לכתובות IP: כתובות VIP בתת-הרשת של אשכול האדמין
בטבלה הבאה מופיעה דוגמה לאופן שבו אפשר להגדיר כתובות VIP במאזן העומסים של אשכול האדמין. שימו לב שכתובות ה-VIP של שרתי Kubernetes API באשכולות המשתמשים נמצאות ברשת המשנה של אשכול האדמין. הסיבה לכך היא שבדוגמה הזו, שרת ה-API של Kubernetes עבור אשכול משתמשים פועל בצומת באשכול הניהול. שימו לב: בקובצי ההגדרות של האשכול, השדה שבו מציינים את כתובת ה-VIP של שרת Kubernetes API נקרא controlPlaneVIP:
| VIP | כתובת IP |
|---|---|
| כתובת VIP לשרת Kubernetes API של אשכול האדמין | 172.16.20.30 |
| Admin cluster add-ons VIP | 172.16.20.31 |
| כתובת ה-VIP של שרת Kubernetes API באשכול משתמש 1 | 172.16.20.32 |
| כתובת ה-VIP של שרת ה-API של Kubernetes באשכול משתמש 2 | 172.16.20.33 |
כתובות IP לדוגמה: צמתים של אשכול משתמשים 1
לדוגמה, אם יש לכם אשכול משתמשים עם חמישה צמתים, תצטרכו להקצות שישה כתובות IP. הכתובת הנוספת נדרשת, כי צריך אותה במהלך שדרוג, עדכון ותיקון אוטומטי של האשכול. לדוגמה, אפשר להקצות את כתובות ה-IP הבאות לצמתים באשכול משתמשים 1:
| כתובות ה-IP של הצמתים באשכול המשתמשים 1 |
|---|
| 172.16.21.2 - 172.16.21.7 |
דוגמה לכתובות IP: כתובות VIP ברשת המשנה של אשכול המשתמשים 1
בטבלה הבאה מוצגת דוגמה לאופן שבו אפשר להגדיר כתובות IP וירטואליות במאזן העומסים עבור אשכול משתמשים מספר 1:
| VIP | תיאור | כתובת IP |
|---|---|---|
| כתובת VIP של תעבורת נתונים נכנסת (ingress) באשכול משתמש 1 | הוגדר במאזן העומסים עבור אשכול משתמשים 1 | 172.16.21.30 |
| כתובות VIP של שירותים באשכול משתמש 1 | 10 כתובות לשירותים מהסוג LoadBalancer.מוגדר לפי הצורך במאזן העומסים עבור אשכול המשתמשים 1. שימו לב שהטווח הזה כולל את כתובת ה-VIP של ה-Ingress. זו דרישה למאזן העומסים MetalLB. |
172.16.21.30 - 172.16.21.39 |
כתובות IP לדוגמה: צמתי אשכול משתמשים 2
לצורך אשכול משתמשים עם ארבעה צמתים, צריך להקצות חמש כתובות IP. הכתובת הנוספת נדרשת, כי צריך אותה במהלך שדרוג, עדכון ותיקון אוטומטי של האשכול. לדוגמה, אפשר להקצות את כתובות ה-IP הבאות לצמתים באשכול משתמשים 2:
| כתובות ה-IP של הצמתים באשכול המשתמשים 2 |
|---|
| 172.16.22.2 - 172.16.22.6 |
דוגמה לכתובות IP: כתובות VIP בתת-רשת של אשכול המשתמשים 2
בטבלה הבאה מוצגת דוגמה לאופן שבו אפשר להגדיר כתובות VIP במאזן העומסים עבור אשכול משתמשים 2:
| VIP | תיאור | כתובת IP |
|---|---|---|
| כתובת IP וירטואלית (VIP) של תעבורת נתונים נכנסת (ingress) עבור אשכול משתמשים 2 | מוגדר במאזן העומסים של אשכול המשתמשים 2 | 172.16.22.30 |
| כתובות VIP של שירותים באשכול משתמש 2 | 10 כתובות לשירותים מהסוג LoadBalancer.מוגדר לפי הצורך במאזן העומסים של אשכול המשתמשים 2. שימו לב שהטווח הזה כולל את כתובת ה-VIP של ה-Ingress. זו דרישה למאזן העומסים MetalLB. |
172.16.22.30 - 172.16.22.39 |
דוגמאות לכתובות IP: Pods ו-Services
לפני שיוצרים אשכול, צריך לציין טווח CIDR לשימוש בכתובות ה-IP של ה-Pod, ועוד טווח CIDR לשימוש בכתובות ClusterIP של שירותי Kubernetes.
מחליטים באילו טווחי CIDR רוצים להשתמש עבור Pods ושירותים. לדוגמה:
| מטרה | טווח CIDR |
|---|---|
| Pods באשכול הניהול | 192.168.0.0/16 |
| Pods באשכול משתמש 1 | 192.168.0.0/16 |
| Pods באשכול משתמש 2 | 192.168.0.0/16 |
| שירותים באשכול האדמין | 10.96.232.0/24 |
| שירותים באשכול משתמש 1 | 10.96.0.0/20 |
| שירותים באשכול משתמש 2 | 10.96.128.0/20 |
הדוגמאות שלמעלה ממחישות את הנקודות הבאות:
טווח ה-CIDR של ה-Pod יכול להיות זהה בכמה אשכולות.
בדרך כלל צריך יותר פודים משירותים, ולכן עבור אשכול נתון, כדאי להשתמש בטווח CIDR של פודים שגדול יותר מטווח ה-CIDR של השירות. טווח ה-Pod לדוגמה עבור אשכול משתמשים הוא 192.168.0.0/16, שיש בו 2^(32-16) = 2^16 כתובות. אבל טווח שירות לדוגמה עבור אשכול משתמשים הוא 10.96.0.0/20, שיש בו רק 2^(32-20) = 2^12 כתובות.
הימנעות מחפיפה
כדאי להשתמש בטווחים של CIDR שאינם ברירת המחדל כדי למנוע חפיפה עם כתובות IP שאפשר להגיע אליהן ברשת שלכם. הטווחים של השירותים וה-Pods לא יכולים לחפוף לכתובות מחוץ לאשכול שרוצים להגיע אליהן מתוך האשכול.
לדוגמה, נניח שטווח השירות הוא 10.96.232.0/24, וטווח הפוד הוא 192.168.0.0/16 (192.168.0.1 עד 192.168.255.254). כל תנועה שנשלחת מ-Pod לכתובת באחד מהטווחים האלה תטופל כתנועה בתוך האשכול ולא תגיע ליעד מחוץ לאשכול.
בפרט, טווחי ה-Service וה-Pod לא יכולים לחפוף ל:
כתובות ה-IP של הצמתים בכל אשכול
כתובות IP שמשמשות מכונות של מאזן עומסים
כתובות VIP שמשמשות צמתים של רמת הבקרה ומאזני עומסים
כתובות IP של שרתי vCenter, שרתי DNS ושרתי NTP
מומלץ שטווח כתובות ה-IP של השירות ושל ה-Pod יהיה במרחב הכתובות הפרטיות של RFC 1918.
זו אחת הסיבות להמלצה להשתמש בכתובות RFC 1918. נניח שטווח ה-Pod או השירות שלכם מכיל כתובות IP חיצוניות. כל תעבורת נתונים שנשלחת מ-Pod לאחת מהכתובות החיצוניות האלה תטופל כתעבורת נתונים בתוך האשכול ולא תגיע ליעד החיצוני.
שרת DNS ושער ברירת מחדל
לפני שממלאים את קובצי ההגדרות, צריך לדעת את כתובת ה-IP של שרת DNS שאפשר להשתמש בו בתחנת העבודה של האדמין ובצמתי האשכול.
צריך גם לדעת את כתובת ה-IP של שער ברירת המחדל של כל אחת מרשתות המשנה. בדוגמאות הקודמות, שער ברירת המחדל של כל רשת משנה הוא הכתובת הראשונה בטווח. לדוגמה, ברשת המשנה של אשכול האדמין, שער ברירת המחדל מוצג כ-172.16.20.1.