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

צמתי GPU או TPU נתקעים עם כתמי impending-node-termination אחרי תחזוקת המארח

באשכולות GKE עם צמתי האצה (GPU או TPU) שמריצים גרסאות מושפעות, יכול להיות שהצמתים יישארו תקועים עם כתמי הצבע cloud.google.com/impending-node-termination או cloud.google.com/maintenance-window-started אחרי תחזוקה או תיקונים של מארח Compute Engine. כשמפעילים מחדש את מופע ה-VM, יכול להיות שבקר התחזוקה של GKE יחיל מחדש את הכתמים האלה לפני הזמן אם מתוזמן אירוע תחזוקה עתידי אחר לצומת, וכך ימנע תזמון של עומסי עבודה חדשים בצמתים תקינים.

פתרון עקיף:

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

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

kubectl label nodes NODE_NAME cloud.google.com/active-node-maintenance-
kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-
kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-latest-
kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination-
kubectl taint nodes NODE_NAME cloud.google.com/maintenance-window-started-
    

מחליפים את NODE_NAME בשם הצומת המושפע.

• ‫1.33
• 1.34

כניסת ה-Pod נכשלה עבור עומסי עבודה של TPU v7 בגלל דיווח על מספר שגוי של שבבים.

‫GKE מפרסם באופן שגוי שמונה שבבי TPU שניתנים להקצאה למאיצי TPU מדגם v7 ‏ (tpu7x) עם טופולוגיה של 2x2x1, שבפועל מכילים רק ארבעה שבבים. חוסר התאמה בדיווח הזה מונע תזמון של Pods לעומסי עבודה של TPU v7.

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

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

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

gVisor shim נכשל בניקוי, מתועדת שגיאה "runsc: executable file not found in $PATH"

בכל יציאה של gVisor Pod או חיסול OOM, ‏ containerd מנסה לפרק את ארגז החול. עם זאת, לפעמים תהליך הניקוי נכשל, והשגיאה exec: "runsc": executable file not found in $PATH נרשמת ביומן. השגיאה הזו עלולה לגרום לבעיות כמו מיצוי משאבים, ירידה בביצועים של הרשת, קריסת NodeLocalDNS, פסק זמן של DNS או חביון גבוה כשיוצרים Pods.

פתרון:

משדרגים את צמתי GKE לגרסה 1.35.1 ואילך. במקרה של אשכולות רגילים, משדרגים את מאגר הצמתים עם הצמתים המושפעים. באשכולות Autopilot, צריך לשדרג ידנית את אשכול Autopilot לגרסה 1.35.1 ואילך, ו-GKE ישדרג אוטומטית את הצמתים שלכם כך שיתאימו לגרסת מישור הבקרה בהקדם האפשרי.

פתרון עקיף:

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

• בודקים ומגדילים את בקשות הזיכרון והמגבלות של ה-pods של gVisor.
• פורסים את ה-DaemonSet הבא עם הרשאות כדי להעתיק את הקובץ הבינארי runsc מ-/home/containerd/usr/local/sbin אל /home/kubernetes/bin:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: runsc-path
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: runsc-path
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: runsc-path
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: sandbox.gke.io/runtime
                operator: In
                values:
                - gvisor
      tolerations:
        - effect: NoSchedule
          key: sandbox.gke.io/runtime
          operator: Equal
          value: gvisor
      volumes:
      - name: host
        hostPath:
          path: /
      initContainers:
      - name: copy-runsc
        image: bash
        command:
        - /usr/local/bin/bash
        - -c
        - |
          set -euo pipefail
          cp /host/home/containerd/usr/local/sbin/runsc /host/home/kubernetes/bin
          chmod a+rx /host/home/kubernetes/bin/runsc
        volumeMounts:
        - name: host
          mountPath: /host
        resources:
          requests:
            memory: 5Mi
            cpu: 5m
        securityContext:
          privileged: true
      containers:
      - image: gcr.io/google-containers/pause:3.2
        name: pause
    

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

