פתרון בעיות באשכולות של Autopilot

בעיות באשכולות Autopilot של Google Kubernetes Engine‏ (GKE) יכולות להשפיע על הזמינות של האפליקציה ועל היעילות התפעולית שלה. הבעיות האלה יכולות לשבש את כל מחזור החיים של האפליקציות, מהפריסה הראשונית ועד להרחבה בעומס.

בדף הזה מוסבר איך לאבחן ולפתור בעיות נפוצות שספציפיות לאשכולות Autopilot. כאן תוכלו למצוא הנחיות לפתרון בעיות שמונעות הקצאה של אשכולות, בעיות שקשורות לשינוי קנה מידה כמו שגיאות out of resources ובעיות שקשורות לעומסי עבודה ספציפיים כמו שגיאות באחסון זמני או Pods שנתקעו במצב Pending.

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

בעיות באשכולות

אי אפשר ליצור אשכול: 0 צמתים רשומים

הבעיה הבאה מתרחשת כשמנסים ליצור אשכול Autopilot עם חשבון שירות של IAM שמושבת או שאין לו את ההרשאות הנדרשות. יצירת האשכול נכשלת ומוצגת הודעת השגיאה הבאה:

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

כדי לפתור את הבעיה:

  1. בודקים אם חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine או חשבון השירות בהתאמה אישית ב-IAM שבו רוצים להשתמש מושבתים:

    gcloud iam service-accounts describe SERVICE_ACCOUNT

    מחליפים את SERVICE_ACCOUNT בכתובת האימייל של חשבון השירות, למשל my-iam-account@my-first-project.s3ns.iam.gserviceaccount.com.

    אם חשבון השירות מושבת, הפלט דומה לזה:

    disabled: true
displayName: my-service-account
email: my-service-account@my-project.s3ns.iam.gserviceaccount.com
...

  2. אם חשבון השירות מושבת, מפעילים אותו:

    gcloud iam service-accounts enable SERVICE_ACCOUNT

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

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT" \
    --role roles/container.defaultNodeServiceAccount

מרחב השמות תקוע במצב Terminating כשיש 0 צמתים באשכול

הבעיה הבאה מתרחשת כשמוחקים מרחב שמות באשכול אחרי שהאשכול מצטמצם לאפס צמתים. הרכיב metrics-server לא יכול לקבל את הבקשה למחיקת מרחב השמות כי יש לו אפס רפליקות.

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

kubectl describe ns/NAMESPACE_NAME

מחליפים את NAMESPACE_NAME בשם של מרחב השמות.

הפלט שיתקבל:

Discovery failed for some groups, 1 failing: unable to retrieve the complete
list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to
handle the request

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

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

ההרחבה האנכית של הצומת נכשלה: יכול להיות שה-Pod לא יתוזמן

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

הודעת השגיאה ביומן האירועים של Kubernetes דומה להודעה הבאה:

LAST SEEN   TYPE      REASON          OBJECT                          MESSAGE
12s         Warning   FailedScaleUp   pod/pod-test-5b97f7c978-h9lvl   Node scale up in zones associated with this pod failed: Internal error. Pod is at risk of not being scheduled

יכול להיות שרישום ביומן של היציאה הטורית מושבת ברמת הארגון באמצעות מדיניות ארגונית שאוכפת את האילוץ compute.disableSerialPortLogging. אפשר גם להשבית את רישום היציאה הטורית ביומן ברמת הפרויקט או ברמת המכונה הווירטואלית (VM).

כדי לפתור את הבעיה:

  1. מבקשים מהאדמין של מדיניות הארגון Cloud de Confiance by S3NS להסיר את האילוץ compute.disableSerialPortLogging בפרויקט עם אשכול Autopilot.
  2. אם אין לכם מדיניות ארגונית שאוכפת את המגבלה הזו, נסו להפעיל את רישום היציאה הטורית ביומן במטא-נתונים של הפרויקט. כדי לבצע את הפעולה הזו נדרשת הרשאת ה-IAM‏ compute.projects.setCommonInstanceMetadata.

הגדלת קנה המידה של הצומת נכשלה: נגמרו המשאבים ב-Compute Engine

הבעיה הבאה מתרחשת כשעומסי העבודה מבקשים יותר משאבים ממה שזמין לשימוש באזור או בתחום של Compute Engine. יכול להיות שה-Pods יישארו במצב Pending.

  • כדי לבדוק את האירועים של ה-Pod:

    kubectl events --for='pod/POD_NAME' --types=Warning

    מחליפים את RESOURCE_NAME בשם של המשאב ב-Kubernetes שנמצא בהמתנה. לדוגמה pod/example-pod.

    הפלט אמור להיראות כך:

    LAST SEEN         TYPE            REASON                  OBJECT                   Message
