פתרון בעיות בזמן הריצה של הקונטיינר

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

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

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

בעיות במאגרי צמתים של Windows Server

בקטעים הבאים מפורטות בעיות בזמן הריצה של קונטיינרים שספציפיות לאשכולות GKE שמריצים מאגרי צמתים של Windows Server.

נתיבי הרכבה עם אותיות כונן חשופות נכשלים

הבעיה הזו נפתרה ב-containerd גרסה 1.6.6 ואילך.

יכול להיות שבאשכולות GKE שמופעלים בהם מאגרי צמתים של שרת Windows שמשתמשים בזמן הריצה של containerd בגרסה מוקדמת מ-1.6.6 יופיעו שגיאות שדומות לשגיאות הבאות:

failed to create containerd task : CreateComputeSystem : The parameter is incorrect : unknown

השגיאה הזו נגרמת בגלל שצוין אות כונן בלי לוכסן הפוך בסוף (לדוגמה, D: במקום D:‎). פרטים נוספים זמינים בבעיה מספר 6589 ב-GitHub.

פתרון

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

תמונות קונטיינרים עם שורות פקודה CMD או ENTRYPOINT שעברו מראש escape ולא מוגדרות כמערך נכשלות במאגרי צמתים של Windows עם containerd

הבעיה הזו נפתרה ב-containerd גרסה 1.6 ואילך.

יכול להיות שבאשכולות GKE שמופעלים בהם מאגרי צמתים של Windows Server שמשתמשים בזמן הריצה של containerd בגרסה 1.5.X יופיעו שגיאות כשמפעילים קונטיינרים, כמו השגיאות הבאות:

failed to start containerd task : hcs::System::CreateProcess : The system cannot find the file specified.: unknown

פרטים נוספים זמינים בבעיה מספר 5067 ב-GitHub ובבעיה מספר 6300 ב-GitHub.

פתרון

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

נפחים של קובצי אימג' של קונטיינרים עם נתיבים לא קיימים או נתיבים בסגנון לינוקס (קו נטוי) נכשלים במאגרי צמתים של Windows עם containerd

הבעיה הזו נפתרה ב-containerd גרסה 1.6 ואילך.

יכול להיות שיהיו שגיאות באשכולות GKE שמופעלים בהם מאגרי צמתים של Windows Server שמשתמשים בזמן הריצה של containerd בגרסה 1.5.X, כשמפעילים קונטיינרים כמו אלה:

failed to generate spec: failed to stat "<volume_path>": CreateFile : The system cannot find the path specified.

פרטים נוספים זמינים בבעיה מספר 5671 ב-GitHub.

פתרון

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

פעולות שמבוססות על צירוף לא פועלות בצורה תקינה אחרי הפעלה מחדש של container-runtime במאגרי צמתים של GKE Windows Server

גרסאות GKE שהושפעו: 1.21 עד 1.21.5-gke.1802, ‏ 1.22 עד 1.22.3-gke.700

באשכולות GKE שמופעלים בהם מאגרי צמתים של שרת Windows שמשתמשים בזמן הריצה של containerd (גרסה 1.5.4 ו-1.5.7-gke.0) עלולות להתרחש בעיות אם זמן הריצה של הקונטיינר מופעל מחדש בכוח, ופעולות צירוף לקונטיינרים קיימים שפועלים לא מצליחות לקשור קלט/פלט מחדש. הבעיה לא תגרום לכשלים בקריאות ל-API, אבל לא יישלחו או יתקבלו נתונים. הנתונים האלה כוללים נתונים של ממשקי CLI ו-API לצירוף ויומנים דרך שרת ה-API של האשכול.

פתרון

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

‫/etc/mtab: אין קובץ או ספרייה בשם הזה

זמן הריצה של קונטיינר Docker מאכלס את הקישור הסמלי הזה בתוך הקונטיינר כברירת מחדל, אבל זמן הריצה של containerd לא מאכלס אותו.

פרטים נוספים זמינים בבעיה מספר 2419 ב-GitHub.

פתרון

כדי לפתור את הבעיה, צריך ליצור ידנית את הקישור הסמלי /etc/mtab במהלך בניית התמונה.

ln -sf /proc/mounts /etc/mtab

שגיאה בשליפת תמונה: זה לא ספרייה

גרסאות GKE שהושפעו: כל הגרסאות

כשיוצרים תמונה באמצעות kaniko, יכול להיות שלא תהיה אפשרות למשוך אותה באמצעות containerd ותוצג הודעת השגיאה 'not a directory' (לא ספריה). השגיאה הזו מתרחשת אם האימג' נוצר בצורה מיוחדת: כשפקודה קודמת מסירה ספרייה והפקודה הבאה יוצרת מחדש את אותם קבצים בספרייה הזו.

בדוגמה הבאה של Dockerfile עם npm אפשר לראות את הבעיה הזו.

RUN npm cache clean --force
RUN npm install

פרטים נוספים זמינים בבעיה מספר 4659 ב-GitHub.

פתרון

כדי לפתור את הבעיה, צריך ליצור את התמונה באמצעות docker build, שלא מושפע מהבעיה הזו.

אם docker build לא מופיעה כאפשרות, משלבים את הפקודות לאחת. בדוגמה הבאה של קובץ Dockerfile משולבים הרכיבים RUN npm cache clean --force ו-RUN npm install:

RUN npm cache clean --force && npm install

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

גרסאות GKE שהושפעו: כל הגרסאות

נקודת הקצה של Kubelet‏ /metrics/cadvisor מספקת מדדים של Prometheus, כפי שמתואר במאמר מדדים של רכיבי מערכת Kubernetes. אם תתקינו כלי לאיסוף מדדים שתלוי בנקודת הקצה הזו, יכול להיות שתיתקלו בבעיות הבאות:

  • פורמט המדדים בצומת Docker הוא k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>, אבל הפורמט בצומת containerd הוא <container-id>.

  • חלק מהמדדים של מערכת הקבצים חסרים בצומת containerd, כמו:

    container_fs_inodes_free
container_fs_inodes_total
container_fs_io_current
container_fs_io_time_seconds_total
container_fs_io_time_weighted_seconds_total
container_fs_limit_bytes
container_fs_read_seconds_total
container_fs_reads_merged_total
container_fs_sector_reads_total
container_fs_sector_writes_total
container_fs_usage_bytes
container_fs_write_seconds_total
container_fs_writes_merged_total

פתרון

כדי לצמצם את הבעיה הזו, אפשר להשתמש ב-cAdvisor כ-daemonset עצמאי.

  1. אפשר למצוא את הגרסה האחרונה של cAdvisor עם תבנית השם vX.Y.Z-containerd-cri (לדוגמה, v0.42.0-containerd-cri).
  2. פועלים לפי השלבים במאמר cAdvisor Kubernetes Daemonset כדי ליצור את ה-daemonset.
  3. מגדירים את כלי איסוף המדדים שהותקן כך שישתמש בנקודת הקצה של cAdvisor ‏/metrics שמספקת את הסט המלא של מדדי הקונטיינר של Prometheus.

חלופות

  1. כדאי להעביר את פתרון המעקב ל-Cloud Monitoring, שמספק את כל מדדי הקונטיינרים.
  2. איסוף מדדים מ-Kubelet summary API עם נקודת קצה של /stats/summary.

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

גרסאות GKE שהושפעו: כל הגרסאות

ההתנהגות של בדיקת ההפעלה בתמונות של containerd שונה מההתנהגות בתמונות של dockershim. כשבדיקת exec שמוגדרת עבור ה-Pod חורגת מסף Kubernetes timeoutSeconds שהוגדר בתמונות dockershim, המערכת מתייחסת לזה כאל כשל בבדיקה. בתמונות containerd, המערכת מתעלמת מתוצאות הבדיקה שמוחזרות אחרי ערך הסף timeoutSeconds שהוגדר.

פתרון

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

פתרון בעיות במאגרי מידע פרטיים

בקטע הזה מפורט מידע על פתרון בעיות בהגדרות של מאגר פרטי ב-containerd.

שליפת התמונה נכשלת עם השגיאה x509: certificate signed by unknown authority

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

  1. נכנסים לדף Logs Explorer במסוף Google Cloud :

    כניסה לדף Logs Explorer

  2. מריצים את השאילתה הבאה:

    ("Internal error pulling certificate" OR
"Failed to get credentials from metadata server" OR
"Failed to install certificate")

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

  1. ב-GKE Standard, פותחים את קובץ ההגדרות. הקובץ נמצא בנתיב הבא:

    /etc/containerd/hosts.d/DOMAIN/config.toml

    מחליפים את DOMAIN ב-FQDN של המאגר.

  2. מוודאים שקובץ ההגדרות מכיל את ה-FQDN הנכון.

  3. מוודאים שהנתיב לאישור בשדה secretURI בקובץ התצורה נכון.

  4. מוודאים שהאישור קיים ב-Secret Manager.

האישור לא קיים

הבעיה הזו מתרחשת אם GKE לא הצליח לשלוף את האישור מ-Secret Manager כדי להגדיר את containerd בצמתים. אם ל-GKE אין גישה לאישור, הצומת מופעל בלי האישור. לעומסי עבודה שפועלים בצומת אין גישה למאגר הפרטי.

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

  1. מוודאים שהצומת המושפע מריץ מערכת הפעלה שמותאמת לקונטיינרים. אין תמיכה בצמתים של Ubuntu ו-Windows.
  2. בקובץ התצורה, מוודאים שהנתיב לסוד בשדה secretURI נכון.
  3. בודקים שלחשבון השירות של IAM באשכול יש את ההרשאות הנכונות לגישה לסוד.
  4. בודקים שלקלאסטר יש את היקף הגישה cloud-platform. הוראות מפורטות זמינות במאמר בדיקת היקפי הגישה.

  5. יוצרים מחדש את הצומת באחת מהשיטות הבאות:

אפשרות רישום לא מאובטחת לא מוגדרת לרשת מקומית (10.0.0.0/8)

גרסאות GKE שהושפעו: כל הגרסאות

בתמונות containerd, האפשרות של רישום לא מאובטח לא מוגדרת לרשת 10.0.0.0/8 מקומית. אם אתם משתמשים במאגרי רישום פרטיים לא מאובטחים, יכול להיות שתיתקלו בשגיאות דומות לאלה:

pulling image: rpc error: code = Unknown desc = failed to pull and unpack image "IMAGE_NAME": failed to do request: Head "IMAGE_NAME": http: server gave HTTP response to HTTPS client

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

הגדרת DaemonSets עם הרשאות לשינוי ההגדרה של containerd

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

  1. בודקים את קובץ המניפסט הבא:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: insecure-registries
  namespace: default
  labels:
    k8s-app: insecure-registries
spec:
  selector:
    matchLabels:
      name: insecure-registries
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        name: insecure-registries
    spec:
      nodeSelector:
        cloud.google.com/gke-container-runtime: "containerd"
      hostPID: true
      containers:
        - name: startup-script
          image: gke.gcr.io/startup-script:v2
          imagePullPolicy: Always
          securityContext:
            privileged: true
          env:
          - name: ADDRESS
            value: "REGISTRY_ADDRESS"
          - name: STARTUP_SCRIPT
            value: |
              set -o errexit
              set -o pipefail
              set -o nounset

              if [[ -z "$ADDRESS" || "$ADDRESS" == "REGISTRY_ADDRESS" ]]; then
                echo "Error: Environment variable ADDRESS is not set in containers.spec.env"
                exit 1
              fi

              echo "Allowlisting insecure registries..."
              containerd_config="/etc/containerd/config.toml"
              hostpath=$(sed -nr 's;  config_path = "([-/a-z0-9_.]+)";\1;p' "$containerd_config")
              if [[ -z "$hostpath" ]]; then
                echo "Node uses CRI config model V1 (deprecated), adding mirror under $containerd_config..."
                grep -qxF '[plugins."io.containerd.grpc.v1.cri".registry.mirrors."'$ADDRESS'"]' "$containerd_config" || \
                  echo -e '[plugins."io.containerd.grpc.v1.cri".registry.mirrors."'$ADDRESS'"]\n  endpoint = ["http://'$ADDRESS'"]' >> "$containerd_config"
              else
                host_config_dir="$hostpath/$ADDRESS"
                host_config_file="$host_config_dir/hosts.toml"
                echo "Node uses CRI config model V2, adding mirror under $host_config_file..."
                if [[ ! -e "$host_config_file" ]]; then
                  mkdir -p "$host_config_dir"
                  echo -e "server = \"https://$ADDRESS\"\n" > "$host_config_file"
                fi
                echo -e "[host.\"http://$ADDRESS\"]\n  capabilities = [\"pull\", \"resolve\"]\n" >> "$host_config_file"
              fi
              echo "Reloading systemd management configuration"
              systemctl daemon-reload
              echo "Restarting containerd..."
              systemctl restart containerd

    בשדה .spec.containers.env, מחליפים את הערך REGISTRY_ADDRESS של המשתנה ADDRESS בכתובת של רישום ה-HTTP המקומי בפורמט DOMAIN_NAME:PORT. לדוגמה,

    containers:
- name: startup-script
  ...
  env:
  - name: ADDRESS
    value: "example.com:5000"

  2. פורסים את DaemonSet:

    kubectl apply -f insecure-registry-ds.yaml

ה-DaemonSet מוסיף את המאגר הלא מאובטח להגדרות של containerd בכל צומת.

‫containerd מתעלם ממיפויים של מכשירים עבור פודים עם הרשאות

גרסאות GKE שהושפעו: כל הגרסאות

במקרה של Pods מורשים של Kubernetes, זמן הריצה של הקונטיינר מתעלם ממיפויים של מכשירים שמועברים אליו על ידי volumeDevices.devicePath, ובמקום זאת מאפשר לקונטיינר גישה לכל מכשיר במארח דרך /dev.

תהליכי shim של containerd דולפים כשצמתים נמצאים בלחץ קלט/פלט

גרסאות GKE שהושפעו: 1.25.0 עד 1.25.15-gke.1040000,‏ 1.26.0 עד 1.26.10-gke.1030000,‏ 1.27.0 עד 1.27.6-gke.1513000 ו-1.28.0 עד 1.28.3-gke.1061000

כשצומת GKE נמצא בלחץ קלט/פלט, יכול להיות ש-containerd לא יצליח למחוק את תהליכי containerd-shim-runc-v2 כש-Pod נמחק, וכתוצאה מכך יתרחשו דליפות של תהליכים. כשהדליפה מתרחשת בצומת, יוצגו יותר containerd-shim-runc-v2 תהליכים בצומת ממספר ה-Pods בצומת הזה. יכול להיות שתראו גם שימוש מוגבר בזיכרון ובמעבד, לצד מזהי תהליכים נוספים. פרטים נוספים זמינים בבעיה ב-GitHub‏ Fix leaked shim caused by high IO pressure.

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

  • 1.25.15-gke.1040000
  • 1.26.10-gke.1030000
  • 1.27.6-gke.1513000
  • 1.28.3-gke.1061000

משפחת הכתובות IPv6 מופעלת בתרמילים שמריצים את containerd

גרסאות GKE שהושפעו: 1.18, ‏ 1.19, ‏ 1.20.0 עד 1.20.9

משפחת תמונות IPv6 מופעלת עבור Pods שפועלים עם containerd. התמונה dockershim משביתה את IPv6 בכל ה-Pods, אבל תמונת ה-containerd לא משביתה אותו. לדוגמה, localhost מומר קודם לכתובת IPv6‏ ::1. בדרך כלל זה לא גורם לבעיה, אבל במקרים מסוימים זה עלול לגרום להתנהגות לא צפויה.

פתרון

כדי לפתור את הבעיה, צריך להשתמש בכתובת IPv4 כמו 127.0.0.1 באופן מפורש, או להגדיר אפליקציה שפועלת ב-Pod כך שתפעל בשתי משפחות הכתובות.

יש התנגשות עם טווח כתובות ה-IP‏ 172.17/16

גרסאות GKE שהושפעו: 1.18.0 עד 1.18.14

טווח כתובות ה-IP‏ 172.17/16 תפוס על ידי הממשק docker0 במכונת ה-VM של הצומת עם containerd מופעל. יכול להיות שהתנועה שנשלחת לטווח הזה או שמקורה בו לא תנותב בצורה נכונה (לדוגמה, יכול להיות ש-Pod לא יוכל להתחבר למארח שמחובר ל-VPN עם כתובת IP בטווח 172.17/16).

מדדי GPU לא נאספים

גרסאות GKE שהושפעו: 1.18.0 עד 1.18.18

מדדי השימוש ב-GPU לא נאספים כשמשתמשים ב-containerd כזמן ריצה בגרסאות GKE לפני 1.18.18.

