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

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

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

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

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

הערה: התכונה multi-NIC for pods נתמכת ב-GKE On-Prem API עבור אשכולות משתמשים. לפרטים נוספים, ראה BareMetalNetworkConfig במאמרי העזרה של ה-API של GKE On-Prem. בגרסה 1.34 ואילך, התכונה הזו נתמכת ב-GKE On-Prem API עבור אשכולות אדמין. לפרטים נוספים, ראו BareMetalAdminNetworkConfig בתיעוד ה-API של GKE On-Prem.

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

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

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

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

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

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

הפעלת multi-NIC

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

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

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

משתמשים במשאבים מותאמים אישית NetworkAttachmentDefinition כדי לציין ממשקי רשת נוספים. NetworkAttachmentDefinition המשאבים המותאמים אישית תואמים לרשתות שזמינות לפודים. אפשר לציין את המשאבים המותאמים אישית בהגדרת האשכול, כמו בדוגמה הבאה, או ליצור את המשאבים המותאמים אישית של 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 של אשכול היעד.

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

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

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

הקצאת ממשקי רשת לפוד

משתמשים בהערה k8s.v1.cni.cncf.io/networks כדי להקצות ממשק רשת אחד או יותר לפוד. כל ממשק רשת מצוין באמצעות מרחב שמות ושם של 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.

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

בדוגמה הבאה, שני ממשקי רשת מוקצים ל-samplepod Pod. ממשקי הרשת מצוינים לפי השמות של שני משאבים מותאמים אישית, 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, כל הפודים שמפנים למשאב המותאם אישית הזה נפרסים על הצמתים הספציפיים האלה. בדוגמה הבאה, Google Distributed Cloud כופה פריסה של כל הפודים שהוקצו להם gke-network-1 ממשק הרשת אל multinicNP NodePool. ‫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, אפשר למקם אותו במרחב שמות שאינו ברירת המחדל, שרק הפודים ממרחב השמות הזה יכולים לגשת אליו. כדי לבצע התאמה של משאבים מותאמים אישית NetworkAttachmentDefinition שצוינו בקובץ התצורה של האשכול, הם תמיד ממוקמים במרחב השמות שמוגדר כברירת מחדל.

בתרשים הבא, ל-Pods ממרחב השמות default אין גישה לממשק הרשת במרחב השמות privileged.

תוספי CNI נתמכים

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

יצירת ממשק:

• ipvlan
• macvlan
• bridge
• sriov

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

• portmap
• sbr
• tuning

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

• host-local
• static
• whereabouts

הגדרת מסלול

ל-Pod עם משאב מותאם אישית אחד או יותר שהוקצו לו יש כמה ממשקי רשת.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, כולל מידע על השימוש בו, זמין במאמר Source-based routing plugin.

בדוגמה הבאה, "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 הוא בעצם הרחבה של הפלאגין 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

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

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

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

מספר קבצים מצורפים לרשת שמשמשים פוד יחיד

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

אותו קובץ מצורף לרשת משמש כמה פעמים על ידי פוד יחיד

פתרון בעיות

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

בדיקת אירועים של פודים

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

kubectl describe pod POD_NAME

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

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

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

בדיקת הממשקים של הפודים

משתמשים בפקודה 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 כדי לאחזר את סטטוס הרשת של פוד נתון:

kubectl get pods POD_NAME -oyaml

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

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