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

• ‫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 מגרסה v1alpha1 לגרסה v1beta1.

• 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 של Cloud de Confiance על ידי בקשה של טוקני גישה או אסימוני זהות של חשבון שירות משרת המטא-נתונים של 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 ואילך

פודים שלא תזמנו ומכסות שנוצלו במהלך שדרוגים קלים בשני שלבים של מישור הבקרה.

במהלך שדרוגים של שתי גרסאות משניות למישורי בקרה באשכולות 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"

צמתים שמתקינים אמצעי אחסון של 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 לא מושפעים.

פתרון עקיף:

כדי לשחזר צומת שהושפע, צריך להפעיל אותו מחדש או ליצור אותו מחדש. רשומות הטעינה הנוספות קיימות רק במצב ההפעלה של הצומת, ולכן הן נמחקות כשהצומת מופעל מחדש. אפשר להסיר פודים שנתקעו במצב 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 דקות מרוקן ונוצר מחדש, וטבלת הטעינה שלו נמחקת.

כשלים בעומסי עבודה של 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, לא תאבדו קיבולת אם תמחקו את מאגרי הצמתים.

צומתי 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 מהצמתים המושפעים. אם תסירו רק את ה-taints, בקר התחזוקה של GKE יחיל אותם מחדש באופן אוטומטי.

כדי לנקות את התוויות וה-taints, מריצים את הפקודות הבאות:

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

כשלים בקבלת 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 ואילך.

לקוח Lustre לא משתמש בכרטיסי רשת משניים בצמתים עם כמה כרטיסי רשת

בצומתי GKE עם כמה כרטיסי רשת (NIC), מנהל ההתקן של Managed Lustre CSI מופעל כברירת מחדל כדי להשתמש בכל כרטיסי הרשת הזמינים לצבירת רוחב פס על ידי פיזור תעבורת האחסון של TCP בין ממשקי הרשת. עם זאת, בגלל בעיה ידועה, יכול להיות שלקוחות Lustre מגרסה 2.14.0_p249 ואילך לא ישתמשו בכרטיסי רשת משניים. במקום זאת, כל תעבורת הנתונים של האחסון ב-TCP למכונה של Managed Lustre מנותבת רק דרך ה-NIC הראשי, מה שמונע צבירת רוחב פס ומגביל את קצב העברת הנתונים באחסון.

פתרון עקיף:

אם עומסי העבודה שלכם דורשים צבירת רוחב פס של כמה כרטיסי רשת (NIC) בשביל Managed Lustre, שדרגו לאחור את מאגרי הצמתים לגרסת GKE שקודמת ל-‎1.35.3-gke.1234000, כמו ‎1.35.2-gke.1842000.

זמן קצוב לתפוגה של החיבור או סירוב לחיבור של תהליכים שהופנו לשרת המטא-נתונים של GKE

ב-GKE בגרסה 1.35 ואילך, עומסי עבודה שמשתמשים ב-Workload Identity כדי לבצע אימות מול Google Cloud APIs עלולים להיתקל בבעיות זמניות של זמן קצוב לתפוגה של החיבור או בחיבורים שנדחו לשרת המטא-נתונים של GKE מיד אחרי הפעלת הצומת.

פתרון עקיף:

במאמר פתרון בעיות של שגיאות זמן קצוב לתפוגה בהפעלת Pod מפורטות המלצות ודרכים לעקיפת הבעיה.

ה-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
    

נפחים דינמיים חוזרים לסוג הדיסק שמוגדר כברירת מחדל

יכול להיות שעומסי עבודה שמשתמשים באמצעי אחסון דינמיים ב-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

עומסי עבודה חדשים לא יופעלו במהלך ההשקה של 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.0-gke.2232000 ואילך.

שכפול זהויות של Cilium באשכולות של GKE Dataplane V2

באשכולות GKE שפועלים בגרסה 1.35 עם GKE Dataplane V2, יכול להיות שתהיה עלייה במספר המשאבים המותאמים אישית של ciliumidentities.cilium.io. הבעיה הזו נגרמת בגלל הוספת תוויות topology.kubernetes.io לקבוצות Pod ב-Kubernetes 1.35, מה שיוצר זהויות Cilium נוספות לכל אזור שבו מתוזמנת קבוצת Pod מעומס עבודה.

גם באשכולות אזוריים וגם באשכולות של אזורים, תזמון של עומס עבודה חדש יכול לגרום לשכפול זמני של זהות Cilium. הכפילות הזו מתרחשת כי Pods מקבלים זהות אחת בזמן היצירה על סמך תוויות ראשוניות, וזהות אחרת אחרי שמוסיפים תוויות טופולוגיה כשה-Pod מתוזמן לצומת. באשכולות אזוריים, מספר הזהויות עשוי לגדול גם בפקטור שפרופורציונלי למספר האזורים שהאשכול משתרע עליהם.

השפעה:

אם המספר הכולל של הזהויות גדול מ-65,535, יכול להיות שלא תצליחו לתזמן עומסי עבודה חדשים.

פתרון עקיף:

כדי להגביל את המספר הכולל של הזהויות, אל תוסיפו לפודים תוויות עם מספר גדול של ערכים ייחודיים.

מידע נוסף זמין במסמכי התיעוד הבאים של 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 לא תואם לליבה (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. במאמרים הגדלת רוחב הפס של רשת ה-GPU באשכולות Standard והגדלת רוחב הפס של רשת ה-GPU באשכולות Autopilot מוסבר איך מגדירים ומשדרגים מאגרי צמתים באמצעות GPUDirect-TCPX.

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

• ‫NCCL WARN logs for Rx Ctrl Timeouts: ההודעה הזו יכולה להופיע אם עומס העבודה מפרסם פעולת תקשורת של Recv ביעד הרבה לפני שהוא מפרסם פעולת תקשורת של Send ביוזם. לא צפויה השפעה על הביצועים.
• יומני NCCL WARN עבור No free space for recv task: ההודעה הזו מזהירה מפני מספר כולל נמוך של משימות רשת לעיבוד פעולות, וכתוצאה מכך כל המשימות תפוסות באופן זמני. לא צפויה השפעה על הביצועים.

הקיבולת המינימלית של המכונות עודכנה

הקיבולת המינימלית של מכונות Managed Lustre עודכנה ל-9,000GiB. באשכולות שפועלים בגרסאות שקודמות ל-1.34.0-gke.2285000, אי אפשר ליצור מכונות עם הקיבולת המינימלית הזו באמצעות מנהל ההתקן של Managed Lustre CSI.

פתרון עקיף:

כדי ליצור מכונות של Managed Lustre עם קיבולת מינימלית של 9,000GiB, צריך לשדרג את גרסת האשכול ל-‎1.34.0-gke.2285000 ואילך.

אי אפשר לערוך את ממשק המשתמש של מסוףCloud de Confiance במהלך תיקון אוטומטי של צומת

כשצומת GKE עובר תיקון אוטומטי, אי אפשר לערוך את מאגר הצמתים דרך מסוף Cloud de Confiance בגלל פעולה שמתבצעת.

פתרון עקיף:

עדיין אפשר לערוך את ההגדרות של מאגר הצמתים באמצעות פקודות ב-CLI של gcloud.

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

כשמקצים באופן דינמי מכונה של Lustre, יצירת המכונה נכשלת עם השגיאה InvalidArgument עבור PerUnitStorageThroughput, בלי קשר לערך perUnitStorageThroughput שצוין בבקשת ה-API.

פתרון עקיף:

לשדרג את אשכול GKE לגרסה 1.33.4-gke.1036000 ואילך. אם אתם משתמשים בערוץ היציב, יכול להיות שגרסה חדשה יותר עדיין לא זמינה. במקרה כזה, אתם יכולים לבחור באופן ידני גרסה מהערוץ הרגיל או המהיר שכוללת את התיקון.

• ‫1.32.3-gke.1099000 ואילך
• 1.33

שגיאת קלט/פלט כשמשנים שם של קבצים או מעבירים אותם באמצעות מנהל התקן ה-CSI של Cloud Storage FUSE

כשמשתמשים בגרסה מושפעת של מנהל התקן ה-CSI של Cloud Storage FUSE, יכול להיות ששינוי השם או ההעברה של קבצים בקטגוריות של Cloud Storage ייכשלו עם שגיאת קלט/פלט.

פתרון עקיף:

מוסיפים באופן זמני הגדרה ספציפית של קובץ צדדי של תמונה למניפסט של ה-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 לגרסת האשכול המשודרגת.

מרוץ תהליכים ב-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

מגבלה נמוכה יותר של קבצים פתוחים ב-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 כדי להימנע מהבעיה הזו עד שיהיה פתרון קבוע.

‫CRD status.storedVersions לא תקין ל-CRD מנוהלים

יכול להיות שבחלק מה-CRD שמנוהלים על ידי GKE יש שדה status.storedVersions לא תקין, שעלול לגרום לבעיות בגישה לאובייקטים של CRD אחרי השדרוג.

הבעיה הזו משפיעה על אשכולות שעונים על שני התנאים הבאים:

• אשכולות שהשתמשו בגרסת GKE מושפעת בשלב כלשהו.
• אשכולות שכללו גרסאות לא נתמכות (served=false) של אובייקטים מסוג CRD שאוחסנו ב-etcd.

פתרון עקיף:

הפתרון המומלץ הוא לדחות את השדרוגים של האשכולות עד שהבעיה תיפתר.

לחלופין, אם אתם יודעים שהאשכול מכיל גרסאות לא נתמכות של אובייקטים מסוג CRD, אתם יכולים להוסיף את הגרסאות האלה לשדה status.storedVersions באמצעות הפקודה kubectl patch.

• ‫1.32.2-gke.1652003 ואילך
• ‫1.31.6-gke.1221001 ואילך
• ‫1.30.10-gke.1227001 ואילך

מדדים חסרים או שהמידרוג האוטומטי של עומס העבודה לא משתנה

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

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

פתרון עקיף:

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

מגבלות הגודל והחיבור של Google Cloud Hyperdisk

בדרך כלל, פוד שלא ניתן לתזמן בגלל מגבלות של volume attachment של צומת, מפעיל הקצאת משאבים אוטומטית של צומת חדש. כשמריצים עומסי עבודה שמשתמשים במוצר Hyperdisk, והם מתוזמנים לצומת שמריץ מכונה וירטואלית מסוג C3, לא מתבצעת הקצאת צמתים אוטומטית וה-Pod מתוזמן לצומת שכבר מלא.

עומס העבודה מתוזמן לצומת למרות שאין חיבור זמין לדיסק. גם עומס העבודה לא מתחיל, בגלל שגיאה כמו זו:

 AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17]

