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

Autopilot Standard

בדף הזה מפורטות בעיות מוכרות ב-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.36.0-gke.0 עד ‎1.36.4-gke.2377000	‫1.36.5-gke.1259000 ואילך	‫tpu-device-plugin Pods exit with OOMKilled on large TPU clusters באשכולות גדולים של GKE TPU, כמו אשכולות עם יותר מ-1,000 צומתי TPU או עומסי עבודה בכמה פרוסות, יכול להיות שהקונטיינרים ב-DaemonSet של kube-system/tpu-device-plugin (כולל tpu-device-plugin ו-vbar-control-agent) ייסגרו עם סטטוס OOMKilled (קוד יציאה 137) כשהשימוש בזיכרון חורג ממגבלות ברירת המחדל של הזיכרון בקונטיינר 80Mi או 150Mi במהלך פרצי קבלה של Pod ואיסוף מדדים בזמן הריצה. אם tpu-device-plugin מופעל מחדש במהלך תזמון Pod, יכול להיות שהקבלה של Pods חדשים של עומסי עבודה ב-TPU תיכשל ותופיע השגיאה הבאה: UnexpectedAdmissionError: Allocate failed due to rpc error פתרון עקיף: משדרגים את מישור הבקרה של אשכול GKE לגרסה 1.36.5-gke.1259000 ואילך, שמגדילה את מגבלות ברירת המחדל של הזיכרון למאגרי DaemonSet של tpu-device-plugin. אם אתם לא יכולים לשדרג מיד, פנו לשירות הלקוחות של Cloud כדי לקבל פתרון זמני לשינוי הגודל של Pod במקום, שמגדיל את מגבלות הזיכרון של הקונטיינר בלי להפעיל מחדש את עומסי העבודה הפעילים של ה-TPU.
פעולה	‫1.37.1-gke.1380000 וגרסאות מאוחרות יותר שקודמות ל-1.37.1-gke.2432000	‫1.37.1-gke.2432000 ואילך	פודים נשארים במצב Pending כש-ComputeClass מובנה של Autopilot מוגדר כברירת המחדל ברמת האשכול אם מגדירים ComputeClass מובנה של Autopilot (כמו autopilot או autopilot-spot) כברירת המחדל ברמת האשכול באמצעות הדגל --default-compute-class, ‏GKE יוצר ComputeClass מסוג default כשהשדה whenUnsatisfiable: מוגדר ל-DoNotScaleUp. פודים שלא נבחר להם ComputeClass וצריכים צמתים שפלטפורמת Autopilot לשימוש כללי לא יכולה ליצור, עשויים להישאר במצב Pending כשצריך צומת חדש. לדוגמה, הבעיה הזו משפיעה על Pods שמבקשים GPUs או TPUs, שבוחרים משפחת מכונות ספציפית באמצעות בורר הצמתים cloud.google.com/machine-family, או שדורשים VM במודל Spot כשהמחלקה שמוגדרת כברירת מחדל משתמשת במכונות וירטואליות על פי דרישה. פודים שמתאימים לצמתים קיימים לא מושפעים. כשמישור הבקרה משודרג לגרסה ‎1.37.1-gke.2432000 ואילך, GKE מעדכן את ComputeClass‏ default על ידי הגדרת השדה whenUnsatisfiable לערך ScaleUpAnyway, והבעיה נפתרת בלי פעולה נוספת. פתרון עקיף: אפשר לבחור באחת מהאפשרויות הבאות: בוחרים ComputeClass באופן מפורש בעומסי העבודה המושפעים, או מגדירים ComputeClass כברירת מחדל ברמת מרחב השמות למרחבי השמות שלהם. לשדרג את מישור הבקרה של האשכול לגרסה ‎1.37.1-gke.2432000‎ או לגרסה חדשה יותר.
שדרוגים ועדכונים	‫1.36.3-gke.1767000 ואילך		עומסי העבודה של Agent Sandbox נכשלים אחרי שדרוג האשכול התוסף Agent Sandbox (agentsandbox) קידם את הגדרות המשאבים בהתאמה אישית ואת ה-API מ-v1alpha1 ל-v1beta1 החל מגרסה 1.36.3-gke.1767000 של GKE. אם משדרגים אשכול שפועל בו Agent Sandbox מגרסה שקודמת ל-‎1.36.3-gke.1767000 בלי להעביר את המשאבים בהתאמה אישית, עומסי העבודה הקיימים של v1alpha1 לא פועלים כמו שצריך. פתרון עקיף: לפני שמשדרגים את מישור הבקרה של האשכול לגרסה ‎1.36.3-gke.1767000 או לגרסה חדשה יותר, צריך להעביר את המניפסטים ועומסי העבודה של Agent Sandbox מ-v1alpha1 ל-v1beta1 לפי המדריך להעברת נתונים (מיגרציה) של Agent Sandbox API.
פעולה	1.35 1.36 1.37	‫1.35.6-gke.1250001 ואילך ‫1.36.4-gke.1391002 ואילך ‫1.37.1-gke.1187000 ואילך	בקשות 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 Gateway שולחים בקשת HTTP POST בלי שרשרת אישורים תקינה בגוף הבקשה. בגרסאות GKE המושפעות, בקשות POST לנקודות הקצה האלה של הטוקנים שמורות אך ורק לטוקנים של גישה ולטוקנים של מזהה מקושרים. כתוצאה מכך, בקשות עם JSON ריק, מקודד בטופס או לא חוקי במטען הייעודי (payload) נדחות. כדי לפתור את הבעיה, שדרגו לגרסה האחרונה עם התיקון בגרסה המשנית של כל ערוץ הפצה. פתרון עקיף: כדי לפתור את הבעיה, צריך להגדיר את האפליקציה, את ספריית הלקוח או את API Gateway כך שישתמשו ב-method‏ 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.33 ואילך	TBD	פודים שלא תזמנו ומכסות שנוצלו במהלך שדרוגים קלים בשני שלבים של מישור הבקרה. במהלך שדרוגים של שתי גרסאות משניות למישורי בקרה באשכולות Autopilot שמשתמשים בפודים עם משך זמן מורחב, יכול להיות שמאגרי צמתים חדשים יוקצו באמצעות גרסת הצומת הקודמת. הכלי Cluster Autoscaler בודק את הצמתים החדשים שהוקצו מול הגרסה המשודרגת של מישור הבקרה, מזהה חוסר התאמה בגרסאות ומחיל את ה-taint‏ cloud.google.com/not-target-gke-version:true. ‫Cluster Autoscaler גם חוסם את האפשרות להגדיל את מאגרי הצמתים הקיימים או החדשים של Pods עם משך זמן מורחב שמשתמשים בגרסה הקודמת של הצומת. ההתנהגות הזו מונעת תזמון של Pods ומפעילה לולאת התאמה אינסופית. במקום להגדיל את מאגר הצמתים הקיים, הקצאת צמתים אוטומטית יוצרת מאגר חדש של צומת יחיד בכל איטרציה של הגדלה, כדי להתאים לעומסי העבודה הממתינים. הלולאה הזו יוצרת מאות מאגרים נפרדים של צמתים ריקים, שבסופו של דבר יכולים למצות את המכסות של קבוצות מופעי המכונה המנוהלים באזור. פתרון עקיף: כדי לפתור את הבעיה של לולאת ההתאמה לעומס, צריך להשלים ידנית את השדרוג של מישור הבקרה באמצעות הפקודה הבאה: gcloud container clusters complete-control-plane-upgrade [CLUSTER_NAME] --location=[LOCATION] אפשר גם להחיל את ה-toleration הבא על עומסי העבודה המושפעים, כדי שאפשר יהיה לתזמן אותם בצמתים של הגרסה הקודמת: tolerations: - key: "cloud.google.com/not-target-gke-version" operator: "Equal" value: "true" effect: "NoSchedule"
פעולה	‫1.37.0-gke.2941000 ואילך	1.37.1-gke.1131000	צמתים שמתקינים אמצעי אחסון של NFS צוברים רשומות התקנה ומפסיקים ליצור קונטיינרים בצמתים שבהם פועלות הגרסאות המושפעות, טעינה של נפח NFS משאירה רשומות נוספות בטבלת הטעינה של הצומת. בנוסף, כש-Pod שמשתמש בנפח NFS מסתיים, ניסיונות הניתוק נכשלים, וגורמים ל-kubelet לנסות שוב ושוב לבצע את הניתוק. כל ניסיון חוזר מוסיף עוד רשומות לטבלת הטעינה, וכך הטבלה גדלה כל הזמן גם כשלא מתוזמנים עומסי עבודה חדשים. כשטבלת ה-mount מגיעה למגבלת הליבה, סביבת זמן הריצה של הקונטיינר לא יכולה יותר ליצור קונטיינרים בצומת הזה. הצומת מפסיק להריץ Pods חדשים, יכול להיות שהוא ידווח על סטטוס NotReady ויכול להיות שהוא יופעל מחדש שוב ושוב. יכול להיות ש-Pods שמשתמשים בנפחי 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 לא מושפעים. פתרון עקיף: כדי לשחזר צומת שהושפע, צריך להפעיל אותו מחדש או ליצור אותו מחדש. רשומות הטעינה הנוספות קיימות רק במצב ההפעלה של הצומת, ולכן הן נמחקות כשהצומת מופעל מחדש. אפשר להסיר Pods שנתקעו במצב Terminating אחרי ההפעלה מחדש באמצעות הפקודה הבאה: kubectl delete pod POD_NAME --namespace NAMESPACE --force --grace-period=0 כדי למנוע את הישנות הבעיה באשכולות Standard, שדרגו לאחור לגרסה 1.36 את מאגרי הצמתים שבהם מותקנים אמצעי אחסון של NFS. מגדירים החרגה מתחזוקה כדי ש-GKE לא ישדרג באופן אוטומטי את מאגרי הצמתים בחזרה לגרסה המושפעת. אם באשכול Autopilot פועלת גרסה שמושפעת מהבעיה, צריך להשתמש באחת מהאפשרויות הבאות: אם נפחי ה-NFS שלכם מגובים על ידי Filestore, צריך לטעון אותם באמצעות מנהל ההתקן של Filestore CSI במקום מנהל ההתקן של 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 ב-GKE‏ (a4x-maxgpu-4g-metal) לגרסאות תיקון ספציפיות (ראו את העמודה גרסאות שזוהו) גורמים לכשלים בעומסי העבודה של ה-GPU עם שבבי NVIDIA GB300 Grace Blackwell Ultra Superchips המצורפים. בגלל זמני טעינה ארוכים של זיכרון ברוחב פס גבוה (HBM) בחומרת GB300 עם סוג המכונה הזה ללא מערכת הפעלה, שירות ההפעלה של nvidia-persistenced נכשל בגלל זמן קצוב לתפוגה. בגלל הזמן הקצוב לתפוגה, ה-GPU לא מאותחלים, ומופיעה הודעת השגיאה cudaErrorDeviceUnavailable(46) כש-Pods מנסים לתבוע משאבי CUDA. הפתרון: לשדרג כל אשכול ומאגר צמתים שהושפעו לגרסה מתוקנת. ‫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. כשהמכונה הווירטואלית מופעלת מחדש, יכול להיות שבקר התחזוקה של GKE יחיל מחדש את ה-taints האלה לפני הזמן אם מתוזמן אירוע תחזוקה עתידי נוסף לצומת, וכך ימנע תזמון של עומסי עבודה חדשים בצמתים תקינים. פתרון עקיף: כדי לפתור את הבעיה, צריך להסיר באופן ידני את התוויות של התחזוקה הפעילה שמנוהלת על ידי GKE ואת ה-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), ה-webhook לאישור של tpu-accelerator-topology-constraints דוחה את הקצאת המשאבים עם השגיאה הבאה: "Invalid resource requests for google.com/tpu. הערך צריך להיות שווה לאחד מ-[4] עבור מאיץ tpu7x וטופולוגיה 2x2x1". פתרון עקיף: כדי לפתור את הבעיה, צריך לשדרג את אשכול GKE לגרסה 1.34.1-gke.1829001 ואילך.
פעולה	‫‎1.35.3-gke.1234000 ואילך	TBD	לקוח Lustre לא משתמש בכרטיסי רשת משניים בצמתים עם כמה כרטיסי רשת בצומתי GKE עם כמה כרטיסי רשת (NIC), מנהל ההתקן של Managed Lustre CSI מופעל כברירת מחדל כדי להשתמש בכל כרטיסי הרשת הזמינים לצבירת רוחב פס על ידי פיזור תנועת האחסון של TCP בין ממשקי הרשת. עם זאת, בגלל בעיה ידועה, יכול להיות שלקוחות Lustre מגרסה 2.14.0_p249 ואילך לא ישתמשו בכרטיסי רשת משניים. במקום זאת, כל תעבורת הנתונים של האחסון ב-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 ואילך	ה-shim של gVisor לא מצליח לנקות, ומתעד את השגיאה "runsc: executable file not found in $PATH" בכל יציאה מ-Pod של gVisor או סגירה בגלל OOM, ‏ containerd מנסה להרוס את ארגז החול. עם זאת, לפעמים תהליך הניקוי נכשל, ומתועדת השגיאה exec: "runsc": executable file not found in $PATH. השגיאה הזו יכולה לגרום לבעיות כמו ניצול יתר של משאבים, פגיעה בביצועי הרשת, קריסה של NodeLocalDNS, זמן קצוב לתפוגה של DNS או זמן אחזור ארוך ביצירת Pods. הפתרון: לשדרג את צומתי GKE לגרסה 1.35.1 ואילך. באשכולות רגילים, משדרגים את מאגר הצמתים עם הצמתים שהושפעו. באשכולות Autopilot, משדרגים ידנית את אשכול Autopilot לגרסה 1.35.1 ואילך, ו-GKE משדרג אוטומטית את הצמתים כך שיתאימו לגרסה של מישור הבקרה בהקדם האפשרי. פתרון עקיף: אם אתם לא יכולים לשדרג את האשכול, אתם יכולים לבצע אחת מהפעולות הבאות: בודקים ומגדילים את בקשות הזיכרון והמגבלות של הפודים של 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 תהיה תצוגה מסונכרנת של תוויות שרלוונטיות לזהות. החל מגרסה 1.35.0-gke.2232000 של GKE, תוויות 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 של שרת ה-API של Kubernetes לכתובות 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 של שרת ה-API של Kubernetes. כדי לעשות את זה, אתם יכולים לשדרג את מאגר הצמתים לאותה גרסה או לגרסה חדשה יותר, או ליצור מחדש באופן ידני את מאגרי הצמתים.
ביצועים	‫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	ירידה בביצועים של רשתות למטרות כלליות בסוגי מכונות עם GPU מסדרת A ו-G4 באשכולות 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 ואילך. למאגרי צמתים של 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 ל-Pods ב-Kubernetes 1.35, מה שיוצר זהויות Cilium נוספות לכל אזור שבו מתוזמן Pod מעומס עבודה. גם באשכולות אזוריים וגם באשכולות של אזורים, תזמון של עומס עבודה חדש יכול לגרום לשכפול זמני של זהות Cilium. הכפילות הזו מתרחשת כי Pods מקבלים זהות אחת בזמן היצירה על סמך תוויות ראשוניות, וזהות אחרת אחרי שמוסיפים תוויות טופולוגיה כשה-Pod מתוזמן לצומת. באשכולות אזוריים, מספר הזהויות עשוי לגדול גם בפקטור שפרופורציונלי למספר האזורים שהאשכול משתרע עליהם. השפעה: אם המספר הכולל של הזהויות חורג מ-65,535, יכול להיות שלא תצליחו לתזמן עומסי עבודה חדשים. פתרון עקיף: כדי להגביל את המספר הכולל של הזהויות, אל תוסיפו לפודים תוויות עם מספר גדול של ערכים ייחודיים. למידע נוסף, קראו את המאמרים הבאים של 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. גרסאות ההתקנה וה-sidecar ממופות ביחס של אחד לאחד וצריכות להתאים. לדוגמה, גרסה 3.1.12 של תוכנת ההתקנה של GPUDirect-TCPX תואמת לגרסה 2.0.15 של ה-sidecar. למידע נוסף על גרסאות של מנהל ההתקנה ו-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 המעודכנת, שמשמשת את מערכת ההפעלה שמותאמת לקונטיינרים מאבן דרך 125 ואילך. גרסה 1.34 של GKE משתמשת באבן דרך 125. סוגי מכונות אחרים של GPU מסוג A3 High‏ (a3-highgpu-1g,‏ a3-highgpu-2g,‏ a3-highgpu-4g) וסדרות מכונות אחרות של GPU לא מושפעים כי הם לא תומכים ב-GPUDirect-TCPX. הפתרון: כדי לפתור את הבעיה, צריך לשדרג לגרסאות התיקון של GKE. לפרטים על הגדרה ושדרוג של מאגרי צמתים באמצעות GPUDirect-TCPX, קראו את המאמרים הגדלת רוחב הפס של רשת ה-GPU באשכולות Standard או הגדלת רוחב הפס של רשת ה-GPU באשכולות Autopilot. כשמריצים בדיקות NCCL בגרסאות קבועות, יכול להיות שיופיעו האזהרות הבאות, שלא משפיעות על הביצועים או על הפונקציונליות: ‫NCCL WARN logs for 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. פתרון עקיף: כדי ליצור מכונות של 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 מידע נוסף זמין במניפסט של Pod בקטע הגדרת קובץ אימג' פרטי לקונטיינר המשני (sidecar). אחרי שמשדרגים את האשכול לגרסה קבועה של GKE או לגרסה מאוחרת יותר, צריך להסיר את כל הבלוק gke-gcsfuse-sidecar מהמניפסט. אחרי הסרת החסימה, GKE ימשיך להוסיף ולנהל באופן אוטומטי את קובץ האימג' הנכון של ה-sidecar לגרסת האשכול המשודרגת.
רישום ביומן ומעקב	כל הגרסאות	TBD	מרוץ תהליכים ב-DaemonSets של gke-metrics-agent כשמוסיפים את התווית cloud.google.com/gke-metrics-agent-scaling-level למאגר צמתים כדי להגדיל ידנית את הקצאת הזיכרון של DaemonSet gke-metrics-agent, מתרחש מרוץ תהליכים ב-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) בקונטיינרים יורדת ל-1,024. זהו שינוי ב-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: משתמשים בפלאגין 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 status.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 שלא ניתן לתזמן בגלל מגבלות של צירוף נפח של צומת מפעיל הקצאת משאבים אוטומטית של צומת חדש. כשעומסי עבודה שמשתמשים בנפח Hyperdisk מתוזמנים לצומת שמריץ VM מסוג C3 או C3D, לא מתבצעת הקצאת צמתים אוטומטית וה-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 ו-C3D, כי מנהל ההתקן של Compute Engine Persistent Disk CSI מדווח למתזמן של Kubernetes על מגבלת החיבור של 127 דיסקים מתמידים, במקום על מגבלת החיבור הנמוכה יותר של Hyperdisk לכל סוג. מגבלות הצירוף של Hyperdisk משתנות בהתאם למספר ה-vCPU של ה-VM ולמוצר Hyperdisk. מידע נוסף זמין במאמר מגבלות הביצועים של Hyperdisk. פתרון עקיף: אפשר להשתמש באחד מהפתרונות הבאים: משתמשים בסדרת מכונות שתומכת רק ב-Hyperdisk, כמו C4 או C4D. במאגרי צמתים רגילים, אפשר לשנות את מגבלת הקבצים המצורפים שפורסמה לצומת על ידי החלת תווית הצומת node-restriction.kubernetes.io/gke-volume-attach-limit-override. הוראות מפורטות זמינות במאמר שינוי מגבלות הצירוף של נפחי אחסון קבועים. כדי להשתמש ב-הקצאת צמתים אוטומטית (NAP), צריך להגדיר צומתי C3D עם לפחות 60 מעבדי vCPU (או צומתי C3 עם לפחות 22 מעבדי vCPU) כדי להגדיל את המגבלה לכל VM ב-Hyperdisk Balanced וב-Hyperdisk ML מ-16 ל-32 אמצעי אחסון, או להשתמש באילוצים של אי-קרבה בין Pods או של פריסת טופולוגיה כדי להגביל את מספר ה-Pods שמתחברים ל-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 is OOMKilled on TPU/GPU nodes בצומתי TPU של GKE (לדוגמה ct4p-hightpu-4t) ובצומתי GPU (לדוגמה a3-highgpu-8g), יכול להיות שהליבה תסיים את gke-metadata-server עם OOMKilled כשהשימוש בזיכרון של השרת חורג מ-100MB. פתרון עקיף: אם אתם רואים אירועים מסוג 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. הרישום העודף הזה ביומן יצרוך את מכסת ה-API לכתיבה ב-Cloud Logging. פתרון עקיף: כדי לצמצם את רישום הנתונים המיותר, אפשר להוסיף מסנן החרגה. כדי להחריג את הודעות היומן מהטמעה ב-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 בגרסה 1.27 של GKE ואילך, נפחי 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 מסוג in-tree של 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, בגלל באג בליבת Linux. אי אפשר להעיר תהליכים במצב 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 ואילך	עומסי עבודה שמשתמשים בסטרימינג של תמונות נכשלים עם שגיאות אימות באג בתכונה "סטרימינג של קובצי אימג'" עלול לגרום לכשל בעומסי העבודה, אם מתקיים סט של תנאים ספציפיים בזמן שהקונטיינר קורא קבצים. יכול להיות שהודעות שגיאה שקשורות לכשלים באימות יופיעו ביומן של 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 ואילך	שיעורי פינוי הפודים עלו בגרסאות 1.30 ו-1.31 של GKE בחלק מהגרסאות של GKE 1.30 ו-GKE 1.31 שמשתמשות ב-COS 113 וב-COS 117, בהתאמה, יש ליבות (kernels) שנבנו עם האפשרות 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. יכול להיות שלא תמיד תראו שיעור פינוי פודים חריג, כי הבעיה הזו תלויה בדפוס השימוש בזיכרון של עומס העבודה. יש סיכון גבוה יותר שה-kubelet יפנה Pods של עומסי עבודה שלא הוגדרה להם מגבלת זיכרון בשדה המשאבים. הסיבה לכך היא שעומסי העבודה עשויים לבקש יותר זיכרון ממה ש-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 ואילך	פודים שנתקעו בסטטוס Terminating באג בסביבת זמן הריצה של הקונטיינר (containerd) עלול לגרום לפודים ולקונטיינרים להיתקע בסטטוס 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 ואילך	העברת התמונות נכשלת בגלל קישורים סמליים באג בתכונה "סטרימינג של קובצי אימג'" עלול לגרום לכך שהקונטיינרים לא יופעלו. יכול להיות שקונטיינרים שפועלים בצומת עם סטרימינג של קובצי אימג' שמופעל בגרסאות ספציפיות של 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: כל הגרסאות	העברת התמונות נכשלה בגלל קבצים חסרים באג בתכונה "סטרימינג של תמונות" עלול לגרום לכך שהקונטיינרים ייכשלו בגלל קובץ או קבצים חסרים. יכול להיות שקונטיינרים שפועלים בצומת עם סטרימינג של תמונות שמופעל בגרסאות הבאות לא יתחילו לפעול, או שיפעלו עם שגיאות שמודיעות שקבצים מסוימים לא קיימים. הנה כמה דוגמאות לשגיאות כאלה: No such file or directory Executable file not found in $PATH אם הבעיה הזו משפיעה עליכם, אתם יכולים להשבית את הסטרימינג של קובצי אימג'.
רשתות,שדרוגים ועדכונים	1.28		שגיאה בהגדרת ה-TLS של השער זיהינו בעיה בהגדרת TLS לשערים באשכולות שבהם פועלת גרסת GKE‏ 1.28.4-gke.1083000. הדבר משפיע על הגדרות TLS שמשתמשות ב-SSLCertificate או ב-CertificateMap. אם משדרגים אשכול עם שערים קיימים, העדכונים שבוצעו בשער ייכשלו. בשערי כניסה חדשים, מאזני העומסים לא יוקצו. הבעיה הזו תתוקן בגרסת תיקון עתידית של 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 ואילך	ההתאמה האוטומטית לעומס (autoscaling) של כל עומסי העבודה נפסקת יכול להיות שהתכונות 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, קראו את המסמכים של HorizontalPodAutoscaler Kubernetes.
פעולה	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 אחרי שדרוג מישור הבקרה באשכולות שבהם מופעלת מדיניות רשת ב-Kubernetes, יכולות להיות בעיות בקישוריות עם Pods של hostPort. בנוסף, יכול להיות שיעברו עוד 30 עד 60 שניות עד שהפודים החדשים שנוצרו יהיו מוכנים. הבעיה מתרחשת כשמשדרגים את מישור הבקרה של אשכול 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 ואילך	פוד של GPU Maintenance Handler תקוע במצב CrashLoopBackOff בבעיה הזו, הפודים של gpu-maintenance-handler תקועים במצב CrashLoopBackOff בצמתים המתאימים שלהם. המצב הזה מונע את החלת התווית `upcoming maintenance` על צומתי GKE, מה שיכול להשפיע על תהליכי ניקוז הצמתים ופינוי ה-Pods של עומסי העבודה. "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 הערה: השבתת הסטרימינג של קובצי אימג' יוצרת מחדש את כל הצמתים במאגר הצמתים.
פעולה	‫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 ואילך	‫ComputeClasses בהתאמה אישית עם ImageType שלא משתמשים במאגרי צמתים קיימים של GKE. כשמשתמשים ב-ComputeClass בהתאמה אישית שמגדיר שדה ImageType, הכלי להתאמה של גודל האשכול יוצר ומגדיל שוב ושוב מאגרי צמתים חדשים במקום להגדיל את מאגרי הצמתים הקיימים. הסטטוס של 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 כדי לקבל תמיכה מהקהילה.
  • לפתוח דיווחים על בעיות או הגשת בקשות להוספת תכונות באמצעות Issue Tracker הציבורי.