הגדרת כמה ממשקי רשת לפודים

ממשקי רשת מרובים (multi-NIC) לפודים ב-Google Distributed Cloud מאפשרים לבודד את התנועה במישור הבקרה מהתנועה במישור הנתונים. ממשקי רשת נוספים מספקים גם יכולת multicast לפודים. אפשר להשתמש ב-Multi-NIC לפודים באשכולות של משתמשים, באשכולות היברידיים ובאשכולות עצמאיים, ובאשכולות של אדמינים בגרסה 1.34 ואילך.

כדי להגדיר את התכונה הזו ב-GKE On-Prem API, משתמשים ב-BareMetalNetworkConfig לאשכולות של משתמשים, או ב-BareMetalAdminNetworkConfig לאשכולות של אדמינים בגרסה 1.34 ואילך.

תרחישים לדוגמה לשימוש בכמה ממשקי רשת

בידוד מישור הרשת חשוב למערכות שמשתמשות בפונקציות וירטואליזציה של רשת (NFV), כמו שירותי Networking מוגדרי-תוכנה ברשת תקשורת מרחבית (WAN)‏ (SD-WAN), מתווכי אבטחה לגישה לענן (CASB) וחומות אש מהדור הבא (NG-FW). סוגים כאלה של NFV מסתמכים על גישה לממשקים מרובים כדי להפריד בין מישורי הניהול והנתונים, בזמן שהם פועלים כקונטיינרים.

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

הגדרת כמה ממשקי רשת

באופן כללי, יש שלושה שלבים להגדרת כמה ממשקי רשת לפודים:

  1. מפעילים multi-NIC לאשכול באמצעות השדה multipleNetworkInterfaces במשאב המותאם אישית של האשכול.

  2. הגדרת ממשקי רשת באמצעות משאבים בהתאמה אישית של NetworkAttachmentDefinition.

  3. הקצאת ממשקי רשת לפודים באמצעות ההערה k8s.v1.cni.cncf.io/networks.

המידע הנוסף יעזור לכם להגדיר את התכונה multi-NIC ולהשתמש בה באופן שהכי מתאים לדרישות הרשת שלכם.

הפעלת multi-NIC

כדי להפעיל multi-NIC לפודים, מוסיפים את השדה multipleNetworkInterfaces לקטע clusterNetwork של המשאב בהתאמה אישית של האשכול ומגדירים אותו כ-true.

  ...
  clusterNetwork:
    multipleNetworkInterfaces: true
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...

ציון ממשקי רשת

משתמשים במשאבים מותאמים אישית של NetworkAttachmentDefinition כדי לציין ממשקי רשת נוספים. המשאבים המותאמים אישית של NetworkAttachmentDefinition תואמים לרשתות שזמינות ל-Pods. אפשר לציין את המשאבים בהתאמה אישית בהגדרות של האשכול, כמו בדוגמה הבאה, או ליצור את המשאבים בהתאמה אישית של NetworkAttachmentDefinition ישירות.

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: my-cluster
  namespace: cluster-my-cluster
spec:
    type: user
    clusterNetwork:
      multipleNetworkInterfaces: true
...
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-network-1
  namespace: cluster-my-cluster
spec:
  config: '{
  "cniVersion":"0.3.0",
  "type": "ipvlan",
  "master": "enp2342",  # defines the node interface that this pod interface would
                         map to.
  "mode": "l2",
  "ipam": {
    "type": "whereabouts",
    "range": "172.120.0.0/24"
  }
}'
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-network-2
  namespace: cluster-my-cluster
spec:
  config: '{
  "cniVersion":"0.3.0",
  "type": "macvlan",
  "mode": "bridge",
  "master": "vlan102",
  "ipam": {
    "type": "static",
    "addresses": [
      {
        "address": "10.10.0.1/24",
        "gateway": "10.10.0.254"
      }
    ],
    "routes": [
      { "dst": "192.168.0.0/16", "gw": "10.10.5.1" }
    ]
  }
}'

