‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מידע על Cloud DNS ל-GKE

Standard

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

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

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

ההנחה במאמר הזה היא שאתם מכירים את המושגים הבאים:

איך Cloud DNS ל-GKE פועל

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

‫Cloud DNS תומך במפרט המלא של Kubernetes DNS ומספק רזולוציה לרשומות A,‏ AAAA,‏ SRV ו-PTR לשירותים בתוך אשכול GKE. רשומות PTR מיושמות באמצעות כללים של מדיניות תגובה. לשימוש ב-Cloud DNS כספק ה-DNS של GKE יש את היתרונות הבאים על פני DNS שמתארח באשכול:

הפחתת העומס: אין צורך לנהל שרתי DNS שמתארחים באשכול. ‫Cloud DNS הוא שירות מנוהל מלא, ולכן לא צריך לבצע בו שינוי גודל, מעקב או ניהול של מופעי DNS באופן ידני.
יכולת התאמה וביצועים גבוהים: פתרון שאילתות באופן מקומי לכל צומת GKE כדי לספק פענוח DNS עם זמן אחזור נמוך ויכולת התאמה גבוהה. כדי להשיג ביצועים אופטימליים, במיוחד באשכולות גדולים, מומלץ להפעיל את NodeLocal DNSCache, שמוסיף שכבת מטמון בצומת.
שילוב עם Google Cloud Observability: מאפשר מעקב ורישום ביומן של DNS. מידע נוסף זמין במאמר הפעלה והשבתה של רישום ביומן עבור אזורים פרטיים מנוהלים.

ארכיטקטורה

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

בתרשים הבא מוצג איך מישור הבקרה ומישור הנתונים של Cloud DNS פותרים שמות של אשכולות:

‫Pod מבקש את כתובת ה-IP של שירות באמצעות Cloud DNS. — פתרון שמות של אשכולות באמצעות Cloud DNS

בתרשים, הקצה העורפי של השירות בוחר את ה-Pods הפועלים של הקצה העורפי. ה-clouddns-controller יוצר רשומת DNS עבור קצה העורפי של השירות.

ה-Pod של ממשק המשתמש שולח בקשת DNS כדי לפתור את כתובת ה-IP של השירות שנקרא backend לשרת המטא-נתונים המקומי של Compute Engine בכתובת 169.254.169.254. שרת המטא-נתונים פועל באופן מקומי בצומת, ושולח את המקרים של אי מציאה במטמון ל-Cloud DNS.

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

אחרי שה-Pod לקצה הקדמי פותר את כתובת ה-IP, הוא יכול לשלוח תנועה לקצה העורפי של השירות ולכל Pod שמאחורי השירות.

היקפי הרשאות של DNS

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

היקף אשכול GKE: אפשר לפתור רשומות DNS רק בתוך האשכול, וזו אותה התנהגות כמו ב-kube-dns. רק צמתים שפועלים באשכול GKE יכולים לפתור שמות של שירותים. כברירת מחדל, לאשכולות יש שמות DNS שמסתיימים ב-*.cluster.local. שמות ה-DNS האלה גלויים רק בתוך האשכול, והם לא חופפים לשמות ה-DNS של *.cluster.local באשכולות GKE אחרים באותו פרויקט, ולא מתנגשים איתם. זהו מצב ברירת המחדל.
- היקף VPC מצטבר של Cloud DNS: היקף ה-VPC המצטבר של Cloud DNS הוא תכונה אופציונלית שמרחיבה את היקף אשכול GKE כדי לאפשר למשאבים אחרים ב-VPC לפתור שירותים ללא ראש, כמו מכונות וירטואליות ב-Compute Engine או לקוחות מקומיים שמחוברים באמצעות Cloud VPN או Cloud Interconnect. המצב הזה הוא מצב נוסף שמופעל לצד היקף האשכול. אתם יכולים להפעיל או להשבית את המצב הזה באשכול בלי להשפיע על זמן הפעולה התקינה של ה-DNS או על היכולות של היקף האשכול.
היקף VPC: אפשר לפתור רשומות DNS בכל ה-VPC. מכונות וירטואליות של Compute Engine ולקוחות מקומיים יכולים להתחבר באמצעות Cloud Interconnect או Cloud VPN, ולפתור ישירות שמות של שירותי GKE. צריך להגדיר דומיין מותאם אישית ייחודי לכל אשכול, כלומר כל רשומות ה-DNS של השירותים וה-Pods הן ייחודיות ב-VPC. המצב הזה מצמצם את החיכוך בתקשורת בין משאבי GKE למשאבים שאינם של GKE.

