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

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

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

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

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

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

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

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

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

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 ב-Pods האלה:

    Warning: OOMKilling Memory cgroup out of memory

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

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

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

    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. אם יש כמה תרמילים שבהם יש בעיות, צריך לחזור על השלבים שבקטע הזה לכל תרמיל.

    אם קובץ ה-binary של ה-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. אם נתקלתם בבעיות עם פוד kube-dns מסוים שמגיב לשאילתות DNS, בדקו אם הפוד הזה יכול לתרגם שם של דומיין חיצוני:

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

תיעוד חבילות

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

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

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

kubectl get networkpolicy -n kube-system

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

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

הפעלת רישום זמני ביומן של שאילתות 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 ושל הגדרות שרתי upstream עלולים לגרום לבעיות.

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

  • בודקים את מספר ה-Pods של kube-dns שפועלים באשכול ומשווים אותו למספר הכולל של צמתי GKE. אם אין מספיק משאבים, כדאי להגדיל את הקיבולת של פודים של 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. אם לא בוצעו שינויים בכללי חומת האש, צריך לבדוק את הגרסה של מאגר הצמתים ולוודא שהיא תואמת למישור הבקרה ולמאגרי צמתים אחרים שפועלים. אם אחד ממאגרי הצמתים של האשכול ישן יותר משתי גרסאות משניות של מישור הבקרה, יכול להיות שזו הסיבה לבעיות. מידע נוסף על חוסר התאימות הזה זמין במאמר בנושא גרסת Node לא תואמת לגרסת מישור הבקרה.

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

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