19m               Warning         FailedScheduling        pod/example-pod          gke.io/optimize-utilization-scheduler  0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
14m               Warning         FailedScheduling        pod/example-pod          gke.io/optimize-utilization-scheduler  0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
12m (x2 over 18m) Warning         FailedScaleUp           cluster-autoscaler       Node scale up in zones us-central1-f associated with this pod failed: GCE out of resources. Pod is at risk of not being scheduled.
34s (x3 over 17m) Warning         FailedScaleUp           cluster-autoscaler       Node scale up in zones us-central1-b associated with this pod failed: GCE out of resources. Pod is at risk of not being scheduled.

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:

  • פורסים את ה-Pod באזור או בתחום אחר. אם ל-Pod יש הגבלה אזורית, כמו בורר טופולוגיה, הסירו את ההגבלה אם אפשר. להוראות, קראו את המאמר הצבת פודים של GKE באזורים ספציפיים.
  • יוצרים אשכול באזור אחר ומנסים שוב לפרוס.
  • נסו להשתמש במחלקת מחשוב אחרת. במחלקות Compute שמגובות בסוגי מכונות קטנים יותר של Compute Engine, יש סיכוי גבוה יותר שיהיו משאבים זמינים. לדוגמה, סוג המכונה שמוגדר כברירת מחדל ב-Autopilot הוא בעל הזמינות הגבוהה ביותר. רשימה של סוגי מכונות וסוגי המכונות התואמים מופיעה במאמר מתי להשתמש בסוגי מכונות ספציפיים.
  • אם אתם מריצים עומסי עבודה של GPU, יכול להיות שה-GPU שביקשתם לא זמין במיקום של הצומת. נסו לפרוס את עומס העבודה במיקום אחר או לבקש סוג אחר של GPU.

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

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

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

הודעת השגיאה ביומנים דומה להודעה הבאה:

    "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              ...

השגיאה הזו מתייחסת לאירוע noScaleUp, שבו הקצאת צמתים אוטומטית (NAP) לא הקצתה אף קבוצת צמתים ל-Pod באזור.

אם נתקלתם בשגיאה הזו, בדקו את הדברים הבאים:

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

הבעיה הזו מתרחשת כשעומס עבודה עם שמירת מצב משתמש בסוג קודם של נפח Persistent Disk, כמו נפחי דיסק מתמיד סטנדרטי (pd-standard) או נפחי דיסק מתמיד שמבוסס על SSD‏ (pd-ssd). סוגי אמצעי האחסון האלה לא תואמים לסדרות מכונות חדשות יותר, כמו C3 או E4.

הבעיה הזו יכולה להתבטא באחת משתי דרכים:

  • תופעה 1: עומס עבודה שאתם מצפים שירוץ בסדרת מכונות חדשה יותר לשימוש כללי (כמו C3) מתוזמן אוטומטית לצומת E2 במקום זאת.
  • תסמין 2: פוד שמבקש במפורש סדרת מכונות חדשה יותר (לדוגמה, באמצעות שדות nodeSelector או ComputeClass בהתאמה אישית) נשאר תקוע במצב Pending.

שורש הבעיה

ב-GKE Autopilot יש אכיפה של תאימות בין סוגי האחסון המבוקשים לבין סדרת המכונות של הצומת. בסדרות מכונות חדשות יותר, כמו C3 ו-E4, נדרש אחסון ב-Google Cloud Hyperdisk (כמו סוג הדיסק hyperdisk-balanced). בסדרות המכונות האלה אי אפשר להשתמש בסוגי נפחים קודמים של Persistent Disk, כמו נפחים של דיסק מתמיד סטנדרטי (pd-standard) או של דיסק מתמיד שמבוסס על SSD‏ (pd-ssd).

  • אם לא תציינו סדרת מכונות, GKE Autopilot יתזמן באופן אוטומטי את עומס העבודה בצומת E2, כי צומתי E2 תומכים בסוגי הנפחים האלה של Persistent Disk. עומס העבודה חוזר באופן אוטומטי מהחומרה החדשה יותר שמוגדרת כברירת מחדל.
  • אם אתם מבקשים במפורש סדרת מכונות חדשה יותר (כמו C3 או E4) אבל מצרפים סוג קודם של נפח דיסק מתמיד, כמו נפחי דיסק מתמיד סטנדרטי (pd-standard) או דיסק מתמיד שמבוסס על SSD‏ (pd-ssd), ‏GKE Autopilot לא יכול לעמוד בשתי הדרישות. ה-Pod נשאר תקוע במצב Pending.

