תכונות הרישות של Distributed Cloud במודל מחובר

בדף הזה מתוארים התכונות של הרשת ב-Google Distributed Cloud במודל מחובר, כולל רשתות משנה ואיזון עומסים.

הפעלת Distributed Cloud Edge Network API

כדי להגדיר רשת בפריסה מחוברת של Distributed Cloud, צריך להפעיל את Distributed Cloud Edge Network API. כדי לעשות זאת, צריך לבצע את השלבים שבקטע הזה. כברירת מחדל, שרתים של Distributed Cloud במודל מחובר נשלחים עם Distributed Cloud Edge Network API שכבר מופעל.

המסוף

1. במסוף Google Cloud , נכנסים לדף Distributed Cloud Edge Network API.

   להפעלת ה-API

2. לוחצים על Enable.

gcloud

משתמשים בפקודה הבאה:

gcloud services enable edgenetwork.googleapis.com

הגדרת רשת ב-Distributed Cloud במודל מחובר

בקטע הזה מוסבר איך להגדיר את רכיבי הרשת בפריסה המחוברת של Distributed Cloud.

המגבלות הבאות חלות על שרתים מחוברים של Distributed Cloud:

• אפשר להגדיר רק רשתות משנה.
• רשתות משנה תומכות רק במזהי VLAN. אין תמיכה ברשתות משנה שמבוססות על CIDR.

הגדרת רשת טיפוסית ל-Distributed Cloud Connected כוללת את השלבים הבאים:

1. אופציונלי: מאתחלים את הגדרות הרשת של אזור היעד, אם צריך.

2. יוצרים רשת.

3. יוצרים רשת משנה אחת או יותר בתוך הרשת.

4. בודקים את ההגדרה.

5. מחברים את ה-Pods לרשת.

אתחול תצורת הרשת של אזור Distributed Cloud

צריך לאתחל את הגדרת הרשת של אזור מחובר ב-Distributed Cloud מיד אחרי התקנת החומרה של Distributed Cloud connected במקום. אתחול הגדרות הרשת של אזור הוא תהליך חד-פעמי.

כשמפעילים את ההגדרה הראשונית של הרשת באזור, נוצרת רשת ברירת מחדל בשם default. ההגדרה הזו מספקת לפריסה שלכם ב-Distributed Cloud במודל מחובר קישוריות בסיסית של העלאה לרשת המקומית.

הוראות מפורטות מופיעות במאמר בנושא איך מאתחלים את הגדרת הרשת של אזור.

יצירת רשת

כדי ליצור רשת חדשה, פועלים לפי ההוראות במאמר יצירת רשת. בנוסף, אתם צריכים ליצור לפחות רשת משנה אחת בתוך הרשת כדי לאפשר לצמתים מחוברים של Distributed Cloud להתחבר לרשת.

יצירת רשת משנה אחת או יותר

כדי ליצור רשת משנה, פועלים לפי ההוראות במאמר בנושא יצירת רשת משנה. כדי שהצמתים יוכלו לגשת לרשת, צריך ליצור ברשת לפחות רשת משנה אחת. רשת ה-VLAN שמתאימה לכל רשת משנה שיוצרים זמינה אוטומטית לכל הצמתים באזור.

בדיקת ההגדרה

כדי לבדוק את ההגדרה של רכיבי הרשת שיצרתם:

1. בדיקת הסטטוס התפעולי של הרשת

2. בדיקת סטטוס ההקצאה של כל רשת משנה

חיבור של ה-Pods לרשת

כדי לחבר את ה-Pods לרשת ולהגדיר פונקציות רשת מתקדמות, צריך לפעול לפי ההוראות במאמר בנושא Network Function operator. הפונקציונליות הזו לא זמינה לעומסי עבודה של מכונות וירטואליות.

אופציונלי: הגדרת בידוד של רשת האשכול

‫Distributed Cloud במודל מחובר תומך בבידוד של רשתות אשכולות. צמתים שהוקצו לאשכול מבודד ברשת לא יכולים לתקשר עם צמתים אחרים באותו אזור מחובר של Distributed Cloud. כדי להפעיל בידוד של רשת האשכול, משתמשים בדגל --enable-cluster-isolation כשיוצרים או משנים אשכול. מידע נוסף מופיע במאמר בנושא יצירה וניהול של אשכולות.