בטבלה הבאה מפורטים ההבדלים בין היקפי ה-DNS:

תכונה	היקף אשכול GKE	היקף VPC נוסף ב-Cloud DNS	היקף ה-VPC
היקף החשיפה של DNS	רק באשכול GKE	באשכול בלבד, עם שירותים ללא כתובת IP שאפשר לפתור ברשת ה-VPC	כל רשת ה-VPC
רזולוציה של Headless Service	ניתן לפתרון בתוך האשכול	ניתן לפתור את הבעיה באשכול באמצעות הדומיין ‎ `cluster.local` ‎, וב-VPC באמצעות הסיומת של האשכול	ניתן לפתור בתוך האשכול ובכל ה-VPC באמצעות הסיומת של האשכול
דרישה לדומיין ייחודי	לא, משתמש בדומיין ברירת המחדל `*.cluster.local`	כן, צריך להגדיר דומיין מותאם אישית ייחודי	כן, צריך להגדיר דומיין מותאם אישית ייחודי
הגדרת התצורה	ברירת מחדל, ללא שלבים נוספים	אופציונלי בזמן יצירת האשכול אפשר להפעיל או להשבית בכל שלב	צריך להגדיר אותו במהלך יצירת האשכול

משאבים של Cloud DNS

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

היקף	אזור חיפוש קדימה	תחום DNS לחיפוש הפוך (reverse lookup zone)
היקף האשכול	אזור פרטי אחד לכל אשכול בכל אזור של Compute Engine (באזור)	‫response policy zone אחת לכל אשכול בכל אזור של Compute Engine (באזור)
היקף VPC נוסף ב-Cloud DNS	‫1 private zone per cluster per Compute Engine zone (in the region) per cluster (global zone) 1 VPC-scoped private zone per cluster (global zone)	‫אזור אחד של מדיניות תגובה לכל אשכול בכל אזור של Compute Engine (באזור) לכל אשכול (אזור גלובלי) אזור אחד של מדיניות תגובה בהיקף VPC לכל אשכול (אזור גלובלי)
היקף ה-VPC	אזור פרטי אחד לכל אשכול (אזור גלובלי)	‫1 response policy zone per cluster (global zone)

המוסכמה למתן שמות למשאבי Cloud DNS האלה היא:

היקף	אזור חיפוש קדימה	תחום DNS לחיפוש הפוך (reverse lookup zone)
היקף האשכול	`gke-CLUSTER_NAME-CLUSTER_HASH-dns`	`gke-CLUSTER_NAME-CLUSTER_HASH-rp`
היקף VPC מצטבר ב-Cloud DNS	`gke-CLUSTER_NAME-CLUSTER_HASH-dns` לאזורים בהיקף אשכול `gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc` לאזורים בהיקף VPC	`gke-CLUSTER_NAME-CLUSTER_HASH-rp` ‫ `gke-NETWORK_NAME_HASH-rp` לאזורים בהיקף VPC לאזורים בהיקף אשכול
היקף ה-VPC	`gke-CLUSTER_NAME-CLUSTER_HASH-dns`	`gke-NETWORK_NAME_HASH-rp`

בנוסף לאזורים שמוזכרים בטבלה הקודמת, בקר Cloud DNS יוצר את האזורים הבאים בפרויקט, בהתאם להגדרה:

הגדרת DNS בהתאמה אישית	סוג האזור	מוסכמה למתן שמות לאזורים
דומיין Stub	העברה (אזור גלובלי)	`gke-CLUSTER_NAME-CLUSTER_HASH-DOMAIN_NAME_HASH`
שרתי שמות בהתאמה אישית	העברה (אזור גלובלי)	`gke-CLUSTER_NAME-CLUSTER_HASH-upstream`

למידע נוסף על יצירת דומיינים מותאמים אישית של שרתי stub או שרתי שמות מותאמים אישית במעלה הזרם, קראו את המאמר הוספת פותרי שמות מותאמים אישית לדומיינים של שרתי stub.