אימות

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

  1. בודקים את הגדרת הנפח של ה-Pod כדי לראות אם הוא משתמש בסוג קודם של נפח דיסק מתמיד, כמו דיסק מתמיד סטנדרטי (pd-standard) או דיסק מתמיד שמבוסס על SSD‏ (pd-ssd).

  2. אם ה-Pod תקוע במצב Pending, צריך לבדוק את יומני החשיפה של המידרוג האוטומטי באשכול. מחפשים יומני הערכה של הקצאת צמתים אוטומטית (NAP) שדומים לאלה:

    NAP: injected node groups for requirements...

  3. בודקים את הודעת היומן של הרשימה families="...". בודקים אם חסרות ברשימה משפחות מכונות חדשות יותר (כמו מזהים של e4 או c3). מזהים חסרים מצביעים על כך ש-GKE סינן את המשפחות האלה במהלך התזמון בגלל דרישת האחסון. המזהה e4 משמש ביומנים פנימיים של סדרת המכונות E4.

רזולוציה

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

  • שימוש באחסון ב-Hyperdisk: מעדכנים את ההגדרה של StorageClass או של אמצעי האחסון כדי להשתמש באחסון ב-Google Cloud Hyperdisk (כמו סוג הדיסק hyperdisk-balanced), שתואם לסדרות חדשות יותר של מכונות.
  • לאפשר תזמון בסדרות ישנות יותר: אם אתם חייבים להשתמש בסוגי נפחים ישנים יותר של Persistent Disk (כמו נפחים של דיסק מתמיד סטנדרטי (pd-standard) או דיסק מתמיד שמבוסס על SSD (pd-ssd)), הסירו את כל הבקשות המפורשות לסדרות מכונות חדשות יותר (כמו שדות nodeSelector או ComputeClasses בהתאמה אישית). הסרת הבקשות האלה מאפשרת ל-GKE Autopilot לתזמן את ה-Pod בצמתים תואמים כמו E2.

בעיות בעומס העבודה

עומסי עבודה תקועים עם שגיאת אחסון זמני

‫GKE לא ייצור פודים אם הבקשות לאחסון הארעי של הפודים חורגות מהמקסימום של Autopilot, שהוא 10GiB ב-GKE בגרסה 1.28.6-gke.1317000 ואילך.

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

kubectl describe CONTROLLER_TYPE/CONTROLLER_NAME

מחליפים את מה שכתוב בשדות הבאים:

  • ‫CONTROLLER_TYPE: סוג בקר עומס העבודה, כמו replicaset או daemonset. רשימה של סוגי בקרים מופיעה במאמר ניהול עומסי עבודה.
  • ‫CONTROLLER_NAME: השם של עומס העבודה שנתקע.

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

# lines omitted for clarity

Events:

{"[denied by autogke-pod-limit-constraints]":["Max ephemeral-storage requested by init containers for workload '' is higher than the Autopilot maximum of '10Gi'.","Total ephemeral-storage requested by containers for workload '' is higher than the Autopilot maximum of '10Gi'."]}

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

פודים תקועים במצב Pending

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

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

אפשר גם לנסות לתזמן את ה-DaemonSets לפני שמתזמנים את ה-Pods של עומס העבודה הרגיל.

ביצועים לא אמינים באופן עקבי של עומס העבודה בצומת ספציפי

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

kubectl drain NODE_NAME --ignore-daemonsets

מחליפים את NODE_NAME בשם של הצומת הבעייתי. כדי למצוא את שם הצומת, מריצים את הפקודה kubectl get nodes.

‫GKE מבצע את הפעולות הבאות:

  • מפנה עומסי עבודה קיימים מהצומת ומפסיק לתזמן עומסי עבודה בצומת הזה.
  • יוצר מחדש באופן אוטומטי בצמתים אחרים עומסי עבודה שפונו ומנוהלים על ידי בקר, כמו Deployment או StatefulSet.
  • מסיים את כל עומסי העבודה שנותרו בצומת ומתקן או יוצר מחדש את הצומת לאורך זמן.
  • אם אתם משתמשים ב-Autopilot, ‏ GKE משבית ומחליף את הצומת באופן מיידי ומתעלם מכל PodDisruptionBudgets שהוגדרו.

תזמון Pods באשכולות ריקים נמשך יותר זמן מהצפוי

