בדף הזה מפורטות בעיות מוכרות ב-GKE. הדף הזה מיועד לאדמינים ולארכיטקטים שמנהלים את מחזור החיים של תשתית הטכנולוגיה הבסיסית, ומגיבים להתראות ולדפים כשלא עומדים ביעדי רמת השירות (SLO) או כשהאפליקציות נכשלות.
בדף הזה מפורטות בעיות מוכרות בכל הגרסאות הנתמכות ובשתי גרסאות המשנה שקודמות לגרסה הכי ישנה בתמיכה מורחבת. אחרי שגרסה מסיימת את תקופת התמיכה המורחבת שלה, כל הבעיות שקשורות לגרסה N-2 מוסרות. לדוגמה, כשגרסה 1.30 מגיעה לסוף התקופה של התמיכה המורחבת, בעיות מוכרות שספציפיות לגרסה 1.28 ולגרסאות קודמות מוסרות.
אם אתם משתתפים ב-Google Developer Program, כדאי לשמור את הדף הזה כדי לקבל התראות כשמתפרסם הערת גרסה שקשורה לדף הזה. מידע נוסף זמין במאמר בנושא דפים שמורים.
כדי לסנן את הבעיות הידועות לפי גרסת מוצר או קטגוריה, בוחרים את המסננים מהתפריטים הנפתחים הבאים.
בוחרים את גרסת GKE:
בוחרים את קטגוריית הבעיה:
אפשר גם לחפש את הבעיה:
| קטגוריה | הגרסאות שזוהו | גרסאות קבועות | הבעיה והפתרון העקיף |
|---|---|---|---|
| שדרוגים ועדכונים |
|
|
בעיות בהפעלה של Pod במהלך שדרוגים ל-GKE 1.35 באשכולות GKE Dataplane V2אשכולות שמשדרגים את מישור הבקרה ל-GKE גרסה 1.35.0-gke.2232000 ואילך מגרסאות
anetd DaemonSet.
עומסי עבודה חדשים לא יופעלו במהלך ההשקה של
הסיבה לכך היא ש-GKE משתמש במצב identity-management-mode של Operator, שבו כל הסוכנים וה-Operator צריכים להציג תצוגה מסונכרנת של תוויות שרלוונטיות לזהות. החל מ-GKE 1.35.0-gke.2232000, התוויות פתרון עקיף:
|
| שדרוגים ועדכונים |
|
|
עיכובים בתזמון של פודים בצמתים חדשים עם מדיניות רשת Calico מופעלת
באשכולות GKE שבהם מופעלת מדיניות רשת Calico, רגרסיה
בגרסאות המושפעות עלולה לגרום לעיכובים משמעותיים בתזמון של Pod בצמתים חדשים או בצמתים שנוצרו מחדש.
העיכובים האלה יכולים לגרום לכך שהצמתים יישארו במצב הבעיה נגרמת בגלל שסקריפט לטעינה בזמן ההפעלה של Calico CNI מעצב באופן שגוי את כתובת ה-URL של שרת Kubernetes API עבור כתובות IPv4, על ידי הוספת סוגריים מרובעים ([]) מסביב לכתובת. הגישה הזו מובילה לשגיאת ניתוח של כתובת URL כשיוצרים ארגזי חול חדשים של Pod, שמופיעה ביומני kubelet:
פתרון עקיף: גרסת רכיב Calico נקבעת לפי גרסת מישור הבקרה של האשכול. כדי לפתור את הבעיה, צריך לשדרג את רמת הבקרה של האשכול לאחת מהגרסאות המתוקנות. אחרי שמשדרגים את מישור הבקרה, צריך ליצור מחדש את הצמתים במאגרי הצמתים כדי לוודא שהם משתמשים בפורמט הנכון של כתובת השרת של Kubernetes API. כדי לעשות את זה, אפשר לבצע שדרוג במקום של מאגר הצמתים לאותה גרסה או לגרסה חדשה יותר, או ליצור מחדש את מאגרי הצמתים באופן ידני. |
| ביצועים |
|
|
הביצועים של רשתות לשימוש כללי יורדים בסדרת 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 לא מושפעים. השגיאה הזו מתרחשת כי הסקריפט ברמת הצומת ( פתרון עקיף: משדרגים כל מאגר צמתים שהושפע לגרסה קבועה. |
| ביצועים |
|
|
הביצועים של GPUDirect-TCPX יורדים ב-A3 Highבאשכולות GKE עם צמתים מסוג A3 High ( השגיאה הזו מתרחשת כי הסקריפט ברמת הצומת ( פתרון עקיף: במאגרי צמתים של 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, יכול להיות שיהיה גידול במספר המשאבים המותאמים אישית גם באשכולות אזוריים וגם באשכולות אזוריים, תזמון של עומס עבודה חדש עלול לגרום לשכפול זמני של זהות Cilium. הכפילות הזו מתרחשת כי ל-Pods יש זהות אחת בזמן היצירה על סמך תוויות ראשוניות, ועוד זהות אחרי שמוסיפים תוויות טופולוגיה כשה-Pod מתוזמן לצומת. באשכולות אזוריים, מספר הזהויות עשוי לגדול גם בפקטור שפרופורציונלי למספר האזורים שהאשכול משתרע עליהם. השפעה: אם המספר הכולל של הזהויות עולה על 65,535, יכול להיות שלא תהיה אפשרות לתזמן עומסי עבודה חדשים. פתרון עקיף: כדי להגביל את המספר הכולל של הזהויות, אל תוסיפו ל-Pods תוויות עם מספר גדול של ערכים ייחודיים. מידע נוסף זמין במאמרי העזרה הבאים של Cilium: צריך לבצע שדרוגים ידניים מגרסאות 1.34.3-gke.1208000 ואילך. אם תתחילו את השדרוג מגרסה מוקדמת יותר מ-1.34.3-gke.1208000, יכול להיות שתיתקלו בבעיות זמניות בתזמון של Pod במהלך תהליך השדרוג. |
| שדרוגים | 1.34 ואילך | TBD |
GPUDirect-TCPX לא זמין ב-A3 High ל-GKE מגרסה 1.34 ואילךבאשכולות GKE עם צמתים מסוג A3 High ( סוגי מכונות אחרים של GPU מסוג A3 High ( כדי למנוע בעיות, GKE חוסם את התרחישים הבאים:
פתרון עקיף: בשלב הזה לא צריך לעשות כלום. מערכת GKE מונעת באופן אוטומטי יצירה של מאגרי צמתים עם צמתי A3 High ( |
| פעולה | כל הגרסאות לפני 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, יצירת המופע נכשלת עם שגיאת פתרון עקיף: משדרגים את אשכול GKE לגרסה 1.33.4-gke.1036000 ואילך. אם אתם משתמשים בערוץ היציב, יכול להיות שגרסה חדשה יותר עדיין לא זמינה. במקרה כזה, אפשר לבחור באופן ידני גרסה מהערוצים הרגילים או מהערוצים המהירים שכוללת את התיקון. |
| פעולה |
|
1.33.3-gke.1266000 ואילך |
שגיאת קלט/פלט כשמשנים את השם של קבצים או מעבירים אותם באמצעות מנהל התקן ה-CSI של Cloud Storage FUSEכשמשתמשים בגרסה מושפעת של מנהל התקן ה-CSI של Cloud Storage FUSE, יכול להיות ששינוי שם של קבצים או העברה של קבצים בקטגוריות של Cloud Storage ייכשלו עם שגיאת קלט/פלט. פתרון עקיף: מוסיפים באופן זמני הגדרה ספציפית של תמונת sidecar למניפסט של ה-Pod. בקטע # 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 או לגרסה חדשה יותר, צריך להסיר את כל הבלוק |
| רישום ביומן ומעקב | כל הגרסאות | TBD |
מרוץ תהליכים ב-
|
| שדרוגים | 1.33 | 1.33.2-gke.1043000 |
הגבלת מספר הקבצים הפתוחים ב-containerd 2.0במאגרי צמתים שמופעלת בהם גרסה 1.33 של GKE, שמשתמשת ב-containerd 2.0, המגבלה הרכה שמוגדרת כברירת מחדל לקבצים פתוחים ( זהו שינוי ב-containerd עצמו (ראו containerd PR #8924) שבו עומסי עבודה שמצפים למגבלת ברירת מחדל גבוהה יותר (לדוגמה, עומסי עבודה שמסתמכים באופן מרומז על ברירת המחדל הקודמת והגבוהה יותר) עלולים להיכשל, למשל עם שגיאות פתרון: שדרוג מגרסת תיקון קודמת של 1.33 לגרסה 1.33.2-gke.1043000 ואילך. פתרון עקיף: כדי להגדיל את מכסת הקבצים הפתוחים לעומסי העבודה, אפשר להשתמש באחת מהשיטות הבאות:
|
| שדרוגים | 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 יש שדה הבעיה הזו משפיעה על אשכולות שעומדים בשני התנאים הבאים:
פתרון עקיף: הפתרון המומלץ הוא לדחות את השדרוגים של האשכולות עד שהבעיה תיפתר. לחלופין, אם אתם יודעים שהאשכול שלכם מכיל גרסאות לא נתמכות של אובייקטים מסוג CRD, אתם יכולים להוסיף את הגרסאות האלה לשדה |
| פעולה, רישום ביומן ומעקב | 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000 |
|
מדדים חסרים או שהמידרוג האוטומטי של עומס העבודה לא פועליכול להיות שתראו פערים בנתוני המדדים בגרסאות המושפעות אחרי שגודל האשכול גדל ביותר מחמישה צמתים. הבעיה הזו עשויה להשפיע גם על פעולות של התאמה אוטומטית לעומס. הבעיה הזו משפיעה רק על אשכולות ששודרגו לגרסאות המושפעות. אשכולות חדשים שנוצרו אמורים לפעול כצפוי. פתרון עקיף: אם אתם מושפעים מהבעיה, אתם יכולים לשנמך גרסה אחת של תיקון או לשדרג לגרסאות החדשות המתוקנות. |
| פעולה |
מגבלות הגודל והקבצים המצורפים של 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. פתרון עקיף: מוצרי Hyperdisk מפעילים הקצאת משאבים אוטומטית בצורות אחרות של מכונות וירטואליות. מומלץ להשתמש בצורה שתומכת רק ב-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 נקטע בגלל חריגה מזיכרון בצמתים של TPU/GPUבצמתי TPU של GKE (לדוגמה, פתרון עקיף: אם אתם רואים אירועים של |
|
| פעולה |
|
|
יכול להיות ששינוי הגודל של נפח אחסון נתקע בגלל סטטוס NodePendingResize תלוי ב-PVC.בגרסה 1.32, אשכולות עם צמתים בגרסה 1.31 או בגרסאות קודמות לא יצליחו לעדכן את הסטטוס של PersistentVolumeClaim במהלך שינוי הגודל. הסטטוס השגוי הזה מונע את תחילתן של פעולות שינוי גודל עוקבות, ולמעשה מונע שינויי גודל נוספים. ל-PVC במצב הזה יש שדה אם נוצר PVC בזמן שהאשכול היה בגרסה מושפעת, יכול להיות שהבעיה הזו תימשך גם אחרי שהאשכול ישודרג לגרסה ידועה שבה הבעיה תוקנה. בתרחיש הזה, צריך להחיל תיקון על ה-PVC כדי להסיר את השדה פתרון עקיף: אפשר לתקן 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}}' |
| פעולה |
|
|
יכול להיות שהנתונים של מנהל ההתקן של 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")
|
| תפעול |
|
|
פודים שמנסים לטעון כרכים קבועים של NFS בצמתי COS שבעבר הייתה להם טעינה לקריאה בלבד (RO), ייטענו רק במצב ROב-GKE בגרסה 1.27 ואילך, אפשר לטעון נפחי NFS באמצעות מנהל התקן ה-CSI של Kubernetes בתוך העץ רק נפחים מתמידים במצב RO אחרי טעינת RO קודמת באותו הצומת. פתרון עקיף: שדרוג לאחור של מאגרי הצמתים לגרסה שקדמה לגרסאות המושפעות |
| תפעול |
|
|
פודים שמנסים לטעון כרכים קבועים של 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" פתרון עקיף: שדרוג לאחור של מאגרי צמתים לגרסה 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 |
|
יכול להיות שפודים שמשתמשים בקריאות מערכת שקשורות ל-io_uring ייתקעו במצב Terminating
יכול להיות שפודים שמשתמשים בקריאות מערכת שקשורות ל-io_uring ייכנסו למצב D (המתנה לדיסק), שנקרא גם TASK_UNINTERRUPTIBLE, בגלל באג בליבת לינוקס. אי אפשר להעיר תהליכים במצב D באמצעות אותות, כולל
כש-Pod מושפע מהבעיה הידועה הזו, יכול להיות שהקונטיינרים שלו לא יסיימו את הפעולה בצורה תקינה. בלוגים של containerd, יכול להיות שתראו הודעות חוזרות שדומות להודעה הבאה:
או
הסימפטומים האלה מצביעים על תהליכים בתוך הקונטיינר שנתקעו במצב שינה שלא ניתן להפריע לו (מצב D), ולכן לא ניתן לסיים את הפוד בצורה תקינה.
עומסי עבודה שמשתמשים ב-io_uring באופן ישיר, או שמשתמשים ב-io_uring באופן עקיף דרך זמן ריצה של שפה כמו NodeJS, עשויים להיות מושפעים מהבעיה הידועה הזו. עומסי העבודה המושפעים כוללים תהליך במצב D (שינה בדיסק) בקובץ פתרון עקיף: משדרגים את צמתי האשכול לגרסה מתוקנת או לגרסה חדשה יותר. |
| פעולה | 1.28, 1.29, 1.30, 1.31 |
|
עומסי עבודה שמשתמשים בסטרימינג של תמונות נכשלים עם שגיאות אימותבאג בתכונה Image streaming עלול לגרום לכשלי עומסי עבודה אם מתקיימים תנאים ספציפיים בזמן שהקונטיינר קורא קבצים. יכול להיות שיופיעו הודעות שגיאה שקשורות לכשלים באימות ביומן של gcfsd.
כדי לבדוק אם אתם מושפעים מהבעיה, מחפשים ביומנים באמצעות שאילתת החיפוש הבאה:
אם השגיאות האלה מופיעות, סימן שהצמתים מושפעים. אם הבעיה הזו משפיעה עליכם, אתם יכולים לשדרג את מאגרי הצמתים לגרסה מתוקנת של GKE. |
| פעולה |
|
|
שיעורי הוצאת ה-Pods משימוש בגרסאות GKE 1.30 ו-1.31 עלו
בגרסאות מסוימות של GKE 1.30 ו-GKE 1.31 שמשתמשות ב-COS 113 וב-COS 117 בהתאמה, יש ליבות שנבנו עם האפשרות
אפשרות ההגדרה יכול להיות שלא תמיד תראו שיעור חריג של הוצאת Pods כי הבעיה הזו תלויה בדפוס השימוש בזיכרון של עומס העבודה. קיים סיכון גבוה יותר ש-kubelet יסלק את ה-Pods עבור עומסי עבודה שלא הוגדרה להם מגבלת זיכרון בשדה המשאבים. הסיבה לכך היא שעומסי העבודה עשויים לבקש יותר זיכרון ממה ש-kubelet מדווח כזמין. אם אתם רואים שימוש גבוה יותר בזיכרון של אפליקציה אחרי שמשדרגים לגרסאות GKE שצוינו בלי לבצע שינויים אחרים, יכול להיות שאתם מושפעים מאפשרות הליבה.
כדי לבדוק אם יש שיעורי פינוי חריגים של Pod, מנתחים את המדדים הבאים באמצעות Metrics Explorer:
אפשר להשתמש בשאילתות PromQL הבאות. מחליפים את הערכים של
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.
אחרי ש-DaemonSet פועל בכל מאגרי הצמתים שנבחרו, השינוי נכנס לתוקף באופן מיידי וחישוב השימוש בזיכרון של kubelet חוזר למצב תקין. |
| פעולה | 1.28, 1.29, 1.30, 1.31 |
|
הפודים תקועים בסטטוס Terminating (בהמתנה לסיום)באג בזמן הריצה של מארח הקונטיינרים (containerd) עלול לגרום לכך שקובצי Pod וקונטיינרים ייתקעו במצב Terminating (סיום) עם שגיאות דומות לאלה: OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown
אם הבעיה הזו משפיעה עליכם, אתם יכולים לשדרג את הצמתים לגרסת GKE עם גרסה קבועה של containerd. |
| פעולה | 1.28,1.29 |
|
הסטרימינג של התמונה נכשל בגלל קישורים סמלייםבאג בתכונה 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.27, 1.28, 1.29 |
|
הזרמת התמונות נכשלת בגלל קבצים חסריםבאג בתכונה 'הזרמת תמונות' עלול לגרום לכשלים במאגרי תמונות בגלל קובץ או קבצים חסרים. יכול להיות שקונטיינרים שפועלים בצומת עם Image streaming מופעל בגרסאות הבאות לא יתחילו לפעול או יפעלו עם שגיאות שמציינות שקבצים מסוימים לא קיימים. דוגמאות לשגיאות כאלה:
אם הבעיה הזו משפיעה עליכם, אתם יכולים להשבית את הסטרימינג של התמונות. |
| נטוורקינג,שדרוגים ועדכונים | 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 של הצמתים (
|
| פעולה | 1.27,1.28 |
|
התאמה אוטומטית לעומס העבודה לכל עומסי העבודה נפסקת
יכול להיות שהתכונות HorizontalPodAutoscaler (HPA) ו-VerticalPodAutoscaler (VPA) יפסיקו את ההתאמה האוטומטית לעומס של כל עומסי העבודה באשכול אם הוא מכיל פתרון עקיף:
כדי לתקן אובייקטים של
מידע נוסף על הגדרת אובייקטים של |
| פעולה | 1.28,1.29 |
|
פריסת התכונה 'זיהוי איומים בקונטיינר' נכשלתיכול להיות שפריסת הכלי זיהוי איומים בקונטיינר תיכשל באשכולות Autopilot שפועלות בהם גרסאות GKE הבאות:
|
| נטוורקינג, שדרוגים | 1.27, 1.28, 1.29, 1.30 |
|
בעיות בקישוריות של
|
| Networking | 1.31, 1.32 |
|
תעבורת UDP שבורה בין Pods שפועלים באותו צומתבאשכולות שבהם הופעלה חשיפה בתוך הצומת, יכול להיות שתהיה תנועת UDP שבורה בין Pods שפועלים באותו צומת. הבעיה מתרחשת כשמשדרגים את הצומת של אשכול GKE לגרסה אחת מהגרסאות הבאות של GKE, או כשיוצרים אותו עם אחת מהגרסאות האלה:
הנתיב המושפע הוא תעבורת UDP מ-Pod ל-Pod באותו צומת דרך Hostport או Service. הפתרון משדרגים את האשכול לאחת מהגרסאות המתוקנות הבאות:
|
| פעולה | 1.29,1.30,1.31 |
|
אי התאמה בין Ray Operator לבין הצפנת מסד נתונים ב-Cloud KMSחלק מהגרסאות של Ray Operator לא תואמות להצפנת מסד נתונים ב-Cloud KMS. פתרונות אפשריים: משדרגים את מישור הבקרה של האשכול לגרסה מתוקנת או לגרסה חדשה יותר. |
| שדרוגים ועדכונים | 1.30, 1.31 |
|
GPU Maintenance Handler Pod תקוע במצב 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 ואילך |
הפעלת הפודים נכשלת בצמתים שבהם מופעלת הזרמת תמונות
יכול להיות שעומסי עבודה לא יופעלו בצמתים שבהם מופעלת הזרמת תמונות
עם חתימת השגיאה הבאה:
היומן של היציאה הטורית של צומת מושפע מכיל גם את חתימת השגיאה הבאה:
הנוכחות של שני חתימות השגיאה האלה מצביעה על מצב של קיפאון באחד מרכיבי הסטרימינג של התמונות. הקיפאון הזה מונע הפעלה תקינה של ה-Pods. השבתה זמנית של אותות אכיפה: כדי לצמצם את הסיכון במהירות, מפעילים מחדש את הצומת. הערה: יכול להיות שהצומת שהופעל מחדש ייתקל שוב בקיפאון. כדי להקטין את הסיכון, כדאי להשבית את הזרמת התמונות במאגר הצמתים באמצעות הפקודה הבאה: gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming |
| פעולה |
|
|
Custom ComputeClasses עם
|
המאמרים הבאים
אם לא מצאתם פתרון לבעיה שלכם במסמכים, תוכלו להיעזר בקבלת תמיכה, כולל עצות בנושאים הבאים:
- פתיחת בקשת תמיכה באמצעות פנייה אל Cloud Customer Care.
- קבלת תמיכה מהקהילה על ידי פרסום שאלות ב-StackOverflow ושימוש בתג
google-kubernetes-engineכדי לחפש בעיות דומות. אפשר גם להצטרף לערוץ Slack#kubernetes-engineכדי לקבל תמיכה נוספת מהקהילה. - פתיחת באגים או בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.