מידע על Cloud DNS ל-GKE

רגילה

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

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

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

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

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

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

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

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

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

היקפי DNS

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

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

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

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

משאבי Cloud DNS

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

היקף	אזור חיפוש קדימה	אזור חיפוש הפוך
היקף האשכול	‫1 private zone per cluster per Compute Engine zone (in the region)	‫1 response policy zone per cluster per Compute Engine zone (in the region)
היקף 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)	‫1 response policy zone per cluster per Compute Engine zone (in the region) per cluster (global zone) ‫1 VPC-scoped response policy zone per cluster (global zone)
היקף VPC	אזור פרטי אחד לכל אשכול (אזור גלובלי)	‫1 response policy zone per cluster (global zone)

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

היקף	אזור חיפוש קדימה	אזור חיפוש הפוך
היקף האשכול	`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 ‫`gke-CLUSTER_NAME-CLUSTER_HASH-rp` לאזורים בהיקף אשכול
היקף 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 או שרתי שמות מותאמים אישית של upstream, ראו הוספת פותרים מותאמים אישית לדומיינים של stub.

תחומים מנוהלים ותחומים להעברה

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

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

לכל DNS stubDomain, בקר Cloud DNS יוצר תחום (zone) להעברה.

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

מכסות

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

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

משאב DNS של Kubernetes	משאב Cloud DNS תואם	מכסה
מספר רשומות ה-DNS	מספר הבייטים המקסימלי לכל תחום מנוהל	‫2,000,000 (עד 50 MB לאזור מנוהל)
מספר ה-Pods לכל שירות ללא כתובת IP (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 for GKE תומך בדומיינים מותאמים אישית של stub ובשרתי שמות במעלה הזרם שמוגדרים באמצעות 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$$
סטאק יחיד	ללא ראש	$$2+P+2E$$
ערימה כפולה	ClusterIP	$$3+P$$
ערימה כפולה	ללא ראש	$$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 של מאזן העומסים החיצוני.
שירותים ללא ממשק משתמש: לשירותים ללא ממשק משתמש יש הגדרת DNS נפרדת. כל Pod מקבל רשומת DNS משלו, שמאפשרת ללקוחות להתחבר ישירות ל-Pods. בגלל הגישה הזו, מספר היציאה לא מוכפל בחישוב של רשומת השירות ללא ראש.

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

סוג סטאק IP	סוג השירות	קבוצות רשומות
סטאק יחיד	ClusterIP	$$2+2$$
סטאק יחיד	ללא ראש	$$2+2+2*3$$
ערימה כפולה	ClusterIP	$$3+2$$
ערימה כפולה	ללא ראש	$$3+2+3*3$$

בנוסף לרשומות המינימליות האלה, יכול להיות ש-Cloud DNS ייצור רשומות SRV ורשומות AAAA (במקרה של רשתות עם תמיכה כפולה ב-IPv4 ו-IPv6). אם 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