כשמציינים את המשאב המותאם אישית NetworkAttachmentDefinition בקובץ התצורה של האשכול, Google Distributed Cloud משתמשת בשם הזה כדי לשלוט במשאב המותאם אישית NetworkAttachmentDefinition אחרי יצירת האשכול. ב-Google Distributed Cloud, המשאב בהתאמה אישית במרחב השמות של האשכול נחשב למקור האמת, והוא מותאם למרחב השמות default של אשכול היעד.

בתרשים הבא מוסבר איך Google Distributed Cloud מתאים בין המשאבים המותאמים אישית של NetworkAttachmentDefinition ממרחב השמות הספציפי לאשכול לבין מרחב השמות של default.

התאמה של NetworkAttachmentDefinition

למרות שזה אופציונלי, מומלץ לציין משאבים בהתאמה אישית של NetworkAttachmentDefinition באופן הזה במהלך יצירת האשכול. היתרון הכי גדול של אשכולות משתמשים הוא שאפשר לציין את המשאבים בהתאמה אישית בזמן שיוצרים את האשכול, ואז לשלוט במשאבים בהתאמה אישית של NetworkAttachmentDefinition מאשכול האדמין.

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

הקצאת ממשקי רשת ל-Pod

משתמשים בהערה k8s.v1.cni.cncf.io/networks כדי להקצות ממשק רשת אחד או יותר ל-Pod. כל ממשק רשת מצוין באמצעות מרחב שמות ושם של משאב בהתאמה אישית של NetworkAttachmentDefinition, שמופרדים באמצעות לוכסן (/).

---
apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: NAMESPACE/NAD_NAME
spec:
  containers:
  ...

מחליפים את מה שכתוב בשדות הבאים:

  • ‫NAMESPACE: מרחב השמות. משתמשים ב-default למרחב השמות שמוגדר כברירת מחדל, שהוא סטנדרטי. בקטע בעיות אבטחה מפורט מקרה חריג.
  • ‫NAD_NAME: השם של המשאב בהתאמה אישית ב-NetworkAttachmentDefinition.

כדי לציין כמה ממשקי רשת, צריך להשתמש ברשימה מופרדת בפסיקים.

בדוגמה הבאה, שני ממשקי רשת מוקצים ל-Pod של samplepod. ממשקי הרשת מצוינים לפי השמות של שני משאבים בהתאמה אישית של NetworkAttachmentDefinition,‏ gke-network-1 ו-gke-network-2, במרחב השמות שמוגדר כברירת מחדל של אשכול היעד.

---
apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: default/gke-network-1,default/gke-network-2
spec:
  containers:
  ...

הגבלת ממשקי הרשת ל-NodePool

משתמשים בהערה k8s.v1.cni.cncf.io/nodeSelector כדי לציין את מאגר הצמתים שבו המשאב המותאם אישית NetworkAttachmentDefinition תקף. ב-Google Distributed Cloud, כל pod שמפנה למשאב בהתאמה אישית נפרס בצמתים הספציפיים האלה. בדוגמה הבאה, Google Distributed Cloud מאלץ פריסה של כל הפודים שהוקצה להם ממשק הרשת gke-network-1 למאגר הצמתים multinicNP. ‫Google Distributed Cloud מוסיף ל-NodePool את התווית baremetal.cluster.gke.io/node-pool בהתאם.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/nodeSelector: baremetal.cluster.gke.io/node-pool=multinicNP
  name: gke-network-1
spec:
...

אתם לא מוגבלים לשימוש בתוויות הרגילות. אתם יכולים ליצור מאגרים מותאמים אישית משלכם מצומתי האשכול, על ידי הוספת תווית מותאמת אישית לצמתים האלה. משתמשים בפקודה kubectl label nodes כדי להחיל תווית בהתאמה אישית:

kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

מחליפים את מה שכתוב בשדות הבאים:

  • ‫NODE_NAME: שם הצומת שאתם מתייגים.
  • ‫LABEL_KEY: המפתח שבו משתמשים בשביל התווית.
  • ‫LABEL_VALUE: שם התווית.

