תכונות רישות של Distributed Cloud

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

הפעלת 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 כוללת את השלבים הבאים:

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

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

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

  4. מקימים סשנים של BGP peering בכיוון צפון עם נתבי ה-PE באמצעות חיבורי ה-Interconnect המתאימים.

  5. יוצרים סשנים של BGP peering מדרום לצפון עם ה-Pods שמריצים את עומסי העבודה באמצעות רשתות המשנה המתאימות.

  6. אופציונלי: הקמת סשנים של BGP peering ב-loopback לזמינות גבוהה.

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

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

אופציונלי: אתחול הגדרות הרשת של אזור Distributed Cloud

צריך לאתחל את הגדרות הרשת של אזור Distributed Cloud במקרים הבאים:

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

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

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

יצירת רשת

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

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

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

יצירת סשנים של קישור BGP בין רשתות שכנות (peering) בכיוון צפון

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

כדי ליצור סשן BGP peering צפונה:

  1. מפרטים את החיבורים הזמינים באזור ואז בוחרים את חיבור ה-Interconnect שאליו רוצים לטרגט את סשן ה-Peering הזה.

  2. יוצרים חיבור אחד או יותר ל-Interconnect ב-Interconnect שנבחר. קבצים מצורפים של קישוריות בין-אזורים מקשרים את הנתב שיוצרים בשלב הבא לקישוריות בין-אזורים שנבחרה.

  3. יצירת נתב הנתב הזה מעביר תעבורה בין הקישוריות לבין הרשת שלכם באמצעות חיבורי הקישוריות שיצרתם בשלב הקודם.

  4. מוסיפים ממשק לנתב לכל קובץ מצורף של קישוריות הדדית שיצרתם קודם בהליך הזה. לכל ממשק, משתמשים בכתובת ה-IP של מתג ה-ToR המתאים במתלה של Distributed Cloud. הוראות מפורטות מופיעות במאמר יצירת סשן של שיתוף פעולה בין רשתות (Peering) בכיוון צפון.

  5. מוסיפים עמית לכל ממשק שיצרתם בנתב בשלב הקודם.

הקמת סשנים של קישור BGP בין רשתות שכנות (peering) מדרום לצפון

כדי להפעיל קישוריות נכנסת לעומסי העבודה מהרשת המקומית, צריך ליצור סשן אחד או יותר של BGP peering לכיוון דרום בין נתבי ה-peering edge לבין רשת המשנה שאליה שייכים הפודים. כתובת ה-IP של השער לכל רשת משנה היא כתובת ה-IP של מתג ה-ToR המתאים במתלה שלכם ב-Distributed Cloud.

כדי ליצור סשן BGP peering מדרום לצפון:

  1. מוסיפים ממשק לנתב ברשת היעד לכל רשת משנה שרוצים להקצות לה קישוריות נכנסת. הוראות מופיעות במאמר בנושא יצירת סשן של שיתוף פעולה עם שרתים במורד הזרם.

  2. מוסיפים עמית לכל ממשק שיצרתם בנתב בשלב הקודם.

אופציונלי: יצירת סשנים של קישור BGP בין רשתות שכנות מסוג loopback

כדי לאפשר קישוריות בזמינות גבוהה בין עומסי העבודה לבין הרשת המקומית, אפשר ליצור סשן של קישור בין רשתות שכנות (peering) מסוג BGP מסוג loopback בין ה-Pod של היעד לבין שני מתגי ToR במתלה של Distributed Cloud. סשן של שיתוף פעולה עם עצמו (loopback peering) יוצר שני סשנים עצמאיים של שיתוף פעולה עם עצמו עבור ה-Pod, אחד עם כל מתג ToR.

כדי ליצור סשן BGP peering של Loopback:

  1. מוסיפים ממשק מסוג loopback לנתב ברשת היעד. הוראות מופיעות במאמר בנושא יצירת סשן של שיתוף פעולה מסוג Loopback.

  2. מוסיפים עמית לממשק הלולאה החוזרת.

בדיקת ההגדרה

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

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

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

  3. בדיקת הסטטוס התפעולי של החיבורים.

  4. בדיקת הסטטוס התפעולי של קבצים מצורפים של קישוריות הדדית.

  5. בדיקת הסטטוס התפעולי של הנתב.

חיבור מכשירי Pod לרשת

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

איזון עומסים

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

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

  3. אחרי שיוצרים את האשכול, האדמין של האשכול מגדיר את מאגרי כתובות ה-VIP המתאימים. עבור אשכולות של מישור בקרה מרחוק, צריך לערוך את metallb-config ConfigMap במרחב השמות metallb-system באמצעות הפקודה kubectl edit או kubectl replace. אל תשתמשו בפקודה kubectl apply כי Distributed Cloud ידרוס את השינויים שלכם אם תשתמשו בה.

    הדוגמה הבאה ממחישה הגדרה כזו:

    # metallb-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: metallb-config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.2-192.168.1.254

    במקרה של אשכולות של מישור בקרה מקומי, צריך לציין את מאגרי כתובות ה-VIP באמצעות הדגל --external-lb-ipv4-address-pools כשיוצרים את האשכול. מידע נוסף זמין במאמר בנושא מצב זמינות.

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

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

תעבורת נתונים נכנסת (ingress) ב-Distributed Cloud

