שימוש ב-GKE Dataplane V2

טייס אוטומטי רגילה

בדף הזה מוסבר איך להפעיל את GKE Dataplane V2 באשכולות Google Kubernetes Engine ‏ (GKE) ואיך לפתור בעיות שקשורות אליו.

בגרסאות 1.22.7-gke.1500 ואילך ובגרסאות 1.23.4-gke.1500 ואילך, האפשרות GKE Dataplane V2 מופעלת באשכולות חדשים של Autopilot. אם אתם נתקלים בבעיות בשימוש ב-GKE Dataplane V2, דלגו אל פתרון בעיות.

יצירת אשכול GKE עם GKE Dataplane V2

אפשר להפעיל את GKE Dataplane V2 כשיוצרים אשכולות חדשים עם GKE בגרסה 1.20.6-gke.700 ואילך באמצעות ה-CLI של gcloud או GKE API. אפשר גם להפעיל את GKE Dataplane V2 בתצוגה מקדימה כשיוצרים אשכולות חדשים עם GKE בגרסה 1.17.9 ואילך.

אזהרה: ב-GKE Dataplane V2 יש אכיפה מובנית של מדיניות הרשת של Kubernetes. כלומר, לא צריך להפעיל מדיניות רשת באשכולות שמשתמשים ב-GKE Dataplane V2. אם תנסו להפעיל או להשבית באופן מפורש את האכיפה של מדיניות הרשת באשכול שמשתמש ב-GKE Dataplane V2, הבקשה תיכשל ותוצג הודעת השגיאה Enabling NetworkPolicy for clusters with DatapathProvider=ADVANCED_DATAPATH is not allowed..

המסוף

כדי ליצור אשכול חדש עם GKE Dataplane V2, מבצעים את המשימות הבאות:

1. נכנסים לדף Create a Kubernetes cluster במסוף Google Cloud .

   מעבר אל יצירת אשכול Kubernetes

2. בקטע 'רשת', מסמנים את התיבה הפעלת Dataplane V2. האפשרות Enable Kubernetes Network Policy מושבתת כשבוחרים באפשרות Enable Dataplane V2, כי אכיפת מדיניות רשת ב-Kubernetes מוטמעת ב-GKE Dataplane V2.

3. לוחצים על יצירה.

gcloud

כדי ליצור אשכול חדש עם GKE Dataplane V2, משתמשים בפקודה הבאה:

gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --release-channel CHANNEL_NAME \
    --location COMPUTE_LOCATION

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

• ‫CLUSTER_NAME: השם של האשכול החדש.
• ‫CHANNEL_NAME: ערוץ הפצה שכולל את GKE בגרסה 1.20.6-gke.700 ואילך. אם אתם לא רוצים להשתמש בערוץ הפצה, אתם יכולים להשתמש גם בדגל --cluster-version במקום --release-channel, ולציין גרסה 1.20.6-gke.700 ואילך.
• ‫COMPUTE_LOCATION: המיקום של Compute Engine של האשכול החדש.

API

כדי ליצור אשכול חדש עם GKE Dataplane V2, צריך לציין את השדה datapathProvider באובייקט networkConfig בבקשת create של האשכול.

בקטע ה-JSON הבא מוצגת ההגדרה שנדרשת כדי להפעיל את GKE Dataplane V2:

"cluster":{
   "initialClusterVersion":"VERSION",
   "ipAllocationPolicy":{
      "useIpAliases":true
   },
   "networkConfig":{
      "datapathProvider":"ADVANCED_DATAPATH"
   },
   "releaseChannel":{
      "channel":"CHANNEL_NAME"
   }
}

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

• ‫VERSION: גרסת האשכול, שצריכה להיות GKE 1.20.6-gke.700 ואילך.
• ‫CHANNEL_NAME: ערוץ הפצה שכולל את GKE בגרסה 1.20.6-gke.700 ואילך.

פתרון בעיות ב-GKE Dataplane V2

בקטע הזה מוסבר איך לחקור ולפתור בעיות ב-GKE Dataplane V2.

1. מוודאים ש-GKE Dataplane V2 מופעל:

   kubectl -n kube-system get pods -l k8s-app=cilium -o wide
   

   אם GKE Dataplane V2 פועל, הפלט כולל Pods עם הקידומת anetd-. ‫anetd הוא בקר הרשת של GKE Dataplane V2.