יכול להיות שעומסי עבודה שמשתמשים בנפחים דינמיים ב-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 צריכים להציג תצוגה מסונכרנת של identity-relevant labels. החל מ-GKE 1.35.0-gke.2232000, התוויות topology.kubernetes.io לא נכללות בקבוצה הרלוונטית לזהות כדי למנוע כפילות של זהויות. השינוי הזה גורם לחוסר התאמה זמני בהגדרות בין מישור הבקרה המשודרג לבין סוכני anetd מיושנים במהלך ההשקה. מידע נוסף זמין בCilium PR.

פתרון עקיף:

• ב-GKE 1.34 בגרסה קודמת ל-‎1.34.3-gke.1208000: קודם משדרגים ל-‎1.34.3-gke.1208000 או לגרסה מאוחרת יותר, ואז משדרגים ל-‎1.35.0-gke.2232000 או לגרסה מאוחרת יותר.
• ל-GKE 1.35 בגרסה מוקדמת יותר מ-1.35.0-gke.2232000: אחרי השדרוג, צריך לחכות עד לסיום ההשקה של anetd. כדי להאיץ את ההשקה באופן ידני, מוחקים את ה-Pods המיושנים של anetd. כך תוכלו לוודא שלמפעיל ולסוכני הצמתים anetd יש תצוגות מסונכרנות של התוויות שרלוונטיות לזהות.

• ‫1.32
• ‫1.33
• 1.34
• ‫1.35

• ‫1.32.11-gke.1153001 ואילך
• ‫1.33.5-gke.2326000 ואילך
• ‫1.34.3-gke.1214000 ואילך
• ‫1.35.0-gke.2180000 ואילך

עיכובים בתזמון של פודים בצמתים חדשים עם מדיניות רשת Calico מופעלת

באשכולות GKE שבהם מופעלת מדיניות רשת Calico, רגרסיה בגרסאות המושפעות עלולה לגרום לעיכובים משמעותיים בתזמון של Pod בצמתים חדשים או בצמתים שנוצרו מחדש. העיכובים האלה עלולים לגרום לכך שהצמתים יישארו במצב NotReady למשך תקופות ארוכות.

הבעיה נגרמת בגלל שסקריפט לטעינה בזמן ההפעלה של Calico CNI מעצב באופן שגוי את כתובת ה-URL של שרת Kubernetes API עבור כתובות IPv4, על ידי הוספת סוגריים מרובעים ([]) מסביב לכתובת. הגישה הזו מובילה לשגיאה בניתוח כתובת ה-URL כשיוצרים ארגז חול חדש של Pod, שמופיעה ביומני kubelet:

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox ""sandbox-id"": plugin type="calico" failed (add): error creating calico client: host must be a URL or a host:port pair: "https://[IPv4-address]:443"

פתרון עקיף:

גרסת רכיב Calico נקבעת לפי גרסת מישור הבקרה של האשכול. כדי לפתור את הבעיה, צריך לשדרג את רמת הבקרה של האשכול לאחת מהגרסאות המתוקנות. אחרי שמשדרגים את מישור הבקרה, צריך ליצור מחדש את הצמתים במאגרי הצמתים כדי לוודא שהם משתמשים בפורמט הנכון של כתובת השרת של Kubernetes API. כדי לעשות את זה, אפשר לבצע שדרוג במקום של מאגר הצמתים לאותה גרסה או לגרסה חדשה יותר, או ליצור מחדש את מאגרי הצמתים באופן ידני.

• ‫1.32.8-gke.1134000 ואילך ל-GKE 1.32
• ‫1.33.3-gke.1392000 ואילך ל-GKE 1.33
• כל גרסאות התיקונים של GKE 1.34 ו-1.35

• ‫1.32.11-gke.1075000 ואילך ל-GKE 1.32
• ‫1.33.5-gke.2392000 ואילך ל-GKE 1.33
• ‫1.34.3-gke.1318000 ואילך ל-GKE 1.34
• ‫1.35.0-gke.2398000 ואילך ל-GKE 1.35

הביצועים של רשתות לשימוש כללי יורדים בסדרות A ובסוגי מכונות G4 GPU

