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

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

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

רשתות עם מחסנית כפולה של IPv4/IPv6

‫Distributed Cloud Connected מאפשר ליצור אשכולות שמשתמשים ברשתות עם תמיכה כפולה ב-IPv4/IPv6. כדי להשתמש בפונקציונליות הזו, צריך להזמין את Distributed Cloud עם הפעלה של רשתות IPv4/IPv6 כפולות. אי אפשר להגדיר מחדש פריסה קיימת של Distributed Cloud שמבוססת על IPv4 בלבד ומחוברת לרשת עם פרוטוקול כפול IPv4/IPv6. כדי לבדוק אם הפריסה תומכת ברשתות עם מחסנית כפולה של IPv4/IPv6, פועלים לפי ההוראות במאמר קבלת מידע על מכונה ובודקים את הערך שמוחזר של התווית dualstack_capable.

בצביר עם תמיכה כפולה, מחסנית IPv4 משתמשת במצב איים, ומחסנית IPv6 משתמשת במצב שטוח. לכן, צריך לציין כתובות IPv6 נפרדות של צמתים ושל פודים ששייכות לאותה תת-רשת. מידע נוסף זמין במאמר בנושא מודלים של רשתות: שטוח לעומת איים.

לדוגמה, אם הצמתים המחוברים של Distributed Cloud ומכונות מקומיות אחרות נמצאים באותו דומיין Layer 2, אפשר לציין את בלוקי ה-CIDR של IPv6 עבור האשכול באופן הבא:

מטרת החסימה חסימת טווח גודל הבלוק
רשת משנה של IPv6 fd12::/56 ‫2^72
קבוצת Pod fd12::1:0/59 ‫2^69
שירותים fd12::2:0/59 ‫2^69

בדוגמה הזו אנחנו מניחים את הפרטים הבאים:

  • בלוקי ה-CIDR של הצומת, ה-Pod והשירות שייכים לרשת העל fd:12::/56.
  • כתובות ה-IP של הצומת, ה-Pod והשירות הן תת-רשתות של בלוק ה-CIDR שצוין.
  • אף אחת מרשתות המשנה לא חופפת.

רשתות עם סטאק כפול של IPv4/IPv6 דורשות איזון עומסים בשכבה 2 עבור שיוך BGP של IPv4, ואיזון עומסים בשכבה 3 עבור שיוך IPv6. מידע נוסף זמין במאמר בנושא איזון עומסים.

מידע נוסף על פריסת עומסי עבודה באשכולות עם מחסנית כפולה של IPv4/IPv6 זמין במאמרים הבאים:

הפעלת 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. מקימים סשנים של BGP peering בכיוון צפון עם נתבי ה-PE באמצעות חיבורי ה-Interconnect המתאימים.

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

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

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

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

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

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

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

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

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

יצירת רשת

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

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

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

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

יצירת סשנים של קישור 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

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

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

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

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

בדיקת ההגדרה

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

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

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

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

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

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

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

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

איזון עומסים

‫Distributed Cloud מגיע עם פתרונות איזון העומסים הבאים:

  • איזון עומסים בשכבה 2 באמצעות MetalLB
  • איזון עומסים בשכבה 3 באמצעות מאזני עומסים של Google Distributed Cloud

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

איזון עומסים בשכבה 2 באמצעות MetalLB

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

  1. מנהל הרשת מתכנן את טופולוגיית הרשת ומציין את רשת המשנה הנדרשת של כתובות IPv4 ו-IPv6 וירטואליות כשמזמינים את Distributed Cloud. ‫Google מגדירה את הציוד של Distributed Cloud בהתאם לפני המסירה. חשוב לזכור:
    • רשת המשנה של כתובות ה-VIP משותפת לכל אשכולות Kubernetes שפועלים באזור Distributed Cloud.
    • מסלול לרשת המשנה של ה-VIP המבוקש מפורסם באמצעות סשנים של BGP בין אזור 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 ו-IPv6, טווחי כתובות ורשתות משנה שייכללו במאגר הכתובות הזה.
    • ‫avoid_buggy_ips: החרגה של כתובות IP שמסתיימות ב-.0 או ב-.255.
    • ‫manual_assign: מאפשר להקצות כתובות באופן ידני מהמאגר הזה בהגדרות של שירות היעד LoadBalancer, במקום שהן יוקצו אוטומטית על ידי בקר MetalLB.

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

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

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

איזון עומסים בשכבה 3 באמצעות מאזני עומסים של Google Distributed Cloud

‫Google Distributed Cloud במודל מחובר כולל פתרון משולב לאיזון עומסים ברשת שמבוסס על מאזני העומסים המשולבים של Google Distributed Cloud במצב Layer 3, שמוגדרים כרכיבי BGP. אתם יכולים להשתמש בפתרון הזה כדי לחשוף שירותים שפועלים באזור המחובר של Distributed Cloud לעולם החיצוני באמצעות כתובות IP וירטואליות.

אפשר לציין את טווחי כתובות ה-VIP עבור שירותי LoadBalancer המתאימים באמצעות metallb-config ConfigMap. לדוגמה:

kind: ConfigMap
apiVersion: v1
data:
  config: |
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 10.100.10.66/27
metadata:
  name: metallb-config
  namespace: metallb-system

