בדף הזה מפורטות בעיות מוכרות ברישות ב-GKE. הדף הזה מיועד לאדמינים ולארכיטקטים שמנהלים את מחזור החיים של תשתית הטכנולוגיה הבסיסית, ומגיבים להתראות ולדפים כשלא עומדים ביעדי רמת השירות (SLO) או כשהאפליקציות נכשלות.
כדי לסנן את הבעיות הידועות לפי גרסת מוצר, בוחרים את המסננים מהתפריטים הנפתחים הבאים.
בוחרים את גרסת GKE:
אפשר גם לחפש את הבעיה:
| גרסאות שזוהו | גרסאות קבועות | הבעיה והפתרון העקיף |
|---|---|---|
| תרשים Helm של InferencePool גרסה 1.1.0 |
InferencePool targetPortNumber flag ignoredבגרסה פתרון עקיף: בודקים את היציאה אחרי ההתקנה: kubectl get inferencepool POOL_NAME -o jsonpath='{.spec.targetPorts}' \ --context=CLUSTER_CONTEXT אם היציאה שגויה, צריך לתקן את kubectl patch inferencepool POOL_NAME --type=merge \ -p '{"spec":{"targetPorts":[{"number":TARGET_PORT}]}}' \ --context=CLUSTER_CONTEXT |
|
| 1.33, 1.34, 1.35 |
|
קישוריות ל-Pod לסירוגין או כשלים ב-DNS בגלל מחיקה של
|
| 1.29, 1.30, 1.31, 1.32, 1.33 | 1.34 |
קריסת מאגר
|
| 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 |
דליפת כתובת IP של Pod בצמתים עם GKE Dataplane V2באשכולות שבהם מופעל GKE Dataplane V2, יכול להיות שכתובות ה-IP של ה-Pods יאזלו בצמתים. הבעיה הזו נגרמת על ידי באג בזמן הריצה של הקונטיינר, שיכול לגרום לדליפה של כתובות IP שהוקצו כש-Pods נתקלים בשגיאות CNI זמניות במהלך היצירה. הבעיה מתרחשת כשמשדרגים את הצומת של אשכול GKE לגרסה הבאה של GKE או יוצרים אותו באמצעות אחת מהגרסאות האלה:
במקרה כזה, הפעלתם של פודים חדשים שמתוזמנים בצומת המושפע נכשלת ומוחזרת הודעת שגיאה שדומה להודעה הבאה: פתרון עקיף: כדי לפתור את הבעיה, אפשר להחיל את DaemonSet של הפתרון על האשכול כדי לנקות את משאבי ה-IP שדלפו: apiVersion: apps/v1 kind: DaemonSet metadata: name: cleanup-ipam-dir namespace: kube-system spec: selector: matchLabels: name: cleanup-ipam template: metadata: labels: name: cleanup-ipam spec: hostNetwork: true securityContext: runAsUser: 0 runAsGroup: 0 seccompProfile: type: RuntimeDefault automountServiceAccountToken: false containers: - name: cleanup-ipam image: gcr.io/gke-networking-test-images/ubuntu-test:2022@sha256:6cfbdf42ccaa85ec93146263b6e4c60ebae78951bd732469bca303e7ebddd85e command: - /bin/bash - -c - | while true; do for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do hash="${hash%%[[:space:]]}" if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then grep -ilr $hash /hostipam fi done | xargs -r rm echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)" sleep 120s done volumeMounts: - name: host-ipam mountPath: /hostipam - name: host-ctr mountPath: /run/containerd securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL volumes: - name: host-ipam hostPath: path: /var/lib/cni/networks/gke-pod-network - name: host-ctr hostPath: path: /run/containerd |
|
| 1.31, 1.32, 1.33 |
|
הפסקות זמניות בשירות של מאזני עומסים מסוג Ingress ומאזני עומסים של שירותים באשכולות עם רשת מדור קודםחוסר תאימות לרשתות מדור קודם גורם לניתוק של קצה העורף של מאזן עומסים בניהול GKE שנפרס באמצעות Ingress או Service. כתוצאה מכך, למאזן העומסים אין קצה עורפי פעיל, ולכן כל הבקשות הנכנסות למאזני העומסים האלה נדחות. הבעיה משפיעה על אשכולות GKE שמשתמשים ברשת מדור קודם ופועלים בגרסה 1.31 ואילך. כדי לזהות אשכולות GKE עם רשת מדור קודם, מריצים את הפקודה הבאה:
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"
במקרה של אשכול עם רשת מדור קודם, הפלט של הפקודה הזו יהיה ריק. פתרון עקיף: רשתות מדור קודם הוצאו משימוש לפני זמן מה, ולכן הפתרון המומלץ הוא להעביר את הרשת מדור קודם לרשת VPC. אפשר לעשות את זה על ידי המרת רשת מדור קודם שמכילה אשכולות GKE. אם אתם לא יכולים לבצע את ההעברה הזו כרגע, אתם יכולים לפנות אל Cloud Customer Care. |
| 1.30, 1.31, 1.32 |
|
צמתים שנוצרו לאחרונה לא נוספים למאזני עומסים פנימיים בשכבה 4Google Cloud יכול להיות שמאזני עומסים שנוצרו לשירותים פנימיים של LoadBalancer לא יכללו צמתים חדשים שנוצרו בקבוצת המכונות של הבק-אנד. הבעיה תהיה הכי בולטת באשכול שהוגדר בו קנה מידה של אפס צמתים ואז הוגדר בו קנה מידה של צומת אחד או יותר. פתרונות אפשריים:
|
| 1.31,1.32 |
|
בעיות ב-Gateway API בגלל הסרת storedVersions מסטטוס ה-CRD
ה-Kube-Addon-Manager ב-GKE מסיר באופן שגוי את האשכול שלכם עלול להיות בסיכון אם מתקיימים כל התנאים הבאים:
פתרון עקיף: הפתרון המומלץ הוא לדחות את השדרוגים של האשכולות עד שהבעיה תיפתר.
לחלופין, אם אתם צריכים לשדרג את גרסת האשכול, אתם צריכים לעדכן את גרסת האחסון של כל ה-CRD של Gateway API המושפעים ל-
|
| 1.32 |
|
תאי Pod חדשים שלא מצליחים לבצע אתחול נתקעים במצב ContainerCreating
יצירת תרמילים חדשים נכשלת והם נתקעים במצב Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "[sandbox-ID]": plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded הבעיה משפיעה על אשכולות GKE בגרסאות שבין 1.32 לבין גרסאות מוקדמות מ-1.32.3-gke.1170000, שנוצרו בגרסאות GKE 1.31 או 1.32. הסיבה הבסיסית היא שמבנה נתונים בזיכרון ששמר אוסף של זהויות Cilium שהוקצו לא סונכרן בצורה נכונה עם מצב שרת ה-API של Kubernetes.
כדי לוודא איזו גרסת GKE שימשה ליצירת האשכול, אפשר להריץ שאילתה על משאב gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
אם הרישום ביומן מופעל באשכול GKE, מאגר resource.type="k8s_container" resource.labels.container_name="cilium-agent" פתרון עקיף: פתרון זמני הוא להפעיל מחדש את רמת הבקרה. אפשר לעשות זאת על ידי שדרוג מישור הבקרה לאותה גרסה שכבר פועלת: gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master |
| 1.27,1.28,1.29,1.30,1.31 |
ה-NEG Controller מפסיק לנהל נקודות קצה כשמסירים יציאה משירותאם בקר ה-NEG מוגדר ליצור Standalone NEG עבור שירות, ואחד מהפורטים המוגדרים מוסר מהשירות בהמשך, בקר ה-NEG יפסיק בסופו של דבר לנהל את נקודות הקצה של ה-NEG. בנוסף לשירותים שבהם המשתמש יוצר הערה של NEG עצמאי, זה משפיע גם על שירותים שמפנים אליהם GKE Gateway, MCI ו-GKE Multi Cluster Gateway. פתרון עקיף: כשמסירים יציאה משירות עם הערה של Standalone NEG, צריך לעדכן גם את ההערה כדי להסיר את היציאה הרלוונטית. |
|
| 1.28 |
שגיאה בהגדרת TLS של שערזיהינו בעיה בהגדרת TLS לשערי כניסה באשכולות שמופעלת בהם גרסת GKE 1.28.4-gke.1083000. הבעיה הזו משפיעה על הגדרות TLS שמשתמשות ב-SSLCertificate או ב-CertificateMap. אם משדרגים אשכול עם שערים קיימים, העדכונים שבוצעו בשער ייכשלו. במקרה של שערים חדשים, מאזני העומסים לא יוקצו. הבעיה הזו תיפתר בגרסת תיקון (patch) קרובה של GKE 1.28. |
|
| 1.27, 1.28, 1.29 |
|
כשלים לסירוגין ביצירת חיבוריכול להיות שבאשכולות בגרסאות של מישור הבקרה 1.26.6-gke.1900 ואילך יתרחשו כשלים לסירוגין בהקמת חיבורים. הסיכויים לכשלים נמוכים, והבעיה לא משפיעה על כל האשכולות. הכשלים אמורים להיפסק לחלוטין אחרי כמה ימים מתחילת הסימפטום. |
| 1.27, 1.28, 1.29 |
|
בעיות בפענוח DNS במערכת הפעלה שמותאמת לקונטיינריםיכול להיות שיהיו בעיות בפענוח DNS בעומסי עבודה שפועלים באשכולות GKE עם צמתים שמבוססים על מערכת הפעלה שמותאמת לקונטיינרים. |
| 1.28 | 1.28.3-gke.1090000 ואילך |
מדיניות הרשת מפסיקה חיבור בגלל חיפוש שגוי של מעקב אחר חיבוריםבאשכולות שבהם מופעל GKE Dataplane V2, כש-Pod של לקוח מתחבר לעצמו באמצעות שירות או כתובת ה-IP הווירטואלית של מאזן עומסי רשת פנימי מסוג passthrough, חבילת התשובה לא מזוהה כחלק מחיבור קיים בגלל חיפוש שגוי של conntrack ב-dataplane. המשמעות היא שמדיניות רשת שמגבילה תעבורת נתונים נכנסת (ingress) ל-Pod נאכפת בצורה שגויה על החבילה. ההשפעה של הבעיה הזו תלויה במספר ה-Pods שהוגדרו לשירות. לדוגמה, אם לשירות יש Pod אחד בעורף, החיבור תמיד נכשל. אם לשירות יש 2 תרמילי Backend, החיבור נכשל ב-50% מהמקרים. פתרון עקיף:
כדי לצמצם את הבעיה, צריך להגדיר את הערכים |
| 1.27,1.28 |
|
השמטת מנות לזרימות של חיבורים עם פניות חדותבקטעי קוד עם GKE Dataplane V2 מופעל, כש-Pod יוצר חיבור TCP לעצמו באמצעות Service, כך ש-Pod הוא גם המקור וגם היעד של החיבור, מעקב החיבורים של GKE Dataplane V2 eBPF עוקב אחרי מצבי החיבור באופן שגוי, מה שמוביל לדליפה של רשומות conntrack. כשמתרחשת דליפה של טופל חיבור (פרוטוקול, כתובת IP של המקור/היעד ויציאת המקור/היעד), חיבורים חדשים שמשתמשים באותו טופל חיבור עלולים לגרום להשמטה של מנות חוזרות. פתרון עקיף: אפשר לנסות את הפתרונות הבאים:
|
| גרסה מוקדמת יותר מ-1.31.0-gke.1506000 | 1.31.0-gke.1506000 ואילך |
הקלדת רשת במכשיר ב-GKE multi-network נכשלת עם שמות רשת ארוכיםיצירת האשכול נכשלת עם השגיאה הבאה:
פתרון עקיף: הגבלת האורך של שמות אובייקטים ברשת מסוג מכשיר ל-41 תווים או פחות. הנתיב המלא של כל שקע דומיין של UNIX מורכב, כולל שם הרשת המתאים. יש מגבלה ב-Linux על אורך נתיבי שקע (עד 107 בייט). אחרי שכוללים את הספרייה, הקידומת של שם הקובץ והסיומת |
| 1.27, 1.28, 1.29, 1.30 |
|
בעיות בקישוריות של
|
| 1.31, 1.32 |
|
תעבורת UDP פגומה בין Pods שפועלים באותו צומתבאשכולות שבהם הופעלה חשיפה בתוך הצומת, יכול להיות שתהיה תנועת UDP שבורה בין Pods שפועלים באותו צומת. הבעיה מתרחשת כשמשדרגים את הצומת של אשכול GKE לגרסה הבאה של GKE או יוצרים אותו באמצעות אחת מהגרסאות האלה:
הנתיב המושפע הוא תעבורת UDP מ-Pod ל-Pod באותו צומת דרך Hostport או Service. פתרון משדרגים את האשכול לאחת מהגרסאות המתוקנות הבאות:
|
| 1.28, 1.29, 1.30, 1.31 |
תקינות הפודים של Calico באשכולות עם פחות מ-3 צמתים בסך הכול ועם vCPU לא מספיקאי אפשר לתזמן פודים של calico-typha ו-calico-node באשכולות שעומדים בכל התנאים הבאים: יש פחות מ-3 צמתים בסך הכול, לכל צומת יש 1 או פחות vCPU שניתנים להקצאה, ומדיניות הרשת מופעלת. הסיבה לכך היא מחסור במשאבי CPU. פתרונות אפשריים:
|
|
הפסקות בשירות Multi-Cluster Gateway (MCG) באשכולות אזוריים במהלך שדרוגים של רמת הבקרהפריסות שמשתמשות ב-Multi-Cluster Gateway (MCG) באשכולות אזוריים של GKE עלולות לחוות הפסקות שירות עם שגיאות מסוג `503` במהלך אירועים שגורמים להפעלה מחדש של מישור הבקרה, כמו שדרוג של אשכול. הבעיה הזו מתרחשת כי MCG מסתמך על מנגנון מדור קודם לגילוי של קבוצת נקודות קצה ברשת (NEG), שמדווח באופן שגוי על אפס שרתי קצה עורפיים כשצמתים באשכול אזורי הופכים ללא זמינים באופן זמני במהלך ההפעלה מחדש של מישור הבקרה. כתוצאה מכך, מאזן העומסים מסיר את כל השרתים העורפיים, מה שגורם לאובדן תנועה. פתרונות אפשריים:
|
||
מרוץ תהליכים בשער מוכנות של NEGבתנאים מסוימים, יכול להיות שמנגנוני מוכנות יחזירו מצב מוכן של 'חיובי כוזב' לפני שבדיקת התקינות של הכניסה תדווח על מצב תקין, וכך ייווצרו אירועי שגיאה כמו הבאים באובייקט הכניסה:
הבעיה הזו גורמת למאזן העומסים לדווח על שגיאה אם יש מספר קטן יחסית של Pods (לדוגמה, 2) בהשוואה למספר ה-NEGs, הסיכון למצב המירוץ הזה יגדל. קבוצות NEG נוצרות לכל אזור, עם קבוצת NEG אחת לכל אזור, מה שבדרך כלל מוביל לשלוש קבוצות NEG. אם יש מספר גדול יחסית של פודים, כך שלכל NEG יש תמיד כמה פודים לפני שתהליך העדכון בהדרגה (rolling) מתחיל, הסיכוי להפעלת מרוץ תהליכים זה נמוך מאוד. פתרון עקיף: הדרך הכי טובה למנוע את מרוץ התהליכים הזה היא להוסיף עוד שרתים עורפיים לקבוצת נקודות הקצה ברשת. מוודאים ששיטת העדכון בהדרגה (rolling) מוגדרת כך שלפחות Pod אחד תמיד פועל. לדוגמה, אם רק 2 פודים פועלים בדרך כלל, הגדרה לדוגמה יכולה להיראות כך: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 הדוגמה הקודמת היא הצעה. צריך לעדכן את האסטרטגיה על סמך כמה גורמים, כמו מספר העותקים. |
||
מנגנון איסוף לא מלא של מאזני עומסים שמקורם בקונטיינרמערכת GKE מבצעת איסוף אשפה של מאזני עומסים שמקורם בקונטיינר כל שתי דקות. אם אשכול נמחק לפני שמאזני העומסים הוסרו לגמרי, צריך למחוק ידנית את קבוצות ה-NEG של מאזן העומסים. פתרון עקיף: כדי לראות את קבוצות ה-NEG בפרויקט, מריצים את הפקודה הבאה: gcloud compute network-endpoint-groups list בפלט פקודה, מחפשים את ה-NEGs הרלוונטיים. כדי למחוק NEG, מריצים את הפקודה הבאה ומחליפים את gcloud compute network-endpoint-groups delete <var>NEG_NAME</var> |
||
התאמה של השקת עומסי עבודה להפצה של נקודות קצההבעיה הזו לא מתרחשת באשכולות שמשתמשים במשוב על מוכנות של Pod כדי לנהל השקות של עומסי עבודה. כשפורסים עומס עבודה באשכול או כשמעדכנים עומס עבודה קיים, יכול להיות שיחלפו יותר זמן עד שמאזן העומסים המקורי של הקונטיינר יפיץ נקודות קצה חדשות, מאשר עד לסיום הפריסה של עומס העבודה. פתרון עקיף: כדי לוודא שלא יהיו שיבושים בשירות בגלל פריסת עומסי עבודה, צריך להגדיר את הערכים של
|
||
ההגדרה initialDelaySeconds ב-readinessProbe של Pod לא מכובדתיכול להיות שתצפו שההגדרה של |