פתרון בעיות ב-Cloud DNS ב-GKE

אם קבוצות ה-Pods לא מצליחות להתחבר לשירותים ואשכול Google Kubernetes Engine ‏ (GKE) משתמש ב-Cloud DNS כספק ה-DNS, יכול להיות שתיתקלו בשגיאות כמו dial tcp: i/o timeout או no such host. השגיאות האלה מעידות בדרך כלל על בעיות בהגדרות של Cloud DNS, כמו אזורים פרטיים שהוגדרו בצורה שגויה או היקף Cloud DNS שגוי.

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

המידע הזה חשוב לאדמינים ולמפעילים של הפלטפורמה ולמומחי רשתות שמגדירים ומנהלים את השילוב בין GKE לבין Cloud DNS. הוא שימושי גם למפתחי אפליקציות שנתקלים בבעיות בגילוי שירותים באפליקציות שלהם. מידע נוסף על התפקידים הנפוצים ודוגמאות למשימות שאנחנו מתייחסים אליהן בתוכן של Cloud de Confiance by S3NS , זמין במאמר תפקידים ומשימות נפוצים של משתמשי GKE.

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

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

אימות ההגדרות הבסיסיות

אם הפוד לא מצליח לבצע בדיקות DNS, צריך לוודא ש-Cloud DNS מוגדר כמו שרוצים. בקטע הזה מוסבר איך לוודא שאתם משתמשים ב-Cloud DNS, לאשר את קיומו של תחום DNS פרטי עבור אשכול GKE ולוודא שרשומות ה-DNS של שירות היעד מדויקות.

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

  1. בודקים באיזה שרת DNS ה-Pod משתמש:

    kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver

    מחליפים את POD_NAME בשם של ה-Pod שנתקל בבעיות בפענוח DNS.

    אם אתם משתמשים ב-Cloud DNS, הפלט הוא:

    nameserver 169.254.169.254

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

  2. מוודאים שהאזורים המנוהלים קיימים:

    gcloud dns managed-zones list --format list

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

    - creationTime: 2021-02-12T19:24:37.045Z
  description: Private zone for GKE cluster "" with cluster suffix "CLUSTER_DOMAIN" in project "PROJECT_ID"
  dnsName: CLUSTER_DOMAIN.
  id: 5887499284756055830
  kind: dns#managedZone
  name: gke-CLUSTER_NAME-aa94c1f9-dns
  nameServers: ['ns-gcp-private.googledomains.com.']
  privateVisibilityConfig: {'kind': 'dns#managedZonePrivateVisibilityConfig'}
  visibility: private

    הפלט הזה כולל את הערכים הבאים:

    • ‫CLUSTER_DOMAIN: סיומת הדומיין של ה-DNS שהוקצתה אוטומטית לאשכול.
    • PROJECT_ID: מזהה הפרויקט.
    • ‫CLUSTER_NAME: השם של האשכול עם האזור הפרטי.

    בפלט הזה, הערך בשדה name מראה ש-Cloud de Confiance יצר אזור בשם gke-CLUSTER_NAME-aa94c1f9-dns.

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

  3. מאמתים את רשומות ה-DNS של השירות:

    gcloud dns record-sets list --zone ZONE_NAME | grep SERVICE_NAME

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

    • ‫ZONE_NAME: השם של האזור הפרטי.
    • ‫SERVICE_NAME: שם השירות.

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

    dns-test.default.svc.cluster.local.                A     30     10.47.255.11

    הפלט הזה מראה ש-Cloud DNS מכיל רשומת A לדומיין dns-test.default.svc.cluster.local. וכתובת ה-IP של האשכול היא 10.47.255.11.

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

אימות מדיניות התגובה

מוודאים שמדיניות התגובה קיימת וששמה נכון:

  1. כדי לראות רשימה של כל כללי המדיניות של התגובות:

    gcloud dns response-policies list --format="table(responsePolicyName, description)"

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

    RESPONSE_POLICY_NAME          DESCRIPTION