2. אם הבעיה היא בשירותים או באכיפת מדיניות הרשת, כדאי לבדוק את anetd יומני ה-Pod. אפשר להשתמש בבוררי היומנים הבאים ב-Cloud Logging:

   resource.type="k8s_container"
   labels."k8s-pod/k8s-app"="cilium"
   resource.labels.cluster_name="CLUSTER_NAME"
   

3. אם יצירת ה-Pod נכשלת, כדאי לבדוק את היומנים של kubelet כדי לקבל רמזים. משתמשים בבוררי היומנים הבאים ב-Cloud Logging:

   resource.type="k8s_node"
   log_name=~".*/logs/kubelet"
   resource.labels.cluster_name="CLUSTER_NAME"
   

   מחליפים את CLUSTER_NAME בשם של האשכול, או מסירים אותו לגמרי כדי לראות את היומנים של כל האשכולות.

4. אם ה-anetd Pods לא פועלים, צריך לבדוק את ה-ConfigMap של cilium-config כדי לראות אם בוצעו בו שינויים. מומלץ להימנע משינוי שדות קיימים ב-ConfigMap הזה, כי שינויים כאלה עלולים לערער את היציבות של האשכול ולשבש את הפעולה של anetd. ה-ConfigMap מתוקן בחזרה למצב ברירת המחדל רק אם נוספים לו שדות חדשים. שינויים בשדות קיימים לא יתוקנו, ואנחנו ממליצים לא לשנות או להתאים אישית את ConfigMap.

בעיות מוכרות

כשמשתמשים ב-GKE Dataplane V2, יכול להיות שנתקלים בבעיות הידועות הבאות.

תם הזמן הקצוב לחיבורים של Pods שלא מוכנים

אם ה-Pod לא מוכן, יכול להיות שהחיבורים לשירות המשויך יסתיימו בטיימ-אאוט. זו ההתנהגות הצפויה של GKE Dataplane V2, והיא שונה מ-kube-proxy, שיכול להחזיר שגיאה מהירה יותר connection refused.

סינון תוויות שרלוונטיות לזהות ב-Cilium Identity לא פועל, ותאי Pod תקועים במצב ContainerCreating

גרסאות שהושפעו: 1.34, ‏ 1.35

באשכולות GKE Dataplane V2, שימוש חירום בסינון תוויות שרלוונטיות לזהויות באמצעות kube-system/cilium-config-emergency-override ConfigMap לא מוחל בצורה נכונה בגרסאות המושפעות.

הגישה הזו מגבילה את התוויות של ה-Pod שמשמשות ליצירת זהות Cilium.

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

בגרסאות GKE המושפעות, זהויות Cilium שנוצרו על ידי האופרטור ממשיכות לכלול את התוויות שהוחרגו.

תסמינים

• יכול להיות שפודים עם תוויות שצריך לסנן ליצירת זהות ב-Cilium לא יתחילו לפעול וייתקעו במצב ContainerCreating. יכול להיות שיוצגו שגיאות של פסק זמן באירועים של Pod:

    {"level":"warning", "msg":"Error changing endpoint identity", "error":"unable to resolve identity: timed out waiting for cilium-operator to allocate CiliumIdentity for key ...;, error: exponential backoff cancelled via context: context canceled", "k8sPodName":"...", "subsys":"endpoint"}
  

• במקום לשתף זהויות על סמך תוויות מסוננות, פודים עם ערכי תוויות ייחודיים ממשיכים ליצור זהויות Cilium ייחודיות. הדבר עלול להוביל לעלייה חדה במספר הזהויות, ולגרום למיצוי של הזהויות הזמינות ב-Cilium (עד למגבלה של 65,536) ולבעיות בהתאמה לגודל.

גרסאות קבועות

כדי לפתור את הבעיה, צריך לשדרג את האשכול לאחת מגרסאות GKE הבאות:

• ‫1.34.6-gke.1307000 ואילך
• ‫1.35.2-gke.1962000 ואילך

פתרון אפשרי

כפתרון עקיף, אפשר להחיל את כללי הסינון של התוויות על השדה data.labels ב-ConfigMap הראשי cilium-config ולהסיר אותם מ-cilium-config-emergency-override. המצב הזה נמשך גם במהלך פעולות במישור הבקרה, כמו שדרוגים, כי GKE שומר את השינויים שמשתמשים מבצעים בשדות שהוא לא מנהל ב-cilium-config ConfigMap.

1. מסירים את המפתח labels מהקטע data של cilium-config-emergency-override ConfigMap אם הוא קיים.

