בעיות מוכרות ב-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.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 שמשתמשים בפודים עם משך זמן מורחב, יכול להיות שמאגרי צמתים חדשים יוקצו באמצעות גרסת הצומת הקודמת. המידרוג האוטומטי של האשכול בודק את הצמתים החדשים שהוקצו מול הגרסה המשודרגת של מישור הבקרה, מזהה חוסר התאמה בגרסאות ומחיל את ה-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 לנסות שוב ושוב לבטל את הטעינה. כל ניסיון חוזר מוסיף עוד רשומות לטבלת נקודות ההתקנה, וכתוצאה מכך טבלת נקודות ההתקנה גדלה באופן רציף גם כשלא מתוזמנים עומסי עבודה חדשים. כשטבלת נקודות הטעינה מגיעה למגבלת הליבה, סביבת זמן הריצה של הקונטיינר לא יכולה יותר ליצור קונטיינרים בצומת הזה. הצומת מפסיק להריץ 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, שדרגו לאחור את מאגרי הצמתים שמחברים את נפחי ה-NFS לגרסה 1.36. מגדירים החרגה מתחזוקה כדי ש-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 המצורפים. בגלל זמני הטעינה הארוכים של High Bandwidth Memory‏ (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 יחיל מחדש את הכתמים האלה לפני הזמן אם מתוכנן אירוע תחזוקה עתידי נוסף לצומת, וכך ימנע תזמון של עומסי עבודה חדשים בצמתים תקינים. פתרון עקיף: כדי לפתור את הבעיה, צריך להסיר באופן ידני את תוויות התחזוקה הפעילות שמנוהלות על ידי 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), ה-admission 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" בכל פעם שיוצאים מ-gVisor Pod או שמתבצעת פעולת OOM kill, ‏containerd מנסה להרוס את ארגז החול. עם זאת, לפעמים תהליך הניקוי נכשל, ומתועדת השגיאה exec: "runsc": executable file not found in $PATH. השגיאה הזו יכולה לגרום לבעיות כמו מיצוי משאבים, פגיעה ברשת, פאניקה של NodeLocalDNS, זמן קצוב לתפוגה של DNS או זמן אחזור גבוה כשיוצרים Pods. הפתרון: לשדרג את צומתי GKE לגרסה 1.35.1 ואילך. באשכולות Standard, משדרגים את מאגר הצמתים עם הצמתים שהושפעו. באשכולות 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	ירידה בביצועים של רשתות למטרות כלליות במכונות מסוג A series ו-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 ואילך. למאגרי צמתים של 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 ממופות באופן חד-חד-ערכי וצריכות להתאים. לדוגמה, גרסת מנהל ההתקנה של 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 לא תואם לליבה (kernel) המעודכנת של 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 עבור 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 במאגרי צמתים שפועלים ב-GKE בגרסה 1.33, שמשתמשת ב-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 שלא ניתן לתזמן בגלל מגבלות של volume attachment של צומת מפעיל הקצאת משאבים אוטומטית של צומת חדש. כשעומסי עבודה שמשתמשים בנפח Hyperdisk מתוזמנים לצומת שמריץ מכונה וירטואלית מסוג 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, כי מנהל ההתקן של Persistent Disk CSI ב-Compute Engine מדווח למתזמן של 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 אמצעי אחסון, או להשתמש באילוצים של Pod anti-affinity או של פריסת טופולוגיה כדי להגביל את מספר הפודים שמתחברים ל-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. הרישום העודף הזה ביומן יצרוך את המכסה של 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 בגרסה 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 ואילך	לא ניתן להפעיל Pods שמנסים לטעון אמצעי אחסון מתמידים של 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	‫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 ואילך	יכול להיות ש-Pods שמשתמשים בקריאות מערכת שקשורות ל-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 ואילך	שיעורי פינוי Pod מוגברים בגרסאות 1.30 ו-1.31 של GKE בחלק מהגרסאות של GKE 1.30 ו-GKE 1.31 שמשתמשות ב-COS 113 וב-COS 117, בהתאמה, יש ליבות שנבנו עם האפשרות CONFIG_LRU_GEN_ENABLED=y. האפשרות הזו מפעילה את התכונה Multi-Gen LRU בליבה (kernel), שגורמת ל-kubelet לחשב באופן שגוי את השימוש בזיכרון, ועלולה להוביל לכך שה-kubelet יפנה Pods. אפשרות ההגדרה CONFIG_LRU_GEN_ENABLED מושבתת ב-cos-113-18244-151-96 וב-cos-117-18613-0-76. יכול להיות שלא תמיד תראו שיעור פינוי Pod חריג, כי הבעיה הזו תלויה בדפוס השימוש בזיכרון של עומס העבודה. יש סיכון גבוה יותר שה-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 כדי לקבל תמיכה מהקהילה.
  • דיווח על בעיות או שליחת בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.