בנוסף לאיזון עומסים, Distributed Cloud תומך גם במשאבי Kubernetes Ingress. משאב Ingress Kubernetes שולט בזרימת תנועת HTTP(S) לשירותי Kubernetes שפועלים באשכולות של Distributed Cloud. בדוגמה הבאה מוצג משאב Ingress אופייני:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: my-service
            port:
              number: 80
        path: /foo
        pathType: Prefix

כשמגדירים את שירות istio-ingress, תנועת הרשת עוברת דרכו. כברירת מחדל, מוקצית לו כתובת IP אקראית ממאגרי ה-VIP שצוינו בהגדרות של MetalLB. אתם יכולים לבחור כתובת IP ספציפית או כתובת IP וירטואלית מתוך ההגדרה של MetalLB באמצעות השדה loadBalancerIP בהגדרת השירות istio-ingress. לדוגמה:

apiVersion: v1
kind: Service
metadata:
  labels:
    istio: ingress-gke-system
    release: istio
  name: istio-ingress
  namespace: gke-system
spec:
  loadBalancerIP: <targetLoadBalancerIPaddress>

השבתה של משאב Distributed Cloud Ingress שמוגדר כברירת מחדל

כברירת מחדל, כשיוצרים אשכול Distributed Cloud, מערכת Distributed Cloud מגדירה באופן אוטומטי את שירות istio-ingress לאשכול. יש לכם אפשרות ליצור אשכול של Distributed Cloud בלי istio-ingress השירות. כדי לעשות זאת, פועלים לפי השלבים הבאים:

gcloud

  1. יוצרים קובץ הגדרות YAML בשם SystemsAddonConfig.yaml עם התוכן הבא:

    systemAddonsConfig:
 ingress:
   disabled: true

  2. מעבירים את הקובץ SystemsAddonConfig.yaml באמצעות הדגל --system-addons-config בפקודת יצירת האשכול. כדי להשתמש בתכונה הזו, צריך להשתמש בגרסה gcloud alpha. לדוגמה:

    gcloud alpha edge-cloud container clusters create MyGDCECluster1 --location us-west1 \
    --system-addons-config=SystemsAddonConfig.yaml

    מידע נוסף על יצירת אשכול Distributed Cloud זמין במאמר יצירת אשכול.

API

  1. מוסיפים את תוכן ה-JSON הבא למטען הייעודי (payload) של ה-JSON בבקשה ליצירת אשכול:

    "systemAddonConfig" {
   "ingress" {
           "disabled": true
   }
}

  2. שולחים את בקשת יצירת האשכול כמו שמתואר במאמר יצירת אשכול.

תמיכה ב-SCTP

‫Distributed Cloud תומך בפרוטוקול Stream Control Transmission Protocol ‏ (SCTP) בממשק הרשת הראשי עבור רשתות פנימיות וחיצוניות. התמיכה ב-SCTP כוללת את סוגי השירות NodePort, LoadBalancer ו-ClusterIP. אפשר להשתמש ב-SCTP כדי לתקשר בין פודים לבין משאבים חיצוניים. בדוגמה הבאה מוסבר איך להגדיר את IPERF כClusterIP שירות באמצעות SCTP:

apiVersion: v1
kind: Pod
metadata:
  name: iperf3-sctp-server-client
  labels:
    app.kubernetes.io/name: iperf3-sctp-server-client
spec:
  containers:
  - name: iperf3-sctp-server
    args: ['-s', '-p 31390']
    ports:
      - containerPort: 31390
        protocol: SCTP
        name: server-sctp
  - name: iperf3-sctp-client
    ...

---

apiVersion: v1
kind: Service
metadata:
  name: iperf3-sctp-svc
spec:
  selector:
    app.kubernetes.io/name: iperf3-sctp-server-client
  ports:
    - port: 31390
      protocol: SCTP
      targetPort: server-sctp

מודולים של ליבת SCTP

החל מגרסה 1.5.0, ‏ Distributed Cloud מגדיר את מודול הליבה של sctp Edge OS כמודול שאפשר לטעון. כך אפשר לטעון את מחסניות פרוטוקול ה-SCTP שלכם במרחב המשתמש של ליבת המערכת.

בנוסף, Distributed Cloud טוען את המודולים הבאים לליבה כברירת מחדל:

שם המודול שם ההגדרה
fou CONFIG_NET_FOU
nf_conntrack_proto_gre CONFIG_NF_CT_PROTO_GRE
nf_conntrack_proto_sctp CONFIG_NF_CT_PROTO_SCTP
inotify CONFIG_INOTIFY_USER
xt_redirect CONFIG_NETFILTER_XT_TARGET_REDIRECT
xt_u32 CONFIG_NETFILTER_XT_MATCH_U32
xt_multiport CONFIG_NETFILTER_XT_MATCH_MULTIPORT
xt_statistic CONFIG_NETFILTER_XT_MATCH_STATISTIC
xt_owner CONFIG_NETFILTER_XT_MATCH_OWNER
xt_conntrack CONFIG_NETFILTER_XT_MATCH_CONNTRACK
xt_mark CONFIG_NETFILTER_XT_MARK
ip6table_mangle CONFIG_IP6_NF_MANGLE
ip6_tables CONFIG_IP6_NF_IPTABLES
ip6table_filter CONFIG_IP6_NF_FILTER
ip6t_reject CONFIG_IP6_NF_TARGET_REJECT
iptable_mangle CONFIG_IP_NF_MANGLE
ip_tables CONFIG_IP_NF_IPTABLES
iptable_filter CONFIG_IP_NF_FILTER

משאב ClusterDNS

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

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