2. עורכים את cilium-config ConfigMap על ידי הוספה או שינוי של המפתח labels בקטע data. לדוגמה, כדי למנוע שימוש בתוויות בשם uuid ליצירת זהויות:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cilium-config
     namespace: kube-system
   data:
     # ... other existing keys
     labels: "!uuid"
     # ... other existing keys
   

3. הפעל מחדש את ה-anet-operator במישור הבקרה על ידי שדרוג מישור הבקרה לגרסה אותה שבה הוא פועל. הפעולה הזו מאלצת את האופרטור להפעיל מחדש ולטעון מחדש את ההגדרה שלו:

   gcloud container clusters upgrade CLUSTER_NAME \
       --location CLUSTER_LOCATION \
       --project PROJECT_ID \
       --cluster-version $(gcloud container clusters describe CLUSTER_NAME --location CLUSTER_LOCATION --project PROJECT_ID --format="value(currentMasterVersion)") \
       --master
   

4. אחרי שמפעילים מחדש את מישור הבקרה, מפעילים מחדש את anetd DaemonSet כדי לוודא שסוכני הצמתים יקבלו גם את השינויים הנדרשים:

   kubectl rollout restart daemonset anetd -n kube-system
   

בעיות בקישוריות לסירוגין שקשורות להתנגשויות בטווח NodePort באשכולות GKE Dataplane V2

באשכולות GKE Dataplane V2, יכולות להתרחש בעיות קישוריות לסירוגין בתנועת גולשים עם מיסוך או בשימוש ביציאות זמניות. הבעיות האלה נובעות מהאפשרות של התנגשויות ביציאות עם טווח NodePort שמור, והן קורות בדרך כלל בתרחישים הבאים:

• ‫ip-masq-agent בהתאמה אישית: אם אתם משתמשים ב-ip-masq-agent בהתאמה אישית (גרסה 2.10 ואילך), שבה לאשכול יש שירותים של NodePort או איזון עומסים, יכול להיות שתיתקלו בבעיות קישוריות לסירוגין בגלל התנגשות עם טווח ה-NodePort. מגרסה 2.10 ואילך, הארגומנט --random-fully מיושם ב-ip-masq-agent באופן פנימי כברירת מחדל. כדי למנוע את הבעיה הזו, צריך להגדיר באופן מפורש את --random-fully=false (רלוונטי החל מגרסה 2.11) בקטע arguments בהגדרות של ip-masq-agent. לפרטים על תצורה, ראה הגדרת סוכן IP masquerade באשכולות סטנדרטיים.

• חפיפה בטווח היציאות האפימריות: אם יש חפיפה בין טווח היציאות האפימריות שמוגדר על ידי net.ipv4.ip_local_port_range בצמתי GKE לבין הטווח NodePort (30000-32767), יכול להיות שזה גם יגרום לבעיות בקישוריות. כדי למנוע את הבעיה הזו, צריך לוודא ששני הטווחים האלה לא חופפים.

בודקים את ההגדרות של ip-masq-agent ואת טווח היציאות האפימריות כדי לוודא שאין התנגשות עם הטווח של NodePort. אם נתקלתם בבעיות קישוריות לסירוגין, כדאי לבדוק את הסיבות האפשריות האלה ולשנות את ההגדרה בהתאם.

בעיות בקישוריות ל-hostPort באשכולות GKE Dataplane V2

גרסאות GKE שהושפעו: 1.29 ואילך

באשכולות שמשתמשים ב-GKE Dataplane V2, יכול להיות שתיתקלו בכשלים בקישוריות כשתעבורת נתונים מכוונת לכתובת IP:יציאה של צומת, כאשר יציאה היא hostPort שמוגדרת ב-Pod. הבעיות האלה מתעוררות בשני תרחישים עיקריים:

• צמתים עם hostPort מאחורי מאזן עומסי רשת (passthrough Network Load Balancer):

  ‫hostPort מקשר בין Pod ליציאה של צומת ספציפי, ומאזן עומסי רשת במצב העברה מעביר את תעבורת הנתונים בין כל הצמתים. כשחושפים Pods לאינטרנט באמצעות hostPort ומאזן עומסי רשת במצב העברה, יכול להיות שמאזן העומסים ישלח תעבורת נתונים לצומת שבו ה-Pod לא פועל, מה שיגרום לכשלי חיבור. הבעיה נובעת ממגבלה מוכרת ב-GKE Dataplane V2, שבה תנועה של מאזן עומסים ברשת שעוברת דרך המערכת לא מועברת באופן עקבי אל hostPort Pods.

  פתרון עקיף: כשחושפים hostPort של Pod בצומת עם מאזן עומסי רשת להעברת סיגנל ללא שינוי, מציינים את כתובת ה-IP הפנימית או כתובת IP חיצונית של מאזן עומסי הרשת בשדה hostIP של ה-Pod.

  ports:
  - containerPort: 62000
    hostPort: 62000
    protocol: TCP
    hostIP: 35.232.62.64
  - containerPort: 60000
    hostPort: 60000
    protocol: TCP
    hostIP: 35.232.62.64
    # Assuming 35.232.62.64 is the external IP address of a passthrough Network Load Balancer.
  

• hostPort יש התנגשות עם הטווח השמור NodePort:

  אם ה-hostPort של Pod מסוים מתנגש עם טווח NodePort השמור (30000-32767), יכול להיות ש-Cilium לא יצליח להעביר תנועה ל-Pod. ההתנהגות הזו נצפתה בגרסאות של אשכולות החל מגרסה 1.29, כי Cilium מנהל עכשיו את היכולות של hostPort, ומחליף את השיטה הקודמת של Portmap. זו התנהגות צפויה ב-Cilium, והיא מוזכרת בתיעוד הציבורי שלהם.

אנחנו לא מתכננים לפתור את המגבלות האלה בגרסאות עתידיות. המקור לבעיות האלה קשור להתנהגות של Cilium, והוא לא בשליטה ישירה של GKE.

המלצה: מומלץ לעבור לשירותי NodePort במקום ל-hostPort כדי לשפר את המהימנות. NodePort השירותים מספקים יכולות דומות.

טווח יציאות של מדיניות רשת לא נכנס לתוקף

אם מציינים שדה endPort במדיניות רשת באשכול שמופעל בו GKE Dataplane V2, השדה לא ייכנס לתוקף.

Kubernetes Network Policy API מאפשר לציין טווח של יציאות שבהן נאכף Network Policy. ה-API הזה נתמך באשכולות עם Calico Network Policy, אבל לא באשכולות עם GKE Dataplane V2.

אפשר לאמת את ההתנהגות של אובייקטים מסוג NetworkPolicy על ידי קריאה חוזרת שלהם אחרי כתיבתם לשרת ה-API. אם האובייקט עדיין מכיל את השדה endPort, התכונה נאכפת. אם השדה endPort לא מופיע, התכונה לא נאכפת. בכל המקרים, האובייקט שמאוחסן בשרת ה-API הוא המקור המהימן למדיניות הרשת.

מידע נוסף זמין במאמר בנושא KEP-2079: Network Policy to support Port Ranges.

גרסאות קבועות

כדי לפתור את הבעיה, צריך לשדרג את האשכול לגרסה 1.32 ואילך של GKE.

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

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

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

גרסאות קבועות

כדי לפתור את הבעיה, משדרגים את האשכול לאחת מגרסאות GKE הבאות:

• ‫1.28.3-gke.1090000 ואילך.

פתרונות עקיפים

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

אובדן מנות בזרימות של חיבורים עם לולאה

כש-Pod יוצר חיבור TCP לעצמו באמצעות Service, כך שה-Pod הוא גם המקור וגם היעד של החיבור, מעקב החיבורים של GKE Dataplane V2 eBPF עוקב אחרי מצבי החיבור באופן שגוי, מה שמוביל לדליפה של רשומות conntrack.

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

גרסאות קבועות

כדי לפתור את הבעיה, משדרגים את האשכול לאחת מגרסאות GKE הבאות:

• ‫1.28.3-gke.1090000 ואילך
• ‫1.27.11-gke.1097000 ואילך

פתרונות עקיפים

אפשר לנסות את הפתרונות הבאים:

• הפעלת שימוש חוזר ב-TCP (keep-alives) לאפליקציות שפועלות ב-Pods שעשויות לתקשר עם עצמן באמצעות שירות. כך נמנעת הנפקת דגל ה-TCP FIN ודליפה של רשומת conntrack.

• כשמשתמשים בחיבורים לטווח קצר, חושפים את ה-Pod באמצעות מאזן עומסים בשרת proxy, כמו Gateway, כדי לחשוף את השירות. כתוצאה מכך, היעד של בקשת החיבור מוגדר לכתובת ה-IP של מאזן העומסים, ומונע מ-GKE Dataplane V2 לבצע SNAT לכתובת ה-IP של ה-loopback.

