מפעיל של פונקציית רשת

בדף הזה מתואר האופרטור הייעודי של פונקציית הרשת Kubernetes שמגיע עם Google Distributed Cloud במודל מחובר. האופרטור הזה מטמיע קבוצה של CustomResourceDefinitions ‏ (CRD) שמאפשרים ל-Distributed Cloud המחובר להריץ עומסי עבודה עם ביצועים גבוהים.

האופרטור Network Function מאפשר לבצע את הפעולות הבאות:

  • שליחת בקשת מידע על מכשירי רשת קיימים בצומת.
  • שאילתה של כתובת ה-IP ומצב הקישור הפיזי של כל מכשיר רשת בצומת.
  • הקצאת ממשקי רשת נוספים בצומת.
  • הגדרה של תכונות מערכת ברמה נמוכה במכונה הפיזית של הצומת שנדרשות לתמיכה בעומסי עבודה עם ביצועים גבוהים.
  • משתמשים בווירטואליזציה של קלט/פלט עם שורש יחיד (SR-IOV) בממשקי רשת של PCI Express כדי להפוך אותם לווירטואליים לממשקים וירטואליים מרובים. לאחר מכן, תוכלו להגדיר את עומסי העבודה המחוברים של Distributed Cloud כך שישתמשו בממשקי הרשת הווירטואליים האלה.

התמיכה המחוברת ב-Distributed Cloud ב-SR-IOV מבוססת על הפרויקטים הבאים בקוד פתוח:

פרופילים של מפעילי פונקציות רשת

‫Distributed Cloud במודל מחובר מספק את פרופילי הפונקציונליות הבאים של מפעיל פונקציות רשת בכל גורם צורה של Distributed Cloud במודל מחובר:

  • מתלים מחוברים של Distributed Cloud תומכים בפרופיל המלא של פונקציית הרשת (NF) עם התכונות הבאות:

    • פונקציות אוטומציה של רשתות מאפשרות לבצע אוטומציה של הגדרת הרשת של ה-Pod של עומס העבודה. לדוגמה, הגדרת קישור בין רשתות שכנות (peering) של BGP וממשקי רשת משניים.

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

    • פונקציות ההגדרה של הצומת מאפשרות לכם לשפר את הביצועים של הצומת כך שיתאימו לצרכים העסקיים שלכם, כולל בידוד CPU, דף ענק, ליבת זמן אמת, פרמטרים של kubelet ו-sysctl.

    • פונקציות ניהול צריכת החשמל מאפשרות לכם לנהל את צריכת החשמל בצומת, כולל מצבי P ומצבי C של מעבדים מבודדים.

    • פונקציות Webhook מאפשרות לאמת את קלט המשתמשים.

    • פונקציות שונות כוללות את כלי האוטומציה SR-IOV שקובע באופן אוטומטי את האופרטור SR-IOV.

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

    • פונקציות אוטומציה של רשתות מאפשרות לבצע אוטומציה של הגדרת הרשת של ה-Pod של עומס העבודה. לדוגמה, הגדרת קישור בין רשתות שכנות (peering) של BGP וממשקי רשת משניים.

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

    • פונקציות Webhook מאפשרות לאמת את קלט המשתמשים.

דרישות מוקדמות

מפעיל פונקציית הרשת מאחזר את תצורת הרשת מ-Distributed Cloud Edge Network API. כדי לאפשר זאת, צריך להקצות לחשבון השירות של מפעיל פונקציית הרשת את התפקיד Edge Network Viewer ‏(roles/edgenetwork.viewer) באמצעות הפקודה הבאה:

gcloud projects add-iam-policy-binding ZONE_PROJECT_ID \
  --role roles/edgenetwork.viewer \
  --member "serviceAccount:CLUSTER_PROJECT_ID.svc.id.goog[nf-operator/nf-angautomator-sa]"

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

  • ‫ZONE_PROJECT_ID במזהה של Google Cloud הפרויקט שמכיל את המשאבים של Distributed Cloud Edge Network API.
  • ‫CLUSTER_PROJECT_ID במזהה של Google Cloud הפרויקט שמכיל את אשכול היעד המחובר ל-Distributed Cloud.

משאבים של מפעילי פונקציות רשת