האירוע הזה מתרחש כשפורסים עומס עבודה באשכול Autopilot שאין בו עומסי עבודה אחרים. אשכולות Autopilot מתחילים עם אפס צמתים שמישים, ומתרחבים לאפס צמתים אם האשכול ריק, כדי למנוע מצב של משאבי מחשוב לא מנוצלים באשכול. פריסת עומס עבודה באשכול שאין בו צמתים מפעילה אירוע של הרחבה אנכית בהתאם לעומס (scale up).

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

בודקים אם ה-Pods ממתינים לצמתים חדשים:

  1. תיאור של ה-Pod בהמתנה:

    kubectl describe pod POD_NAME

    מחליפים את POD_NAME בשם של ה-Pod בהמתנה.

  2. בודקים את הקטע Events בפלט. אם ה-Pod ממתין לצמתים חדשים, הפלט דומה לזה:

    Events:
  Type     Reason            Age   From                                   Message
  ----     ------            ----  ----                                   -------
  Warning  FailedScheduling  11s   gke.io/optimize-utilization-scheduler  no nodes available to schedule pods
  Normal   TriggeredScaleUp  4s    cluster-autoscaler                     pod triggered scale-up: [{https://www.googleapis.com/compute/v1/projects/example-project/zones/example-zone/instanceGroups/gk3-example-cluster-pool-2-9293c6db-grp 0->1 (max: 1000)} {https://www.googleapis.com/compute/v1/projects/example-project/zones/example-zone/instanceGroups/gk3-example-cluster-pool-2-d99371e7-grp 0->1 (max: 1000)}]

    האירוע TriggeredScaleUp מראה שהאשכול שלכם משתנה מאפס צמתים למספר הצמתים שנדרש כדי להריץ את עומס העבודה שנפרס.

פודים של המערכת לא מצליחים לתזמן באשכולות ריקים

האירוע הזה מתרחש כשאין עומסי עבודה שפועלים באשכול, וכתוצאה מכך האשכול מצטמצם לאפס צמתים. אשכולות Autopilot מתחילים עם אפס צמתים שמישים, ומתכווצים לאפס צמתים אם לא מריצים אף אחד מעומסי העבודה באשכול. כך אפשר לצמצם את בזבוז משאבי המחשוב באשכול.

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

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

  1. בודקים אם יש צמתים באשכול:

    kubectl get nodes

    הפלט הבא מציין שבאשכול יש אפס צמתים:

    No resources found

  2. בודקים את הסטטוס של Pods של המערכת:

    kubectl get pods --namespace=kube-system

    הפלט אמור להיראות כך:

    NAME                                                       READY   STATUS    RESTARTS   AGE
antrea-controller-horizontal-autoscaler-6d97f7cf7c-ngfd2   0/1     Pending   0          9d
egress-nat-controller-84bc985778-6jcwl                     0/1     Pending   0          9d
event-exporter-gke-5c5b457d58-7njv7                        0/2     Pending   0          3d5h
event-exporter-gke-6cd5c599c6-bn665                        0/2     Pending   0          9d
konnectivity-agent-694b68fb7f-gws8j                        0/2     Pending   0          3d5h
konnectivity-agent-7d659bf64d-lp4kt                        0/2     Pending   0          9d
konnectivity-agent-7d659bf64d-rkrw2                        0/2     Pending   0          9d
konnectivity-agent-autoscaler-5b6ff64fcd-wn7fw             0/1     Pending   0          9d
konnectivity-agent-autoscaler-cc5bd5684-tgtwp              0/1     Pending   0          3d5h
kube-dns-65ccc769cc-5q5q7                                  0/5     Pending   0          3d5h
kube-dns-7f7cdb9b75-qkq4l                                  0/5     Pending   0          9d
kube-dns-7f7cdb9b75-skrx4                                  0/5     Pending   0          9d
kube-dns-autoscaler-6ffdbff798-vhvkg                       0/1     Pending   0          9d
kube-dns-autoscaler-8b7698c76-mgcx8                        0/1     Pending   0          3d5h
l7-default-backend-87b58b54c-x5q7f                         0/1     Pending   0          9d
metrics-server-v1.31.0-769c5b4896-t5jjr                    0/1     Pending   0          9d

  3. בודקים למה ה-Pods של המערכת נמצאים בסטטוס Pending:

    kubectl describe pod --namespace=kube-system SYSTEM_POD_NAME

    מחליפים את SYSTEM_POD_NAME בשם של כל Pod מערכת מהפלט של הפקודה הקודמת.

    הפלט אמור להיראות כך:

    ...
Events:
Type     Reason            Age                       From               Message
----     ------            ----                      ----               -------
Warning  FailedScheduling  4m35s (x27935 over 3d5h)  default-scheduler  no nodes available to schedule pods
...

    בפלט, הערך no nodes available to schedule pods בשדה Message של האירוע FailedScheduling מציין שה-Pod של המערכת לא תזמן כי האשכול ריק.

באשכול GKE Autopilot אסור לגשת לצמתים הבסיסיים. לכן, צריך להריץ את הכלי tcpdump מתוך Pod ואז להעתיק אותו באמצעות הפקודה kubectl cp. אם אתם מריצים בדרך כלל את כלי השירות tcpdump מתוך Pod באשכול GKE Autopilot, יכול להיות שתופיע השגיאה הבאה:

    tcpdump: eth0: You don't have permission to perform this capture on that device
    (socket: Operation not permitted)

זה קורה כי כברירת מחדל, GKE Autopilot מחיל הקשר אבטחה על כל ה-Pods שמבטלים את היכולת NET_RAW כדי לצמצם נקודות חולשה פוטנציאליות. לדוגמה:

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: tcpdump
  name: tcpdump
spec:
  containers:
  - image: nginx
    name: nginx
    resources:
      limits:
        cpu: 500m
        ephemeral-storage: 1Gi
        memory: 2Gi
      requests:
        cpu: 500m
        ephemeral-storage: 1Gi
        memory: 2Gi
    securityContext:
      capabilities:
        # This section drops NET_RAW to mitigate security vulnerabilities
        drop:
        - NET_RAW

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

  1. מוסיפים את היכולת NET_RAW לקטע securityContext במפרט ה-YAML של ה-Pod:

    securityContext:
  capabilities:
    add:
    - NET_RAW

  2. מריצים את tcpdump מתוך Pod:

    tcpdump port 53 -w packetcap.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

  3. כדי להעתיק את הקובץ למכונה המקומית לניתוח נוסף, משתמשים בפקודה kubectl cp:

    kubectl cp POD_NAME:/PATH_TO_FILE/FILE_NAME/PATH_TO_FILE/FILE_NAME

  4. משתמשים ב-kubectl exec כדי להריץ את הפקודה tcpdump, לבצע תיעוד של חבילות נתונים ולהפנות את הפלט:

    kubectl exec -it POD_NAME -- bash -c "tcpdump port 53 -w -" > packet-new.pcap

‫Pods לא יכולים לפעול בצומת כי הפעולה NRI RunPodSandbox נכשלה

במקרים נדירים, צומת Autopilot בסוגי המחשוב שמוגדרים כברירת מחדל, Balanced,‏ Scale-Out,‏ autopilot ו-autopilot-spot יכול להיכנס למצב שבו Pods של המערכת, כמו anetd, ו-Pods פוטנציאליים של משתמשים שמוקצים לצומת, לא יכולים לעבור למצב פעולה. אם anetd לא יכול לעבור למצב פעולה, אז הרשת של Pod שבורה באופן חלקי או מלא בצומת. מצב השגיאה הזה מופעל רק במהלך שדרוגים מסוימים של מישור הבקרה של האשכול.

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

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

  • ‫1.35: כל גרסאות התיקון
  • ‫1.34: ‏‎1.34.1-gke.3899000 ואילך
  • ‫1.33: ‏‎1.33.5-gke.2392000 ואילך

אם אתם חושדים שצומת נמצא במצב השגיאה הזה, אתם יכולים לבדוק את זה כך:

  1. מאתרים את ה-Pod של efficiency-daemon שפועל בצומת החשוד:

    DAEMON_POD_NAME=$(kubectl get pods \
  --namespace kube-system \
  --selector k8s-app=efficiency-daemon \
  --field-selector spec.nodeName=NODE_NAME \
  --output custom-columns=":metadata.name" \
  --no-headers)
echo $DAEMON_POD_NAME

    אם אין pod של efficiency-daemon בצומת, הצומת לא מושפע מהבעיה הספציפית הזו.

  2. בודקים אם יש שגיאות ספציפיות ב-Pod של efficiency-daemon:

    kubectl logs -n kube-system $DAEMON_POD_NAME | grep "connect: operation not permitted" | wc -l

    אם הפלט גדול מ-10, סביר מאוד שהצומת מושפע מהבעיה הזו.

אם אתם רואים כל הזמן את הודעת השגיאה הבאה באירועי Pod של Pod שהוקצה לצומת, זה סימן שהצומת מושפע מהבעיה הזו: Failed to create pod sandbox: rpc error: code = Unknown desc = NRI RunPodSandbox failed: rpc error: code = Unknown desc = internal error: reconciliation failed.

המאמרים הבאים