שדרוג של מישור הבקרה של GKE גורם לקיפאון של anetd Pod

כשמשדרגים אשכול GKE שמופעל בו GKE Dataplane V2 (נתיב נתונים מתקדם) מגרסה 1.27 לגרסה 1.28, יכול להיות שתיתקלו במצב של חסימה הדדית (deadlock). יכול להיות שיהיו שיבושים בעומסי העבודה בגלל חוסר היכולת לסיים Pods ישנים או לתזמן רכיבים נדרשים כמו anetd.

מטרה

תהליך השדרוג של האשכול מגדיל את דרישות המשאבים של רכיבי GKE Dataplane V2. העלייה הזו עלולה לגרום למאבק על משאבים, מה שמשבש את התקשורת בין התוסף Cilium Container Network Interface ‏ (CNI) לבין Cilium daemon.

תסמינים

יכול להיות שיופיעו התסמינים הבאים:

• anetd תרמילים נתקעים במצב Pending.
• פודים של עומסי עבודה נתקעים במצב Terminating.
• שגיאות שמצביעות על כשלים בתקשורת של Cilium, כמו failed to connect to Cilium daemon.

• שגיאות במהלך ניקוי משאבי הרשת בארגזי חול של Pod, לדוגמה:

  1rpc error: code = Unknown desc = failed to destroy network for sandbox "[sandbox_id]": plugin type="cilium-cni" failed (delete): unable to connect to Cilium daemon... connection refused
  

דרך לעקיפת הבעיה

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

1. מזהים את הצומת המושפע ובודקים את המעבד (CPU) והזיכרון שניתן להקצות לו:

   kubectl get nodes NODE_NAME -o json | jq '.status.allocatable | {cpu, memory}'
   

2. הגדלה זמנית של המעבד (CPU) והזיכרון שניתן להקצות:

   kubectl patch node NODE_NAME -p '{"status":{"allocatable":{"cpu":CPU_VALUE, "memory":MEMORY_VALUE}}}'
   

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

   • ‫NODE_NAME: השם של הצומת המושפע.
   • ‫CPU_VALUE: ערך ה-CPU החדש. מוסיפים 500m לערך הנוכחי של השימוש במעבד שזוהה בשלב הקודם. לדוגמה, אם הערך הנוכחי הוא 1500m, צריך להשתמש בערך 2 (ששווה ל-2000m).
   • ‫MEMORY_VALUE: ערך הזיכרון החדש. מוסיפים מאגר של 512Mi (ששווה ל-0.5Gi) לערך הזיכרון הנוכחי שזוהה בשלב הקודם. לדוגמה, אם הערך הנוכחי הוא 3.5Gi, צריך להשתמש בערך 4Gi.

   לדוגמה, כדי להגדיל את המעבד (CPU) שניתן להקצאה ל-2 ואת הזיכרון ל-4Gi בצומת gke-cluster-node-1, מריצים את הפקודה:

   kubectl patch node gke-cluster-node-1 -p '{"status":{"allocatable":{"cpu":"2", "memory":"4Gi"}}}'
   

אשכולות Autopilot: כדי לפתור את בעיית הקיפאון באשכולות Autopilot, צריך לפנות משאבים על ידי מחיקה בכוח של ה-Pod המושפע:

kubectl delete pod POD_NAME -n NAMESPACE --grace-period=0 --force

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

• ‫POD_NAME: שם ה-Pod.
• ‫NAMESPACE: מרחב השמות של ה-Pod.

אחרי שמגדילים את המשאבים שניתנים להקצאה בצומת, וכשהשדרוג מגרסה 1.27 של GKE לגרסה 1.28 מסתיים, ה-Pod‏ anetd פועל בגרסה החדשה יותר.

צמתים במצב NodeNotReady בגלל שגיאת containerID חסרה

כשמשדרגים אשכולות לגרסה GKE 1.35.1-gke.1616000 ואילך, יכול להיות שהצמתים יעברו מיד למצב NodeNotReady אם גם GKE Dataplane V2 וגם Cloud Service Mesh מופעלים.

הערה: אם אתם משתמשים במישור הבקרה בתוך האשכול ב-Cloud Service Mesh, אתם צריכים לשדרג ידנית את רכיב ה-CNI לגרסה 1.23 (שמתאימה למפרט CNI גרסה 1.1.0) לפני השדרוג לגרסה 1.35 של GKE.