gke-CLUSTER_NAME-52c8f518-rp  Response Policy for GKE cluster "CLUSTER_NAME" with cluster suffix "cluster.local." in project "gke-dev" with scope "CLUSTER_SCOPE".

    בפלט הזה, gke-CLUSTER_NAME-52c8f518-rp מראה ש-Cloud de Confiance יצר אזור פרטי בשם gke-CLUSTER_NAME-aa94c1f9-rp. לכללי מדיניות התגובה שנוצרים על ידיCloud de Confiance יש את הקידומת gke-.

  2. כדי לראות את מדיניות התגובה באזור פרטי ספציפי:

    gcloud dns response-policies rules list ZONE_NAME \
    --format="table(localData.localDatas[0].name, localData.localDatas[0].rrdatas[0])"

    מחליפים את ZONE_NAME בשם של האזור הפרטי שבו נתקלתם בבעיות.

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

    1.240.27.10.in-addr.arpa.    kubernetes.default.svc.cluster.local.
52.252.27.10.in-addr.arpa.   default-http-backend.kube-system.svc.cluster.local.
10.240.27.10.in-addr.arpa.   kube-dns.kube-system.svc.cluster.local.
146.250.27.10.in-addr.arpa.  metrics-server.kube-system.svc.cluster.local.

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

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

חקירה באמצעות יומנים, מרכזי בקרה ומדדים

‫Cloud DNS כולל כמה אפשרויות לרישום ביומן ולמעקב, שיעזרו לכם לחקור בעיות ב-DNS:

  • כדי לראות יומנים של משאבים כמו אזורים ורשומות, צריך להפעיל את Cloud Logging ל-Cloud DNS.

  • כדי לראות תרשימים של שאילתות DNS ונתונים של שיעור השגיאות, QPS וחביון באחוזון ה-99 של התחומים הפרטיים, משתמשים בלוח הבקרה של Cloud DNS.

  • כדי להציג באופן חזותי את זמן האחזור ואת שיעורי ההצלחה של שאילתות ה-DNS, משתמשים במדדים query/latencies ו-query/response_count ב-Metrics Explorer.

חיפוש רשומות חדשות

בודקים את היומנים כדי לראות אם נוצרו רשומות חדשות באזור הפרטי המנוהל של Cloud DNS. האפשרות הזו יכולה לעזור אם פתאום נתקלתם בבעיות בפענוח DNS באשכול.

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

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

    כניסה לדף Logs Explorer

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

    resource.type="dns_managed_zone"
protoPayload.request.change.additions.name="headless-svc-stateful.default.svc.cluster.local."
protoPayload.methodName="dns.changes.create"

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

  4. בדקו את התוצאה. אם אתם מוצאים שינויים שתואמים לזמן שבו הבחנתם לראשונה בשגיאות, כדאי לשחזר אותם.

אימות של שרתי שמות ודומיינים של סטאבים בהתאמה אישית

אם אתם משתמשים באשכול GKE Standard עם דומיין stub מותאם אישית או שרת שמות במעלה הזרם, כדאי לבדוק את ConfigMap ולוודא שהערכים נכונים.

‫Cloud DNS מתרגם את הערכים stubDomains ו-upstreamNameservers לאזורי העברה של Cloud DNS. ‫Google מנהלת את המשאבים האלה, ולכן אם אתם מבחינים בשגיאות כלשהן, אתם יכולים לפנות לצוות Cloud Customer Care לקבלת עזרה.

פנייה ל-Cloud Customer Care

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

פתרון שגיאות ספציפיות

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

בעיה: אי אפשר לפתור את בעיית השירות של אשכול GKE ממכונה וירטואלית ב-Compute Engine

אם אתם לא מצליחים לפתור בעיה בשירות של אשכול GKE ממכונה וירטואלית של Compute Engine, כדאי לבדוק את היקף Cloud DNS של האשכול.