אופרטור של פונקציית רשת במודל מחובר של Distributed Cloud מטמיע את ה-CRD הבאים של Kubernetes:

  • ‫Network. מגדיר רשת וירטואלית שקבוצות ה-Pod יכולות להשתמש בה כדי לתקשר עם משאבים פנימיים וחיצוניים. לפני שמציינים את ה-VLAN במשאב הזה, צריך ליצור את ה-VLAN המתאים באמצעות Distributed Cloud Edge Network API. הוראות מפורטות מופיעות במאמר בנושא יצירת רשת משנה.
  • ‫NetworkInterfaceState. מאפשרת לגלות את מצבי ממשק הרשת ולשאול את ממשק הרשת לגבי מצב הקישור וכתובת ה-IP.
  • ‫NodeSystemConfigUpdate. מאפשרת להגדיר תכונות מערכת ברמה נמוכה, כמו אפשרויות ליבה ודגלים של Kubelet.
  • ‫SriovNetworkNodePolicy. בוחר קבוצה של ממשקי רשת וירטואליים של SR-IOV ומפעיל את הקבוצה כמשאב Kubernetes. אפשר להשתמש במשאב הזה במשאב NetworkAttachmentDefinition.
  • ‫SriovNetworkNodeState. מאפשרת לשלוח שאילתה לגבי מצב ההקצאה של משאב SriovNetworkNodePolicy בצומת של Distributed Cloud.
  • ‫NetworkAttachmentDefinition. מאפשרת לכם לצרף תרמילי Distributed Cloud לרשת לוגית או פיזית אחת או יותר בצומת המחובר של Distributed Cloud. לפני שמציינים את ה-VLAN במשאב הזה, צריך ליצור את ה-VLAN המתאים באמצעות Distributed Cloud Edge Network API. הוראות מפורטות מופיעות במאמר בנושא יצירת רשת משנה.

מפעיל פונקציית הרשת מאפשר גם להגדיר ממשקי רשת משניים שלא משתמשים בפונקציות וירטואליות של SR-IOV.

משאב Network

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

משאב Network מספק את הפרמטרים הבאים שאפשר להגדיר עבור ממשק הרשת שנחשף כשדות שאפשר לכתוב בהם:

  • ‫spec.type: מציין את שכבת התעבורה ברשת עבור הרשת הזו. הערך החוקי היחיד הוא L2. צריך לציין גם ערך nodeInterfaceMatcher.interfaceName.
  • ‫spec.nodeInterfaceMatcher.interfaceName: השם של ממשק הרשת הפיזי בצומת היעד של Distributed Cloud במודל מחובר, שרוצים להשתמש בו עם הרשת הזו.
  • ‫spec.gateway4: כתובת ה-IP של שער הרשת עבור הרשת הזו.
  • ‫spec.l2NetworkConfig.prefixLength4: מציין את טווח ה-CIDR של הרשת הזו.
  • ‫annotations.networking.gke.io/gdce-per-node-ipam-size: מציין את הגודל של מסכה של רשת משנה עבור צומת בודד. אם לא מציינים ערך, גודל מסכה של רשת משנה מוגדר לערך של השדה cluster-cidr-config-per-node-mask-size ב-ConfigMap‏ nf-operator-defaults במרחב השמות nf-operator.
  • ‫annotations.networking.gke.io/gke-gateway-clusterip-cidr: מציין חסימת CIDR לגישה לאשכולות דרך Connect Gateway. המשתנה הזה משמש את CoreDNS בממשקי רשת משניים.
  • ‫annotations.networking.gke.io/gke-gateway-pod-cidr: מציין חסימת CIDR עבור Pod שאפשר להקצות בממשקי רשת משניים.
  • ‫annotations.networking.gke.io/gdce-vlan-id: מציין את מזהה ה-VLAN של הרשת הזו.
  • ‫annotations.networking.gke.io/gdce-vlan-mtu: (אופציונלי) מציין את ערך ה-MTU של הרשת הזו. אם לא מציינים ערך, הערך של MTU מועבר בירושה מהממשק ברמת ההורה.
  • ‫annotations.networking.gke.io/gdce-lb-service-vip-cidr: מציין את טווח כתובות ה-IP הווירטואליות של שירות איזון העומסים. הערך יכול להיות בלוק CIDR או טווח כתובות מפורש. ההערה הזו היא חובה עבור איזון עומסים בשכבה 3 ואופציונלית עבור איזון עומסים בשכבה 2.

בדוגמה הבאה אפשר לראות את מבנה המשאב:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: vlan200-network
  annotations:
    networking.gke.io/gdce-vlan-id: 200
    networking.gke.io/gdce-vlan-mtu: 1500
    networking.gke.io/gdce-lb-service-vip-cidrs: "10.1.1.0/24"
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.200
  gateway4: 10.53.0.1

כדי לציין כמה טווחים של כתובות IP וירטואליות לשירות איזון העומסים, משתמשים בהערה networking.gke.io/gdce-lb-service-vip-cidrs. אפשר לספק את הערכים של ההערה הזו כרשימה מופרדת בפסיקים או כמטען ייעודי (payload) בפורמט JSON. לדוגמה:

[
  {
    "name": "test-oam-3",
    "addresses": ["10.235.128.133-10.235.128.133"],
    "autoAssign": false
  }
  ,
  {
    "name": "test-oam-4",
    "addresses": ["10.235.128.134-10.235.128.134"],
    "autoAssign": false
  },
  {
    "name": "test-oam-5",
    "addresses": ["10.235.128.135-10.235.128.135"],
    "autoAssign": false
  }
]

אם בוחרים להשתמש במטען ייעודי (payload) בפורמט JSON, מומלץ להשתמש בפורמט JSON המצומצם. לדוגמה:

apiVersion: networking.gke.io/v1
  kind: Network
  metadata:
    annotations:
      networking.gke.io/gdce-lb-service-vip-cidrs: '[{"name":"test-oam-3","addresses":["10.235.128.133-10.235.128.133"],"autoAssign":false},{"name":"test-oam-4","addresses":["10.235.128.134-10.235.128.134"],"autoAssign":false},{"name":"test-oam-5","addresses":["10.235.128.135-10.235.128.135"],"autoAssign":false}]'
      networking.gke.io/gdce-vlan-id: "81"
    name: test-network-vlan81
  spec:
    IPAMMode: Internal
    dnsConfig:
      nameservers:
      - 8.8.8.8
    gateway4: 192.168.81.1
    l2NetworkConfig:
      prefixLength4: 24
    nodeInterfaceMatcher:
      interfaceName: gdcenet0.81
    type: L2

חשוב לזכור שאם לא מציינים את השדה autoAssign, ברירת המחדל שלו היא false.

משאב NetworkInterfaceState

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

ההגדרה שמוגדרת כברירת מחדל במכונות שמחוברות ל-Distributed Cloud כוללת ממשק רשת מאוגד בכרטיס הבת של הרשת לבחירת מתלים (rNDC) שנקרא gdcenet0. הממשק הזה מאגד את ממשקי הרשת eno1np0 ו-eno2np1. כל אחד מהם מחובר למתג ToR של Distributed Cloud.

המשאב NetworkInterfaceState מספק את הקטגוריות הבאות של מידע על ממשק הרשת, שמוצגות כשדות סטטוס לקריאה בלבד.

מידע כללי:

  • ‫status.interfaces.ifname: השם של ממשק הרשת של היעד.
  • status.lastReportTime: השעה והתאריך של דוח הסטטוס האחרון של ממשק היעד.

פרטי ההגדרה של כתובת ה-IP:

  • ‫status.interfaces.interfaceinfo.address: כתובת ה-IP שהוקצתה לממשק היעד.
  • ‫status.interfaces.interfaceinfo.dns: כתובת ה-IP של שרת ה-DNS שהוקצתה לממשק היעד.
  • ‫status.interfaces.interfaceinfo.gateway: כתובת ה-IP של שער הרשת שמשרת את ממשק היעד.
  • ‫status.interfaces.interfaceinfo.prefixlen: אורך קידומת ה-IP.

מידע על החומרה:

  • ‫status.interfaces.linkinfo.broadcast: כתובת ה-MAC של השידור של ממשק היעד.
  • ‫status.interfaces.linkinfo.businfo: הנתיב של מכשיר PCIe בפורמט bus:slot.function.
  • ‫status.interfaces.linkinfo.flags: הסימונים של הממשק, לדוגמה, BROADCAST.
  • ‫status.interfaces.linkinfo.macAddress: כתובת ה-MAC של שידור יחיד של ממשק היעד.
  • ‫status.interfaces.linkinfo.mtu: ערך ה-MTU של ממשק היעד.

נתוני קבלה:

  • ‫status.interfaces.statistics.rx.bytes: המספר הכולל של הבייטים שהתקבלו בממשק היעד.
  • ‫status.interfaces.statistics.rx.dropped: המספר הכולל של חבילות הנתונים שהופלו על ידי ממשק היעד.
  • ‫status.interfaces.statistics.rx.errors: סך השגיאות בקבלת חבילות הנתונים בממשק היעד.
  • ‫status.interfaces.statistics.rx.multicast: המספר הכולל של חבילות הנתונים של שידור מרובה משתתפים שהתקבלו בממשק היעד.
  • ‫status.interfaces.statistics.rx.overErrors: המספר הכולל של חבילות הנתונים שהתקבלו מעבר לשגיאות בממשק היעד.
  • ‫status.interfaces.statistics.rx.packets: המספר הכולל של חבילות הנתונים שהתקבלו בממשק היעד.