מטרה

החל מגרסה GKE 1.35.1-gke.1616000, קובצי התצורה של CNI באשכולות GKE Dataplane V2 משתמשים בגרסה CNI 1.1.0. השינוי הזה מחייב שגם פלאגינים של CNI במורד הזרם, כמו Google Managed Istio, יתמכו ב-CNI בגרסה 1.1.0. בגלל עיכוב בהשקה של Managed Istio, חלק מהאשכולות עדיין לא קיבלו את הגרסה התואמת (1.23), ולכן האתחול נכשל.

תסמינים

הצמתים המושפעים מוצגים מיד כ-NodeNotReady. הודעת השגיאה הבאה מופיעה ביומני containerd:

NetworkPluginNotReady message:Network plugin returns error: missing containerID

דרך לעקיפת הבעיה

כדי לפתור את הבעיה, צריך לשנמך את האשכול המושפע לגרסת GKE מוקדמת יותר מ-1.35.1-gke.1616000.

הפרעות בתוכניות eBPF בהתאמה אישית

‫GKE משתמש בתוכניות eBPF כדי לנהל את הרשת עבור GKE Dataplane V2. אם פורסים תוכניות eBPF מותאמות אישית בממשקי רשת של צמתים שמנוהלים על ידי GKE, התוכניות האלה עלולות להפריע לתוכניות eBPF שמנוהלות על ידי GKE ולגרום לבעיות ברישות.

‫GKE לא תומך בתוכניות eBPF מותאמות אישית שמצורפות לממשקי הרשת הבאים:

• eth*
• ens4
• lo
• cilium*
• gke*
• veth*

הנוכחות של תוכנות eBPF מותאמות אישית בממשקים האלה עלולה להפריע לתוכנות של GKE Dataplane V2 anetd שהותקנו על ידי סוכן, מה שעלול לשבש את הרשת של האשכול. מומלץ להסיר מהאשכול תוכניות או עומסי עבודה מותאמים אישית של eBPF שמזריקים תוכניות כאלה.

גילוי תוכניות eBPF בהתאמה אישית

כדי לגלות תוכניות eBPF מותאמות אישית שפועלות בצמתי אשכול, אפשר ליצור DaemonSet שמוגדר עם ההגדרה hostNetwork: true, שמשתמש ב-bpftool כדי לשלוח שאילתה לתוכניות eBPF כאלה:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: bpftool-logger
  labels:
    app: bpftool-logger
spec:
  selector:
    matchLabels:
      app: bpftool-logger
  template:
    metadata:
      labels:
        app: bpftool-logger
    spec:
      hostPID: true
      hostNetwork: true
      containers:
      - name: bpftool
        image: ubuntu:22.04
        securityContext:
          privileged: true
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        command:
        - /bin/bash
        - -c
        - |
          echo "Installing dependencies..."
          apt-get update -y > /dev/null 2>&1
          apt-get install -y curl tar > /dev/null 2>&1

          echo "Downloading and setting up bpftool..."
          curl -sL https://github.com/libbpf/bpftool/releases/download/v7.7.0/bpftool-v7.7.0-amd64.tar.gz | tar xz
          chmod +x bpftool
          mv bpftool /usr/local/bin/

          echo "========== $(date) | Node: ${NODE_NAME} =========="
          bpftool net | grep -E '^(eth|ens4|lo|cilium|gke|veth)' | grep -v ' cil_'
          sleep infinity

1. שומרים את המניפסט כ-ebpf-discovery.yaml ומחילים את DaemonSet:

   kubectl apply -f ebpf-discovery.yaml
   

2. מחכים שה-Pods יפעלו:

   kubectl rollout status ds/bpftool-logger
   

3. כדי לגלות תוכניות eBPF, בודקים את היומנים מה-Pods:

   kubectl logs -l app=bpftool-logger
   

4. כשמסיימים, מוחקים את DaemonSet:

   kubectl delete -f ebpf-discovery.yaml
   

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

• איך משתמשים ברישום ביומן של מדיניות הרשת
• איך שולטים בתקשורת בין Pods לבין Services באמצעות מדיניות רשת
• מידע נוסף על GKE Dataplane V2
• מידע נוסף על יכולות התצפית של GKE Dataplane V2
• איך מגדירים את יכולות התצפית של GKE Dataplane V2