אופציונלי: הגדרת מצב איים

‫Distributed Cloud Connected תומך במצב איים עבור מערכת המשנה של הרשת הווירטואלית. מצב Island מאפשר לציין טווח כתובות IP מבודד בממשק הרשת המשני של Pod. טווח הכתובות המבודד הזה לא תלוי בטווח הכתובות של ה-VLAN של ממשק הרשת הראשי. לפודים שהוגדרו למצב איים מוקצות רק כתובות מטווח הכתובות המבודד הזה של 'האי'. מידע נוסף זמין במאמר בנושא מודלים של רשתות: שטוח לעומת איים.

טווח כתובות ה-IP המבודד שאתם מציינים למצב איים לא יכול להיות זהה לטווחים הבאים של כתובות IP:

• ה-CIDR של ה-VLAN הראשי לכל רשת שמוגדרת באשכול
• טווח כתובות ה-IP הווירטואליות של מאזן העומסים שצוין בהערה networking.gke.io/gdce-lb-service-vip-cidrs במשאב Network
• טווחי כתובות ה-IP שמשמשים למצב איים ברשתות אחרות באשכול

הגדרת מצב אי

כדי להגדיר מצב איים ברמת ה-Pod, מוסיפים את ההערה networking.gke.io/gdce-pod-cidr למשאב המותאם אישית Network המתאים. מגדירים את ערך ההערה לטווח כתובות ה-IP המבודד של היעד ומחילים את משאב Network ששונה על האשכול. לדוגמה:

networking.gke.io/gdce-pod-cidr: 172.15.10.32/27

צריך גם להגדיר את הפרמטרים הבאים:

• הערך של type חייב להיות L3.
• הערך של IPAMMode חייב להיות Internal.

לדוגמה:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: my-network
  annotations:
    # Enable island mode and specify the isolated address range.
    networking.gke.io/gdce-pod-cidr: 172.15.10.32/27
    # Specify the VLAN ID for this secondary network.
    networking.gke.io/gdce-vlan-id: "561"
    # Specify the CIDR block for load balancer services on this network.
    networking.gke.io/gdce-lb-service-vip-cidrs: 172.20.5.180/30
spec:
  # Network type must be L3 for island mode.
  type: L3
  # IPAMMode must be Internal for island mode.
  IPAMMode: Internal
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.561 # The name for the target network interface.
  gateway4: 172.20.5.177 # Gateway IP address; must be unique in this CR.
  externalDHCP4: false
  dnsConfig:
    nameservers:
    - 8.8.8.8

כדי לוודא שמצב 'אי' מופעל:

1. יוצרים Pod לבדיקה ומחילים אותו על האשכול. לדוגמה:

   apiVersion: v1
   kind: Pod
   metadata:
     name: island-pod-tester
     annotations:
       networking.gke.io/interfaces: '[{"interfaceName":"eth1","network":"test-network-vlan561"}]'
       networking.gke.io/default-interface: "eth1"
   spec:
     containers:
     - name: sample-container
       image: busybox
       command: ["/bin/sh", "-c", "sleep 3600"]
   

2. קבלת כתובת ה-IP של ה-Pod:

   kubectl get pod island-pod-tester -o wide
   

   הפקודה מחזירה את כתובת ה-IP של ה-Pod, שנמצאת בטווח הכתובות המבודד שציינתם.

הגדרת מצב אי עם שירות ClusterIP

כדי להגדיר מצב איים באמצעות שירות ClusterIP, צריך לבצע את השלבים שבקטע הקודם, ואז להוסיף את ההערה networking.gke.io/gke-gateway-clusterip-cidr למשאב Network ולהגדיר את הערך שלה בהתאם לצרכים העסקיים. טווח הכתובות שצוין במשאב Network לא יכול לחפוף. לדוגמה:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  annotations:
    networking.gke.io/gdce-lb-service-vip-cidrs: 172.20.5.180/30
    networking.gke.io/gdce-pod-cidr: 172.15.10.32/27
    networking.gke.io/gdce-vlan-id: "561"
    networking.gke.io/gke-gateway-clusterip-cidr: 10.20.1.0/28
  name: test-network-vlan561
spec:
  IPAMMode: Internal
  dnsConfig:
    nameservers:
    - 8.8.8.8
  externalDHCP4: false
  gateway4: 172.20.5.177
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.561
  type: L3