נתונים סטטיסטיים של הפצה:

  • ‫status.interfaces.statistics.tx.bytes: המספר הכולל של הבייטים שמועברים על ידי ממשק היעד.
  • ‫status.interfaces.statistics.tx.carrierErrors: סך השגיאות של הספק שנתקלו בהן בממשק היעד.
  • ‫status.interfaces.statistics.tx.collisions: המספר הכולל של התנגשויות חבילות הנתונים שהממשק של היעד נתקל בהן.
  • ‫status.interfaces.statistics.tx.dropped: המספר הכולל של חבילות הנתונים שהופלו על ידי ממשק היעד.
  • ‫status.interfaces.statistics.tx.errors: סך שגיאות השידור בממשק היעד.
  • ‫status.interfaces.statistics.tx.packets: המספר הכולל של חבילות הנתונים שמועברות על ידי ממשק היעד.

בדוגמה הבאה אפשר לראות את מבנה המשאב:

apiVersion: networking.gke.io/v1
kind: NetworkInterfaceState
metadata:
  name: MyNode1
nodeName: MyNode1
status:
  interfaces:
  - ifname: eno1np0
    linkinfo:
      businfo: 0000:1a:00.0
      flags: up|broadcast|multicast
      macAddress: ba:16:03:9e:9c:87
      mtu: 9000
    statistics:
      rx:
        bytes: 1098522811
        errors: 2
        multicast: 190926
        packets: 4988200
      tx:
        bytes: 62157709961
        packets: 169847139
  - ifname: eno2np1
    linkinfo:
      businfo: 0000:1a:00.1
      flags: up|broadcast|multicast
      macAddress: ba:16:03:9e:9c:87
      mtu: 9000
    statistics:
      rx:
        bytes: 33061895405
        multicast: 110203
        packets: 110447356
      tx:
        bytes: 2370516278
        packets: 11324730
  - ifname: enp95s0f0np0
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2bf4
      prefixlen: 64
    linkinfo:
      businfo: 0000:5f:00.0
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:f4
      mtu: 9000
    statistics:
      rx:
        bytes: 37858381
        multicast: 205645
        packets: 205645
      tx:
        bytes: 1207334
        packets: 6542
  - ifname: enp95s0f1np1
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2bf5
      prefixlen: 64
    linkinfo:
      businfo: 0000:5f:00.1
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:f5
      mtu: 9000
    statistics:
      rx:
        bytes: 37852406
        multicast: 205607
        packets: 205607
      tx:
        bytes: 1207872
        packets: 6545
  - ifname: enp134s0f0np0
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2b6c
      prefixlen: 64
    linkinfo:
      businfo: 0000:86:00.0
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:6c
      mtu: 9000
    statistics:
      rx:
        bytes: 37988773
        multicast: 205584
        packets: 205584
      tx:
        bytes: 1212385
        packets: 6546
  - ifname: enp134s0f1np1
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2b6d
      prefixlen: 64
    linkinfo:
      businfo: 0000:86:00.1
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:6d
      mtu: 9000
    statistics:
      rx:
        bytes: 37980702
        multicast: 205548
        packets: 205548
      tx:
        bytes: 1212297
        packets: 6548
  - ifname: gdcenet0
    interfaceinfo:
    - address: 208.117.254.36
      prefixlen: 28
    - address: fe80::b816:3ff:fe9e:9c87
      prefixlen: 64
    linkinfo:
      flags: up|broadcast|multicast
      macAddress: ba:16:03:9e:9c:87
      mtu: 9000
    statistics:
      rx:
        bytes: 34160422968
        errors: 2
        multicast: 301129
        packets: 115435591
      tx:
        bytes: 64528301111
        packets: 181171964
     .. <remaining interfaces omitted>
   lastReportTime: "2022-03-30T07:35:44Z"

משאב NodeSystemConfigUpdate

המשאב NodeSystemConfigUpdate מאפשר לכם לבצע שינויים בהגדרות של מערכת ההפעלה של הצומת, וגם לשנות את הדגלים Kubelet. כדי שהשינויים ייכנסו לתוקף, צריך להפעיל מחדש את הצומת, למעט שינויים ב-sysctl. המשאב הזה לא זמין בפריסות של שרתים מקושרים ב-Distributed Cloud.

