פתרון בעיות ב-kube-dns ב-GKE

אם אתם משתמשים ב-kube-dns לזיהוי שירותים, יכול להיות שתקבלו הודעות שגיאה בחיבור כמו dial tcp: i/o timeout או no such host. שגיאות כאלה מעידות בדרך כלל על בעיות ב-Pods של kube-dns במרחב השמות kube-system, כמו הגדרות שגויות, מגבלות משאבים או בעיות בקישוריות לרשת שמשפיעות על ה-Pods האלה.

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

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

זיהוי המקור של בעיות DNS ב-kube-dns

בקטעים הבאים מוסבר איך לאבחן למה ל-kube-dns קשה לפתור שאילתות.

בדיקה אם Pods של kube-dns פועלים

‫Pods של Kube-dns הם קריטיים לתרגום שם בתוך האשכול. אם הם לא פועלים, סביר להניח שתיתקלו בבעיות בפענוח ה-DNS.

כדי לוודא שפודים של kube-dns פועלים בלי הפעלות מחדש מהזמן האחרון, צריך להציג את הסטטוס של הפודים האלה:

kubectl get pods -l k8s-app=kube-dns -n kube-system

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

NAME                   READY          STATUS          RESTARTS       AGE
kube-dns-POD_ID_1      5/5            Running         0              16d
kube-dns-POD_ID_2      0/5            Terminating     0              16d

בפלט הזה, POD_ID_1 ו-POD_ID_2 מייצגים מזהים ייחודיים שמצורפים אוטומטית ל-Pods של kube-dns.

אם הפלט מראה שלפודים של kube-dns אין סטטוס של Running, צריך לבצע את השלבים הבאים:

  1. אפשר להשתמש ביומני הביקורת Admin Activity כדי לבדוק אם בוצעו שינויים לאחרונה, כמו שדרוג של גרסת אשכול או מאגר צמתים, או שינויים ב-ConfigMap של kube-dns. מידע נוסף על יומני ביקורת זמין במאמר בנושא יומני ביקורת של GKE. אם מוצאים שינויים, מבטלים אותם וצופים שוב בסטטוס של ה-Pods.

  2. אם לא מצאתם שינויים רלוונטיים שבוצעו לאחרונה, בדקו אם אתם נתקלים בשגיאת OOM בצומת שבו פועל ה-Pod של kube-dns. אם מופיעה שגיאה דומה לשגיאה הבאה בהודעות היומן של Cloud Logging, סימן שהפודים האלה נתקלו בשגיאת OOM:

    Warning: OOMKilling Memory cgroup out of memory

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

    כדי לפתור את השגיאה, אפשר למחוק את עומסי העבודה הבעייתיים או להגדיר מגבלות זיכרון או מעבד. למידע נוסף על הגדרת מגבלות, קראו את המאמר ניהול משאבים לפודים ולמאגרים במסמכי התיעוד של Kubernetes. מידע נוסף על אירועי OOM זמין במאמר בנושא פתרון בעיות שקשורות לאירועי OOM.

  3. אם לא מופיעות הודעות שגיאה של OOM, מפעילים מחדש את kube-dns Deployment:

    kubectl rollout restart deployment/kube-dns --namespace=kube-system

    אחרי שמפעילים מחדש את הפריסה, בודקים אם הפודים של kube-dns פועלים.

אם השלבים האלה לא עוזרים, או אם כל ה-Pods של kube-dns הם בסטטוס Running, אבל עדיין יש בעיות ב-DNS, צריך לוודא שהקובץ /etc/resolv.conf מוגדר בצורה נכונה.

צריך לוודא ש-/etc/resolv.conf מוגדר בצורה נכונה