איזון עומסים

‫Distributed Cloud מגיע עם פתרון משולב לאיזון עומסים ברשת שמבוסס על MetalLB במצב Layer 2. אתם יכולים להשתמש בפתרון הזה כדי לחשוף שירותים שפועלים באזור של Distributed Cloud לעולם החיצוני באמצעות כתובות IP וירטואליות (VIP) באופן הבא:

1. אדמין הרשת מתכנן את טופולוגיית הרשת ומציין את רשת המשנה הווירטואלית של כתובת IPv4 הנדרשת כשמזמינים את Distributed Cloud. ‫Google מגדירה את הציוד של Distributed Cloud בהתאם לפני המסירה. חשוב לזכור:
   • רשת המשנה של כתובות ה-VIP משותפת לכל אשכולות Kubernetes שפועלים באזור Distributed Cloud.
   • הכתובות הראשונה (מזהה הרשת), השנייה (שער ברירת המחדל) והאחרונה (כתובת השידור) ברשת המשנה שמורות לפונקציונליות של מערכת הליבה. אל תקצו את הכתובות האלה למאגרי הכתובות של הגדרות MetalLB.
   • כל אשכול חייב להשתמש בטווח VIP נפרד שנמצא בתוך רשת המשנה של ה-VIP שהוגדרה.
2. כשיוצרים אשכול באזור Distributed Cloud, האדמין של האשכול מציין את מאגרי הכתובות של הפודים ושירות ClusterIP באמצעות סימון CIDR. מנהל הרשת מספק את רשת המשנה המתאימה של כתובת ה-VIP לאדמין של האשכול.LoadBalancer

3. אחרי שיוצרים את האשכול, האדמין של האשכול מגדיר את מאגרי כתובות ה-VIP המתאימים. כשיוצרים את האשכול, צריך לציין את מאגרי כתובות ה-VIP באמצעות הדגל --external-lb-address-pools. הדגל מקבל קובץ עם מטען ייעודי (payload) בפורמט YAML או JSON, בפורמט הבא:

    addressPools:
    - name: foo
      addresses:
      - 10.2.0.212-10.2.0.221
      - fd12::4:101-fd12::4:110
      avoid_buggy_ips: true
      manual_assign: false
   
    - name: bar
      addresses:
      - 10.2.0.202-10.2.0.203
      - fd12::4:101-fd12::4:102
      avoid_buggy_ips: true
      manual_assign: false
   

   כדי לציין מאגר כתובות VIP, צריך לספק את הפרטים הבאים במטען הייעודי (payload):

   • ‫name: שם תיאורי שמזהה באופן ייחודי את מאגר כתובות ה-IP הווירטואליות הזה.
   • ‫addresses: רשימה של כתובות IPv4, טווחי כתובות ורשתות משנה שצריך לכלול במאגר הכתובות הזה.
   • ‫avoid_buggy_ips: החרגה של כתובות IP שמסתיימות ב-.0 או ב-.255.
   • ‫manual_assign: מאפשר להקצות כתובות באופן ידני מהמאגר הזה בהגדרות של שירות היעד LoadBalancer, במקום שהן יוקצו אוטומטית על ידי בקר MetalLB.

   מידע נוסף על הגדרת מאגרי כתובות VIP זמין במאמר בנושא ציון מאגרי כתובות במסמכי התיעוד של MetalLB.

4. האדמין של האשכול יוצר את שירותי LoadBalancer Kubernetes המתאימים.

צמתים של Distributed Cloud במאגר צמתים יחיד חולקים דומיין משותף בשכבה 2, ולכן הם גם צמתים של מאזן העומסים MetalLB. כשפועלים לפי השלבים האלה, מאזנים את עומס העבודה בשכבה 2 באמצעות MetalLB באופן אוטומטי.

משאב ClusterDNS

‫Google Distributed Cloud במודל מחובר תומך במשאב ClusterDNS של Google Distributed Cloud להגדרת שרתי שמות במעלה הזרם לדומיינים ספציפיים באמצעות הקטע spec.domains. מידע נוסף על הגדרת המשאב הזה זמין במאמר spec.domains.

המאמרים הבאים

• הקצאת כתובות של רשתות שירות ו-Pods