כשמפעילים את המשאב הזה, צריך לציין את צמתי היעד בשדה nodeSelector. בשדה nodeSelector צריך לכלול את כל צמדי מפתח/ערך לכל צומת יעד. אם מציינים יותר מצומת יעד אחד בשדה הזה, צמתי היעד מתעדכנים אחד בכל פעם.

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

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

  • ‫spec.containerRuntimeDNSConfig.ip: מציין רשימה של כתובות IP עבור מאגרי תמונות פרטיים.

  • ‫spec.containerRuntimeDNSConfig: מציין רשימה של רשומות DNS בהתאמה אישית שמשמשות את סביבת זמן הריצה של הקונטיינר בכל צומת מחובר של Distributed Cloud. כל רשומה כוללת את השדות הבאים:

    • ‫ip: מציינת את כתובת ה-IPv4 של היעד,
    • ‫domain: מציין את הדומיין המתאים,
    • ‫interface: מציין את ממשק היציאה מהרשת שדרכו אפשר להגיע לכתובת ה-IP שצוינה בשדה ip. אפשר לציין ממשק שמוגדר באמצעות המשאבים הבאים: CustomNetworkInterfaceConfig,‏ Network (באמצעות הערה), NetworkAttachmentDefinition (באמצעות הערה).

  • ‫spec.kubeletConfig.cpuManagerPolicy: מציין את המדיניות של Kubernetes CPUManager. הערכים התקינים הם None ו-Static.

  • ‫spec.kubeletConfig.topologyManagerPolicy: מציין את מדיניות TopologyManager של Kubernetes. הערכים התקפים הם None,‏ BestEffort,‏ Restricted ו-SingleNumaMode.

  • ‫spec.osConfig.cgroupConfig.noKernelMemory: לא כולל זיכרון במרחב ליבה בחישוב השימוש בזיכרון של ה-Pod. הערכים התקינים הם true ו-false.

  • ‫spec.osConfig.hugePagesConfig: מציין את ההגדרה של דפים ענקיים לכל צומת NUMA. הערכים התקינים הם 2MB ו-1GB. מספר הדפים הענקיים המבוקש מתחלק באופן שווה בין שני צמתי ה-NUMA במערכת. לדוגמה, אם מקצים 16 דפים גדולים בגודל של 1 GB כל אחד, כל צומת מקבל הקצאה מראש של 8 GB.

  • ‫spec.osConfig.isolatedCpusPerSocket: מציין את מספר המעבדים המבודדים לכל שקע. חובה אם הערך של cpuManagerPolicy הוא Static. המספר המקסימלי של מעבדים מבודדים צריך להיות קטן מ-80% ממספר המעבדים הכולל בצומת.

  • ‫spec.osConfig.cpuIsolationPolicy: מציין את מדיניות הבידוד של המעבד. המדיניות Default מבודדת רק משימות של systemd ממעבדים ששמורים לעומסי עבודה. המדיניות Kernel מסמנת את המעבדים כ-isolcpus ומגדירה את הדגלים rcu_nocb, nohz_full ו-rcu_nocb_poll בכל מעבד. המדיניות KernelOptimized מסמנת את המעבדים כ-isolcpus ומגדירה את הסימונים rcu_nocb ו-rcu_nocb_poll בכל מעבד, אבל לא את הסימון nohz_full.

  • ‫spec.sysctls.NodeLevel: מציין את הפרמטרים של sysctls שאפשר להגדיר באופן גלובלי בצומת באמצעות האופרטור Network Function. הפרמטרים שניתנים להגדרה הם:

    • fs.inotify.max_user_instances
    • fs.inotify.max_user_watches
    • kernel.sched_rt_runtime_us
    • kernel.core_pattern
    • net.ipv4.tcp_wmem
    • net.ipv4.tcp_rmem
    • net.ipv4.tcp_slow_start_after_idle
    • net.ipv4.udp_rmem_min
    • net.ipv4.udp_wmem_min
    • net.ipv4.tcp_rmem
    • net.ipv4.tcp_wmem
    • net.core.rmem_max
    • net.core.wmem_max
    • net.core.rmem_default
    • net.core.wmem_default
    • net.netfilter.nf_conntrack_tcp_timeout_unacknowledged
    • net.netfilter.nf_conntrack_tcp_timeout_max_retrans
    • net.sctp.auth_enable
    • net.sctp.sctp_mem
    • net.ipv4.udp_mem
    • net.ipv4.tcp_mem
    • net.ipv4.tcp_slow_start_after_idle
    • net.sctp.auth_enable
    • vm.max_map_count

    אפשר גם להגדיר את ההיקף של פרמטרים בטוחים ולא בטוחים של sysctls לפוד או למרחב שמות ספציפיים באמצעות תוסף Container Networking Interface‏ (CNI) של tuning.

במשאב NodeSystemConfigUpdate מופיעים שדות הסטטוס הכלליים הבאים לקריאה בלבד:

  • status.lastReportTime: הפעם האחרונה שבה דווח על הסטטוס של ממשק היעד.
  • status.conditions.lastTransitionTime: הפעם האחרונה שבה השתנה התנאי של הממשק.
  • ‫status.conditions.observedGeneration: מציין את הערך .metadata.generation שעליו התבסס התנאי הראשוני.
  • ‫status.conditions.message: הודעה אינפורמטיבית שמתארת את השינוי במצב הממשק.
  • ‫status.conditions.reason: מזהה פרוגרמטי שמציין את הסיבה לשינוי האחרון במצב הממשק.
  • status.conditions.status: תיאור הסטטוס של התנאי. הערכים התקפים הם True,‏ False ו-Unknown.
  • ‫status.conditions.type: סוג התנאי ב-camelCase.