בודקים את הקובץ /etc/resolv.conf של ה-Pods שנתקלים בבעיות DNS ומוודאים שהרשומות שהוא מכיל נכונות:

  1. צפייה בקובץ /etc/resolv.conf של ה-Pod:

    kubectl exec -it POD_NAME -- cat /etc/resolv.conf

    מחליפים את POD_NAME בשם ה-Pod שבו יש בעיות ב-DNS. אם יש כמה Pods שבהם נתקלתם בבעיות, חזרו על השלבים שבקטע הזה לכל Pod.

    אם הקובץ הבינארי של Pod לא תומך בפקודה kubectl exec, יכול להיות שהפקודה הזו תיכשל. במקרה כזה, צרו Pod פשוט שישמש כסביבת בדיקה. התהליך הזה מאפשר להריץ Pod לבדיקה באותו מרחב שמות כמו ה-Pod הבעייתי.

  2. מוודאים שכתובת ה-IP של שרת השמות בקובץ /etc/resolv.conf נכונה:

    • פודים שמשתמשים ברשת מארחת צריכים להשתמש בערכים בקובץ /etc/resolv.conf של הצומת. כתובת ה-IP של שרת השמות צריכה להיות 169.254.169.254.

    • ב-Pods שלא משתמשים ברשת מארחת, כתובת ה-IP של שירות kube-dns צריכה להיות זהה לכתובת ה-IP של שרת השמות. כדי להשוות את כתובות ה-IP, מבצעים את השלבים הבאים:

      1. משיגים את כתובת ה-IP של שירות kube-dns:

        kubectl get svc kube-dns -n kube-system

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

        NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
kube-dns   ClusterIP   192.0.2.10   <none>        53/UDP,53/TCP   64d

      2. חשוב לרשום את הערך בעמודה Cluster IP (כתובת ה-IP של האשכול). בדוגמה הזו, זה 192.0.2.10.

      3. משווים את כתובת ה-IP של שירות kube-dns לכתובת ה-IP מהקובץ /etc/resolv.conf:

        # cat /etc/resolv.conf

search default.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_NAME google.internal
nameserver 192.0.2.10
options ndots:5

        בדוגמה הזו, שני הערכים תואמים, כך שכתובת IP שגויה של שרת שמות היא לא הסיבה לבעיה.

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

        אם הערך בשדה dnsConfig.nameservers נכון, צריך לבדוק את שרת ה-DNS ולוודא שהוא פועל כמו שצריך.

        אם לא רוצים להשתמש בשרת השמות בהתאמה אישית, מסירים את השדה ומבצעים הפעלה מחדש של ה-Pod:

        kubectl rollout restart deployment POD_NAME

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

  3. בודקים את הרשומות search ו-ndots ב-/etc/resolv.conf. ודאו שאין שגיאות כתיב, הגדרות לא עדכניות ושהבקשה שנכשלה מפנה לשירות קיים במרחב השמות הנכון.

ביצוע חיפוש DNS

אחרי שמוודאים שההגדרה של /etc/resolv.conf נכונה ורשומת ה-DNS נכונה, משתמשים בכלי שורת הפקודה dig כדי לבצע חיפושי DNS מה-Pod שמדווח על שגיאות DNS:

  1. כדי לשלוח שאילתה ישירות ל-Pod, פותחים מעטפת בתוכו:

    kubectl exec -it POD_NAME -n NAMESPACE_NAME -- SHELL_NAME

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

    • ‫POD_NAME: השם של ה-Pod שמדווח על שגיאות DNS.
    • ‫NAMESPACE_NAME: מרחב השמות שאליו שייך ה-Pod.
    • ‫SHELL_NAME: השם של המעטפת שרוצים לפתוח. לדוגמה, sh או /bin/bash.

    יכול להיות שהפקודה הזו תיכשל אם ה-Pod לא מאפשר את הפקודה kubectl exec או אם אין ב-Pod את הקובץ הבינארי dig. אם זה קורה, צריך ליצור Pod לבדיקה עם תמונה שמותקן בה dig:

    kubectl run "test-$RANDOM" ti --restart=Never --image=thockin/dnsutils - bash

  2. בודקים אם ה-Pod יכול לפתור בצורה נכונה את שירות ה-DNS הפנימי של האשכול:

    dig kubernetes

    מכיוון שהקובץ /etc/resolv.conf מפנה לכתובת ה-IP של שירות kube-dns, כשמריצים את הפקודה הזו שרת ה-DNS הוא שירות kube-dns.

    אמורה להתקבל תגובת DNS עם כתובת ה-IP של שירות ה-API של Kubernetes (לרוב משהו כמו 10.96.0.1). אם מופיעה השגיאה SERVFAIL או שלא מתקבלת תגובה, בדרך כלל זה מצביע על כך ש-Pod kube-dns לא מצליח לפתור את שמות השירות הפנימיים.

  3. בודקים אם שירות kube-dns יכול לפתור שם דומיין חיצוני:

    dig example.com

  4. אם נתקלתם בבעיות בתגובה של Pod מסוים של kube-dns לשאילתות DNS, בדקו אם ה-Pod הזה יכול לפתור שם של דומיין חיצוני:

     dig example.com @KUBE_DNS_POD_IP

    מחליפים את KUBE_DNS_POD_IP בכתובת ה-IP של kube-dns Pod. אם אתם לא יודעים מה הערך של כתובת ה-IP הזו, מריצים את הפקודה הבאה:

     kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide

    כתובת ה-IP מופיעה בעמודה IP.

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

     ; <<>> DiG 9.16.27 <<>> example.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31256
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 512
 ;; QUESTION SECTION:
 ;example.com.                   IN      A

 ;; ANSWER SECTION:
 example.com.            30      IN      A       93.184.215.14

 ;; Query time: 6 msec
 ;; SERVER: 10.76.0.10#53(10.76.0.10)
 ;; WHEN: Tue Oct 15 16:45:26 UTC 2024
 ;; MSG SIZE  rcvd: 56

  5. יוצאים מהמעטפת:

    exit

