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

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

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

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

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

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

kubectl get networkpolicy -n kube-system

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

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

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