באשכולות GKE עם צומתי GPU מסדרות A ו-G4, הביצועים של רישות למטרות כלליות ב-GKE 1.32.8-gke.1134000 ואילך עבור GKE 1.32, וב-GKE 1.33.3-gke.1392000 ואילך, נמוכים יותר. הירידה בביצועים ברשתות לשימוש כללי משפיעה על סוגי מכונות GPU, כולל סדרת מכונות A3, סדרת מכונות A4, סדרת מכונות A4X וסדרת מכונות G4. שימו לב ש-GPUDirect-TCPXO ב-A3 Mega ו-GPUDirect-RDMA ב-A3 Ultra,‏ A4 ו-A4X לא מושפעים.

הסיבה לכך היא שהסקריפט ברמת הצומת (/usr/bin/google_set_multiqueue) שמגדיר את זיקת ההפרעה מוגדר בצורה שגויה.

פתרון עקיף:

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

• ‫1.32.8-gke.1134000 ואילך ל-GKE 1.32
• ‫1.33.3-gke.1392000 ואילך ל-GKE 1.33 ואילך

• ‫1.32.11-gke.1075000 ואילך ל-GKE 1.32
• ‫1.33.5-gke.2392000 ואילך ל-GKE 1.33

הביצועים של GPUDirect-TCPX יורדים ב-A3 High

באשכולות GKE עם צמתים מסוג A3 High ‏ (a3-highgpu-8g) יש ירידה בביצועים כשמשתמשים ב-GPUDirect-TCPX ב-GKE 1.32.8-gke.1134000 ואילך ל-GKE 1.32, וב-GKE 1.33.3-gke.1392000 ואילך.

הסיבה לכך היא שהסקריפט ברמת הצומת (/usr/bin/google_set_multiqueue) שמגדיר את זיקת ההפרעה מוגדר בצורה שגויה.

פתרון עקיף:

במאגרי צמתים של GKE 1.32, משדרגים את גרסאות מאגר הצמתים של GKE לגרסה ‎1.32.11-gke.1075000 ואילך. במאגרי צמתים של GKE מגרסה 1.33 ואילך, צריך לשדרג את גרסאות מאגרי הצמתים של GKE לגרסה ‎1.33.5-gke.2392000 ואילך.1392000. למאגרי צמתים של GKE 1.34, אפשר לעיין במאמר GPUDirect-TCPX לא זמין עם A3 High ב-GKE מגרסה 1.34 ואילך.

‫1.35.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, יכול להיות שלא תהיה אפשרות לתזמן את ה-workloads החדשים.

פתרון עקיף:

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

מידע נוסף זמין במאמרי העזרה הבאים של Cilium:

• אבטחה מבוססת-זהות
• זהויות אבטחה

צריך לבצע שדרוגים ידניים מגרסאות 1.34.3-gke.1208000 ואילך. אם תתחילו את השדרוג מגרסה מוקדמת יותר מ-1.34.3-gke.1208000, יכול להיות שתיתקלו בבעיות זמניות בתזמון של Pod במהלך תהליך השדרוג.

‫GPUDirect-TCPX לא זמין עם A3 High ל-GKE מגרסה 1.34 ואילך

אשכולות GKE עם צמתים מסוג A3 High (a3-highgpu-8g) יכולים להשתמש ב-GPUDirect-TCPX כדי למקסם את רוחב הפס של רשת ה-GPU. בצמתים שמשתמשים ב-TCPX וב-A3 High, שדרוג לגרסאות משניות של GKE מגרסה 1.34 ואילך עלול לגרום לבעיות בפונקציונליות או בביצועים של TCPX. הסיבה לכך היא ש-TCPX לא תואם לליבת Linux המעודכנת 6.12 שמשמשת את מערכת הפעלה שמותאמת לקונטיינרים Milestone 125 ואילך. גרסה 1.34 של GKE משתמשת באבן הדרך 125.

סוגי מכונות אחרים של GPU מסוג A3 High (‏a3-highgpu-1g, ‏a3-highgpu-2g, ‏a3-highgpu-4g) וסדרות מכונות אחרות של GPU לא מושפעים כי הם לא תומכים ב-GPUDirect-TCPX.

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

• אי אפשר ליצור מאגרי צמתים עם צמתים מסוג A3 High (a3-highgpu-8g) שמשתמשים בגרסה 1.34 ואילך.
• אי אפשר לשדרג באופן ידני מאגרי צמתים עם צמתים מסוג A3 High ‏ (a3-highgpu-8g) לגרסה 1.34 ואילך.
• ‫GKE לא משדרג אוטומטית מאגרי צמתים עם צמתי A3 High (a3-highgpu-8g) לגרסה 1.34 ואילך.

