במאמר הזה מוסבר איך לתכנן את כתובות ה-IP להתקנה של Google Distributed Cloud.
לפני שמתחילים
קריאת הסקירה הכללית על Google Distributed Cloud והסקירה הכללית על ההתקנה.
דוגמה להקצאת כתובת IP
בקטע הזה מופיעה דוגמה להקצאת כתובות IP סטטיות בהתקנה שכוללת את הרכיבים הבאים:
תחנת עבודה של אדמין
קלאסטר אדמין עם זמינות גבוהה (HA)
קלאסטר משתמש אחד עם זמינות גבוהה (HA) שיש לו חמישה צמתי עובד
קלאסטר משתמשים אחד ללא זמינות גבוהה עם ארבעה צמתי עובדים
בדוגמה הזו, באשכולות המשתמשים מופעל Controlplane V2. ב-Controlplane V2, הצמתים של מישור הבקרה של אשכול משתמשים נמצאים באשכול המשתמשים עצמו.
אם אתם לא רוצים להפעיל את Controlplane V2 עבור אשכולות המשתמשים, תוכלו לעיין במאמר תכנון כתובות ה-IP (kubeception). המונח kubeception מתייחס למקרה שבו מישור הבקרה של אשכול משתמשים פועל בצומת אחד או יותר באשכול האדמין. לא מומלץ להשתמש ב-kubeception. מומלץ להפעיל את Controlplane V2.
צמתים של אשכול אדמין
לצביר אדמין יש שלושה צמתים, ובכל אחד מהם פועלים רכיבי מישור הבקרה.
איזון עומסים
בדוגמה הזו, ההנחה היא שהאשכולות משתמשים במאזן העומסים 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 |
|---|---|
| אשכול אדמין HA | 172.16.20.2 - 172.16.20.4 |
כתובות IP לדוגמה: VIP לאשכול הניהול
צריך להקצות כתובת VIP לשרת Kubernetes API של אשכול האדמין.
שימו לב שבקובץ התצורה של האשכול, השדה של כתובת ה-VIP הזו נקרא controlPlaneVIP. לדוגמה, אפשר להקצות את כתובת ה-VIP הבאה לשרת ה-API של Kubernetes של אשכול האדמין:
| VIP | כתובת IP |
|---|---|
| כתובת VIP לשרת Kubernetes API של אשכול האדמין | 172.16.20.30 |
שימו לב: באשכולות אדמין של HA, ה-controlPlaneVIP צריך להיות באותו VLAN כמו כתובות ה-IP של צומת מישור הבקרה שצוינו ב-network.controlPlaneIPBlock.
כתובות IP לדוגמה: צמתים של אשכול משתמשים 1
לצורך אשכול משתמשים עם שמונה צמתים, צריך להקצות תשע כתובות IP. הכתובת הנוספת נדרשת, כי צריך אותה במהלך שדרוג, עדכון ותיקון אוטומטי של האשכול. לדוגמה, אפשר להקצות את כתובות ה-IP הבאות לצמתים באשכול משתמשים 1:
| כתובות ה-IP של הצמתים באשכול המשתמשים 1 |
|---|
| 172.16.21.2 - 172.16.21.10 |
כתובות IP לדוגמה: כתובות IP וירטואליות לאשכול משתמשים 1
בטבלה הבאה מוצגת דוגמה לאופן שבו אפשר להגדיר כתובות IP וירטואליות במאזן העומסים עבור אשכול משתמשים מספר 1:
| VIP | תיאור | כתובת IP |
|---|---|---|
| כתובת ה-VIP של שרת Kubernetes API באשכול משתמש 1 | הוגדר במאזן העומסים עבור אשכול משתמשים 1 | 172.16.21.30 |
| כתובת VIP של תעבורת נתונים נכנסת (ingress) באשכול משתמש 1 | הוגדר במאזן העומסים עבור אשכול משתמשים 1 | 172.16.21.31 |
| כתובות VIP של שירותים באשכול משתמש 1 | 10 כתובות לשירותים מהסוג LoadBalancer.מוגדר לפי הצורך במאזן העומסים עבור אשכול המשתמשים 1. שימו לב שהטווח הזה כולל את כתובת ה-VIP של ה-Ingress. זו דרישה למאזן העומסים MetalLB. |
172.16.21.31 - 172.16.21.40 |
שימו לב: כתובת ה-VIP של שרת ה-API של Kubernetes מצוינת ב-loadBalancer.vips.controlPlaneVIP בקובץ התצורה של האשכול. אם ControlPlane V2 מופעל, controlPlaneVIP צריך להיות באותו VLAN כמו כתובות ה-IP של צומת מישור הבקרה שצוינו ב-network.controlPlaneIPBlock.
כתובות IP לדוגמה: צמתי אשכול משתמשים 2
לדוגמה, אם יש לכם אשכול משתמשים עם חמישה צמתים, תצטרכו להקצות שישה כתובות IP. הכתובת הנוספת נדרשת, כי צריך אותה במהלך שדרוג, עדכון ותיקון אוטומטי של האשכול. לדוגמה, אפשר להקצות את כתובות ה-IP הבאות לצמתים באשכול משתמשים 2:
| כתובות ה-IP של הצמתים באשכול המשתמשים 2 |
|---|
| 172.16.22.2 - 172.16.22.7 |
דוגמה לכתובות IP: כתובות VIP לאשכול משתמשים 2
בטבלה הבאה מוצגת דוגמה לאופן שבו אפשר להגדיר כתובות VIP במאזן העומסים עבור אשכול משתמשים 2:
| VIP | תיאור | כתובת IP |
|---|---|---|
| כתובת VIP לשרת Kubernetes API עבור אשכול משתמש 2 | מוגדר במאזן העומסים של אשכול המשתמשים 2 | 172.16.22.30 |
| כתובת IP וירטואלית (VIP) של תעבורת נתונים נכנסת (ingress) עבור אשכול משתמשים 2 | מוגדר במאזן העומסים של אשכול המשתמשים 2 | 172.16.22.31 |
| כתובות VIP של שירותים באשכול משתמש 2 | 10 כתובות לשירותים מהסוג LoadBalancer.מוגדר לפי הצורך במאזן העומסים של אשכול המשתמשים 2. שימו לב שהטווח הזה כולל את כתובת ה-VIP של ה-Ingress. זו דרישה למאזן העומסים MetalLB. |
172.16.22.31 - 172.16.22.40 |
שימו לב: כתובת ה-VIP של שרת ה-API של Kubernetes מצוינת ב-loadBalancer.vips.controlPlaneVIP בקובץ התצורה של האשכול. אם ControlPlane V2 מופעל, controlPlaneVIP צריך להיות באותו VLAN כמו כתובות ה-IP של צומת מישור הבקרה שצוינו ב-network.controlPlaneIPBlock.
דוגמאות לכתובות 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.