בעיות מוכרות ב-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.34.9-gke.1065000 ואילך, 1.35.6-gke.1049000 ואילך, וכל גרסאות התיקונים של 1.36	TBD	כשלים בעומס העבודה של GPU ב-A4X Max (GB300) יצירה או שדרוג של מאגרי צמתים מסוג GKE A4X Max (a4x-maxgpu-4g-metal) בגרסאות תיקון ספציפיות או לגרסאות תיקון ספציפיות (ראו את העמודה גרסאות מזוהות) גורמים לכשלים בעומסי עבודה של GPU עם שבבי NVIDIA GB300 Grace Blackwell Ultra Superchips המצורפים. בגלל זמני אתחול ארוכים של זיכרון ברוחב פס גבוה (HBM) בחומרה של GB300 עם סוג המכונה הזה של Bare Metal, שירות ההפעלה של nvidia-persistenced מגיע לזמן קצוב לתפוגה. בגלל פסק הזמן הזה, מעבדי ה-GPU לא עוברים אתחול, וכש-Pods מנסים לתבוע משאבי CUDA, מוצגת הודעת השגיאה cudaErrorDeviceUnavailable(46). פתרון עקיף: מוחקים את כל מאגרי הצמתים של A4X Max שמופעלות בהם גרסאות מושפעות, ויוצרים מחדש את מאגרי הצמתים באמצעות גרסה קודמת שלא מושפעת. שימו לב: מכיוון שקיבולת A4X Max חייבת להתקבל באמצעות הזמנה, לא תאבדו קיבולת אם תמחקו את מאגרי הצמתים. מערכת GKE מונעת יצירה של מאגרי צמתים של A4X Max עם גרסאות מושפעות, ולא תשדרג אוטומטית את מאגרי הצמתים לגרסאות מושפעות. ב-GKE אפשר לבצע שדרוגים ידניים. עם זאת, כדי להימנע מהכשלים, אנחנו ממליצים לא לשדרג לגרסאות המושפעות.
פעולה	גרסאות 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 מדור 7 ‏ (tpu7x) עם טופולוגיה של 2x2x1, שבפועל מכילים רק ארבעה שבבים. חוסר התאמה בדיווח הזה מונע תזמון של Pods לעומסי עבודה של 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 משתמש ב-Operator identity-management-mode, שבו כל הסוכנים וה-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 נקבעת לפי גרסת מישור הבקרה של האשכול. כדי לפתור את הבעיה, צריך לשדרג את רמת הבקרה של האשכול לאחת מהגרסאות המתוקנות. אחרי שמשדרגים את מישור הבקרה, צריך ליצור מחדש את הצמתים במאגרי הצמתים כדי לוודא שהם משתמשים בפורמט הנכון של כתובת השרת של 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 installer ובגרסה 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,000GiB. במערכות הפעלה של אשכולות בגרסאות שקודמות ל-1.34.0-gke.2285000, אי אפשר ליצור מכונות עם הקיבולת המינימלית הזו באמצעות מנהל ההתקן של Managed Lustre CSI. פתרון עקיף: כדי ליצור מופעים מנוהלים של 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 האלה מנסים לבצע binding לאותו מספר יציאה. פתרון עקיף: אחרי שמוסיפים את התווית 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	Invalid CRD status.storedVersions for managed CRDs יכול להיות שלחלק מ-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 בדרך כלל, אם אי אפשר לתזמן פוד בגלל מגבלות על צירוף נפח של צומת, מופעל ניהול הקצאות אוטומטי של צומת חדש. כשמריצים עומסי עבודה שמשתמשים במוצר 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 מפעילים הקצאת משאבים אוטומטית בצורות אחרות של מכונות וירטואליות. מומלץ להשתמש בצורה שתומכת רק ב-Hyperdisk של Google Cloud.
פעולה	‫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 נקטע בגלל חריגה מזיכרון בצמתים של TPU/GPU בצמתי TPU ב-GKE (לדוגמה, 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 שנתקעו בגלל סטטוס dangling כדי להסיר את הסטטוס הזה. כדי להסיר את הסטטוס 'תלוי ועומד', אפשר להשתמש בפקודת תיקון כמו זו שבהמשך: 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 ואילך	פודים שמנסים לטעון כרכים קבועים של 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 ואילך	תאי Pod נתקעים בסטטוס Terminating (הפסקת פעולה) באג בזמן הריצה של הקונטיינר (containerd) עלול לגרום לכך שקובצי Pod וקונטיינרים ייתקעו במצב 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 אם הבעיה הזו משפיעה עליכם, אתם יכולים להשבית את הסטרימינג של התמונות.
נטוורקינג,שדרוגים ועדכונים	‫1.28		שגיאה בהגדרת TLS של שער זיהינו בעיה בהגדרת TLS לשערי כניסה באשכולות שמופעלת בהם גרסת GKE‏ 1.28.4-gke.1083000. הבעיה הזו משפיעה על הגדרות TLS שמשתמשות ב-SSLCertificate או ב-CertificateMap. אם משדרגים אשכול עם שערים קיימים, העדכונים שבוצעו בשער ייכשלו. במקרה של שערים חדשים, מאזני העומסים לא יוקצו. הבעיה הזו תיפתר בגרסת תיקון (patch) קרובה של GKE 1.28.
שדרוגים ועדכונים	1.27	גרסה 1.27.8 ואילך	בעיה בפלאגין של מכשיר GPU יכול להיות שיהיו בעיות באשכולות שמופעלים בהם מעבדי GPU ושודרגו מגרסה 1.26 לגרסת תיקון 1.27 מוקדמת יותר מ-1.27.8, בתוספים של מכשירי ה-GPU של הצמתים (nvidia-gpu-device-plugin). צריך לבצע את השלבים הבאים בהתאם למצב האשכול: אם באשכול שלכם פועלת גרסה 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 שהוגדרו בצורה שגויה. הבעיה משפיעה על אשכולות שמריצים גרסאות קודמות של תיקונים בגרסאות 1.27 ו-1.28 של GKE (לדוגמה, 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
רישות, שדרוגים	‫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 או יוצרים אותו באמצעות אחת מהגרסאות הבאות של 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 ואילך	‫GPU Maintenance Handler Pod תקוע במצב CrashLoopBackOff בבעיה הזו, רכיבי ה-Pod של 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 ואילך	הפעלת ה-Pods בצמתים עם הפעלת Image streaming נכשלת יכול להיות שעומסי עבודה בצמתים שבהם מופעלת הזרמת תמונות לא יתחילו לפעול, עם חתימת השגיאה הבאה: 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 כדי לקבל תמיכה נוספת מהקהילה.
  • פתיחת דיווחים על בעיות או בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.