בדוגמה הקודמת, לכל שירות LoadBalancer שאתם מגדירים מוקצית באופן אוטומטי כתובת IP וירטואלית מהטווח 10.100.10.66/27 שצוין ב-ConfigMap. כתובות ה-VIP האלה מפורסמות צפונה על ידי רכיבי BGP של Distributed Cloud שהוגדרו במתגי ToR באמצעות משאבי BGPPeer.

כשיוצרים אשכול של Distributed Cloud, המשאבים הבאים נוצרים אוטומטית באשכול הזה:

  • BGPLoadBalancer משאב שמייצר את מאזן העומסים של BGP.
  • משאב NetworkGatewayGroup שמציין את כתובות ה-IP הצפות המקומיות שבהן יש להשתמש עבור רכיבי ה-BGP. כתובות ה-IP האלה מוגדרות אוטומטית כשתי כתובות ה-IP האחרונות של תת-הרשת של צומת Kubernetes שהוקצתה לאשכול.

אחרי שיוצרים את המשאבים האלה, אפשר להגדיר סשנים של BGP למתגי ToR של Distributed Cloud על ידי הגדרת משאבי BGPPeer מתאימים. כדי לעשות זאת, צריכים להיות לכם מספרי המערכת האוטונומית (ASN) הנדרשים וכתובות ה-IP של עמיתי ה-loopback עבור מתגי ה-ToR. כתובות ה-IP האלה משמשות כנקודות קצה של סשן BGP במתג ToR במשאב הרשת שמוגדר כברירת מחדל. חשוב לזכור שהערך של הפרמטר network חייב להיות pod-network.

דוגמה לשני משאבי BGPPeer:

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor1
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.10
  sessions: 1

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor2
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.11
  sessions: 1

הגדרת אוטומציה של איזון עומסים BGP בשכבה 3 עבור קישור IPv6

כדי להתחיל להשתמש ב-Peering של IPv6 באשכול של רשתות עם מחסנית כפולה של IPv4/IPv6, צריך לפנות לתמיכה של Google כדי להפעיל אוטומציה של איזון עומסים ב-Google Distributed Cloud בפריסה המקושרת של Distributed Cloud.

יצירת שירות LoadBalancer בשכבה 3

אחרי שמפעילים אוטומציה של איזון עומסים ב-Google Distributed Cloud בפריסה שמחוברת ל-Distributed Cloud, צריך ליצור מופע של שירות LoadBalancer בשכבה 3. לדוגמה:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app.kubernetes.io/name: MyApp
spec:
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
  - IPv6
  - IPv4
  selector:
    app.kubernetes.io/name: MyApp
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80

בדיקת המצב של סשן ה-BGP ושירותי איזון העומסים

כדי לבדוק את המצב של סשן ה-BGP, משתמשים בפקודה הבאה:

kubectl get bgpsessions.networking.gke.io -A

הפקודה מחזירה פלט שדומה לדוגמה הבאה:

NAMESPACE     NAME                                                 LOCAL ASN   PEER ASN   LOCAL IP        PEER IP         STATE            LAST REPORT
kube-system   bgppeertor1-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.10     Established      2s
kube-system   bgppeertor2-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.11     Established      2s

כדי לוודא שהשירותים של LoadBalancer מפורסמים על ידי רכיבי BGP, משתמשים בפקודה הבאה:

kubectl get bgpadvertisedroutes.networking.gke.io -A

הפקודה מחזירה פלט שדומה לדוגמה הבאה:

NAMESPACE      NAME                           PREFIX            METRIC
kube-system    bgplb-default-service-tcp      10.100.10.68/32
kube-system    bgplb-default-service-udp      10.100.10.77/32

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

בנוסף לאיזון עומסים, Distributed Cloud Connected תומך גם במשאבי 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.

השבתה של משאב 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. שולחים את בקשת יצירת האשכול כמו שמתואר במאמר יצירת אשכול.

שירות NodePort

‫Distributed Cloud connected תומך בשירות Kubernetes NodePort שמחכה לחיבורים בצומת Distributed Cloud במספר יציאה שתבחרו. שירות NodePort תומך בפרוטוקולים TCP,‏ UDP ו-SCTP. לדוגמה:

apiVersion: v1
kind: pod
metadata:
  name: socat-nodeport-sctp
  labels:
    app.kubernetes.io/name: socat-nodeport-sctp
spec:
  containers:
  - name: socat-nodeport-sctp
    ...
    ports:
      - containerPort: 31333
        protocol: SCTP
        name: server-sctp

---

apiVersion: v1
kind: service
metadata:
  name: socat-nodeport-sctp-svc
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: socat-nodeport-sctp
  ports:
    - port: 31333
      protocol: SCTP
      targetPort: server-sctp
      nodePort: 31333

תמיכה ב-SCTP

‫Distributed Cloud connected תומך בפרוטוקול Stream Control Transmission (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

הפונקציונליות הזו לא זמינה בשרתים מקושרים של Distributed Cloud.

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

החל מגרסה 1.5.0, ‏Distributed Cloud connected מגדיר את מודול הליבה של 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

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

הפונקציונליות הזו לא זמינה בשרתים מקושרים של Distributed Cloud.

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