ההיקף שבו משתמשים ב-Cloud DNS קובע אילו משאבים אפשר לפענח:

  • היקף האשכול: פענוח ה-DNS מוגבל למשאבים בתוך אשכול Kubernetes (Pods ו-Services). זו הגדרת ברירת המחדל, והיא מתאימה כשלא צריך לפתור בעיות שקשורות למשאבים חיצוניים מחוץ לאשכול Kubernetes או לענן הווירטואלי הפרטי (VPC) של GKE.

  • היקף ה-VPC: פתרון ה-DNS מתרחב לכל ה-VPC, כולל משאבים כמו מכונות וירטואליות ב-Compute Engine. כך האשכול יכול לפתור רשומות DNS פנימיות של משאבים מחוץ לאשכול GKE, אבל בתוך אותו VPC, כמו מכונות וירטואליות של Cloud de Confiance by S3NS .

כדי לאמת את היקף Cloud DNS של האשכול:

  1. נכנסים לדף Kubernetes clusters במסוף Cloud de Confiance .

    כניסה לאשכולות של Kubernetes

  2. לוחצים על השם של האשכול שחווה בעיות ב-DNS.

  3. בקטע Cluster networking בדף הפרטים של האשכול, בודקים את המידע בשורה ספק DNS.

  4. אם מופיע Cloud DNS (cluster scope), אתם משתמשים בהיקף אשכול. כדי לשנות את היקף ה-DNS, צריך ליצור מחדש את האשכול עם היקף ה-DNS המתאים.

הבעיה: Pods עדיין משתמשים ב-kube-dns אחרי שהופעל Cloud DNS

אם ה-Pods שלכם משתמשים ב-kube-dns גם אחרי שהפעלתם את Cloud DNS באשכול קיים, ודאו ששדרגתם או יצרתם מחדש את מאגרי הצמתים אחרי שהפעלתם את Cloud DNS באשכול. עד שהשלב הזה יושלם, הפודים ימשיכו להשתמש ב-kube-dns.

בעיה: אי אפשר לעדכן אשכול קיים או ליצור אשכול עם Cloud DNS מופעל

חשוב לוודא שאתם משתמשים בגרסה הנכונה. כדי להשתמש ב-Cloud DNS ל-GKE, צריך להשתמש בגרסה 1.19 ואילך של GKE לאשכולות עם היקף VPC, או בגרסה 1.24.7-gke.800,‏ 1.25.3-gke.700 ואילך של GKE לאשכולות עם היקף אשכול.

בעיה: חיפושי DNS בצמתים נכשלים אחרי הפעלת Cloud DNS באשכול

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

בעיה: אי אפשר לעדכן או ליצור אשכול עם היקף VPC מצטבר של Cloud DNS

חשוב לוודא שאתם משתמשים בגרסה הנכונה. כדי להשתמש בהיקף VPC מצטבר ב-Cloud DNS, צריך להשתמש ב-GKE בגרסה 1.28 ואילך.

שגיאה: Cloud DNS מושבת

האירוע הבא מתרחש כשמשביתים את Cloud DNS API:

Warning   FailedPrecondition        service/default-http-backend
Failed to send requests to Cloud DNS: Cloud DNS API Disabled. Please enable the Cloud DNS API in your project PROJECT_NAME: Cloud DNS API has not been used in project PROJECT_NUMBER before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/dns.googleapis.com/overview?project=PROJECT_NUMBER then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.

השגיאה הזו מתרחשת כי Cloud DNS API לא מופעל כברירת מחדל. צריך להפעיל את Cloud DNS API באופן ידני.

כדי לפתור את הבעיה, צריך להפעיל את Cloud DNS API.

שגיאה: שליחת הבקשות ל-Cloud DNS נכשלה כי חרגתם ממגבלת הקצב של ה-API.

האירוע הבא מתרחש כשפרויקט חורג ממכסת Cloud DNS או ממגבלה:

kube-system   27s         Warning   InsufficientQuota
managedzone/gke-cluster-quota-ee1bd2ca-dns     Failed to send requests to Cloud DNS: API rate limit exceeded. Contact Google Cloud support team to request a quota increase for your project PROJECT_NAME: Quota exceeded for quota metric 'Write requests' and limit 'Write limit for a minute for a region' of service 'dns.googleapis.com' for consumer 'project_number:PROJECT_NUMBER.

