סקירה כללית
יש שני סוגים של מודלים של רשת במצב שטוח: רשת במצב סטטי ורשת במצב דינמי (באמצעות פרוטוקול Border Gateway Protocol). אפשר להשתמש במצב סטטי שטוח כשצמתים משתרעים על פני דומיין יחיד של שכבה 2. לצמתים שמשתרעים על פני כמה דומיינים של שכבה 2, משתמשים במצב IP שטוח עם BGP.
במודל רשת שטוח, ל-Pods יש כתובות IP ייחודיות בכל האשכולות. צריך לוודא שכתובות ה-CIDR של ה-Pods שהוקצו הן ייחודיות ולא חופפות לאף רשת משנה אחרת. לדוגמה, כתובות IP לא יכולות לחפוף לכתובות IP שמשמשות את הצמתים או את כתובות ה-CIDR של ה-Pods באשכולות אחרים. אפשר לגשת לכתובות ה-IP האלה מבחוץ, ולכן Pods בכל צומת יכולים לתקשר עם כל ה-Pods בכל הצמתים האחרים. תקשורת מה-Pod לכל כתובת IP חיצונית לא דורשת תרגום כתובות רשת (NAT). מידע נוסף על מודל רשת שטוח והשוואה שלו למודל הרשת של איים שמוגדר כברירת מחדל זמין במאמר מודלים של רשת שטוחה לעומת מודל של רשת איים.
משתמשים במודל רשת במצב שטוח כשיש מרחב גדול של כתובות IP ואפשר להקצות CIDR ייחודי של פוד לאשכול. אתם יכולים להגדיר את ה-CIDR של הפודים באופן דינמי באמצעות ClusterCIDRConfigs. אפשר להוסיף או למחוק ClusterCIDRConfigs אחרי יצירת האשכול. מידע נוסף על ClusterCIDRConfig ודוגמאות לשימוש בו מופיע במאמר הסבר על המשאב המותאם אישית ClusterCIDRConfig.
מידע נוסף על מצב שטוח עם BGP זמין במאמר בנושא הטמעה של מודל רשת במצב שטוח עם תמיכה ב-BGP.
הסבר על הנגישות של כתובות ה-IP של קבוצת ה-Pod
במצב רשת שטוחה סטטית ל-IPv4, הנגישות של כתובת ה-IP של ה-Pod מבוססת על חבילות של Address Resolution Protocol (ARP). לכן, אפשר להגיע לכתובות ה-IP של ה-Pods רק כשה-Pods נמצאים באותו דומיין Layer 2. הצמתים צריכים להיות שייכים לאותו דומיין בשכבה 2. כתובות ה-IP שאתם מציינים עבור ה-Pods (באמצעות ClusterCIDRConfigs) צריכות להיות באותה רשת משנה כמו צמתי האשכול. כתובות ה-CIDR של ה-Pods שמוגדרות צריכות להיות מרשת המשנה של הצמתים. לדוגמה, אם הצמתים באשכול משתמשים ברשת משנה 222.1.0.0/16, בוחרים ברשת משנה קטנה יותר בתוך רשת המשנה עבור הפודים, 222.1.2.0/24. מוודאים שאף משאב אחר באשכול לא משתמש בכתובת IP מהטווח שהוקצה לפודים.
בקטע הבא מוסבר איך להגדיר רשתות במצב שטוח ל-IPv4.
איך מטמיעים רשת סטטית במצב שטוח
כברירת מחדל, אשכול Google Distributed Cloud נוצר ברשת במצב איים. בחלק הזה מוסבר איך להגדיר רשת במצב שטוח לאשכול.
כדי לפרוס אשכול עם מודל רשת במצב שטוח, מבצעים את השינויים הבאים בקובץ התצורה של האשכול:
אפשר להפעיל רשת במצב שטוח רק במהלך יצירת אשכול. כדי ליצור אשכול חדש עם רשת במצב שטוח, פועלים לפי השלבים הבאים:
עורכים את קובץ ההגדרות האישיות של האשכול כדי להוסיף את
clusterNetwork.flatIPv4ולהגדיר אותו ל-true.כשמפעילים רשת במצב שטוח, המערכת מתעלמת מ-CIDR של הפוד שצוין בקובץ התצורה של האשכול (
clusterNetwork.pods.cidrBlocks).מוסיפים מניפסט ClusterCIDRConfig לקובץ התצורה של האשכול.
במניפסט ClusterCIDRConfig, כוללים את הפרטים הבאים:
metadata.namespace: מרחב השמות של האשכול.
spec.ipv4.cidr: טווח כתובות ה-IP בפורמט של בלוק CIDR לשימוש עבור Pod באשכול. הטווח הזה צריך להיות מאותה רשת משנה כמו צמתי האשכול.perNodeMaskSize: בדיקות קדם-הפעלה של יצירת אשכול מאמתות שהערך שלperNodeMaskSizeמספיק להקצאת מספר ה-Pod-ים שצוין ב-maxPodsPerNode.
nodeSelector: אם אין תוויות צמתים שתואמות לערךnodeSelector, תהליך ההתאמה של הצומת יישאר בהמתנה והיצירה של האשכול לא תושלם.
קטע הקוד הבא מתוך קובץ הגדרות של אשכול מראה איך להטמיע רשת במצב שטוח ללא תמיכה ב-BGP. ה-CIDR שמופיעים בקטע הקוד הזה הם רק דוגמאות, ותצטרכו להחליף אותם ב-CIDR משלכם. כשמחליפים את ה-CIDR ב-CIDR משלכם, חשוב לוודא שהם עומדים בקריטריונים לנגישות של פודים, כפי שמפורט במאמר הסבר על נגישות של כתובות IP של פודים.
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: flat-mode
namespace: cluster-flat-mode
spec:
... (other cluster config omitted)
...
# Cluster networking configuration
clusterNetwork:
flatIPv4: true
services:
cidrBlocks:
- 10.96.0.0/12
... (other cluster config omitted)
...
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
name: cluster-wide-1
namespace: cluster-flat-mode
spec:
ipv4:
cidr: "222.1.0.0/16"
perNodeMaskSize: 24
מגבלות
לרשת הסטטית במצב שטוח ב-Google Distributed Cloud יש את המגבלות הבאות:
אפשר להגיע ל-Pods שמשתמשים ברשתות במצב שטוח בתוך דומיין יחיד של שכבה 2. כל מכונה אחרת שלא נמצאת באשכול, אבל נמצאת באותו דומיין Layer 2, יכולה גם להגיע ל-Pods. המגבלה הזו קיימת גם ב-IPv6 כשיוצרים אשכולות dualstack וכש-IPv6 נמצא במצב שטוח ללא BGP. מידע נוסף זמין במאמר בנושא הבנת הנגישות של כתובת ה-IP של ה-Pod.
בקר ה-IPAM של Google Distributed Cloud עוקב אחרי הזמינות של כתובות IP ב-CIDR של הפודים שהוגדרו. הוא לא עוקב אחרי כתובות ה-IP שכבר נמצאות בשימוש במכשירים אחרים. לכן, כתובות IP אחרות בדומיין Layer 2 לא יכולות להפריע ל-CIDR של הפודים. למידע נוסף אפשר לעיין במאמר הסבר על הנגישות של כתובות ה-IP של הפודים.