הבעיה קיימת בכל מוצרי Hyperdisk במכונות C3.

מגבלות הצירוף של Hyperdisk משתנות בהתאם למספר ה-vCPU של ה-VM ולמוצר Hyperdisk. מידע נוסף זמין במאמר מגבלות הביצועים של Hyperdisk.

פתרון עקיף:

מוצרי Google Cloud Hyperdisk מפעילים הקצאת משאבים אוטומטית בצורות אחרות של מכונות וירטואליות. מומלץ לבחור תצורה שתומכת רק ב-Google Cloud Hyperdisk.

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.

ב-GKE בגרסה 1.27 ואילך, נפחי NFS שמשתמשים במנהל התקן ה-CSI המובנה של Kubernetes יכולים לטעון נפחים קבועים במצב RO רק אחרי טעינת RO קודמת באותו צומת.

פתרון עקיף:

להוריד את הגרסה של מאגרי הצמתים לגרסה שקודמת לגרסאות המושפעות.

• גרסאות 1.32 מ-‎1.32.1-gke.1357001 עד ‎1.32.4-gke.1106000 (לא כולל)
• כל הגרסאות של 1.33 שקודמות ל-‎1.33.0-gke.1552000

• גרסה 1.32: ‏1.32.4-gke.1106000 ואילך
• גרסה 1.33: ‏‎1.33.0-gke.1552000 ואילך

פודים שמנסים לטעון אמצעי אחסון מתמידים של NFS בצומתי Ubuntu לא יוכלו לפעול.

ב-GKE מגרסה 1.32 ואילך, נפחי NFS שמשתמשים במנהל התקן ה-CSI המובנה של Kubernetes לא יוכלו לטעון נפחים קבועים בצמתים של Ubuntu. במקרים כאלה, יכול להיות שיופיעו הודעות השגיאה הבאות:

"MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1"

Output: Mount failed: mount failed: exit status 127

"Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes"

בנוסף להודעות השגיאה האלה, לא תהיה אפשרות להעלות Pods שמשתמשים בנפחים האלה.

פתרון עקיף:

שנמוך של מאגרי הצמתים לגרסה 1.31.

• ‫1.28.15-gke.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.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, בהתאמה, יש ליבות (kernels) שנבנו עם האפשרות 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.

יכול להיות שלא תמיד תראו שיעור פינוי פודים חריג, כי הבעיה הזו תלויה בדפוס השימוש בזיכרון של עומס העבודה. יש סיכון גבוה יותר שה-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 בשם ובסוג של עומס העבודה שרוצים לנתח:

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

דרך לעקיפת הבעיה

אם אתם לא יכולים לשדרג לגרסאות המתוקנות ואתם מריצים בסביבת GKE שבה אפשר לפרוס Pods עם הרשאות, אתם יכולים להשבית את האפשרות Multi-Gen LRU באמצעות DaemonSet.

1. מעדכנים את מאגרי הצמתים של GKE שמהם רוצים להריץ את DaemonSet עם הערה כדי להשבית את האפשרות Multi-Gen LRU. לדוגמה, disable-mglru: "true".
2. מעדכנים את הפרמטר nodeSelector במניפסט של DaemonSet עם אותה הערה שבה השתמשתם בשלב הקודם. לדוגמה, אפשר לעיין בקובץ disable-mglru.yaml במאגר GoogleCloudPlatform/k8s-node-tools.
3. פורסים את ה-DaemonSet באשכול.