אחרי שמוסיפים תווית לצומת, מוסיפים לו את ההערה baremetal.cluster.gke.io/label-taint-no-sync כדי למנוע מ-Google Distributed Cloud להתאים את התוויות. כדי לבדוק אם צומת מסומן בתווית, משתמשים בפקודה kubectl get nodes --show-labels.

בעיות אבטחה

משאב מותאם אישית של NetworkAttachmentDefinition מספק גישה מלאה לרשת, ולכן אדמינים של אשכולות צריכים להיזהר כשהם נותנים למשתמשים אחרים גישה ליצירה, לעדכון או למחיקה. אם צריך לבודד משאב מותאם אישית מסוים של NetworkAttachmentDefinition, אפשר למקם אותו במרחב שמות שאינו ברירת המחדל, שבו רק pod-ים מאותו מרחב שמות יכולים לגשת אליו. כדי להתאים בין משאבים מותאמים אישית של NetworkAttachmentDefinition שצוינו בקובץ התצורה של האשכול, הם תמיד ממוקמים במרחב השמות שמוגדר כברירת מחדל.

בתרשים הבא, פודים ממרחב השמות default לא יכולים לגשת לממשק הרשת במרחב השמות privileged.

שימוש במרחבי שמות כדי לבודד את התנועה ברשת

יישומי פלאגין נתמכים של CNI

בקטע הזה מפורטים יישומי הפלאגין של CNI שנתמכים בתכונה multi-NIC ב-Google Distributed Cloud. כשמציינים משאב בהתאמה אישית של NetworkAttachmentDefinition, צריך להשתמש רק בפלאגינים הבאים.

יצירת ממשק:

  • ipvlan
  • macvlan
  • bridge
  • sriov

פלאגינים של Meta:

  • portmap
  • sbr
  • tuning

יישומי פלאגין של IPAM:

  • host-local
  • static
  • whereabouts

הגדרת המסלול

פוד עם משאב אחד או יותר בהתאמה אישית של NetworkAttachmentDefinition כולל כמה ממשקי רשת. כברירת מחדל, טבלת הניתוב במצב הזה מורחבת עם הממשקים הנוספים שזמינים באופן מקומי ממשאבים מותאמים אישית של NetworkAttachmentDefinition שהוקצו בלבד. שער ברירת המחדל עדיין מוגדר להשתמש בממשק הראשי או בממשק ברירת המחדל של ה-Pod,‏ eth0.

אפשר לשנות את ההתנהגות הזו באמצעות הפלאגינים הבאים של CNI:

  • sbr
  • static
  • whereabouts

לדוגמה, יכול להיות שתרצו שכל התנועה תעבור דרך שער ברירת המחדל, הממשק שמוגדר כברירת מחדל. עם זאת, חלק מהתנועה הספציפית עוברת דרך אחד מהממשקים שאינם ברירת המחדל. יכול להיות שיהיה קשה להבחין בין התנועה על סמך כתובת ה-IP של היעד (ניתוב רגיל), כי אותה נקודת קצה זמינה בשני סוגי הממשקים. במקרה כזה, אפשר להשתמש בניתוב מבוסס-מקור (SBR).

פלאגין SBR

הפלאגין sbr נותן לאפליקציה שליטה על החלטות הניתוב. האפליקציה קובעת מהי כתובת ה-IP של המקור של החיבור שהיא יוצרת. כשהאפליקציה בוחרת להשתמש בכתובת ה-IP של המשאב המותאם אישית NetworkAttachmentDefinition בתור כתובת ה-IP של המקור, החבילות מגיעות לטבלת הניתוב הנוספת שהוגדרה על ידי sbr. טבלת הניתוב של sbr מגדירה את הממשק של המשאב בהתאמה אישית של NetworkAttachmentDefinition כשער ברירת המחדל. כתובת ה-IP של שער ברירת המחדל בטבלה הזו נשלטת באמצעות השדה gateway בתוך הפלאגינים whereabouts או static. מגדירים את הפלאגין sbr כפלאגין משורשר. למידע נוסף על הפלאגין sbr, כולל מידע על השימוש, ראו פלאגין לניתוב מבוסס-מקור.

בדוגמה הבאה, "gateway":"21.0.111.254" מוגדר ב-whereabouts, ו-sbr מוגדר כפלאגין משורשר אחרי ipvlan:

# ip route
default via 192.168.0.64 dev eth0  mtu 1500
192.168.0.64 dev eth0 scope link
# ip route list table 100
default via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1

פלאגינים סטטיים ופלאגינים של whereabouts

הפלאגין whereabouts הוא למעשה תוסף של הפלאגין static, ושניהם משתמשים באותה הגדרת ניתוב. לדוגמה להגדרה, ראו פלאגין לניהול כתובות IP סטטיות. אפשר להגדיר שער ומסלול כדי להוסיף אותם לטבלת הניתוב של ה-Pod. עם זאת, אי אפשר לשנות את שער ברירת המחדל של ה-Pod בדרך הזו.

בדוגמה הבאה מוצגת הוספה של "routes": [{ "dst": "172.31.0.0/16" }] במשאב בהתאמה אישית NetworkAttachmentDefinition:

# ip route
default via 192.168.0.64 dev eth0  mtu 1500
172.31.0.0/16 via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1
192.168.0.64 dev eth0 scope link

תצורות לדוגמה

בקטע הזה מוצגות כמה מהגדרות הרשת הנפוצות שנתמכות בתכונה multi-NIC.

חיבור רשת יחיד שמשמש כמה פודים

מחבר רשת אחד שמשמש כמה פודים

פוד אחד משתמש בכמה מחברי רשת

פוד אחד משתמש בכמה מחברי רשת

כמה מחברי רשת שמפנים לאותו ממשק שמשמש פוד אחד

כמה מחברי רשת שמפנים לאותו ממשק שמשמש פוד אחד

אותו מחבר רשת משמש כמה פעמים פוד אחד

אותו מחבר רשת משמש כמה פעמים פוד אחד

פתרון בעיות

אם ממשקי רשת נוספים מוגדרים באופן שגוי, ה-Pods שהם מוקצים להם לא יתחילו. בקטע הזה מוסבר איך למצוא מידע לפתרון בעיות בתכונה multi-NIC.

בדיקת אירועי pod

‫Multus מדווח על כשלים באמצעות אירועי pod ב-Kubernetes. כדי להציג אירועים של pod מסוים, משתמשים בפקודה הבאה של kubectl describe:

kubectl describe pod POD_NAME

בדיקת היומנים

בכל צומת, אפשר למצוא את היומנים של Whereabouts ו-Multus במיקומים הבאים:

  • /var/log/whereabouts.log
  • /var/log/multus.log

בדיקת הממשקים של ה-Pod

משתמשים בפקודה kubectl exec כדי לבדוק את הממשקים של ה-Pod. אחרי שמחילים בהצלחה את המשאבים בהתאמה אישית של NetworkAttachmentDefinition, הממשקים של ה-Pod נראים כמו הפלט הבא:

$ kubectl exec samplepod-5c6df74f66-5jgxs -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 00:50:56:82:3e:f0 brd ff:ff:ff:ff:ff:ff
    inet 21.0.103.112/21 scope global net1
       valid_lft forever preferred_lft forever
38: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 36:23:79:a9:26:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.2.191/32 scope global eth0
       valid_lft forever preferred_lft forever

קבלת סטטוס של Pod

משתמשים ב-kubectl get כדי לאחזר את סטטוס הרשת של pod נתון:

kubectl get pods POD_NAME -oyaml

הנה פלט לדוגמה שמציג את הסטטוס של pod עם כמה רשתות:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/network-status: |-
      [{
          "name": "",
          "interface": "eth0",
          "ips": [
              "192.168.1.88"
          ],
          "mac": "36:0e:29:e7:42:ad",
          "default": true,
          "dns": {}
      },{
          "name": "default/gke-network-1",
          "interface": "net1",
          "ips": [
              "21.0.111.1"
          ],
          "mac": "00:50:56:82:a7:ab",
          "dns": {}
      }]
    k8s.v1.cni.cncf.io/networks: gke-network-1