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

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

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

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

נתיבי הרכבה עם אותיות כונן פשוטות נכשלים במאגרי צמתים של Windows עם containerd

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

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

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

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

פתרון

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

תמונות קונטיינרים עם שורות פקודה CMD או ENTRYPOINT שעברו בריחה מראש ולא מוגדרות כמערך נכשלות במאגרי צמתים של 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 שמשתמשות בזמן ריצה של containerd בגרסה 1.6.6 ומעלה.

נפחים של קובץ אימג' של קונטיינר עם נתיבים לא קיימים או נתיבים בסגנון לינוקס (קו נטוי) נכשלים במאגרי צמתים של 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 ואילך.

/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 שהושפעו: כל הגרסאות

נקודת הקצה /metrics/cadvisor של Kubelet מספקת מדדי 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 עם נקודת קצה (endpoint) של /stats/summary.

פעולות שמבוססות על צירוף לא פועלות בצורה תקינה אחרי הפעלה מחדש של זמן ריצה של קונטיינר ב-GKE Windows

גרסאות 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, אבל לא יישלחו או יתקבלו נתונים. הנתונים האלה כוללים נתונים של ממשקי API ושל ממשקי CLI ליומנים ולצירוף, דרך שרת ה-API של האשכול.

פתרון

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

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

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

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

פתרון

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

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

בקטע הזה מפורט מידע על פתרון בעיות בהגדרות של מאגר פרטי ב-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, האפשרות insecure registry לא מוגדרת לרשת 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 מתעלם ממיפויי מכשירים עבור pods עם הרשאות

גרסאות 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 נמחק, וכתוצאה מכך יתרחשו דליפות של תהליכים. כשהדליפה מתרחשת בצומת, תראו יותר תהליכים בצומת מאשר מספר ה-Pods בצומת הזה.containerd-shim-runc-v2 יכול להיות שתראו גם שימוש מוגבר בזיכרון ובמעבד, לצד מזהי תהליכים נוספים. פרטים נוספים זמינים בבעיה ב-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 לא אותחל

גרסאות 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 כדי לסמן צמתים שלא מוכנים, וקבוצות Pod של המערכת יכולות לסבול את ה-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 בהצלחה והשגיאה עדיין מופיעה, פנו ל-Customer Care.

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

  1. זיהוי של webhooks שהוגדרו בצורה שגויה.

    אם אתם משתמשים באשכול עם מדיניות רשת 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 של המערכת.

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