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

אם קבוצות ה-Pod לא מצליחות להתחבר לשירותים, ובאשכול 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. הוא שימושי גם למפתחי אפליקציות שהאפליקציות שלהם נתקלות בבעיות באיתור שירותים. מידע נוסף על התפקידים הנפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם בתוכן של Google Cloud , זמין במאמר תפקידי משתמשים נפוצים ומשימות ב-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 מראה ש-Google Cloud יצר אזור בשם 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 של האשכול היא dns-test.default.svc.cluster.local..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 מציין ש-Google Cloud יצר אזור פרטי בשם gke-CLUSTER_NAME-aa94c1f9-rp. למדיניות התגובה ש-Google Cloud יוצר יש את הקידומת 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 DNS. האפשרות הזו יכולה להיות שימושית אם פתאום נתקלתם בבעיות ברזולוציות DNS באשכול.

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

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

    כניסה לדף 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, כמו מכונות וירטואליות ב-Compute Engine. Google Cloud

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

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

    מעבר אל Kubernetes clusters

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

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

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

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

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

שגיאה: לא ניתן לשלוח בקשות ל-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 for 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 תקינה.

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