פתרון עקיף:

בשלב הזה לא נדרשת שום פעולה מצידך. מערכת GKE מונעת באופן אוטומטי יצירה של מאגרי צמתים עם צמתי A3 High ‏ (a3-highgpu-8g) בגרסה 1.34 ואילך, ומונעת שדרוגים של מאגרי צמתים עם צמתי A3 High ‏ (a3-highgpu-8g) לגרסה 1.34 ואילך.

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

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

פתרון עקיף:

כדי ליצור מופעים מנוהלים של 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 ייכשלו עם שגיאת קלט/פלט.

פתרון עקיף:

מוסיפים באופן זמני הגדרה ספציפית של תמונת sidecar למניפסט של ה-Pod. בקטע spec.containers של מניפסט ה-Pod, מוסיפים את הגדרת הקונטיינר הבאה עם התמונה: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2.

    # Add the following block to use the fixed sidecar image
    - name: gke-gcsfuse-sidecar
      image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2
    

מידע נוסף זמין במאמר בנושא הגדרת תמונה פרטית עבור קונטיינר sidecar.

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

מרוץ תהליכים ב-gke-metrics-agent DaemonSets

כשמוסיפים את התווית cloud.google.com/gke-metrics-agent-scaling-level למאגר צמתים כדי להגדיל ידנית את הקצאת הזיכרון של DaemonSet‏ gke-metrics-agent, מתרחש מרוץ תהליכים ב-DaemonSet במהלך יצירת צומת חדש. מרוץ התהליכים הזה גורם להפעלות מחדש לסירוגין, ויכול להיות שחלק מהמדדים לא יתועדו.

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

פתרון עקיף:

אחרי שמוסיפים את התווית cloud.google.com/gke-metrics-agent-scaling-level למאגר צמתים, מפעילים מחדש את DaemonSet‏ gke-metrics-agent:

kubectl -n kube-system rollout restart daemonset gke-metrics-agent

הגבלת מספר הקבצים הפתוחים ב-containerd 2.0

במאגרי צמתים שפועלים ב-GKE גרסה 1.33, שמשתמשת ב-containerd 2.0, המגבלה הרכה שמוגדרת כברירת מחדל לקבצים פתוחים (ulimit -n) לקונטיינרים מוגדרת ל-1024.