אזורים מנוהלים ואזורים להעברה

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

לדוגמה, אם פורסים אשכול באזור us-central1-c, בקר Cloud DNS יוצר אזור מנוהל ב-us-central1-a, ב-us-central1-b, ב-us-central1-c וב-us-central1-f.

לכל stubDomain של DNS, בקר Cloud DNS יוצר אזור העברה אחד.

‫Cloud DNS מעבד כל בקשת DNS במעלה הזרם באמצעות תחום מנוהל אחד עם שם ה-DNS‏ ..

מכסות

ב-Cloud DNS יש מכסות שמגבילות את מספר המשאבים ש-GKE יכול ליצור עבור רשומות DNS. המכסות והמגבלות של Cloud DNS עשויות להיות שונות מהמגבלות של kube-dns בפרויקט שלכם.

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

משאב DNS של Kubernetes	המשאב התואם ב-Cloud DNS	מכסה
מספר רשומות ה-DNS	מספר הבייטים המקסימלי לכל אזור מנוהל	‫2,000,000 (עד 50MB לאזור מנוהל)
מספר ה-Pods לכל שירות ללא ממשק משתמש (IPv4 או IPv6)	מספר הרשומות בכל קבוצה של רשומות משאבים	‫GKE 1.24 עד 1.25: ‏1,000 (גם IPv4 וגם IPv6) ‫GKE 1.26 ואילך: 3,500 ל-IPv4; ‏2,000 ל-IPv6
מספר אשכולות GKE בפרויקט	מספר מדיניות התגובה לכל פרויקט	100
מספר רשומות ה-PTR לכל אשכול	מספר הכללים בכל מדיניות תגובה	100,000

הגבלות על משאבים

המשאבים ב-Kubernetes שאתם יוצרים לכל אשכול נכללים במגבלות המשאבים של Cloud DNS, כפי שמתואר בטבלה הבאה:

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

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

יותר מאשכול אחד לכל פרויקט שירות

החל מגרסאות GKE‏ 1.22.3-gke.700 ו-1.21.6-gke.1500, אפשר ליצור אשכולות בכמה פרויקטים של שירות שמפנים ל-VPC באותו פרויקט מארח.

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

‫Cloud DNS ל-GKE תומך בדומיינים מותאמים אישית של שרתי proxy ובשרתי שמות במעלה הזרם, שמוגדרים באמצעות kube-dns ConfigMap. התמיכה הזו זמינה רק לאשכולות GKE Standard.

‫Cloud DNS מתרגם את הערכים של stubDomains ו-upstreamNameservers לאזורי העברה של Cloud DNS.

תוספים של מפרטים

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

יציאות עם שם

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

סוג מחסנית ה-IP	סוג השירות	קבוצות של רשומות
סטאק יחיד	ClusterIP	$$2+P$$
סטאק יחיד	דפדפן בלי GUI	$$2+P+2E$$
Dual stack	ClusterIP	$$3+P$$
Dual stack	דפדפן בלי GUI	$$3+P+3E$$
מידע נוסף על שירותים עם ערימה יחידה וערימה כפולה זמין במאמר שירותים עם ערימה יחידה וערימה כפולה.

רשומות DNS נוספות שנוצרו על ידי Cloud DNS

יכול להיות ש-Cloud DNS ייצור רשומות DNS נוספות מעבר למספר המינימלי של קבוצות הרשומות. לרשומות האלה יש מטרות שונות, כולל:

רשומות SRV: לזיהוי שירותים, Cloud DNS יוצר לעיתים קרובות רשומות SRV. הרשומות האלה מספקות מידע על היציאה והפרוטוקול של השירות.
רשומות AAAA (לסטאק כפול): בהגדרות של סטאק כפול שמשתמשות ב-IPv4 וב-IPv6, ‏ Cloud DNS יוצר רשומות A (ל-IPv4) ורשומות AAAA (ל-IPv6) לכל נקודת קצה.
רשומות פנימיות: יכול להיות ש-Cloud DNS ייצור רשומות פנימיות לניהול ולאופטימיזציה שלו. בדרך כלל, הרשומות האלה לא רלוונטיות ישירות למשתמשים.
‫LoadBalancer Services: לשירותים מסוג LoadBalancer, מערכת Cloud DNS יוצרת רשומות שמשויכות לכתובת ה-IP של מאזן העומסים החיצוני.
שירותים ללא ממשק משתמש (headless): לשירותים ללא ממשק משתמש יש הגדרת DNS נפרדת. כל Pod מקבל רשומת DNS משלו, שמאפשרת ללקוחות להתחבר ישירות ל-Pods. בגלל הגישה הזו, מספר היציאה לא מוכפל בחישוב של רשומת השירות ללא ראש.