אם אחת מהפקודות האלה נכשלת, מבצעים הפעלה מחדש מתגלגלת של kube-dns Deployment:

kubectl rollout restart deployment/kube-dns --namespace=kube-system

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

תיעוד חבילות

מבצעים לכידת חבילות כדי לוודא שהתרמילים של kube-dns מקבלים את שאילתות ה-DNS ועונים עליהן כמו שצריך:

  1. באמצעות SSH, מתחברים לצומת שבו פועל ה-Pod של kube-dns. לדוגמה:

    1. נכנסים לדף VM instances במסוף Google Cloud .

      כניסה לדף VM Instances

    2. מאתרים את הצומת שאליו רוצים להתחבר. אם אתם לא יודעים את השם של הצומת ב-Pod של kube-dns, מריצים את הפקודה הבאה:

      kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide

      שם הצומת מופיע בעמודה Node (צומת).

    3. בעמודה Connect, לוחצים על SSH.

  2. ב-Terminal, מפעילים את toolbox, כלי לניפוי באגים שמותקן מראש:

    toolbox

  3. בפרומפט של שורש, מתקינים את חבילת tcpdump:

    apt update -y && apt install -y tcpdump

  4. באמצעות tcpdump, מבצעים לכידת מנות של תעבורת ה-DNS:

    tcpdump -i eth0 port 53" -w FILE_LOCATION

    מחליפים את FILE_LOCATION בנתיב שבו רוצים לשמור את הצילום.

  5. בודקים את לכידת המנות. בודקים אם יש חבילות עם כתובות IP של יעד שתואמות לכתובת ה-IP של שירות kube-dns. כך אפשר לוודא שבקשות ה-DNS מגיעות ליעד הנכון לצורך תרגום. אם תנועת ה-DNS לא מגיעה ל-Pods הנכונים, יכול להיות שיש מדיניות רשת ב-Kubernetes שחוסמת את הבקשות.

בדיקה אם יש מדיניות רשת ב-Kubernetes

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

kubectl get networkpolicy -n kube-system

אם מצאתם מדיניות רשת, בדקו אותה וודאו שהיא מאפשרת את תקשורת ה-DNS הנדרשת. לדוגמה, אם יש לכם מדיניות רשת ב-Kubernetes שחוסמת את כל תעבורת הנתונים היוצאת (egress), המדיניות הזו תחסום גם בקשות DNS.

אם הפלט הוא No resources found in kube-system namespace, אין לכם מדיניות רשת ב-Kubernetes ואתם יכולים לשלול את האפשרות שזו הסיבה לבעיה. בדיקת היומנים יכולה לעזור לכם למצוא נקודות כשל נוספות.

הפעלת רישום זמני ביומן של שאילתות DNS

כדי לזהות בעיות כמו תגובות DNS שגויות, אפשר להפעיל באופן זמני רישום ביומן של ניפוי באגים של שאילתות DNS. כדי להפעיל שאילתות, יוצרים Pod שמבוסס על Pod קיים של kube-dns. כל שינוי בפריסת kube-dns יבוטל אוטומטית.

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