זהו שינוי ב-containerd עצמו (ראו containerd PR #8924) שבו LimitNOFILE הוסר מ-containerd.service כשיטה מומלצת, כך שהמגבלה הרכה של מערכת ברירת המחדל חלה.

יכול להיות שעומסי עבודה שמצפים למגבלת ברירת מחדל גבוהה יותר (לדוגמה, עומסי עבודה שמסתמכים באופן מרומז על ברירת המחדל הקודמת והגבוהה יותר) יחוו כשלים, כמו שגיאות Too many open files.

פתרון:

שדרוג מגרסת תיקון קודמת של 1.33 לגרסה 1.33.2-gke.1043000 ואילך.

פתרון עקיף:

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

• שינוי ברמת האפליקציה: משנים את קוד האפליקציה או את ההגדרה כדי להגדיר במפורש את ulimit -n או prlimit --nofile=524288.
• ‫Containerd NRI Ulimit Adjuster Plugin אפשר להשתמש בפלאגין containerd/nri ulimit-adjuster כדי לשנות את ulimit.
• הורדת גרסה של מאגר הצמתים (Standard בלבד): באשכולות GKE מסוג Standard, אפשר להוריד את הגרסה של מאגר הצמתים לגרסה 1.32 באופן זמני כדי להימנע מהבעיה הזו עד שיהיה פתרון קבוע.

Invalid CRD status.storedVersions for managed CRDs

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

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

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

פתרון עקיף:

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

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

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

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

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

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

פתרון עקיף:

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

מגבלות הגודל והקבצים המצורפים של Google Cloud Hyperdisk

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

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

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

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

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

פתרון עקיף:

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

תהליך gke-metadata-server נקטע בגלל חריגה מזיכרון בצמתים של TPU/GPU

בצמתי TPU ב-GKE (לדוגמה, ct4p-hightpu-4t) ובצמתי GPU (לדוגמה, a3-highgpu-8g), יכול להיות שהליבה תסיים את התהליך gke-metadata-server עם OOMKilled אם השימוש בזיכרון של השרת יעלה על 100 MB.

פתרון עקיף:

אם אתם רואים אירועי OOMKilled עבור gke-metadata-server בצמתים של TPU או GPU, פנו לצוות התורן של GKE Identity (מזהה הרכיב: 395450) כדי לקבל אפשרויות לצמצום הבעיה.

• ‫1.32.0-gke.1358000 עד 1.32.4-gke.1106006, ‏ 1.32.4-gke.1236007, ‏ 1.32.4-gke.1353001, ‏ 1.32.4-gke.1415001, ‏ 1.32.4-gke.1533000
• ‫1.33.0-gke.0 עד 1.33.0-gke.1552000

• ‫1.32.4-gke.1353003 ואילך
• ‫1.33.0-gke.1552000 ואילך

יכול להיות ששינוי הגודל של נפח אחסון נתקע בגלל סטטוס NodePendingResize תלוי ב-PVC.

בגרסה 1.32, אשכולות עם צמתים בגרסה 1.31 או בגרסאות קודמות לא יצליחו לעדכן את הסטטוס של PersistentVolumeClaim במהלך שינוי הגודל. הסטטוס השגוי הזה מונע את תחילתן של פעולות שינוי גודל עוקבות, ולמעשה מונע שינויי גודל נוספים.

ל-PVC במצב הזה יש שדה status.allocatedResourceStatuses שמכיל את הערך NodePendingResize או את השדה status.allocatedResources ואת השדה status.conditions.type: FileSystemResizePending.

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

פתרון עקיף:

אפשר להחיל תיקון על PVCs שנתקעו בגלל סטטוס dangling כדי להסיר את הסטטוס הזה. כדי להסיר את הסטטוס 'תלוי ועומד', אפשר להשתמש בפקודת תיקון כמו זו שבהמשך:

kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}'

kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}'

• ‫1.32.4-gke.1236007, ‏ 1.32.4-gke.1353001

• ‫1.32.4-gke.1353003 ואילך

יכול להיות שהרישום ביומן של מנהל ההתקן PDCSI יהיה מוגזם

יכול להיות שבאשכולות GKE בגרסאות ספציפיות של 1.32 יופיעו הודעות יומן מוגזמות מדרייבר ה-PDCSI. הרישום העודף הזה ינצל את המכסה של Cloud Logging Write API.

פתרון עקיף:

כדי לצמצם את הרישום המוגזם הזה ביומן, אפשר להוסיף מסנן החרגה. כדי להחריג את הודעות היומן מהטמעה ב-Cloud Logging, משתמשים בשאילתה הבאה:

      resource.type="k8s_container"
      resource.labels.container_name="gce-pd-driver"
      (sourceLocation.file="cache.go" OR "Cannot process volume group")
    

• ‫1.27.16-gke.2440000 ואילך
• ‫1.28.15-gke.1673000 ואילך
• ‫1.29.13-gke.1038000 ואילך
• ‫1.30.9 ואילך
• גרסה 1.31.7 ואילך
• ‫1.32.1-gke.1357001 ואילך

• ‫1.27.16-gke.2691000 ואילך
• ‫1.28.15-gke.2152000 ואילך
• ‫1.29.15-gke.1218000 ואילך
• ‫1.30.11-gke.1190000 ואילך
• ‫1.31.7-gke.1363000 ואילך
• ‫1.32.4-gke.1106000 ואילך
• ‫1.33.0-gke.1552000 ואילך

פודים שמנסים לטעון כרכים קבועים של NFS בצמתי COS שבעבר הייתה להם טעינה לקריאה בלבד (RO) ייטענו רק במצב RO

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

פתרון עקיף:

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

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

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

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

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

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

Output: Mount failed: mount failed: exit status 127

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

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

פתרון עקיף:

שדרוג לאחור של מאגרי צמתים לגרסה 1.31.

• ‫1.28.15-gke.1668000 ואילך
• ‫1.29.13-gke.1028000 ואילך
• ‫1.30.8-gke.1287000 ואילך
• ‫1.31.6-gke.1020000 ואילך
• ‫1.32.1-gke.1369000 ואילך

יכול להיות שפודים שמשתמשים בקריאות מערכת שקשורות ל-io_uring ייתקעו במצב Terminating

יכול להיות שפודים שמשתמשים בקריאות מערכת שקשורות ל-io_uring ייכנסו למצב D (המתנה לדיסק), שנקרא גם TASK_UNINTERRUPTIBLE, בגלל באג בליבת לינוקס. אי אפשר להעיר תהליכים במצב D באמצעות אותות, כולל SIGKILL.

כש-Pod מושפע מהבעיה הידועה הזו, יכול להיות שהקונטיינרים שלו לא יסיימו את הפעולה בצורה תקינה. בלוגים של containerd, יכול להיות שתראו הודעות חוזרות שדומות להודעה הבאה: Kill container [container-id]. ההודעה הזו מציינת שהמערכת מנסה שוב ושוב לעצור קונטיינר.
במקביל, ביומני kubelet מוצגות הודעות שגיאה, כמו הבאות:

"Kill container failed" err="rpc error: code = DeadlineExceeded desc = context deadline exceeded"

או

"Error syncing pod, skipping" err="[failed to \"KillContainer\" for \"container-name\" with KillContainerError: \"rpc error: code = DeadlineExceeded desc = an error occurs during waiting for container \\\"container-id\\\" to be killed: wait container \\\"container-id\\\": context deadline exceeded\", failed to \"KillPodSandbox\" for \"pod-uuid\" with KillPodSandboxError: \"rpc error: code = DeadlineExceeded desc = context deadline exceeded\"]" pod="pod-name" podUID="pod-uuid"

הסימפטומים האלה מצביעים על תהליכים בתוך הקונטיינר שנתקעו במצב שינה שלא ניתן להפריע לו (מצב D), ולכן לא ניתן לסיים את הפוד בצורה תקינה.

עומסי עבודה שמשתמשים ב-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 ואילך

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

באג בתכונה Image streaming עלול לגרום לעומסי עבודה להיכשל אם מתקיימים תנאים ספציפיים בזמן שהקונטיינר קורא קבצים. יכול להיות שיופיעו הודעות שגיאה שקשורות לכשלים באימות ביומן של gcfsd.

כדי לבדוק אם אתם מושפעים מהבעיה, מחפשים ביומנים באמצעות שאילתת החיפוש הבאה: resource.type="k8s_node" resource.labels.project_id="[project_id]" resource.labels.cluster_name="[cluster_name]" logName="projects/[project_id]/logs/gcfsd" "backend.FileContent failed" "Request is missing required authentication credential."

הופעת השגיאות האלה מצביעה על כך שהצמתים מושפעים.

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

• ‫1.30.0 עד 1.30.5-gke.1443001
• ‫1.31.0 עד 1.31.1-gke.1678000

• ‫1.30.5-gke.1628000 ואילך
• ‫1.31.1-gke.1846000 ואילך

שיעורי פינוי גבוהים יותר של Pod בגרסאות GKE 1.30 ו-1.31

בגרסאות מסוימות של GKE 1.30 ו-GKE 1.31 שמשתמשות ב-COS 113 וב-COS 117 בהתאמה, יש ליבות שנבנו עם האפשרות CONFIG_LRU_GEN_ENABLED=y. האפשרות הזו מפעילה את תכונת הליבה Multi-Gen LRU, שגורמת ל-kubelet לחשב באופן שגוי את השימוש בזיכרון, ועלולה להוביל לכך ש-kubelet יסיר Pods.

אפשרות ההגדרה CONFIG_LRU_GEN_ENABLED מושבתת ב-cos-113-18244-151-96 וב-cos-117-18613-0-76.

יכול להיות שלא תמיד תראו שיעור חריג של הוצאת Pods כי הבעיה הזו תלויה בדפוס השימוש בזיכרון של עומס העבודה. קיים סיכון גבוה יותר ש-kubelet יסלק את ה-Pods עבור עומסי עבודה שלא הוגדרה להם מגבלת זיכרון בשדה resources. הסיבה לכך היא שעומסי העבודה עשויים לבקש יותר זיכרון ממה ש-kubelet מדווח כזמין.

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

כדי לבדוק אם יש שיעורי הוצאה חריגים של Pod, מנתחים את המדדים הבאים באמצעות Metrics Explorer: kubernetes.io/container_memory_used_bytes ו- kubernetes.io/container_memory_request_bytes

אפשר להשתמש בשאילתות PromQL הבאות. מחליפים את הערכים של cluster_name, ‏ namespace_name, ‏ metadata_system_top_level_controller_type ו-metadata_system_top_level_controller_name בשם ובסוג של עומס העבודה שרוצים לנתח:

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

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

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

תאי Pod תקועים בסטטוס Terminating (הפסקת פעולה)

באג בזמן הריצה של הקונטיינר (containerd) עלול לגרום לכך ש-Pods וקונטיינרים ייתקעו במצב Terminating עם שגיאות דומות לאלה:

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

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

הסטרימינג של התמונה נכשל בגלל קישורים סמליים

באג בתכונה Image streaming עלול לגרום לכך שמאגרי תמונות לא יתחילו.

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

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

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

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

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

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

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

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

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

זיהינו בעיה בהגדרת TLS לשערי כניסה באשכולות שמופעלת בהם גרסת GKE‏ 1.28.4-gke.1083000. הדבר משפיע על הגדרות TLS שמשתמשות ב-SSLCertificate או ב-CertificateMap. אם משדרגים אשכול עם שערים קיימים, העדכונים שבוצעו בשער ייכשלו. במקרה של שערים חדשים, מאזני העומסים לא יוקצו. הבעיה הזו תיפתר בגרסת תיקון (patch) קרובה של 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 ואילך

התאמה אוטומטית לעומס העבודה לכל עומסי העבודה נפסקת

יכול להיות שהתכונות 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 מופיע במסמכי התיעוד של Kubernetes בנושא HorizontalPodAutoscaler.

• 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 Pods אחרי שדרוג של מישור הבקרה

באשכולות שבהם מדיניות הרשת מופעלת, יכולות להיות בעיות בקישוריות עם 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 Pod תקוע במצב CrashLoopBackOff

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

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

הפעלת ה-Pods בצמתים עם הפעלת Image streaming נכשלת

יכול להיות שעומסי עבודה לא יופעלו בצמתים שבהם מופעלת הזרמת תמונות, עם חתימת השגיאה הבאה: Failed to create pod sandbox ... context deadline exceeded

היומנים של היציאה הטורית של צומת מושפע מכילים גם את חתימת השגיאה הבאה: task gcfsd ... blocked for more than X seconds

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

הפחתת הסיכון:

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

gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming

• ‫1.32.4-gke.1198000 ואילך
• ‫1.33 גרסאות לפני 1.33.5-gke.1862000
• גרסאות 1.34 לפני 1.34.1-gke.2541000

• ‫1.33.5-gke.1862000 ואילך
• ‫1.34.1-gke.2541000 ואילך

‫Custom ComputeClasses עם ImageType שלא משתמשים במאגרי צמתים קיימים של GKE.

כשמשתמשים ב-ComputeClass בהתאמה אישית שמגדיר שדה ImageType, הכלי Cluster Autoscaler יוצר שוב ושוב מאגרי צמתים חדשים ומגדיל את הגודל שלהם, במקום להגדיל את הגודל של מאגרי צמתים קיימים. הסטטוס של ComputeClass לא תקין.

פתרון עקיף:

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

• ‫1.33.5-gke.1862000 ואילך
• ‫1.34.1-gke.2541000 ואילך

אפשרות נוספת היא להגדיר שדות מסוימים ב-ComputeClass המותאם אישית.

• אם לא משתמשים ב-ComputeClass בהתאמה אישית ב-Autopilot, לא מגדירים את השדה ImageType. במקרה כזה, הערך שבו נעשה שימוש הוא הגדרת ברירת המחדל ברמת האשכול, שהיא cos_containerd כברירת מחדל.
• אם אתם משתמשים ב-ComputeClass בהתאמה אישית ב-Autopilot, אל תגדירו את השדה nodePoolConfig, שהוא ברמה אחת ImageType.