דוגמה: נניח שיש שירות בשם my-http-server שנמצא במרחב השמות backend. השירות הזה חושף שני פורטים, 80 ו-8080, לפריסה עם שלוש קבוצות Pod. לכן, E = 3 ו-P = 2.

סוג מחסנית ה-IP	סוג השירות	קבוצות של רשומות
סטאק יחיד	ClusterIP	$$2+2$$
סטאק יחיד	דפדפן בלי GUI	$$2+2+2*3$$
Dual stack	ClusterIP	$$3+2$$
Dual stack	דפדפן בלי GUI	$$3+2+3*3$$

בנוסף לרשומות המינימליות האלה, יכול להיות ש-Cloud DNS ייצור רשומות SRV, ובמקרה של רשתות עם שני סטאקים, רשומות AAAA. אם my-http-server הוא שירות מסוג LoadBalancer, נוצרות רשומות נוספות לכתובת ה-IP של מאזן העומסים. הערה: Cloud DNS מוסיף רשומות DNS משלימות לפי הצורך. הרשומות הספציפיות שנוצרות תלויות בגורמים כמו סוג השירות וההגדרות שלו.

בעיות מוכרות

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

‫Terraform מנסה ליצור מחדש את אשכול Autopilot בגלל שינוי `dns_config`

אם אתם משתמשים ב-terraform-provider-google או ב-terraform-provider-google-beta, יכול להיות שתיתקלו בבעיה שבה Terraform מנסה ליצור מחדש אשכול Autopilot. השגיאה הזו מתרחשת כי אשכולות Autopilot שנוצרו לאחרונה ומריצים את הגרסאות ‎1.25.9-gke.400,‏ ‎1.26.4-gke.500 או ‎1.27.1-gke.400 ואילך משתמשים ב-Cloud DNS כספק DNS במקום ב-kube-dns.

הבעיה נפתרה בגרסה 4.80.0 של ספק Terraform של Google Cloud.

אם אתם לא יכולים לעדכן את הגרסה של terraform-provider-google או של terraform-provider-google-beta, אתם יכולים להוסיף את ההגדרה lifecycle.ignore_changes למשאב כדי לוודא ש-google_container_cluster מתעלם משינויים ב-dns_config:

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

פענוח ה-DNS נכשל אחרי מעבר מ-`kube-dns` ל-Cloud DNS עם NodeLocal DNSCache מופעל

בקטע הזה מתוארת בעיה מוכרת באשכולות GKE שנמצאים ב-Cloud DNS, ושהופעל בהם NodeLocal DNSCache בהיקף האשכול.

אם NodeLocal DNSCache מופעל באשכול, ואתם מבצעים מיגרציה מ-kube-dns ל-Cloud DNS, יכול להיות שבאשכול יתרחשו שגיאות לסירוגין בפתרון בעיות.

אם אתם משתמשים ב-kube-dns כש-NodeLocal DNSCache מופעל באשכול, NodeLocal DNSCache מוגדר להאזין בשתי הכתובות: הכתובת של NodeLocal DNSCache והכתובת של kube-dns.

כדי לבדוק את הסטטוס של NodeLocal DNSCache, מריצים את הפקודה הבאה:

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind

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

    bind 169.254.20.10 x.x.x.10
    bind 169.254.20.10 x.x.x.10

אם GKE Dataplane V2 מופעל באשכול והאשכול משתמש ב-kube-dns,‏ NodeLocal DNSCache פועל ברשת מבודדת ומוגדר להאזין לכל כתובות ה-IP של Pod‏ (0.0.0.0). הפלט אמור להיראות כך:

    bind 0.0.0.0
    bind 0.0.0.0

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

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind