בעיות מוכרות ב-GKE

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

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

בדף הזה מפורטות בעיות מוכרות בכל הגרסאות הנתמכות ובשתי גרסאות המשנה שקודמות לגרסה המוקדמת ביותר בתמיכה מורחבת. אחרי שגרסה מסוימת מגיעה לסוף תקופת התמיכה המורחבת, כל הבעיות שקשורות לגרסה N-2 מוסרות. לדוגמה, כשגרסה 1.30 מגיעה לסוף התקופה של התמיכה המורחבת, אנחנו מסירים בעיות מוכרות שספציפיות לגרסאות 1.28 וקודמות.

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

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

בוחרים את גרסת GKE:

1.35 1.34 ‫1.33 ‫1.32 ‫1.31 1.30 1.29 ‫1.28 1.27

בחירת קטגוריית הבעיה:

הגדרות אישיות התקנה שדרוגים ועדכונים פעולה רישום ביומן ומעקב אבטחה איפוס/מחיקה ביצועים

אפשר גם לחפש את הבעיה:

קטגוריה	גרסאות שזוהו	גרסאות שבהן הבעיה נפתרה	בעיה ופתרון עקיף
פעולה	‫1.35 (1.35.6-gke.1250000 ואילך) 1.36 1.37	TBD	בקשות HTTP POST לקבלת טוקנים משרת המטא-נתונים נכשלות עם הודעת השגיאה ‎400 Bad Request יכול להיות שעומסי עבודה שמשתמשים ב-איחוד זהויות של עומסי עבודה ל-GKE כדי לבצע אימות ל-API של Google Cloud באמצעות בקשה לאסימוני גישה לחשבון שירות או לאסימוני זהות משרת המטא-נתונים של GKE (כמו /computeMetadata/v1/instance/service-accounts/default/token או /computeMetadata/v1/instance/service-accounts/default/identity) ייכשלו עם השגיאה HTTP 400 Bad Request (INVALID_ARGUMENT). הבעיה הזו מתרחשת כשיישום, ספריית לקוח או שער API שולחים בקשת HTTP POST בלי שרשרת אישורים תקינה בגוף הבקשה. בגרסאות GKE המושפעות, בקשות POST לנקודות הקצה של האסימונים האלה שמורות אך ורק לאסימוני גישה ולאסימונים מזהים שמשויכים ל-Service Account. כתוצאה מכך, בקשות עם מטען ייעודי (payload) ריק, עם קידוד טופס או עם JSON לא תקין נדחות. פתרון עקיף: כדי לפתור את הבעיה, צריך להגדיר את האפליקציה, ספריית הלקוח או שער ה-API כך שישתמשו בשיטה GET במקום בשיטה POST כשמבקשים טוקנים של גישה או מזהים משרת המטא-נתונים, כמו בדוגמה הבאה: curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" אם עומס העבודה משתמש ב-SDK או בשער של צד שלישי (כמו MuleSoft Flex Gateway,‏ IBM App Connect או סקריפטים מותאמים אישית של HTTP) שמוגדרים כברירת מחדל לשליחת בקשות POST לנקודות קצה של שרת מטא-נתונים, צריך לעדכן את ההגדרה או את ספריית הלקוח כדי לשלוח בקשות GET.
פעולה	‫1.37.0-gke.2941000 ואילך	TBD	צמתים שטענו נפחי NFS צוברים רשומות טעינה ומפסיקים ליצור קונטיינרים בצמתים שמופעלות בהם גרסאות מושפעות, הרכבה של נפח NFS משאירה רשומות נוספות בטבלת ההרכבה של הצומת. בנוסף, כש-Pod שמשתמש בנפח NFS מסתיים, הניסיונות לבטל את הטעינה נכשלים, ולכן kubelet מנסה שוב ושוב לבטל את הטעינה. כל ניסיון חוזר מוסיף עוד רשומות לטבלת ההרכבה, ולכן הטבלה גדלה באופן רציף גם כשלא מתוזמנות עומסי עבודה חדשים. כשטבלת ההרכבה מגיעה למגבלת הליבה, זמן הריצה של הקונטיינר לא יכול יותר ליצור קונטיינרים בצומת הזה. הצומת מפסיק להריץ Pods חדשים, יכול לדווח על סטטוס NotReady ועשוי להפעיל מחדש שוב ושוב. יכול להיות שפודים שמשתמשים בנפחי NFS יישארו במצב Terminating כי אי אפשר לבטל את הטעינה של הנפחים שלהם. באירועי ה-Pod וביומנים של kubelet, הצמתים במצב הזה מדווחים על שגיאות שדומות לשגיאות הבאות: MountVolume.SetUp failed for volume "VOLUME_NAME" : mount failed: exit status 1 mount: /etc: mount(2) system call failed: No space left on device הבעיה הזו משפיעה על מאגרי צמתים שטעונים בהם נפחי אחסון של NFS באמצעות מנהל התקן ה-NFS בתוך העץ של Kubernetes. ההשפעה לא חלה על צמתים שלא משתמשים במנהל ההתקן NFS בתוך העץ כדי לטעון נפחי NFS. פתרון עקיף: כדי לשחזר צומת מושפע, מפעילים אותו מחדש או יוצרים אותו מחדש. רשומות ההרכבה הנוספות קיימות רק במצב הפעלה של הצומת, ולכן הן נמחקות כשהצומת מופעל מחדש. אפשר להסיר פודים שנתקעו במצב Terminating אחרי ההפעלה מחדש באמצעות הפקודה הבאה: kubectl delete pod POD_NAME --namespace NAMESPACE --force --grace-period=0 כדי שהבעיה לא תחזור באשכולות Standard, צריך לשדרג לאחור את מאגרי הצמתים שמבצעים mount של נפחי NFS לגרסה 1.36. מגדירים החרגה של תחזוקה כדי ש-GKE לא ישדרג אוטומטית את מאגרי הצמתים בחזרה לגרסה מושפעת. אם אשכול Autopilot מריץ גרסה מושפעת, אפשר להשתמש באחת מהאפשרויות הבאות: אם נפחי ה-NFS שלכם מגובים על ידי Filestore, צריך לטעון אותם באמצעות מנהל התקן ה-CSI של Filestore במקום מנהל התקן ה-NFS בתוך העץ. מנהל ההתקן של CSI מטמיע נפחים מהקונטיינר שלו ולא משתמש ברכיב הצומת המושפע. אם אתם חייבים להמשיך להשתמש בדרייבר NFS בתוך העץ, אתם יכולים להשתמש בתיקון אוטומטי של צמתים כדי לשחזר את הצמתים המושפעים. ב-Autopilot, הצמתים מתוקנים אוטומטית, ואם צומת מדווח על סטטוס NotReady במשך כ-10 דקות, הוא מתרוקן ונוצר מחדש, וכך טבלת הנקודות שלו מתרוקנת.
שדרוגים	‫1.34.9-gke.1065000 ואילך, 1.35.6-gke.1049000 ואילך, וכל גרסאות התיקונים של 1.36	‫1.34.10-gke.1328000 ואילך, 1.35.8-gke.1026000 ואילך, 1.36.4-gke.1058000 ואילך (עדיין אין תיקון לגרסה 1.37)	כשלים בעומס העבודה של GPU‏ A4X Max (GB300) יצירה או שדרוג של מאגרי צמתים מסוג A4X Max (a4x-maxgpu-4g-metal) ב-GKE לגרסאות תיקון ספציפיות (ראו את העמודה גרסאות מזוהות) גורמים לכשלים בעומסי עבודה של GPU עם שבבי NVIDIA GB300 Grace Blackwell Ultra Superchips המצורפים. בגלל זמני האתחול הממושכים של זיכרון ברוחב פס גבוה (HBM) בחומרת GB300 עם סוג המכונה הזה של Bare Metal, שירות ההפעלה nvidia-persistenced מגיע לזמן קצוב לתפוגה. בגלל פסק הזמן הזה, מעבדי ה-GPU לא עוברים אתחול, וכש-Pods מנסים לתבוע משאבי CUDA, מוצגת הודעת השגיאה cudaErrorDeviceUnavailable(46). פתרון: משדרגים כל אשכול ומאגר צמתים שהושפעו לגרסה מתוקנת. ‫GKE מונע יצירה של מאגרי צמתים של A4X Max עם גרסאות מושפעות, ולא ישדרג אוטומטית את מאגרי הצמתים לגרסאות מושפעות. ב-GKE אפשר לבצע שדרוגים ידניים לגרסאות המושפעות. עם זאת, כדי להימנע מהכשלים, אנחנו ממליצים לא לשדרג לגרסאות המושפעות. פתרון עקיף: אם אי אפשר לשדרג, צריך למחוק את כל מאגרי הצמתים של A4X Max שמופעלים בגרסאות מושפעות, וליצור מחדש את מאגרי הצמתים באמצעות גרסה קודמת שלא הושפעה. חשוב לזכור: מכיוון שקיבולת A4X מקסימלית חייבת להתקבל באמצעות הזמנה, לא תאבדו קיבולת אם תמחקו את מאגרי הצמתים.
פעולה	גרסאות 1.33 מוקדמות יותר מ-1.33.5-gke.2469000, גרסאות 1.34 מוקדמות יותר מ-1.34.1-gke.2037001	‫1.33.5-gke.2469000 ואילך, 1.34.1-gke.2037001 ואילך, 1.35 ואילך	צמתים של GPU או TPU נתקעים עם כתמי impending-node-termination אחרי תחזוקת מארח באשכולות GKE עם צמתי האצה (GPU או TPU) שמריצים גרסאות מושפעות, יכול להיות שהצמתים יישארו תקועים עם ההגדרות cloud.google.com/impending-node-termination או cloud.google.com/maintenance-window-started אחרי השלמת תחזוקה או תיקונים של מארח Compute Engine. כשמפעילים מחדש את מכונת ה-VM, יכול להיות שבקר התחזוקה של GKE יחיל מחדש את הכתמים האלה מוקדם מדי אם מתוכנן אירוע תחזוקה עתידי נוסף לצומת, וכך ימנע את התזמון של עומסי עבודה חדשים בצמתים תקינים. פתרון עקיף: כדי לפתור את הבעיה של המצב התקוע, צריך להסיר באופן ידני את התוויות של תחזוקה פעילה בניהול GKE ואת ה-taints מהצמתים המושפעים. אם תסירו רק את ה-taints, בקר התחזוקה של GKE יחיל אותם מחדש באופן אוטומטי. כדי לנקות את התוויות וההכתמות, מריצים את הפקודות הבאות: kubectl label nodes NODE_NAME cloud.google.com/active-node-maintenance- kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time- kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-latest- kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination- kubectl taint nodes NODE_NAME cloud.google.com/maintenance-window-started- מחליפים את NODE_NAME בשם הצומת המושפע.
פעולה	‫1.33 1.34	‫1.34.1-gke.1829001 ואילך	כניסה של Pod נכשלה עבור עומסי עבודה של TPU v7 בגלל דיווח על מספר שגוי של שבבים. ‫GKE מפרסם באופן שגוי שמונה שבבי TPU שניתנים להקצאה למאיצי TPU v7 ‏ (tpu7x) עם טופולוגיה של 2x2x1, אבל בפועל יש רק ארבעה שבבים. הפער הזה בדיווח מונע תזמון של Pod לעומסי עבודה של TPU v7. הארכיטקטורה של TPU v7 עם שני שבבים לא מטופלת בצורה נכונה בגרסאות קודמות, ולכן יש כשלים בהקצאת משאבים ל-Pod. בהתאם למשאבי ה-TPU המבוקשים, השגיאות הבאות מתרחשות: כשמבקשים ארבע יחידות TPU‏ (google.com/tpu: 4), ‏ kubelet מחזיר את השגיאה הבאה: UnexpectedAdmissionError: "invalid TPU chip count request, you must request all 4 chips on this node together". כשמבקשים שמונה יחידות TPU ‏ (google.com/tpu: 8), tpu-accelerator-topology-constraints ה-webhook של אישור הבקשה דוחה את הבקשה עם השגיאה הבאה: "Invalid resource requests for google.com/tpu. הערך צריך להיות אחד מתוך [4] עבור מאיץ tpu7x וטופולוגיה 2x2x1". פתרון עקיף: כדי לפתור את הבעיה, צריך לשדרג את אשכול GKE לגרסה ‎1.34.1-gke.1829001 ואילך.
פעולה	‫1.35.3-gke.1234000 ואילך	TBD	לקוח Lustre לא משתמש בכרטיסי NIC משניים בצמתים עם multi-NIC בצמתים של GKE עם כמה כרטיסי ממשק רשת (NIC), דרייבר ה-CSI של Managed Lustre מופעל כברירת מחדל כדי להשתמש בכל כרטיסי ה-NIC הזמינים לצבירת רוחב הפס על ידי פיזור תעבורת האחסון של TCP על פני ממשקי הרשת. עם זאת, בגלל בעיה מוכרת, יכול להיות שלקוחות Lustre החל מגרסה 2.14.0_p249 לא ישתמשו בכרטיסי NIC משניים. במקום זאת, כל תנועת האחסון של TCP למכונת Managed Lustre מנותבת באופן בלעדי דרך כרטיס ה-NIC הראשי, מה שמונע צבירה של רוחב פס ומגביל את קצב העברת הנתונים של האחסון. פתרון עקיף: אם עומסי העבודה שלכם דורשים צבירת רוחב פס של multi-NIC עבור Managed Lustre, צריך לשנמך את מאגרי הצמתים לגרסת GKE מוקדמת יותר מ-1.35.3-gke.1234000, כמו 1.35.2-gke.1842000.
פעולה	‫1.35 ואילך	TBD	זמן קצוב לתפוגה של החיבור או שהחיבור נדחה להפניות אוטומטיות לשרת המטא-נתונים של GKE ב-GKE בגרסה 1.35 ואילך, עומסי עבודה שמשתמשים ב-Workload Identity כדי לבצע אימות ל-Google Cloud APIs עשויים לחוות פסק זמן זמני לחיבור או חיבורים שנדחו לשרת המטא-נתונים של GKE מיד אחרי הפעלת הצומת. פתרון עקיף: המלצות ופתרונות עקיפים זמינים במאמר בנושא פתרון בעיות שקשורות לפסק זמן בהפעלה של Pod.
פעולה	‫1.33.8-gke.1026000 ואילך	גרסה 1.35.1 ואילך	gVisor shim לא מצליח לנקות, היומנים מציגים שגיאה "runsc: executable file not found in $PATH" בכל יציאה של gVisor Pod או חיסול OOM, ‏ containerd מנסה לפרק את ארגז החול. עם זאת, לפעמים תהליך הניקוי נכשל, והשגיאה exec: "runsc": executable file not found in $PATH נרשמת ביומן. השגיאה הזו עלולה לגרום לבעיות כמו מיצוי משאבים, פגיעה ברשת, פאניקה ב-NodeLocalDNS, זמני קצוב לתפוגה של DNS או חביון גבוה כשיוצרים Pods. פתרון: משדרגים את צמתי GKE לגרסה 1.35.1 ואילך. במקרים של אשכולות רגילים, משדרגים את מאגר הצמתים עם הצמתים המושפעים. באשכולות Autopilot, צריך לשדרג ידנית את אשכול Autopilot לגרסה 1.35.1 ואילך, ו-GKE ישדרג אוטומטית את הצמתים שלכם כך שיתאימו לגרסת מישור הבקרה בהקדם האפשרי. פתרון עקיף: אם אי אפשר לשדרג את האשכול, אפשר לבצע אחת מהפעולות הבאות: בודקים ומגדילים את בקשות הזיכרון והמגבלות של ה-pods של gVisor. פורסים את ה-DaemonSet הבא עם הרשאות כדי להעתיק את הקובץ הבינארי runsc מ-/home/containerd/usr/local/sbin אל /home/kubernetes/bin: apiVersion: apps/v1 kind: DaemonSet metadata: name: runsc-path namespace: kube-system spec: selector: matchLabels: app: runsc-path updateStrategy: type: RollingUpdate template: metadata: labels: app: runsc-path spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: sandbox.gke.io/runtime operator: In values: - gvisor tolerations: - effect: NoSchedule key: sandbox.gke.io/runtime operator: Equal value: gvisor volumes: - name: host hostPath: path: / initContainers: - name: copy-runsc image: bash command: - /usr/local/bin/bash - -c - | set -euo pipefail cp /host/home/containerd/usr/local/sbin/runsc /host/home/kubernetes/bin chmod a+rx /host/home/kubernetes/bin/runsc volumeMounts: - name: host mountPath: /host resources: requests: memory: 5Mi cpu: 5m securityContext: privileged: true containers: - image: gcr.io/google-containers/pause:3.2 name: pause
פעולה	‫1.35.0-gke.2232000 ואילך	‫1.35.3-gke.1.35.3-gke.1290000 ואילך	נפחים דינמיים חוזרים לסוג הדיסק שמוגדר כברירת מחדל יכול להיות שעומסי עבודה שמשתמשים בנפחים דינמיים ב-GKE בגרסה ‎1.35.0-gke.2232000 ואילך לא יצליחו לתזמן או לצרף. הבעיה הזו יכולה גם לגרום להקצאת נפחי אחסון באמצעות חלופת ברירת המחדל hd-type (למשל hyperdisk-balanced) במקום pd-type, גם בצמתים שלא תומכים ב-Hyperdisk. הבעיה הזו מתרחשת כי שרת הצומת PDCSI לא מאכלס את האובייקט CSINode בטופולוגיות של סוגי הדיסקים הנתמכים. כתוצאה מכך, לבקר חסר מידע טופולוגי נדרש כדי להתאים נפחים לצמתים תואמים. פתרון עקיף: שדרוג לגרסה 1.35.3-gke.1290000 ואילך.
שדרוגים ועדכונים	כל גרסאות התיקונים שקודמות לגרסה ‎1.34.3-gke.1208000 של GKE 1.34 כל הגרסאות עם תיקוני אבטחה שקודמות לגרסה 1.35.0-gke.2232000 של GKE 1.35	‫1.34.3-gke.1208000 ל-GKE 1.34 ‫1.35.0-gke.2232000 ל-GKE 1.35	בעיות בהפעלה של Pod במהלך שדרוגים ל-GKE 1.35 באשכולות GKE Dataplane V2 אשכולות שמשדרגים את מישור הבקרה לגרסה ‎1.35.0-gke.2232000 ואילך של GKE מגרסאות גרסה מוקדמת יותר מ-‎1.34.3-gke.1208000 ל-GKE 1.34 גרסה מוקדמת יותר מ-1.35.0-gke.2232000 ל-GKE 1.35 יכול להיות שיהיו בעיות בהפעלת ה-Pod עבור עומסי עבודה חדשים שנוצרו במהלך ההשקה של anetd DaemonSet. אם עומסי עבודה חדשים מתוזמנים להפעלה בצומת עם גרסה לא עדכנית של anetd, הם לא יופעלו במהלך ההשקה של anetd. במהלך ההשקה, יכול להיות שתופיע הודעת השגיאה הבאה: Failed to create pod sandbox: rpc error [...] plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded הבעיה הזו מתרחשת כי GKE משתמש במצב identity-management-mode של Operator, שבו כל הסוכנים וה-Operator צריכים להציג תצוגה מסונכרנת של identity-relevant labels. החל מ-GKE 1.35.0-gke.2232000, התוויות topology.kubernetes.io לא נכללות בקבוצה הרלוונטית לזהות כדי למנוע כפילות של זהויות. השינוי הזה גורם לחוסר התאמה זמני בהגדרות בין מישור הבקרה המשודרג לבין סוכני anetd מיושנים במהלך ההשקה. מידע נוסף זמין בCilium PR. פתרון עקיף: ב-GKE 1.34 בגרסה קודמת ל-1.34.3-gke.1208000: קודם משדרגים לגרסה 1.34.3-gke.1208000 ואילך, ואז משדרגים לגרסה 1.35.0-gke.2232000 ואילך. ל-GKE 1.35 בגרסה מוקדמת יותר מ-1.35.0-gke.2232000: אחרי השדרוג, צריך לחכות עד לסיום ההשקה של anetd. כדי להאיץ את ההשקה באופן ידני, מוחקים את ה-Pods anetd שהם מיושנים. כך תוכלו לוודא שלמפעיל ולסוכני הצמתים anetd יש תצוגות מסונכרנות של התוויות שרלוונטיות לזהות.
שדרוגים ועדכונים	‫1.32 ‫1.33 1.34 1.35	‫1.32.11-gke.1153001 ואילך ‫1.33.5-gke.2326000 ואילך ‫1.34.3-gke.1214000 ואילך ‫1.35.0-gke.2180000 ואילך	עיכובים בתזמון של Pod בצמתים חדשים עם מדיניות רשת ב-Kubernetes Calico מופעלת באשכולות GKE שבהם מופעלת מדיניות רשת ב-Kubernetes Calico, רגרסיה בגרסאות המושפעות עלולה לגרום לעיכובים משמעותיים בתזמון של Pod בצמתים חדשים או בצמתים שנוצרו מחדש. העיכובים האלה עלולים לגרום לכך שהצמתים יישארו במצב NotReady למשך תקופות ארוכות. הבעיה נגרמת בגלל שסקריפט לטעינה בזמן ההפעלה של Calico CNI מעצב באופן שגוי את כתובת ה-URL של שרת Kubernetes API עבור כתובות IPv4, על ידי הוספת סוגריים מרובעים ([]) סביבן. הגישה הזו מובילה לשגיאת ניתוח של כתובת ה-URL כשיוצרים ארגזי חול חדשים של Pod, שמופיעה ביומני kubelet: Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox ""sandbox-id"": plugin type="calico" failed (add): error creating calico client: host must be a URL or a host:port pair: "https://[IPv4-address]:443" פתרון עקיף: גרסת רכיב Calico נקבעת לפי גרסת מישור הבקרה של האשכול. כדי לצמצם את הבעיה, צריך לשדרג את רמת הבקרה של האשכול לאחת מהגרסאות המתוקנות. אחרי שמשדרגים את מישור הבקרה, צריך ליצור מחדש את הצמתים במאגרי הצמתים כדי לוודא שהם משתמשים בפורמט הנכון של כתובת ה-URL של שרת Kubernetes API. כדי לעשות את זה, אפשר לבצע שדרוג במקום של מאגר הצמתים לאותה גרסה או לגרסה חדשה יותר, או ליצור מחדש את מאגרי הצמתים באופן ידני.
ביצועים	‫1.32.8-gke.1134000 ואילך ל-GKE 1.32 ‫1.33.3-gke.1392000 ואילך ל-GKE 1.33 כל גרסאות התיקונים של GKE 1.34 ו-1.35	‫1.32.11-gke.1075000 ואילך ל-GKE 1.32 ‫1.33.5-gke.2392000 ואילך ל-GKE 1.33 ‫1.34.3-gke.1318000 ואילך ל-GKE 1.34 ‫1.35.0-gke.2398000 ואילך ל-GKE 1.35	הביצועים של רשתות למטרות כלליות יורדים בסוגי מכונות מסדרות A ו-G4 GPU באשכולות GKE עם צומתי GPU מסדרות A ו-G4, הביצועים של רישות למטרות כלליות ב-GKE 1.32.8-gke.1134000 ואילך ב-GKE 1.32, וב-GKE 1.33.3-gke.1392000 ואילך, נמוכים מהרגיל. הירידה בביצועים ברשתות למטרות כלליות משפיעה על סוגי מכונות GPU, כולל סדרת מכונות A3, סדרת מכונות A4, סדרת מכונות A4X וסדרת מכונות G4. שימו לב ש-GPUDirect-TCPXO ב-A3 Mega ו-GPUDirect-RDMA ב-A3 Ultra,‏ A4 ו-A4X לא מושפעים. השגיאה הזו מתרחשת כי הסקריפט ברמת הצומת (/usr/bin/google_set_multiqueue) שמגדיר את זיקת ההפרעה מוגדר בצורה שגויה. פתרון עקיף: משדרגים כל מאגר צמתים שהושפע לגרסה מתוקנת.
ביצועים	‫1.32.8-gke.1134000 ואילך ל-GKE 1.32 ‫1.33.3-gke.1392000 ואילך ל-GKE 1.33 ואילך	‫1.32.11-gke.1075000 ואילך ל-GKE 1.32 ‫1.33.5-gke.2392000 ואילך ל-GKE 1.33	הביצועים של GPUDirect-TCPX יורדים ב-A3 High באשכולות GKE עם צמתים מסוג A3 High (a3-highgpu-8g) יש ירידה בביצועים כשמשתמשים ב-GPUDirect-TCPX ב-GKE 1.32.8-gke.1134000 ואילך ל-GKE 1.32, וב-GKE 1.33.3-gke.1392000 ואילך. השגיאה הזו מתרחשת כי הסקריפט ברמת הצומת (/usr/bin/google_set_multiqueue) שמגדיר את זיקת ההפרעה מוגדר בצורה שגויה. פתרון עקיף: במאגרי צמתים של GKE 1.32, משדרגים את גרסאות מאגר הצמתים של GKE לגרסה ‎1.32.11-gke.1075000 ואילך. במאגרי צמתים של GKE מגרסה 1.33 ואילך, צריך לשדרג את גרסאות מאגרי הצמתים של GKE לגרסה ‎1.33.5-gke.2392000 ואילך.1392000. למאגרי צמתים של GKE 1.34, אפשר לעיין במאמר GPUDirect-TCPX לא זמין עם A3 High ל-GKE מגרסה 1.34 ואילך.
שדרוגים	1.35	‫1.35.0-gke.2232000 ואילך.	שכפול זהויות של Cilium באשכולות GKE Dataplane V2 באשכולות GKE שמופעלת בהם גרסה 1.35 עם GKE Dataplane V2, יכול להיות שיהיה גידול במספר המשאבים המותאמים אישית ciliumidentities.cilium.io. הבעיה הזו נגרמת בגלל תוויות של topology.kubernetes.io שנוספות לקבוצות Pod ב-Kubernetes 1.35, ויוצרות זהויות Cilium נוספות לכל אזור שבו מתוזמן Pod מעומס עבודה. גם באשכולות אזוריים וגם באשכולות אזוריים, תזמון של עומס עבודה חדש עלול לגרום לשכפול זמני של זהות Cilium. הכפילות הזו מתרחשת כי ל-Pods יש זהות אחת בזמן היצירה על סמך תוויות ראשוניות, ועוד זהות אחרי שמוסיפים תוויות טופולוגיה כשה-Pod מתוזמן לצומת. באשכולות אזוריים, מספר הזהויות עשוי לגדול גם בפקטור שפרופורציונלי למספר האזורים שהאשכול משתרע עליהם. השפעה: אם המספר הכולל של הזהויות גדול מ-65,535, יכול להיות שלא תהיה אפשרות לתזמן עומסי עבודה חדשים. פתרון עקיף: כדי להגביל את המספר הכולל של הזהויות, אל תוסיפו ל-Pods תוויות עם מספר גדול של ערכים ייחודיים. מידע נוסף זמין במאמרי העזרה הבאים של Cilium: אבטחה מבוססת-זהות זהויות אבטחה צריך לבצע שדרוגים ידניים מגרסאות 1.34.3-gke.1208000 ואילך. אם תתחילו את השדרוג מגרסה מוקדמת יותר מ-1.34.3-gke.1208000, יכול להיות שתיתקלו בבעיות זמניות בתזמון של Pod במהלך תהליך השדרוג.
שדרוגים	גרסאות תיקון של 1.34 לפני 1.34.5-gke.1153000 גרסאות תיקון 1.35 לפני 1.35.2-gke.1485000	‫1.34.5-gke.1153000 ואילך ‫1.35.2-gke.1485000 ואילך ‫1.36 ואילך בנוסף, צריך להשתמש בגרסה 3.1.9 ואילך של קובץ ההתקנה של GPUDirect-TCPX ובגרסה 2.0.12 ואילך של sidecar. הגרסאות של תוכנת ההתקנה ושל קובץ העזר ממופות אחת לאחת, והן צריכות להיות זהות. לדוגמה, גרסת תוכנת ההתקנה של GPUDirect-TCPX‏ 3.1.12 תואמת לגרסת ה-sidecar‏ 2.0.15. מידע נוסף על גרסאות של קובצי התקנה ו-sidecar זמין בהערות לגבי הגרסה של GPUDirect-TCPX.	‫GPUDirect-TCPX לא זמין ב-A3 High לגרסאות GKE ספציפיות אשכולות GKE עם צמתים מסוג A3 High (a3-highgpu-8g) משתמשים ב-GPUDirect-TCPX כדי למקסם את רוחב הפס של רשת ה-GPU. בצמתים שמשתמשים ב-TCPX וב-A3 High, שדרוג לגרסאות GKE שמושפעות מנקודת החולשה עלול לגרום לבעיות פונקציונליות או בעיות בביצועים של TCPX. הסיבה לכך היא ש-TCPX לא תואם לליבת Linux המעודכנת 6.12 שמשמשת את מערכת הפעלה שמותאמת לקונטיינרים milestone 125 ואילך. גרסה 1.34 של GKE משתמשת באבן הדרך 125. סוגי מכונות אחרים של GPU מסוג A3 High (‏a3-highgpu-1g, ‏ a3-highgpu-2g,‏ a3-highgpu-4g) וסדרות מכונות GPU אחרות לא מושפעים כי הם לא תומכים ב-GPUDirect-TCPX. פתרון: כדי לפתור את הבעיה, צריך לשדרג לתיקוני GKE גרסה קבועים. לפרטים על הגדרה ושדרוג של מאגרי צמתים עם GPUDirect-TCPX, אפשר לעיין במאמרים הגדלת רוחב הפס של רשת ה-GPU באשכולות רגילים או הגדלת רוחב הפס של רשת ה-GPU באשכולות Autopilot. כשמריצים בדיקות של NCCL בגרסאות קבועות, יכול להיות שיוצגו האזהרות הבאות שלא משפיעות על הביצועים או על הפונקציונליות: יומני NCCL WARN עבור Rx Ctrl Timeouts: ההודעה הזו יכולה להופיע אם עומס העבודה מפרסם פעולת תקשורת Recv ביעד הרבה לפני שהוא מפרסם פעולת תקשורת Send ביוזם. לא צפויה השפעה על הביצועים. יומני NCCL WARN עבור No free space for recv task: ההודעה הזו מזהירה מפני מספר נמוך של משימות רשת לעיבוד פעולות, שגורם לכך שכל המשימות תפוסות באופן זמני. לא צפויה השפעה על הביצועים.
פעולה	כל הגרסאות לפני 1.34.0-gke.2285000	‫1.34.0-gke.2285000 ואילך	עדכון הקיבולת המינימלית של המופע הקיבולת המינימלית למכונות Managed Lustre עודכנה ל-9,000‎ GiB. באשכולות שמריצים גרסאות מוקדמות מ-1.34.0-gke.2285000, אי אפשר ליצור מכונות עם הקיבולת המינימלית הזו באמצעות מנהל ההתקנים של Managed Lustre CSI. פתרון עקיף: כדי ליצור מופעי Managed Lustre עם קיבולת מינימלית של 9,000GiB, צריך לשדרג את גרסת האשכול לגרסה 1.34.0-gke.2285000 ואילך.
פעולה	כל הגרסאות	TBD	ממשק המשתמש שלGoogle Cloud הופך ללא ניתן לעריכה במהלך תיקון אוטומטי של הצומת כשצומת GKE עובר תיקון אוטומטי, אי אפשר לערוך את מאגר הצמתים דרך Google Cloud המסוף בגלל פעולה שמתבצעת. פתרון עקיף: עדיין אפשר לערוך את ההגדרות של מאגר הצמתים באמצעות פקודות של ה-CLI של gcloud.
פעולה	גרסאות 1.33 לפני 1.33.4-gke.1036000	‫1.33.4-gke.1036000 ואילך	רמת הביצועים שגויה עבור מכונות Lustre שהוקצו באופן דינמי כשמבצעים הקצאה דינמית של מופע Lustre, יצירת המופע נכשלת עם שגיאת InvalidArgument עבור PerUnitStorageThroughput, בלי קשר לערך perUnitStorageThroughput שצוין בבקשת ה-API. פתרון עקיף: משדרגים את אשכול GKE לגרסה ‎1.33.4-gke.1036000 ואילך. אם אתם משתמשים בערוץ היציב, יכול להיות שגרסה חדשה יותר עדיין לא זמינה. במקרה כזה, אפשר לבחור באופן ידני גרסה מערוצי ההפצה הרגילים או המהירים שכוללת את התיקון.
פעולה	‫1.32.3-gke.1099000 ואילך ‫1.33	‫1.33.3-gke.1266000 ואילך	שגיאת קלט/פלט כשמשנים את השם של קבצים או מעבירים אותם באמצעות מנהל התקן ה-CSI של Cloud Storage FUSE כשמשתמשים בגרסה מושפעת של מנהל התקן ה-CSI של Cloud Storage FUSE, יכול להיות ששינוי שם של קבצים או העברה שלהם לקטגוריות של Cloud Storage ייכשלו עם שגיאת קלט/פלט. פתרון עקיף: מוסיפים באופן זמני הגדרה ספציפית של תמונת sidecar למניפסט של ה-Pod. בקטע spec.containers של מניפסט ה-Pod, מוסיפים את הגדרת הקונטיינר הבאה עם התמונה: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2. # Add the following block to use the fixed sidecar image - name: gke-gcsfuse-sidecar image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2 מידע נוסף זמין במאמר בנושא הגדרת תמונה פרטית עבור קונטיינר sidecar. אחרי שמשדרגים את האשכול לגרסה קבועה של GKE או לגרסה חדשה יותר, צריך להסיר את כל הבלוק gke-gcsfuse-sidecar מהמניפסט. אחרי הסרת החסימה, מערכת GKE תחזור להוסיף ולנהל באופן אוטומטי את תמונת ה-sidecar הנכונה לגרסת האשכול המשודרגת.
רישום ביומן ומעקב	כל הגרסאות	TBD	מרוץ תהליכים ב-gke-metrics-agent DaemonSets כשמוסיפים את התווית cloud.google.com/gke-metrics-agent-scaling-level למאגר צמתים כדי להגדיל ידנית את הקצאת הזיכרון של gke-metrics-agent DaemonSet, מתרחש מרוץ תהליכים ב-DaemonSet במהלך יצירת צומת חדש. מרוץ התהליכים הזה גורם להפעלות מחדש לסירוגין, ויכול להיות שחלק מהמדדים לא יתועדו. הבעיה הזו מתרחשת כי יש עיכוב לפני שהתווית נוספת לצומת חדש במאגר הצמתים. במהלך העיכוב הזה, ה-DaemonSet יוצר Pod עם הקצאת הזיכרון המקורית בצומת הזה. אחרי שמחילים את התווית, ה-DaemonSet יוצר Pod עם הקצאת הזיכרון החדשה. ה-Pod הקיים לא נמחק לגמרי כשה-Pod המעודכן מתחיל. שני ה-Pods האלה מנסים להיקשר לאותו מספר יציאה. פתרון עקיף: אחרי שמוסיפים את התווית cloud.google.com/gke-metrics-agent-scaling-level למאגר צמתים, מפעילים מחדש את DaemonSet‏ gke-metrics-agent: kubectl -n kube-system rollout restart daemonset gke-metrics-agent
שדרוגים	‫1.33	1.33.2-gke.1043000	הורדת מכסת הקבצים הפתוחים ב-containerd 2.0 במאגרי צמתים שפועלים בגרסה 1.33 של GKE, שמשתמשת ב-containerd 2.0, המגבלה הרכה שמוגדרת כברירת מחדל לקבצים פתוחים (ulimit -n) לקונטיינרים הופחתה ל-1024. זהו שינוי ב-containerd עצמו (ראו containerd PR #8924) שבו LimitNOFILE הוסר מ-containerd.service כשיטה מומלצת, כך שהמגבלה הרכה של המערכת חלה כברירת מחדל. עומסי עבודה שמצפים למגבלה רכה גבוהה יותר כברירת מחדל (לדוגמה, עומסי עבודה שמסתמכים באופן מרומז על ברירת המחדל הקודמת שהייתה גבוהה יותר) עלולים להיכשל, למשל להציג שגיאות Too many open files. פתרון: שדרוג מגרסת תיקון קודמת של 1.33 לגרסה 1.33.2-gke.1043000 ואילך. פתרון עקיף: כדי להגדיל את מכסת הקבצים הפתוחים לעומסי העבודה, אפשר להשתמש באחת מהשיטות הבאות: שינוי ברמת האפליקציה: משנים את קוד האפליקציה או את ההגדרה כדי להגדיר במפורש את ulimit -n או prlimit --nofile=524288. Containerd NRI Ulimit Adjuster Plugin אפשר להשתמש containerd/nri ulimit-adjuster בפלאגין כדי לשנות את הערך של ulimit. הורדת גרסה של מאגר הצמתים (Standard בלבד): באשכולות GKE מסוג Standard, אפשר להוריד באופן זמני את הגרסה של מאגר הצמתים לגרסה 1.32 כדי למנוע את הבעיה הזו עד שיהיה פתרון קבוע. מידע נוסף על המעבר ל-containerd 2 זמין במאמר העברת צמתים ל-containerd 2.
שדרוגים	‫1.31.5-gke.1169000, ‏ 1.32.1-gke.1376000	‫1.31.7-gke.1164000, ‏ 1.32.3-gke.1512000	סטטוס CRD לא תקין.storedVersions ל-CRD מנוהלים יכול להיות שלחלק מ-CRD שמנוהלים על ידי GKE יש שדה status.storedVersions לא תקין, ולכן קיים סיכון לשיבוש הגישה לאובייקטים של CRD אחרי שדרוג. הבעיה הזו משפיעה על אשכולות שעומדים בשני התנאים הבאים: אשכולות שהשתמשו בגרסת GKE מושפעת בשלב מסוים. אשכולות שכללו גרסאות לא נתמכות (served=false) של אובייקטים מסוג CRD שמאוחסנים ב-etcd. פתרון עקיף: הפתרון המומלץ הוא לדחות את השדרוגים של האשכולות עד שהבעיה תיפתר. לחלופין, אם אתם יודעים שהאשכול שלכם מכיל גרסאות לא נתמכות של אובייקטים מסוג CRD, אתם יכולים להוסיף את הגרסאות האלה לשדה status.storedVersions באמצעות הפקודה kubectl patch.
תפעול, רישום ביומן ומעקב	‫1.32.2-gke.1652000, ‏ 1.31.6-gke.1221000, ‏ 1.30.10-gke.1227000	‫1.32.2-gke.1652003 ואילך ‫1.31.6-gke.1221001 ואילך ‫1.30.10-gke.1227001 ואילך	מדדים חסרים או שהמידרוג האוטומטי של עומס העבודה לא פועל יכול להיות שתבחינו בפערים בנתוני המדדים בגרסאות המושפעות אחרי שגודל האשכול גדל ביותר מחמישה צמתים. הבעיה הזו עשויה להשפיע גם על פעולות של שינוי גודל אוטומטי. הבעיה הזו משפיעה רק על אשכולות ששודרגו לגרסאות המושפעות. קלאסטרים חדשים שנוצרו אמורים לפעול כצפוי. פתרון עקיף: אם אתם מושפעים מהבעיה, אתם יכולים לשדרג לגרסאות החדשות המתוקנות או לשנמך לגרסה אחת קודמת.
פעולה			מגבלות הגודל והקבצים המצורפים של Google Cloud Hyperdisk בדרך כלל, אם אי אפשר לתזמן Pod בגלל מגבלות על volume attachment של צומת, מופעלת הקצאת משאבים אוטומטית של צומת חדש. כשמריצים עומסי עבודה שמשתמשים במוצר Hyperdisk ומתוזמנים לצומת שמריץ מכונה וירטואלית C3, לא מתבצעת הקצאת צמתים אוטומטית (NAP) וה-Pod מתוזמן לצומת שכבר מלא. עומס העבודה מתוזמן לצומת למרות שאין דיסק זמין לצירוף. גם הפעלת עומס העבודה נכשלת, בגלל שגיאה כמו הבאה: AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17] הבעיה קיימת בכל מוצרי Hyperdisk במכונות C3. מגבלות הצירוף של Hyperdisk משתנות בהתאם למספר ליבות ה-vCPU של מכונת ה-VM ולמוצר Hyperdisk. מידע נוסף זמין במאמר בנושא מגבלות הביצועים של Hyperdisk. פתרון עקיף: מוצרי Google Cloud Hyperdisk מפעילים הקצאת משאבים אוטומטית בצורות אחרות של מכונות וירטואליות. מומלץ לבחור צורה שתומכת רק ב-Google Cloud Hyperdisk.
פעולה	‫1.32.3-gke.1927000, ‏ 1.32.3-gke.1785000, ‏ 1.32.3-gke.1717000, ‏ 1.32.3-gke.1440000, ‏ 1.32.3-gke.1170000, ‏ 1.32.3-gke.1250000, ‏ 1.32.3-gke.1671000, ‏ 1.32.3-gke.1596000, ‏ 1.32.3-gke.1298000		תהליך gke-metadata-server נקטל בגלל חריגה מזיכרון (OOM) בצמתים של TPU/GPU בצמתים של GKE TPU (לדוגמה, ct4p-hightpu-4t) ובצמתים של GPU (לדוגמה, a3-highgpu-8g), יכול להיות שהליבה תסיים את gke-metadata-server עם OOMKilled אם השימוש בזיכרון של השרת יעלה על 100 MB. פתרון עקיף: אם אתם רואים אירועי OOMKilled עבור gke-metadata-server בצמתים של TPU או GPU, פנו לצוות התורן של GKE Identity (מזהה רכיב: 395450) כדי לקבל אפשרויות לצמצום הבעיה.
פעולה	‫1.32.0-gke.1358000 עד 1.32.4-gke.1106006, ‏ 1.32.4-gke.1236007, ‏ 1.32.4-gke.1353001, ‏ 1.32.4-gke.1415001, ‏ 1.32.4-gke.1533000 ‫1.33.0-gke.0 עד 1.33.0-gke.1552000	‫1.32.4-gke.1353003 ואילך ‫1.33.0-gke.1552000 ואילך	יכול להיות ששינוי הגודל של נפחים נתקע בגלל סטטוס NodePendingResize תלוי ב-PVC. בגרסה 1.32, אשכולות עם צמתים בגרסה 1.31 או בגרסאות קודמות לא יצליחו לעדכן את הסטטוס של PersistentVolumeClaim במהלך שינוי הגודל. הסטטוס השגוי הזה מונע את תחילת הפעולות הבאות של שינוי הגודל, ולמעשה מונע שינויי גודל נוספים. ל-PVC במצב הזה יש שדה status.allocatedResourceStatuses שמכיל את הערך NodePendingResize או את שני השדות status.allocatedResources ו-status.conditions.type: FileSystemResizePending. אם נוצר PVC בזמן שהאשכול היה בגרסה מושפעת, יכול להיות שהבעיה הזו תימשך גם אחרי שהאשכול ישודרג לגרסה ידועה שבה הבעיה תוקנה. בתרחיש הזה, צריך להחיל תיקון על ה-PVC כדי להסיר את השדה status.allocatedResources באמצעות פתרון עקיף חד-פעמי. פתרון עקיף: אפשר לתקן PVCs שנתקעו בגלל סטטוס לא תקין כדי להסיר את הסטטוס הזה. כדי להסיר את הסטטוס 'תלוי ועומד', אפשר להשתמש בפקודת תיקון כמו זו שבהמשך: kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}' kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}'
פעולה	‫1.32.4-gke.1236007, ‏ 1.32.4-gke.1353001	‫1.32.4-gke.1353003 ואילך	יכול להיות שהרישום ביומן של מנהל ההתקן PDCSI יהיה מוגזם יכול להיות שבאשכולות GKE בגרסאות ספציפיות של 1.32 יופיעו הודעות יומן מוגזמות מדרייבר PDCSI. הרישום העודף הזה ינצל את המכסה של Cloud Logging Write API. פתרון עקיף: כדי לצמצם את הרישום המוגזם הזה, אפשר להוסיף מסנן החרגה. כדי לא לכלול את הודעות היומן בהעברה ל-Cloud Logging, משתמשים בשאילתה הבאה: resource.type="k8s_container" resource.labels.container_name="gce-pd-driver" (sourceLocation.file="cache.go" OR "Cannot process volume group")
תפעול	‫1.27.16-gke.2440000 ואילך ‫1.28.15-gke.1673000 ואילך ‫1.29.13-gke.1038000 ואילך ‫1.30.9 ואילך ‫1.31.7 ואילך ‫1.32.1-gke.1357001 ואילך	‫1.27.16-gke.2691000 ואילך ‫1.28.15-gke.2152000 ואילך ‫1.29.15-gke.1218000 ואילך ‫1.30.11-gke.1190000 ואילך ‫1.31.7-gke.1363000 ואילך ‫1.32.4-gke.1106000 ואילך ‫1.33.0-gke.1552000 ואילך	תצורות Pod שמנסות לטעון כרכים קבועים של NFS בצמתים של COS שבעבר היה להם טעינה במצב קריאה בלבד (RO) ייטענו רק במצב RO ב-GKE מגרסה 1.27 ואילך, אפשר לטעון נפחי NFS באמצעות מנהל התקן ה-CSI של Kubernetes בתוך העץ רק כנפחים קבועים במצב RO אחרי טעינת RO קודמת באותו הצומת. פתרון עקיף: הורדת גרסה של מאגרי צמתים לגרסה שקודמת לגרסאות המושפעות
תפעול	גרסאות 1.32 מ-1.32.1-gke.1357001 עד 1.32.4-gke.1106000, לא כולל כל הגרסאות 1.33 שקודמות לגרסה 1.33.0-gke.1552000 גרסה 1.32: ‏ 1.32.4-gke.1106000 ואילך גרסה 1.33: ‏ 1.33.0-gke.1552000 ואילך	פודים שמנסים לטעון נפחי אחסון קבועים של NFS בצמתי Ubuntu לא יוכלו לפעול. ב-GKE מגרסה 1.32 ואילך, לא ניתן לטעון נפחי NFS באמצעות מנהל התקן ה-CSI של Kubernetes בתוך העץ בצמתים של Ubuntu. במקרה כזה, יכול להיות שיופיעו הודעות השגיאה הבאות: "MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1" Output: Mount failed: mount failed: exit status 127 "Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes" בנוסף להודעות השגיאה האלה, לא ניתן יהיה להפעיל את ה-Pods שמשתמשים באמצעי האחסון האלה. פתרון עקיף: הורדת הגרסה של מאגרי הצמתים לגרסה 1.31.
פעולה	‫‎>= 1.28.15-gke.1436000, < 1.28.15-gke.1668000, >= 1.29.12-gke.1040000, < 1.29.13-gke.1028000, >= 1.30.8-gke.1053000, < 1.30.8-gke.1287000, >= 1.31.4-gke.1057000, < 1.31.6-gke.1020000, >= 1.32.0-gke.1281000, < 1.32.1-gke.1369000	‫1.28.15-gke.1668000 ואילך ‫1.29.13-gke.1028000 ואילך ‫1.30.8-gke.1287000 ואילך ‫1.31.6-gke.1020000 ואילך ‫1.32.1-gke.1369000 ואילך	יכול להיות שפודים שמשתמשים בקריאות מערכת שקשורות ל-io_uring ייתקעו במצב Terminating יכול להיות שפודים שמשתמשים בקריאות מערכת שקשורות ל-io_uring ייכנסו למצב D (המתנה לדיסק), שנקרא גם TASK_UNINTERRUPTIBLE, בגלל באג בליבת לינוקס. אי אפשר להעיר תהליכים במצב D באמצעות אותות, כולל SIGKILL. כש-Pod מושפע מהבעיה הידועה הזו, יכול להיות שהקונטיינרים שלו לא יסיימו את הפעולה בצורה תקינה. ביומנים של containerd, יכול להיות שתראו הודעות חוזרות שדומות להודעה הבאה: Kill container [container-id]. ההודעות האלה מציינות שהמערכת מנסה שוב ושוב לעצור מאגר. במקביל, ביומני kubelet מוצגות הודעות שגיאה, כמו הבאות: "Kill container failed" err="rpc error: code = DeadlineExceeded desc = context deadline exceeded" או "Error syncing pod, skipping" err="[failed to \"KillContainer\" for \"container-name\" with KillContainerError: \"rpc error: code = DeadlineExceeded desc = an error occurs during waiting for container \\\"container-id\\\" to be killed: wait container \\\"container-id\\\": context deadline exceeded\", failed to \"KillPodSandbox\" for \"pod-uuid\" with KillPodSandboxError: \"rpc error: code = DeadlineExceeded desc = context deadline exceeded\"]" pod="pod-name" podUID="pod-uuid" התסמינים האלה מצביעים על תהליכים בתוך הקונטיינר שנתקעו במצב שינה שלא ניתן להפריע לו (מצב D), מה שמונע את הסיום התקין של ה-Pod. עומסי עבודה שמשתמשים ב-io_uring באופן ישיר, או שמשתמשים ב-io_uring באופן עקיף דרך זמן ריצה של שפה כמו NodeJS, עשויים להיות מושפעים מהבעיה הידועה הזו. עומסי העבודה המושפעים כוללים תהליך במצב D (שינה של הדיסק) בקובץ /proc/<pid>/state, ומציגים את המחרוזת io_uring כחלק מהתוכן של /proc/<pid>/stack. יכול להיות שעומסי עבודה של NodeJS יוכלו להשבית את השימוש ב-io_uring באמצעות UV_USE_IO_URING=0. פתרון עקיף: משדרגים את הצמתים באשכול לגרסה קבועה או לגרסה חדשה יותר.
פעולה	‫1.28, 1.29, 1.30, 1.31	‫1.30.8-gke.1261000 ואילך ‫1.31.4-gke.1183000 ואילך ‫1.32.0-gke.1448000 ואילך	עומסי עבודה שמשתמשים בסטרימינג של תמונות נכשלים עם שגיאות אימות באג בתכונה Image streaming עלול לגרום לכשלי עומסי עבודה אם מתקיימים תנאים ספציפיים בזמן שהקונטיינר קורא קבצים. יכול להיות שיופיעו הודעות שגיאה שקשורות לכשלים באימות ביומן של gcfsd. כדי לבדוק אם הבעיה משפיעה עליכם, מחפשים ביומנים באמצעות שאילתת החיפוש הבאה: resource.type="k8s_node" resource.labels.project_id="[project_id]" resource.labels.cluster_name="[cluster_name]" logName="projects/[project_id]/logs/gcfsd" "backend.FileContent failed" "Request is missing required authentication credential." הופעת השגיאות האלה מצביעה על כך שהצמתים מושפעים. אם הבעיה הזו משפיעה עליכם, אתם יכולים לשדרג את מאגרי הצמתים לגרסה של GKE עם תיקון.
פעולה	‫1.30.0 עד 1.30.5-gke.1443001 ‫1.31.0 עד 1.31.1-gke.1678000	‫1.30.5-gke.1628000 ואילך ‫1.31.1-gke.1846000 ואילך	שיעורי פינוי גבוהים יותר של Pod בגרסאות GKE 1.30 ו-1.31 בגרסאות מסוימות של GKE 1.30 ו-GKE 1.31 שמשתמשות ב-COS 113 וב-COS 117 בהתאמה, יש ליבות שנבנו עם האפשרות CONFIG_LRU_GEN_ENABLED=y. האפשרות הזו מפעילה את תכונת הליבה Multi-Gen LRU, שגורמת ל-kubelet לחשב באופן שגוי את השימוש בזיכרון, ועלולה להוביל לכך ש-kubelet יסיר Pods. אפשרות ההגדרה CONFIG_LRU_GEN_ENABLED מושבתת ב-cos-113-18244-151-96 וב-cos-117-18613-0-76. יכול להיות שלא תמיד תראו שיעור חריג של הוצאת Pods כי הבעיה הזו תלויה בדפוס השימוש בזיכרון של עומס העבודה. קיים סיכון גבוה יותר ש-kubelet יסלק את ה-Pods עבור עומסי עבודה שלא הוגדרה להם מגבלת זיכרון בשדה resources. הסיבה לכך היא שעומסי העבודה עשויים לבקש יותר זיכרון ממה ש-kubelet מדווח כזמין. אם אתם רואים שימוש גבוה יותר בזיכרון של אפליקציה אחרי שדרוג לגרסאות GKE שצוינו בלי לבצע שינויים אחרים, יכול להיות שאתם מושפעים מאפשרות הליבה. כדי לבדוק אם יש שיעורי הוצאה חריגים של Pod, מנתחים את המדדים הבאים באמצעות Metrics Explorer: ‫kubernetes.io/container_memory_used_bytes ו-kubernetes.io/container_memory_request_bytes אפשר להשתמש בשאילתות PromQL הבאות. מחליפים את הערכים של cluster_name, ‏namespace_name, ‏metadata_system_top_level_controller_type ו-metadata_system_top_level_controller_name בשם ובסוג של עומס העבודה שרוצים לנתח: max by (pod_name)(max_over_time(kubernetes_io:container_memory_used_bytes{monitored_resource="k8s_container",memory_type="non-evictable",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}])) sum by (pod_name)(avg_over_time(kubernetes_io:container_memory_request_bytes{monitored_resource="k8s_container",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}])) אם אתם רואים עליות חריגות בשימוש בזיכרון שחורגות מהזיכרון המבוקש, יכול להיות שעומס העבודה נמחק לעיתים קרובות יותר. דרך לעקיפת הבעיה אם אתם לא יכולים לשדרג לגרסאות המתוקנות ואתם מריצים בסביבת GKE שבה אתם יכולים לפרוס Pods עם הרשאות, אתם יכולים להשבית את האפשרות Multi-Gen LRU באמצעות DaemonSet. מעדכנים את מאגרי הצמתים של GKE שמהם רוצים להריץ את DaemonSet באמצעות הערה כדי להשבית את האפשרות Multi-Gen LRU. לדוגמה, disable-mglru: "true". מעדכנים את הפרמטר nodeSelector במניפסט של DaemonSet באותה הערה שהשתמשתם בה בשלב הקודם. לדוגמה, אפשר לעיין בקובץ disable-mglru.yaml במאגר GoogleCloudPlatform/k8s-node-tools. פורסים את DaemonSet באשכול. אחרי ש-DaemonSet פועל בכל מאגרי הצמתים שנבחרו, השינוי נכנס לתוקף באופן מיידי וחישוב השימוש בזיכרון של kubelet חוזר למצב תקין.
פעולה	‫1.28, 1.29, 1.30, 1.31	‫1.28.14-gke.1175000 ואילך ‫1.29.9-gke.1341000 ואילך ‫1.30.5-gke.1355000 ואילך ‫1.31.1-gke.1621000 ואילך	‫Pods נתקעים בסטטוס Terminating (הפסקת פעולה) באג בזמן הריצה של הקונטיינר (containerd) עלול לגרום לכך ש-Pods וקונטיינרים ייתקעו בסטטוס Terminating (סיום) עם שגיאות דומות לאלה: OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown אם הבעיה הזו משפיעה עליכם, אתם יכולים לשדרג את הצמתים לגרסת GKE עם גרסה קבועה של containerd.
פעולה	‫1.34 וגרסאות קודמות גרסאות 1.35 מוקדמות יותר מ-1.35.6-gke.1005000 גרסאות 1.36 ישנות יותר מ-1.36.0-gke.2459000	‫1.35.6-gke.1005000 ואילך ‫1.36.0-gke.2459000 ואילך	הסטרימינג של התמונה נכשל בגלל קישורים סמליים באג בתכונה Image streaming עלול לגרום לכך שמאגרי תמונות לא יופעלו. יכול להיות שלא תצליחו ליצור קונטיינרים שפועלים בצומת עם סטרימינג של תמונות שמופעל בגרסאות ספציפיות של GKE, ותקבלו את השגיאה הבאה: "CreateContainer in sandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to create containerd container: failed to mount [PATH]: too many levels of symbolic links" פתרון עקיף: כדי לפתור את הבעיה, צריך לשדרג את מאגרי הצמתים לגרסה קבועה (1.35.6-gke.1005000 ואילך, או 1.36.0-gke.2459000 ואילך). אם אי אפשר לשדרג, אפשר לבדוק אם יש שכבות ריקות או שכבות כפולות. אם אתם לא מצליחים להסיר שכבות ריקות או שכבות כפולות, צריך להשבית את הזרמת התמונות.
פעולה	‫1.27,‏ 1.28,‏ 1.29	‫1.28.9-gke.1103000 ואילך ‫1.29.4-gke.1202000 ואילך ‫1.30: כל הגרסאות	הזרמת התמונות נכשלת בגלל קבצים חסרים באג בתכונה Image streaming עלול לגרום לכשלים במאגרי תמונות בגלל קובץ או קבצים חסרים. יכול להיות שקונטיינרים שפועלים בצומת עם סטרימינג של תמונות שמופעל בגרסאות הבאות לא יתחילו לפעול או יפעלו עם שגיאות שמציינות שקבצים מסוימים לא קיימים. דוגמאות לשגיאות כאלה: No such file or directory Executable file not found in $PATH אם הבעיה הזו משפיעה עליכם, אתם יכולים להשבית את הסטרימינג של התמונות.
Networking,שדרוגים ועדכונים	‫1.28		שגיאה בהגדרת TLS של שער זיהינו בעיה בהגדרת TLS לשערי כניסה באשכולות שמופעלת בהם גרסת GKE‏ 1.28.4-gke.1083000. הדבר משפיע על הגדרות TLS שמשתמשות ב-SSLCertificate או ב-CertificateMap. אם משדרגים אשכול עם שערים קיימים, העדכונים שבוצעו בשער ייכשלו. במקרה של שערים חדשים, מאזני העומסים לא יוקצו. הבעיה הזו תיפתר בגרסת תיקון (patch) של GKE 1.28 שתצא בקרוב.
שדרוגים ועדכונים	1.27	גרסה 1.27.8 ואילך	בעיה בתוסף של מכשיר GPU יכול להיות שיהיו בעיות בתוספים של מכשירי ה-GPU בצמתים (nvidia-gpu-device-plugin) באשכולות שמופעלים בהם מעבדי GPU ושודרגו מגרסה 1.26 לגרסת תיקון 1.27 מוקדמת יותר מ-1.27.8. צריך לבצע את השלבים הבאים בהתאם למצב האשכול: אם באשכול שלכם פועלת גרסה 1.26 ויש בו מעבדי GPU, אל תשדרגו את האשכול באופן ידני עד שגרסה 1.27.8 תהיה זמינה בערוץ ההפצה של האשכול. אם האשכול שלכם מריץ גרסת תיקון מוקדמת יותר של 1.27 והצמתים מושפעים, צריך להפעיל מחדש את הצמתים או למחוק ידנית את ה-Pod‏ nvidia-gpu-device-plugin בצמתים (מנהל התוספים ייצור תוסף עובד חדש). אם הקלאסטר שלכם משתמש בשדרוגים אוטומטיים, זה לא ישפיע עליכם כי שדרוגים אוטומטיים יעבירו קלאסטרים רק לגרסאות תיקון עם התיקון.
פעולה	‫1.27,1.28	‫1.27.5-gke.1300 ואילך ‫1.28.1-gke.1400 ואילך	השינוי האוטומטי של נפח האחסון לכל עומסי העבודה מפסיק יכול להיות שהתכונות HorizontalPodAutoscaler‏ (HPA) ו-VerticalPodAutoscaler‏ (VPA) יפסיקו את ההתאמה האוטומטית של כל עומסי העבודה באשכול אם הוא מכיל אובייקטים של autoscaling/v2 HPA שהוגדרו בצורה שגויה. הבעיה משפיעה על אשכולות שמריצים גרסאות קודמות של תיקונים ב-GKE בגרסאות 1.27 ו-1.28 (לדוגמה, 1.27.3-gke.100). פתרון עקיף: כדי לתקן אובייקטים של autoscaling/v2 HPA שהוגדרו בצורה שגויה, צריך לוודא שהשדות ב-spec.metrics.resource.target תואמים, לדוגמה: כשהערך של spec.metrics.resource.target.type הוא Utilization, ערך היעד צריך להיות averageUtilization כשהערך של spec.metrics.resource.target.type הוא AverageValue, ערך היעד צריך להיות averageValue מידע נוסף על הגדרת אובייקטים של autoscaling/v2 HPA מופיע במסמכי התיעוד של Kubernetes בנושא HorizontalPodAutoscaler.
פעולה	‫1.28,1.29	1.28.7-gke.1026000 1.29.2-gke.1060000	פריסת התכונה 'זיהוי איומים בקונטיינר' נכשלת יכול להיות שפריסת התכונה 'זיהוי איומים בקונטיינרים' באשכולות Autopilot שפועלות בהם הגרסאות הבאות של GKE תיכשל: ‫1.28.6-gke.1095000 עד 1.28.7-gke.1025000 ‫1.29.1-gke.1016000 עד 1.29.1-gke.1781000
Networking, Upgrades	‫1.27, 1.28, 1.29, 1.30	‫1.30.4-gke.1282000 ואילך ‫1.29.8-gke.1157000 ואילך ‫1.28.13-gke.1078000 ואילך ‫1.27.16-gke.1342000 ואילך	בעיות בקישוריות של hostPort Pods אחרי שדרוג של מישור הבקרה באשכולות שבהם מדיניות רשת ב-Kubernetes מופעלת, יכולות להיות בעיות בקישוריות עם Pods של hostPort. בנוסף, יכול להיות שיחלפו עוד 30 עד 60 שניות עד ש-Pods חדשים יהיו מוכנים. הבעיה מתרחשת כשמשדרגים את מישור הבקרה של GKE באשכול לאחת מהגרסאות הבאות של GKE ‫1.30 עד 1.30.4-gke.1281999 ‫1.29.1-gke.1545000 עד 1.29.8-gke.1156999 ‫‎1.28.7-gke.1042000 עד ‎1.28.13-gke.1077999 ‫1.27.12-gke.1107000 עד 1.27.16-gke.1341999 פתרון עקיף: משדרגים או יוצרים מחדש את הצמתים מיד אחרי שדרוג מישור הבקרה של GKE.
Networking	‫1.31, 1.32	‫1.32.1-gke.1729000 ואילך ‫1.31.6-gke.1020000 ואילך	תנועת UDP פגומה בין Pods שפועלים באותו צומת באשכולות שבהם הגישה לנתונים בתוך הצומת מופעלת, יכול להיות שתעבורת ה-UDP בין ה-Pods שפועלים באותו צומת תיפסק. הבעיה מתרחשת כשמשדרגים את הצומת של אשכול GKE לגרסה אחת מהגרסאות הבאות של GKE, או כשיוצרים אותו עם אחת מהגרסאות האלה: ‫1.32.1-gke.1729000 ואילך ‫1.31.6-gke.1020000 ואילך הנתיב שמושפע הוא תנועת UDP מ-Pod ל-Pod באותו צומת דרך Hostport או Service. רזולוציה משדרגים את האשכול לאחת מהגרסאות המתוקנות הבאות: ‫1.32.3-gke.1927000 ואילך ‫1.31.7-gke.1390000 ואילך
פעולה	‫1.29,‏1.30,‏1.31	‫1.29.10-gke.1071000 ואילך ‫1.30.5-gke.1723000 ואילך ‫1.31.2-gke.1115000 ואילך	אי התאמה בין Ray Operator לבין הצפנת מסד נתונים ב-Cloud KMS חלק מהגרסאות של Ray Operator לא תואמות להצפנת מסד נתונים ב-Cloud KMS. פתרונות עקיפים: משדרגים את רמת הבקרה של האשכול לגרסה מתוקנת או לגרסה חדשה יותר.
שדרוגים ועדכונים	‫1.30, 1.31	‫1.30.8-gke.1051000 ואילך ‫1.31.1-gke.2008000 ואילך	‫Pod של GPU Maintenance Handler תקוע במצב CrashLoopBackOff בגלל הבעיה הזו, תרמילי gpu-maintenance-handler תקועים במצב CrashLoopBackOff בצמתים המתאימים. המצב הזה מונע את הוספת התווית upcoming maintenance (תחזוקה בקרוב) לצומתי GKE, ויכול להשפיע על תהליכי ניקוז הצמתים והוצאת הפודים מעומסי העבודה. "Node upcoming maintenance label not applied due to error: Node "gke-yyy-yyy" is invalid: metadata.labels: Invalid value: "-62135596800": a valid label must be an empty string or consist of alphanumeric characters, '-','' or '.', and must start and end with an alphanumeric character (e.g.'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9])?')" אם הבעיה הזו משפיעה עליכם, תוכלו לפתור אותה על ידי שדרוג מישור הבקרה לגרסת GKE שכוללת את התיקון.
פעולה	‫1.33.1-gke.1522000 ואילך	‫1.33.4-gke.1142000 ואילך	הפעלת הפודים בצמתים עם סטרימינג של תמונות נכשלת בצמתים שבהם מופעלת הזרמת תמונות, יכול להיות שעומסי עבודה לא יתחילו לפעול עם חתימת השגיאה הבאה: Failed to create pod sandbox ... context deadline exceeded יומני יציאה טורית של צומת מושפע מכילים גם את חתימת השגיאה הבאה: task gcfsd ... blocked for more than X seconds הנוכחות של שני חתימות השגיאה האלה מצביעה על מצב של קיפאון באחד מרכיבי הזרמת התמונות. הקיפאון הזה מונע הפעלה תקינה של ה-Pods. הפחתת הסיכון: כדי לצמצם את הסיכון במהירות, מפעילים מחדש את הצומת. שימו לב: יכול להיות שהצומת שהופעל מחדש עדיין ייתקל שוב במצב של חסימה הדדית. כדי להקטין את הסיכון בצורה משמעותית, משביתים את הזרמת התמונות במאגר הצמתים באמצעות הפקודה הבאה: gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming הערה: השבתה של Image streaming יוצרת מחדש את כל הצמתים במאגר הצמתים.
פעולה	‫1.32.4-gke.1198000 ואילך גרסאות 1.33 לפני 1.33.5-gke.1862000 גרסאות 1.34 לפני 1.34.1-gke.2541000	‫1.33.5-gke.1862000 ואילך ‫1.34.1-gke.2541000 ואילך	‫Custom ComputeClasses עם ImageType שלא משתמשים במאגרי צמתים קיימים של GKE. כשמשתמשים ב-ComputeClass בהתאמה אישית שמגדיר שדה ImageType, הכלי Cluster Autoscaler יוצר שוב ושוב מאגרי צמתים חדשים ומגדיל את הגודל שלהם, במקום להגדיל את הגודל של מאגרי צמתים קיימים. הסטטוס של ComputeClass לא תקין. פתרון עקיף: משדרגים את האשכול לאחת מהגרסאות המתוקנות הבאות: ‫1.33.5-gke.1862000 ואילך ‫1.34.1-gke.2541000 ואילך אפשרות נוספת היא להגדיר רק חלק מהשדות ב-ComputeClass המותאם אישית כדי למנוע את הבעיה. אם לא משתמשים ב-ComputeClass בהתאמה אישית של Autopilot, לא מגדירים את השדה ImageType. במקרה כזה, הערך שבו נעשה שימוש הוא הגדרת ברירת המחדל ברמת האשכול, שהיא cos_containerd כברירת מחדל. אם משתמשים ב-ComputeClass בהתאמה אישית ב-Autopilot, לא מגדירים את השדה nodePoolConfig, שהוא ברמה ImageType.

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

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

  • פתיחת בקשת תמיכה באמצעות פנייה אל Cloud Customer Care.
  • קבלת תמיכה מהקהילה על ידי פרסום שאלות ב-StackOverflow ושימוש בתג google-kubernetes-engine כדי לחפש בעיות דומות. אתם יכולים גם להצטרף לערוץ Slack‏ #kubernetes-engine כדי לקבל תמיכה נוספת מהקהילה.
  • פתיחת דיווחים על בעיות או בקשות למאפיינים חדשים באמצעות הכלי הציבורי למעקב אחר בעיות.