אחרי ש-DaemonSet פועל בכל מאגרי הצמתים שנבחרו, השינוי נכנס לתוקף באופן מיידי וחישוב השימוש בזיכרון של kubelet חוזר למצב רגיל.

• ‫1.28.14-gke.1175000 ואילך
• ‫1.29.9-gke.1341000 ואילך
• ‫1.30.5-gke.1355000 ואילך
• ‫1.31.1-gke.1621000 ואילך

פודים שנתקעו בסטטוס Terminating (בסיום)

באג בסביבת זמן הריצה של הקונטיינר (containerd) עלול לגרום לפודים ולקונטיינרים להיתקע בסטטוס Terminating, עם שגיאות שדומות לשגיאה הבאה:

אם הבעיה משפיעה עליכם, אתם יכולים לשדרג את הצמתים לגרסת 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 לא ייווצרו, ותופיע השגיאה הבאה:

פתרון עקיף:

כדי לפתור את הבעיה, צריך לשדרג את מאגרי הצמתים לגרסה מתוקנת (‎1.35.6-gke.1005000 ואילך, או ‎1.36.0-gke.2459000 ואילך).

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

• ‫1.28.9-gke.1103000 ואילך
• ‫1.29.4-gke.1202000 ואילך
• ‫1.30: כל הגרסאות

העברת התמונה נכשלה בגלל קבצים חסרים

באג בתכונה "סטרימינג של תמונות" עלול לגרום לכשל בקונטיינרים בגלל קובץ או קבצים חסרים.

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

• No such file or directory
• Executable file not found in $PATH

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

שגיאה בהגדרת ה-TLS של השער

זיהינו בעיה בהגדרת TLS לשערים באשכולות שבהם פועלת גרסת GKE‏ 1.28.4-gke.1083000. השינוי משפיע על הגדרות TLS שמשתמשות ב-SSLCertificate או ב-CertificateMap. אם משדרגים אשכול עם שערים קיימים, העדכונים שבוצעו בשער ייכשלו. בשערי כניסה חדשים, מאזני העומסים לא יוקצו. הבעיה הזו תתוקן בגרסת תיקון עתידית של GKE 1.28.

בעיה בפלאגין של מכשיר 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.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.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.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 שניות עד שה-Pods החדשים יהיו מוכנים.

הבעיה מתרחשת כשמשדרגים את מישור הבקרה של אשכול GKE לאחת מהגרסאות הבאות של GKE:

• ‫1.30 עד 1.30.4-gke.1281999
• ‫1.29.1-gke.1545000 עד 1.29.8-gke.1156999
• ‫1.28.7-gke.1042000 עד 1.28.13-gke.1077999
• ‫1.27.12-gke.1107000 עד 1.27.16-gke.1341999

פתרון עקיף:

לשדרג או ליצור מחדש את הצמתים מיד אחרי השדרוג של מישור הבקרה של GKE.

• ‫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.10-gke.1071000 ואילך
• ‫1.30.5-gke.1723000 ואילך
• ‫1.31.2-gke.1115000 ואילך

חוסר תאימות בין Ray Operator לבין הצפנת מסד הנתונים של Cloud KMS

חלק מהגרסאות של Ray Operator לא תואמות להצפנה של מסד הנתונים ב-Cloud KMS.

פתרונות עקיפים:

לשדרג את מישור הבקרה של האשכול לגרסה עם התיקון או לגרסה חדשה יותר.

• ‫1.30.8-gke.1051000 ואילך
• ‫1.31.1-gke.2008000 ואילך

פוד של GPU Maintenance Handler תקוע במצב CrashLoopBackOff

בבעיה הזו, פודים של gpu-maintenance-handler תקועים במצב CrashLoopBackOff בצמתים המתאימים שלהם. המצב הזה מונע את החלת התווית `upcoming maintenance` על צומתי GKE, מה שיכול להשפיע על תהליכי ניקוז הצמתים ופינוי ה-Pod של עומסי העבודה.

אם הבעיה הזו משפיעה עליכם, אתם יכולים לפתור אותה על ידי שדרוג מישור הבקרה לגרסת GKE שכוללת את התיקון.

הפודים לא מופעלים בצמתים שבהם מופעלת העברת תמונות בסטרימינג

בצמתים שבהם מופעל סטרימינג של תמונות, יכול להיות שעומסי העבודה לא יתחילו, ותופיע חתימת השגיאה הבאה: 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.