פתרון

כדי לפתור את הבעיה, צריך לשדרג את האשכולות לגרסאות GKE‏ 1.18.18 ואילך.

אי אפשר להשתמש בתמונות שבהן הערך של config.mediaType מוגדר כ-application/octet-stream ב-containerd

גרסאות GKE שהושפעו: כל הגרסאות

אי אפשר להשתמש בתמונות עם config.mediaType שמוגדר ל-"application/octet-stream" ב-containerd. מידע נוסף זמין בבעיה מספר 4756 ב-GitHub. התמונות האלה לא תואמות למפרט של Open Container Initiative (OCI) ונחשבות שגויות. התמונות האלה פועלות עם Docker כדי לספק תאימות לאחור, אבל ב-containerd אין תמיכה בתמונות האלה.

תיאור הבעיה וניתוח

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

Error syncing pod <pod-uid> ("<pod-name>_<namespace>(<pod-uid>)"), skipping: failed to "StartContainer" for "<container-name>" with CreateContainerError: "failed to create containerd container: error unpacking image: failed to extract layer sha256:<some id>: failed to get reader from content store: content digest sha256:<some id>: not found"

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

"mediaType": "application/octet-stream",

פתרון

קהילת containerd החליטה לא לתמוך בתמונות כאלה, ולכן כל הגרסאות של containerd מושפעות ואין תיקון. צריך לבנות מחדש את קובץ אימג' של קונטיינר באמצעות Docker בגרסה 1.11 ואילך, ולוודא שהשדה config.mediaType לא מוגדר לערך "application/octet-stream".

CNI not initialized

גרסאות GKE שהושפעו: כל הגרסאות

אם מופיעה שגיאה דומה לזו שבהמשך, התצורה של Container Network Interface‏ (CNI) לא מוכנה:

Error: "network is not ready: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized".

יש שתי סיבות עיקריות להופעת השגיאה הזו:

  • ההתקנה של CNI לא הסתיימה
  • ה-webhook מוגדר בצורה שגויה

מוודאים שההתקנה של CNI הסתיימה

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

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

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

תיקון webhooks שהוגדרו באופן שגוי

אם השגיאה 'CNI לא אותחל' נמשכת ואתם מבחינים בכך ש-GKE לא מצליח ליצור צמתים במהלך שדרוג, שינוי גודל או פעולה אחרת, יכול להיות שיש לכם webhook שהוגדר בצורה שגויה.

אם יש לכם webhook מותאם אישית שמיירט את הפקודה של בקר DaemonSet ליצירת Pod, וה-webhook הזה מוגדר בצורה שגויה, יכול להיות שתראו את השגיאה כסטטוס שגיאה של צומת ב Google Cloud מסוף. ההגדרה השגויה הזו מונעת מ-GKE ליצור Pod של netd או calico-node. אם הפעלתם את ה-Pods של netd או של calico-node בהצלחה והשגיאה נמשכת, פנו לתמיכת הלקוחות.

כדי לתקן את ה-webhook שהוגדר בצורה שגויה, מבצעים את השלבים הבאים:

  1. זיהוי של webhooks שהוגדרו באופן שגוי.

    אם אתם משתמשים באשכול עם אכיפה של מדיניות רשת ב-Kubernetes Dataplane V1 מופעלת, אתם יכולים גם לבדוק את הסטטוס של calico-typha Pod כדי לקבל מידע על ה-webhook שגורם לשגיאה הזו:

    kubectl describe pod -n kube-system -l k8s-app=calico-typha

    אם יש שגיאה ב-Pod, הפלט אמור להיראות כך:

    Events:
Type     Reason        Age                     From                   Message
----     ------        ----                    ----                   -------
Warning  FailedCreate  9m15s (x303 over 3d7h)  replicaset-controller  Error creating: admission webhook WEBHOOK_NAME denied the request [...]

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

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

    kubectl delete mutatingwebhookconfigurations WEBHOOK_NAME
kubectl delete validatingwebhookconfigurations WEBHOOK_NAME

    מחליפים את WEBHOOK_NAME בשם של ה-webhook עם ההגדרה השגויה שרוצים להסיר.

  3. מגדירים את ה-webhook כך שיתעלם מ-Pods של המערכת.

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