בדף הזה מפורטות בעיות מוכרות שקשורות לרשתות GKE. הדף הזה מיועד לאדמינים ולארכיטקטים שמנהלים את מחזור החיים של תשתית הטכנולוגיה הבסיסית, ומגיבים להתראות ולדפים כשלא עומדים ביעדי רמת השירות (SLO) או כשהאפליקציות נכשלות.
כדי לסנן את הבעיות הידועות לפי גרסת מוצר, בוחרים את המסננים מהתפריטים הנפתחים הבאים.
בוחרים את גרסת GKE:
אפשר גם לחפש את הבעיה:
| הגרסאות שזוהו | גרסאות קבועות | הבעיה והפתרון העקיף |
|---|---|---|
| 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 שהוקצו כשמתרחשות שגיאות זמניות ב-CNI במהלך יצירת ה-Pods. הבעיה מתרחשת כשמשדרגים את הצומת של אשכול 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 |
|
צמתים שנוצרו לאחרונה לא נוספים למאזני עומסים פנימיים בשכבה 4יכול להיות שמאזני עומסים (LB) שנוצרו לשירותים פנימיים של LoadBalancer לא יכללו צמתים חדשים שנוצרו בקבוצת המכונות של הבק-אנד. Google Cloud הבעיה תהיה הכי בולטת באשכול שהורחב לאפס צמתים ואז צומצם בחזרה לצומת אחד או יותר. פתרונות אפשריים:
|
| 1.31,1.32 |
|
בעיות ב-Gateway API בגלל הסרת storedVersions ממצב CRD
Kube-Addon-Manager ב-GKE מסיר באופן שגוי את האשכול שלכם עלול להיות בסיכון אם מתקיימים כל התנאים הבאים:
פתרון עקיף: הפתרון המומלץ הוא לדחות את השדרוגים של האשכולות עד שהבעיה תיפתר.
לחלופין, אם אתם צריכים לשדרג את גרסת האשכול, אתם צריכים לעדכן את גרסת האחסון של כל ה-CRD של Gateway API המושפעים ל-
|
| 1.32 |
|
הפעלת Pods חדשים נכשלת והם נתקעים במצב 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 שהוקצו לא סונכרן בצורה נכונה עם מצב שרת Kubernetes API.
כדי לוודא את גרסת 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, MCI ושער GKE מרובה אשכולות. פתרון עקיף: כשמסירים יציאה משירות עם הערה של 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 שהוגדרו לשירות. לדוגמה, אם לשירות יש פוד אחד של קצה עורפי, החיבור תמיד נכשל. אם לשירות יש 2 תרמילי Backend, החיבור נכשל ב-50% מהמקרים. פתרון עקיף:
כדי לפתור את הבעיה הזו, צריך להגדיר את הערכים |
| 1.27,1.28 |
|
אובדן מנות בזרימות של חיבורי hairpinבקטעי קוד עם 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 צמתים בסך הכול, לכל צומת יש מכסת ליבות וירטואליות (vCPU) של 1 או פחות, ומדיניות הרשת מופעלת. הסיבה לכך היא מחסור במשאבי CPU. פתרונות אפשריים:
|
|
הפסקות זמניות בשערים מרובי-אשכולות (MCG) באשכולות אזוריים במהלך שדרוגים של רמת הבקרהפריסות שמשתמשות ב-Multi-Cluster Gateway (MCG) באשכולות אזוריים של GKE עלולות לחוות הפסקות שירות עם שגיאות מסוג `503` במהלך אירועים שגורמים להפעלה מחדש של מישור הבקרה, כמו שדרוג של אשכול. הבעיה הזו מתרחשת כי MCG מסתמך על מנגנון מדור קודם לגילוי של קבוצת נקודות קצה ברשת (NEG), שמדווח באופן שגוי על אפס בק-אנדים כשצמתים באשכול אזורי הופכים ללא זמינים באופן זמני במהלך ההפעלה מחדש של מישור הבקרה. כתוצאה מכך, מאזן העומסים מסיר את כל השרתים העורפיים, מה שגורם לאובדן תנועה. פתרונות אפשריים:
|
||
מרוץ תהליכים בשער מוכנות של NEGבתנאים מסוימים, יכול להיות שמסנני המוכנות יחזירו מצב מוכנות של 'חיובי כוזב' לפני שבדיקת התקינות של הכניסה תדווח על מצב תקין, וכך ייווצרו אירועי שגיאה כמו הבאים באובייקט הכניסה:
הבעיה הזו גורמת למאזן העומסים לדווח על שגיאה אם יש מספר קטן יחסית של Pods (לדוגמה, 2) בהשוואה למספר ה-NEGs, הסיכון ל מרוץ תהליכים הזה גדל. נוצרים NEGs לכל אזור, עם NEG אחד לכל אזור, מה שבדרך כלל מוביל לשלושה NEGs. אם יש מספר גדול יחסית של Pods, כך שלכל NEG יש תמיד כמה Pods לפני שתהליך העדכון בהדרגה (rolling) מתחיל, הסיכוי להפעלת מרוץ תהליכים זה הוא נמוך מאוד. פתרון עקיף: הדרך הכי טובה למנוע את מרוץ התהליכים הזה היא להוסיף עוד שרתים עורפיים לקבוצת נקודות הקצה ברשת. חשוב לוודא ששיטת העדכון בהדרגה (rolling) מוגדרת כך שלפחות Pod אחד תמיד פועל. לדוגמה, אם רק 2 פודים פועלים בדרך כלל, הגדרה לדוגמה יכולה להיראות כך: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 הדוגמה הקודמת היא הצעה. צריך לעדכן את האסטרטגיה על סמך כמה גורמים, כמו מספר העותקים. |
||
איסוף אשפה לא מלא של מאזני עומסים שמקורם בקונטיינרמערכת GKE מבצעת איסוף אשפה של מאזני עומסים שמקורם בקונטיינר כל שתי דקות. אם אשכול נמחק לפני שמאזני העומסים הוסרו לגמרי, צריך למחוק ידנית את קבוצות ה-NEG של מאזן העומסים. פתרון עקיף: כדי לראות את קבוצות ה-NEG בפרויקט, מריצים את הפקודה הבאה: gcloud compute network-endpoint-groups list בפלט פקודה, מחפשים את קבוצות ה-NEG הרלוונטיות. כדי למחוק NEG, מריצים את הפקודה הבאה ומחליפים את gcloud compute network-endpoint-groups delete <var>NEG_NAME</var> |
||
התאמה של השקת עומסי עבודה להפצה של נקודות קצההבעיה הזו לא מתרחשת באשכולות שמשתמשים במשוב על מוכנות של Pod כדי לנהל השקות של עומסי עבודה. כשפורסים עומס עבודה באשכול או כשמעדכנים עומס עבודה קיים, יכול להיות שיעבור יותר זמן עד שמאזן העומסים המקורי של הקונטיינר יפיץ נקודות קצה חדשות, מאשר עד לסיום הפריסה של עומס העבודה. פתרון עקיף: כדי לוודא שלא יהיו שיבושים בשירות בגלל פריסת עומסי עבודה, צריך להגדיר את הערכים של
|
||
ההגדרה initialDelaySeconds ב-readinessProbe של Pod לא מכובדתיכול להיות שתצפו שההגדרה של |