הגדרת כמה ממשקי רשת לקבוצות Pod

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

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

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

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

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

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

כדי להפעיל multi-NIC באשכול המשתמשים, משתמשים בשדות multipleNetworkInterfaces ו-enableDataplaneV2 בקובץ התצורה של האשכול.
מציינים ממשקי רשת באמצעות הקטע additionalNodeInterfaces בקובץ התצורה של האשכול, ויוצרים משאב מותאם אישית אחד או יותר מסוג NetworkAttachmentDefinition.
הקצאת ממשקי רשת לקבוצות Pod באמצעות ההערה k8s.v1.cni.cncf.io/networks.

הפעלת multi-NIC

כדי להפעיל multi-NIC עבור ה-Pods, מגדירים את השדות multipleNetworkInterfaces ו-enableDataplaneV2 בקובץ התצורה של אשכול המשתמשים לערך true.

apiVersion: v1
multipleNetworkInterfaces: true
enableDataplaneV2: true
  ...

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

בקובץ התצורה של האשכול, מציינים ממשקי רשת נוספים של הצומת בקטע additionalNodeInterfaces.

לדוגמה, הנה חלק מקובץ התצורה של אשכול משתמשים שבו מוצג ממשק רשת של צומת נוסף:

apiVersion: v1
multipleNetworkInterfaces: true
enableDataplaneV2: true
network:
  serviceCIDR: "10.96.0.0/20"
  podCIDR: "192.168.0.0/16"
  vCenter:
    networkName: network-private310
  ...
  # New multiple network configs
  additionalNodeInterfaces:
  - networkName: "gke-network-1"
    ipBlockFilePath: "my-block-yaml"
    type: static

אחרי שיוצרים אשכול עם ההגדרה הקודמת, צריך ליצור משאב מותאם אישית אחד או יותר של NetworkAttachmentDefinition (NAD) באשכול המשתמש, שבו מציינים ממשקי רשת נוספים. המספרים NetworkAttachmentDefinitions מייצגים את הרשתות שזמינות ל-Pods שלכם. בדוגמה הבאה מוצג מניפסט של NetworkAttachmentDefinition:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-network-1
  namespace: default
spec:
  config: '{
  "cniVersion":"0.3.0",
  "type": "ipvlan",
  "master": "ens224", # defines the node interface that this Pod interface would map to
  "mode": "l2",
  "ipam": {
    "type": "whereabouts",
    "range": "172.16.0.0/24"
   }
}'

שומרים את המניפסט כקובץ YAML, למשל my-nad.yaml, ויוצרים את NetworkAttachmentDefinition:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f my-nad.yaml

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

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

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

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

הגבלת ממשקי רשת לקבוצת צמתים

אם לא רוצים ש-NetworkAttachmentDefinition יחול על אשכול שלם, אפשר להגביל את הפונקציונליות שלו לקבוצה של צמתים.

אפשר לקבץ את צמתי האשכול באמצעות התווית הרגילה שהוקצתה לצומת או באמצעות תווית מותאמת אישית משלכם. לאחר מכן אפשר לציין את תווית הצומת בקובץ NetworkAttachmentDefinition המניפסט באמצעות ההערה k8s.v1.cni.cncf.io/nodeSelector. ב-Google Distributed Cloud, כל ה-Pods שמפנים למשאב המותאם אישית הזה נפרסים רק בצמתים עם התווית הזו.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/nodeSelector: LABEL_KEY=LABEL_VALUE
  name: gke-network-1
spec:
...

בדוגמה הבאה מוצגת התווית my-label=multinicNP שצוינה ב-NetworkAttachmentDefinition, והיא מאלצת פריסה של כל ה-Pods שהוקצו לרשת gke-network-1 לצמתים שיש להם את התווית הזו.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/nodeSelector: my-label=multinicNP
  name: gke-network-1
spec:
...

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

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

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

‫NODE_NAME: השם של הצומת שרוצים להוסיף לו תווית.
‫LABEL_KEY: המפתח שבו רוצים להשתמש לתווית.
‫LABEL_VALUE: ערך התווית.

בדוגמה הזו, הצומת my-node מקבל את התווית environment=production:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] label nodes my-node environment=production

בעיות אבטחה

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

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

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

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

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

יצירת ממשק:

ipvlan
macvlan
bridge

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

portmap
sbr
tuning

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

host-local
static
whereabouts

הגדרת מסלול

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

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

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

צירוף לרשת יחידה שמשמש כמה פודים:

צירוף יחיד לרשת שמשמש כמה פודים.

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

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

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

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

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

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

פתרון בעיות

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

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

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

kubectl describe pod POD_NAME

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

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

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

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

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

user@node1:~$ 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

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