כדי לפתור את הבעיה, צריך לעיין במכסות של Cloud DNS ובמכסות ומגבלות של Compute Engine. אפשר להגדיל את המכסה באמצעות מסוף Cloud de Confiance .

שגיאה: שליחת הבקשות ל-Cloud DNS נכשלה בגלל שגיאה קודמת

האירוע הבא מתרחש כששגיאות גורמות לכשלים מדורגים:

kube-system   27s         Warning   InsufficientQuota
managedzone/gke-cluster-quota-ee1bd2ca-dns     Failed to send requests to Cloud DNS: API rate limit exceeded. Contact Google Cloud support team to request a quota increase for your project PROJECT_NAME: Quota exceeded for quota metric 'Write requests' and limit 'Write limit for a minute for a region' of service 'dns.googleapis.com' for consumer 'project_number:PROJECT_NUMBER.
kube-system   27s         Warning   FailedPrecondition               service/default-http-backend                         Failed to send requests to Cloud DNS due to a previous error. Please check the cluster events.

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

בדוגמה שלמעלה, השגיאה InsufficientQuota באזור המנוהל גרמה לשגיאות משורשרות. השגיאה השנייה עבור FailedPrecondition מציינת שקרתה שגיאה קודמת, שהיא בעיית המכסה הראשונית הלא מספקת. כדי לפתור את הבעיה שמוצגת בדוגמה, צריך לפעול לפי ההנחיות לפתרון שגיאת מכסת Cloud DNS.

שגיאה: שיוך מדיניות התשובה נכשל

האירוע הבא מתרחש כשמדיניות תגובה משויכת לרשת של האשכול, ו-Cloud DNS ל-GKE מנסה לשייך מדיניות תגובה לרשת:

kube-system   9s          Warning   FailedPrecondition               responsepolicy/gke-2949673445-rp
Failed to bind response policy gke-2949673445-rp to test. Please verify that another Response Policy is not already associated with the network: Network 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/NETWORK_NAME' cannot be bound to this response policy because it is already bound to another response policy.
kube-system   9s          Warning   FailedPrecondition               service/kube-dns
Failed to send requests to Cloud DNS due to a previous error. Please check the cluster events.

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

  1. מקבלים את מדיניות התגובה שקשורה לרשת:

    gcloud dns response-policies list --filter='networks.networkUrl: NETWORK_URL'

    מחליפים את NETWORK_URL בכתובת ה-URL של הרשת מהשגיאה, לדוגמה https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/NETWORK_NAME.

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

    אם הפלט דומה לזה שמופיע בהמשך, דלגו לשלב 4 כדי למחוק את מדיניות התגובה.

    [
   {
      "description": "Response Policy for GKE cluster \"CLUSTER_NAME\" with cluster suffix \"cluster.local.\" in project \"PROJECT_ID\" with scope \"CLUSTER_SCOPE\".",
      ...
      "kind": "dns#responsePolicy",
      "responsePolicyName": "gke-CLUSTER_NAME-POLICY_ID-rp"
   }
]

  2. מציגים רשימה של פרויקטים עם ההרשאה dns.networks.bindDNSResponsePolicy באמצעות כלי הניתוח למדיניות של IAM.

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

    gcloud dns response-policies list --filter='networks.networkUrl:NETWORK_URL' \
    --project=PROJECT_NAME

  4. מחיקת מדיניות התגובה.

שגיאה: צוינה הגדרה לא חוקית ב-kube-dns

האירוע הבא מתרחש כשמחילים kube-dns ConfigMap מותאם אישית שלא תקף ל-Cloud DNS ל-GKE:

kube-system   49s         Warning   FailedValidation                 configmap/kube-dns
Invalid configuration specified in kube-dns: error parsing stubDomains for ConfigMap kube-dns: dnsServer [8.8.8.256] validation: IP address "8.8.8.256" invalid

כדי לפתור את הבעיה, צריך לבדוק את הפרטים בשגיאה לגבי החלק הלא תקין של ConfigMap. בדוגמה שלמעלה, 8.8.8.256 היא לא כתובת IP תקינה.

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