בדוגמה הבאה אפשר לראות את מבנה המשאב:

apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
  name: node-pool-1-config
  namespace: default
spec:
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
    networking.gke.io/worker-network-sriov.capable: true
  sysctls:
    nodeLevel:
      "net.ipv4.udp_mem" : "12348035 16464042 24696060"
  kubeletConfig:
    topologyManagerPolicy: BestEffort
    cpuManagerPolicy: Static
  osConfig:
    hugePagesConfig:
      "TWO_MB": 0
      "ONE_GB": 16
    isolatedCpusPerSocket:
      "0": 10
      "1": 10

משאב SriovNetworkNodePolicy

המשאב SriovNetworkNodePolicy מאפשר להקצות קבוצה של פונקציות וירטואליות (VF) של SR-IOV במכונה פיזית שמחוברת לענן מבוזר, וליצור מופע של הקבוצה הזו כמשאב Kubernetes. אחר כך תוכלו להשתמש במשאב הזה במשאב NetworkAttachmentDefinition. המשאב הזה לא זמין בפריסות של שרתים מחוברים ב-Distributed Cloud

אפשר לבחור כל פונקציה וירטואלית לפי ספק ה-PCIe ומזהה המכשיר, לפי כתובות המכשיר ב-PCIe או לפי שם המכשיר שמופיע ברשימה ב-Linux. מפעיל הרשת SR-IOV מגדיר כל ממשק רשת פיזי כדי להקצות את הפונקציות הווירטואליות של היעד. הפעולה הזו כוללת עדכון של הקושחה של ממשק הרשת, הגדרה של מנהל ההתקן של ליבת Linux והפעלה מחדש של המכונה המחוברת ל-Distributed Cloud, אם יש צורך בכך.

כדי לגלות את ממשקי הרשת שזמינים בצומת, אפשר לחפש את NetworkInterfaceState המשאבים בצומת הזה במרחב השמות nf-operator.

בדוגמה הבאה אפשר לראות את מבנה המשאב:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlnx6-p2-sriov-en2
  namespace: sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  mtu: 9000
  nicSelector:
    pfNames:
    - enp134s0f1np1
  nodeSelector:
    edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_p2_sriov_en2

בדוגמה הקודמת נוצרות עד 31 פונקציות וירטואליות מהיציאה השנייה בממשק הרשת שנקרא enp134s0f1np1 עם ערך MTU של 9000 (הערך המקסימלי המותר). משתמשים בתווית לבחירת צומת edgecontainer.googleapis.com/network-sriov.capable, שמופיעה בכל הצמתים המחוברים ל-Distributed Cloud שתומכים ב-SR-IOV.

מידע על השימוש במשאב הזה זמין במאמר SriovNetworkNodeState.

משאב SriovNetworkNodeState

המשאב SriovNetworkNodeState read-only מאפשר לכם לשלוח שאילתה לגבי מצב ההקצאה של המשאב SriovNetworkNodePolicy בצומת מחובר של Distributed Cloud. היא מחזירה את ההגדרה המלאה של משאב SriovNetworkNodePolicy בצומת, וגם רשימה של פונקציות וירטואליות פעילות בצומת. השדה status.syncStatus מציין אם כל המשאבים SriovNetworkNodePolicy שהוגדרו לצומת SriovNetworkNodePolicy הוחלו בצורה תקינה. המשאב הזה לא זמין בפריסות של שרתים מקושרים ב-Distributed Cloud

בדוגמה הבאה אפשר לראות את מבנה המשאב:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodeState
metadata:
  name: MyNode1
  namespace: sriov-network-operator
spec:
  dpConfigVersion: "1969684"
  interfaces:
  - mtu: 9000
    name: enp134s0f1np1
    numVfs: 31
    pciAddress: 0000:86:00.1
    vfGroups:
    - deviceType: netdevice
      mtu: 9000
      policyName: mlnx6-p2-sriov-en2
      resourceName: mlnx6_p2_sriov_en2
      vfRange: 0-30
status:

Status:
  Interfaces:
    Device ID:    1015
    Driver:       mlx5_core
    Link Speed:   25000 Mb/s
    Link Type:    ETH
    Mac:          ba:16:03:9e:9c:87
    Mtu:          9000
    Name:         eno1np0
    Pci Address:  0000:1a:00.0
    Vendor:       15b3
    Device ID:    1015
    Driver:       mlx5_core
    Link Speed:   25000 Mb/s
    Link Type:    ETH
    Mac:          ba:16:03:9e:9c:87
    Mtu:          9000
    Name:         eno2np1
    Pci Address:  0000:1a:00.1
    Vendor:       15b3
    Vfs:
  - Vfs:
    - deviceID: 101e
      driver: mlx5_core
      mac: c2:80:29:b5:63:55
      mtu: 9000
      name: enp134s0f1v0
      pciAddress: 0000:86:04.1
      vendor: 15b3
      vfID: 0
    - deviceID: 101e
      driver: mlx5_core
      mac: 7e:36:0c:82:d4:20
      mtu: 9000
      name: enp134s0f1v1
      pciAddress: 0000:86:04.2
      vendor: 15b3
      vfID: 1
      .. <omitted 29 other VFs here>
  syncStatus: Succeeded

מידע על השימוש במשאב הזה זמין במאמר SriovNetworkNodeState.

משאב NetworkAttachmentDefinition

המשאב NetworkAttachmentDefinition מאפשר לכם לצרף פודים של Distributed Cloud לרשת לוגית או פיזית אחת או יותר בצומת המחובר של Distributed Cloud. הוא מבוסס על מסגרת Multus-CNI ועל הפלאגינים הבאים:

אפשר להשתמש בהערה כדי להפנות לשם של משאב SriovNetworkNodePolicy מתאים. כשיוצרים את ההערה הזו, צריך לבצע את הפעולות הבאות:

  • משתמשים במקש k8s.v1.cni.cncf.io/resourceName.
  • משתמשים בקידומת gke.io/ בערך שלה, ואחריה בשם של משאב היעד SriovNetworkNodePolicy.

משתמשים בהערה networking.gke.io/gdce-vlan-id כדי לציין את מזהה ה-VLAN של רשת היעד. חובה להוסיף את ההערה הזו.

בדוגמאות הבאות אפשר לראות את מבנה המשאב. לרשתות IPv4.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: sriov-net1
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_p2_sriov_en2
    networking.gke.io/gdce-vlan-id: 225

spec:
  config: '{
  "type": "sriov",
  "cniVersion": "0.3.1",
  "name": "sriov-network",
  "ipam": {
    "type": "host-local",
    "subnet": "10.56.217.0/24",
    "routes": [{
      "dst": "0.0.0.0/0"
    }],
    "gateway": "10.56.217.1"
  }
}'

לרשתות IPv6:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: sriov-210-den102
  annotations:
    k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_p0_sriov_en
    networking.gke.io/gdce-vlan-id: 225
spec:
  config: '{
  "type": "sriov",
  "cniVersion": "0.3.1",
  "name": "sriov-210-den102",
  "vlan": 210,
  
  "ipam": {
    "type": "host-local",
    "rangeStart": "2001:4860:1025:102:ffff:0220::2",
    "rangeEnd": "2001:4860:1025:102:ffff:0220::F",
    "subnet": "2001:4860:1025:102:ffff:0220::/96",
    "routes": [{
      "dst": "::/0"
    }],
    "gateway": "2001:4860:1025:102:ffff:0220::1"
  }
}'

הגדרת ממשק משני בתרמיל באמצעות SR-IOV VFs

אחרי שמגדירים משאב SriovNetworkNodePolicy ומשאב NetworkAttachmentDefinition תואם, אפשר להגדיר ממשק רשת משני ב-pod של Distributed Cloud באמצעות פונקציות וירטואליות של SR-IOV.

כדי לעשות זאת, מוסיפים הערה להגדרת ה-pod של Distributed Cloud באופן הבא:

  • מקש: k8s.v1.cni.cncf.io/networks
  • ערך: nameSpace/<NetworkAttachmentDefinition1,nameSpace/NetworkAttachmentDefinition2...

בדוגמה הבאה אפשר לראות איך ההערה הזו נראית:

apiVersion: v1
kind: pod
metadata:
  name: sriovpod
  annotations:
    k8s.v1.cni.cncf.io/networks: mynamespace/sriov-net1
spec:
  containers:
  - name: sleeppodsriov
    command: ["sh", "-c", "trap : TERM INT; sleep infinity & wait"]
    image: alpine
    securityContext:
      capabilities:
        add:
          - NET_ADMIN

הגדרת ממשק משני בתרמיל באמצעות מנהל ההתקן MacVLAN

‫Distributed Cloud connected תומך גם ביצירת ממשק רשת משני ב-Pod באמצעות מנהל ההתקן MacVLAN. רק בממשק gdcenet0 יש תמיכה בהגדרה הזו, ורק בפודים שמריצים עומסי עבודה מבוססי-קונטיינרים.

