שימוש ב-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 ואילך.

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

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

פתרון בעיות ב-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. אם ה-Pods‏ anetd לא פועלים, בודקים את ה-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. יכול להיות שיוצגו שגיאות של פסק זמן (timeout) באירועים של 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 שומר את השינויים שמשתמשים מבצעים בשדות שהוא לא מנהל ב-ConfigMap‏ cilium-config.

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 Dataplane V2, יכול להיות שתיתקלו בכשלים בקישוריות כשתעבורת הנתונים מכוונת לכתובת IP:יציאה של צומת, כאשר יציאה היא hostPort שמוגדר ב-Pod. הבעיות האלה מתעוררות בשני תרחישים עיקריים:

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

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

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

אובדן מנות בזרימות של חיבורים מסוג 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 ודליפה של רשומת 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.
• תאי 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
  

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

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

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

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

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

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

אשכולות במצב 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 מופעלים.

מטרה

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

   kubectl logs -l app=bpftool-logger
   

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

   kubectl delete -f ebpf-discovery.yaml
   

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

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