שימוש ב-GKE Dataplane V2

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

‫GKE Dataplane V2 תמיד מופעל באשכולות חדשים של Autopilot. אם נתקלתם בבעיות בשימוש ב-GKE Dataplane V2, אפשר לדלג אל פתרון בעיות.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

  • מפעילים את ממשק Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות ליצירת אשכול GKE, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM ‏Kubernetes Engine Cluster Admin (container.clusterAdmin) בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

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

אפשר להפעיל את GKE Dataplane V2 רק כשיוצרים אשכול GKE חדש. אי אפשר לשנות את ההגדרה הזו באשכול קיים.

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

המסוף

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

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

  2. בתפריט הניווט, לוחצים על Networking (רשת).

  3. מרחיבים את הקטע Container Network Interface (CNI).

  4. מסמנים את התיבה Dataplane V2.

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

gcloud

מריצים את הפקודה הבאה:

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-dataplane-v2

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

  • ‫CLUSTER_NAME: שם לאשכול החדש.
  • ‫CONTROL_PLANE_LOCATION: מיקום של מישור הבקרה של האשכול.

API

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

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

"cluster":{
    "networkConfig":{
      "datapathProvider":"ADVANCED_DATAPATH"
    }
}

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

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

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

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

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

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

  • צמתים עם hostPort מאחורי מאזן עומסי רשת להעברת סיגנל ללא שינוי:

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

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

גרסאות GKE שהושפעו: גרסאות קודמות ל-1.32

אם מציינים את השדה endPort באובייקט NetworkPolicy באשכול שמופעל בו GKE Dataplane V2 ומריץ גרסת GKE מוקדמת יותר מ-1.32, ‏ Kubernetes מתעלם מהשדה.

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

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

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

גרסאות מתוקנות

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

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

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

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

גרסאות מתוקנות

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

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

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

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

אובדן מנות בתהליכי חיבור מסוג hairpin

כש-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 ודליפה של רשומת מעקב החיבור.

  • כשמשתמשים בחיבורים לטווח קצר, חושפים את ה-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) לבין ה-daemon של Cilium.

תסמינים

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

  • anetd פודים נתקעים במצב Pending.
  • תאי Pod של עומסי עבודה נתקעים במצב 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

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

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

  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 לגרסה 1.28 של GKE מסתיים, ה-Pod‏ anetd פועל בגרסה החדשה יותר.

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

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

מטרה

החל מגרסה GKE 1.35.1-gke.1616000, באשכולות GKE Dataplane V2 נעשה שימוש בגרסה CNI 1.1.0 בקובצי התצורה של CNI. השינוי הזה מחייב תמיכה בגרסה 1.1.0 של CNI גם בפלאגינים של CNI במורד הזרם, כמו Google Managed Istio. בגלל עיכוב בהשקת 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

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