כדי להגדיר ממשק לשימוש במנהל ההתקן MacVLAN:

  1. מגדירים משאב NetworkAttachmentDefinition כמו בדוגמאות הבאות. לרשתות IPv4:

     apiVersion: "k8s.cni.cncf.io/v1"
 kind: NetworkAttachmentDefinition
 metadata:
   name: macvlan-b400-1
   annotations:
     networking.gke.io/gdce-vlan-id: 400
 spec:
   config: '{
   "type": "macvlan",
   "master": "gdcenet0.400",
   "ipam": {
     "type": "static",
     "addresses": [
       {
         "address": "192.168.100.20/27",
         "gateway": "192.168.100.1"
       }
     ]
   ...
   }
 }'

    לרשתות IPv6:

     apiVersion: "k8s.cni.cncf.io/v1"
 kind: NetworkAttachmentDefinition
 metadata:
   name: macvlan-bond0-210-den402
   annotations:
       networking.gke.io/gdce-vlan-id
 spec:
   config: '{
   "type": "macvlan",
   "cniVersion": "0.3.1",
   "name": "bond0-210",
   "master": "bond0.210",

   "ipam": {
     "type": "host-local",
     "rangeStart": "2001:4860:1025:102:0001:0210::2",
     "rangeEnd": "2001:4860:1025:102:0001:0210::F",
     "subnet": "2001:4860:1025:102:0001:0210::/96",
     "routes": [{
       "dst": "::/0"
     }],
     "gateway": "2001:4860:1025:102:0001:0210::1"
   }
 }'

  2. מוסיפים הערה להגדרת ה-pod של Distributed Cloud באופן הבא. לרשתות IPv4:

     apiVersion: v1
 kind: pod
 metadata:
   name: macvlan-testpod1
   annotations:
     k8s.v1.cni.cncf.io/networks: macvlan-b400-1

    לרשתות IPv6:

     apiVersion: v1
 kind: Pod
 metadata:
   name: vlan210-1
   namespace: default
   annotations:
     k8s.v1.cni.cncf.io/networks: default/macvlan-bond0-210-den402

הגדרה של ממשק משני בפוד באמצעות רשתות מרובות ב-Distributed Cloud

‫Distributed Cloud connected תומך ביצירת ממשק רשת משני בתרמיל באמצעות התכונה multi-network. כדי לעשות זאת, צריך לבצע את השלבים הבאים:

  1. מגדירים Network משאב. לדוגמה:

    apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: my-network-410
  annotations:
      networking.gke.io/gdce-vlan-id: "410"
      networking.gke.io/gdce-lb-service-vip-cidrs: '[{"name":"myPool","addresses":["10.100.63.130-10.100.63.135"],"avoidBuggyIPs":false,"autoAssign":true}]'
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.410
  gateway4: 10.100.63.129
  l2NetworkConfig:
    prefixLength4: 27

    ההערה networking.gke.io/gdce-lb-service-vip-cidrs מציינת מאגר אחד או יותר של כתובות IP לרשת הווירטואלית הזו. החצי הראשון של ה-CIDR שאתם מציינים כאן חייב לכלול כתובות IP וירטואליות של שירות (SVIP). ב-Distributed Cloud במודל מחובר, הדרישה הזו נאכפת באמצעות בדיקות של webhook באופן הבא:

    • טווח כתובות ה-SVIP חייב להיות בתוך טווח ה-CIDR של ה-VLAN המתאים, ו
    • טווח הכתובות של SVIP יכול לכלול רק עד המחצית הראשונה של טווח ה-CIDR של ה-VLAN.

  2. מוסיפים הערה להגדרת ה-pod של Distributed Cloud באופן הבא:

    apiVersion: v1
kind: pod
metadata:
  name: myPod
  annotations:
    networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"pod-network"}, {"interfaceName":"eth1","network":"my-network-410"}]'
    networking.gke.io/default-interface: eth1

    ההערה הזו מגדירה את הממשק eth0 כראשי ואת הממשק eth1 כמשני, עם איזון עומסים בשכבה 2 באמצעות MetalLB.

הגדרת הממשק המשני כמו שמתואר בקטע הזה גורמת ליצירה אוטומטית של המשאבים המותאמים אישית הבאים:

  • משאב IPAddressPool, שמאפשר הקצאה אוטומטית של כתובות SVIP לפודים. לדוגמה:
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: test-410-pool
  namespace: kube-system
  annotations:
    networking.gke.io/network:my-network-410
    …
  spec:
  addresses:
  - 10.100.63.130-10.100.63.135
  autoAssign: true
  • L2Advertisement משאב שמאפשר פרסום של כתובות ה-SVIP שצוינו. לדוגמה:
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertise-410
  namespace: kube-system
spec:
  ipAddressPools:
  - test-410-pool
  interfaces:
  - gdcenet0.410

## מה השלב הבא