כדי להפעיל רישום זמני ביומן של שאילתות DNS:

  1. מאחזרים Pod של kube-dns ושומרים אותו במשתנה בשם POD:

    POD=$(kubectl -n kube-system get pods --selector=k8s-app=kube-dns -o jsonpath="{.items[0].metadata.name}")

  2. יוצרים Pod בשם kube-dns-debug. ה-Pod הזה הוא עותק של ה-Pod שמאוחסן במשתנה POD, אבל עם הפעלת רישום ביומן של dnsmasq. הפקודה הזו לא משנה את ה-Pod המקורי של kube-dns:

    kubectl apply -f <(kubectl get pod -n kube-system ${POD} -o json | jq -e '

(

(.spec.containers[] | select(.name == "dnsmasq") | .args) += ["--log-queries"]

)

| (.metadata.name = "kube-dns-debug")

| (del(.metadata.labels."pod-template-hash"))

')

  3. בודקים את היומנים:

    kubectl logs -f --tail 100 -c dnsmasq -n kube-system kube-dns-debug

    אפשר לראות את השאילתות גם ב-Cloud Logging.

  4. אחרי שמסיימים לצפות ביומני שאילתות DNS, מוחקים את kube-dns-debug ה-Pod:

    kubectl -n kube-system delete pod kube-dns-debug

בדיקת ה-Pod של kube-dns

בודקים איך פודי kube-dns מקבלים ומפענחים שאילתות DNS באמצעות Cloud Logging.

כדי לראות רשומות ביומן שקשורות ל-Pod של kube-dns, פועלים לפי השלבים הבאים:

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

    כניסה לדף Logs Explorer

  2. בחלונית השאילתה, מזינים את המסנן הבא כדי להציג אירועים שקשורים לקונטיינר kube-dns:

    resource.type="k8s_container"
resource.labels.namespace_name="kube-system"
resource.labels.pod_name:"kube-dns"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="CLUSTER_LOCATION"

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

    • ‫CLUSTER_NAME: השם של האשכול שאליו שייך ה-Pod של kube-dns.
    • ‫CLUSTER_LOCATION: המיקום של האשכול.

  3. לוחצים על Run query.

  4. בדקו את התוצאה. בדוגמה הבאה מוצג פלט עם שגיאה אפשרית:

    {
   "timestamp": "2024-10-10T15:32:16.789Z",
   "severity": "ERROR",
   "resource": {
      "type": "k8s_container",
      "labels": {
      "namespace_name": "kube-system",
      "pod_name": "kube-dns",
      "cluster_name": "CLUSTER_NAME",
      "location": "CLUSTER_LOCATION"
      }
   },
   "message": "Failed to resolve 'example.com': Timeout."
},

    בדוגמה הזו, kube-dns לא הצליח לפענח את example.com בזמן סביר. יכולות להיות כמה סיבות לשגיאה מהסוג הזה. לדוגמה, יכול להיות שהשרת במעלה הזרם מוגדר בצורה שגויה ב-ConfigMap של kube-dns, או שיש תנועה גבוהה ברשת.

אם לא הפעלתם את Cloud Logging, תוכלו לראות את יומני Kubernetes:

Pod=$(kubectl get Pods -n kube-system -l k8s-app=kube-dns -o name | head -n1)
kubectl logs -n kube-system $Pod -c dnsmasq
kubectl logs -n kube-system $Pod -c kubedns
kubectl logs -n kube-system $Pod -c sidecar

בודקים את השינויים האחרונים ב-ConfigMap של kube-dns

אם פתאום יש כשלים בפענוח ה-DNS באשכול, יכול להיות שהסיבה לכך היא שינוי שגוי בהגדרות של ConfigMap ב-kube-dns. בפרט, שינויים בהגדרות של דומיינים מסוג stub ושל שרתים במעלה הזרם עלולים לגרום לבעיות.

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

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

    כניסה לדף Logs Explorer

  2. בחלונית השאילתה, מזינים את השאילתה הבאה:

    resource.labels.cluster_name="clouddns"
resource.type="k8s_container"
resource.labels.namespace_name="kube-system"
labels.k8s-pod/k8s-app="kube-dns" jsonPayload.message=~"Updated stubDomains to"

  3. לוחצים על Run query.

  4. בדקו את התוצאה. אם בוצעו עדכונים, הפלט ייראה כך:

    Updated stubDomains to map[example.com: [8.8.8.8 8.8.4.4 1.1.3.3 1.0.8.111]]

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

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

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

    כניסה לדף Logs Explorer

  2. בחלונית השאילתה, מזינים את השאילתה הבאה:

    resource.labels.cluster_name="clouddns"
resource.type="k8s_container" resource.labels.namespace_name="kube-system"
labels.k8s-pod/k8s-app="kube-dns" jsonPayload.message=~"Updated upstreamNameservers to"

  3. לוחצים על Run query.

  4. בדקו את התוצאה. אם בוצעו שינויים, הפלט אמור להיראות כך:

    Updated upstreamNameservers to [8.8.8.8]

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

אם בדקתם אם יש שינויים בדומיינים של ה-stub ובשרתים במעלה הזרם, אבל לא מצאתם תוצאות, בדקו אם יש שינויים באמצעות המסנן הבא:

resource.type="k8s_cluster"
protoPayload.resourceName:"namespaces/kube-system/configmaps/kube-dns"
protoPayload.methodName=~"io.k8s.core.v1.configmaps."

בודקים את השינויים שמופיעים ברשימה כדי לראות אם הם גרמו לשגיאה.

פנייה ל-Cloud Customer Care

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

פתרון בעיות נפוצות

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

הבעיה: פסקי זמן לסירוגין ב-DNS

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

  • בודקים את מספר הפודים של kube-dns שפועלים באשכול ומשווים אותו למספר הכולל של צומתי GKE. אם אין מספיק משאבים, כדאי להרחיב אנכית (scale up) את הפודים של kube-dns.

  • כדי לשפר את זמן החיפוש הממוצע ב-DNS, צריך להפעיל את NodeLocal DNS Cache.

  • רזולוציית DNS לשמות חיצוניים עלולה ליצור עומס יתר על ה-Pod של kube-dns. כדי להקטין את מספר השאילתות, משנים את ההגדרה ndots בקובץ /etc/resolv.conf. ‫ndots מייצג את מספר הנקודות שצריכות להופיע בשם הדומיין כדי לפתור שאילתה לפני השאילתה האבסולוטית הראשונית.

    הדוגמה הבאה היא קובץ /etc/resolv.conf של Pod של אפליקציה:

    search default.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
nameserver 10.52.16.10
options ndots:5

    בדוגמה הזו, kube-dns מחפש חמש נקודות בדומיין שנשלחה לגביו שאילתה. אם ה-Pod מבצע קריאה לפתרון DNS עבור example.com, היומנים ייראו כמו בדוגמה הבאה:

    "A IN example.com.default.svc.cluster.local." NXDOMAIN
"A IN example.com.svc.cluster.local." NXDOMAIN
"A IN example.com.cluster.local." NXDOMAIN
"A IN example.com.google.internal." NXDOMAIN
"A IN example.com.c.PROJECT_ID.internal." NXDOMAIN
"A IN example.com." NOERROR

    כדי לפתור את הבעיה, אפשר לשנות את הערך של ndots ל-1 כדי לחפש רק נקודה אחת, או להוסיף נקודה (.) בסוף הדומיין שאתם שולחים לגביו שאילתה או משתמשים בו. לדוגמה:

    dig example.com.

הבעיה: שאילתות DNS נכשלות מדי פעם מצמתים מסוימים

אם אתם מבחינים בשאילתות DNS שנכשלות לסירוגין מכמה צמתים, יכול להיות שתראו את התסמינים הבאים:

  • כשמריצים פקודות dig לכתובת ה-IP של שירות kube-dns או לכתובת ה-IP של Pod, שאילתות ה-DNS נכשלות מדי פעם בגלל זמן קצוב לתפוגה.
  • הפעלת פקודות dig מ-Pod באותו צומת כמו ה-Pod של kube-dns נכשלת.

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

  1. מבצעים בדיקת קישוריות. מגדירים את ה-Pod או הצומת הבעייתיים כמקור, ואת כתובת ה-IP של ה-Pod של kube-dns כיעד. כך תוכלו לבדוק אם הוגדרו כללי חומת האש הנדרשים כדי לאפשר את התנועה הזו.

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

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

      כניסה לדף Logs Explorer

    2. בחלונית השאילתה, מזינים את השאילתה הבאה:

      logName="projects/project-name/logs/cloudaudit.googleapis.com/activity"
resource.type="gce_firewall_rule"

    3. לוחצים על Run query. משתמשים בפלט של השאילתה כדי לקבוע אם בוצעו שינויים. אם מופיעות שגיאות, מתקנים אותן ומחילים מחדש את כלל חומת האש.

      חשוב לוודא שלא מבצעים שינויים בכללי חומת אש אוטומטיים.

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

  4. כדי לבדוק אם הבקשות נשלחות לכתובת ה-IP הנכונה של שירות kube-dns, צריך ללכוד את תעבורת הרשת בצומת הבעייתי ולסנן לפי יציאה 53 (תעבורת DNS). כדי לבדוק אם הבקשות מגיעות ל-Pods המיועדים ואם הן נפתרות בהצלחה, כדאי ללכוד את התנועה ב-Pods של kube-dns עצמם.

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