חיפוש DNS ב-Kubernetes

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

אחד היתרונות העיקריים של פריסת יישומים ב- Kubernetes הוא גילוי חלק של יישומים. האינטראקציה בתוך אשכול מפושטת מאוד הודות לתפיסת השירות (שֵׁרוּת), שהוא IP וירטואלי התומך בקבוצה של כתובות IP של תרמילים. לדוגמה, אם השירות vanilla מעוניין ליצור קשר עם השירות chocolate, הוא יכול לגשת ישירות ל-IP הווירטואלי עבור chocolate. נשאלת השאלה: למי במקרה זה יפתור את בקשת ה-DNS chocolate ואיך?

רזולוציית שם DNS מוגדרת באשכול Kubernetes באמצעות CoreDNS. Kubelet רושם פוד עם CoreDNS כשרת שמות בקבצים /etc/resolv.conf כל התרמילים. אם מסתכלים על התוכן /etc/resolv.conf כל פוד, הוא ייראה בערך כך:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

תצורה זו משמשת לקוחות DNS להעברת בקשות לשרת ה-DNS. בקובץ resolv.conf מכיל את המידע הבא:

• שם שרת: שרת שאליו יישלחו בקשות DNS. במקרה שלנו, זו הכתובת של שירות CoreDNS;
• search: מגדיר את נתיב החיפוש עבור תחום ספציפי. זה מעניין google.com או mrkaran.dev אינם FQDN (שמות דומיין מוסמכים לחלוטין). על פי המוסכמה הסטנדרטית שרוב פותרי ה-DNS פועלים לפיה, רק אלו המסתיימים בנקודה ".", המייצגת את אזור השורש, נחשבים לדומיינים כשירים לחלוטין (FDQN). חלק מהפותרים יכולים להוסיף נקודה בעצמם. לכן, mrkaran.dev. הוא שם הדומיין המלא (FQDN), ו mrkaran.dev - לא;
• נקודות: הפרמטר המעניין ביותר (מאמר זה עוסק בו). ndots מציין את מספר הסף של נקודות בשם בקשה לפני שהוא ייחשב כשם דומיין "מוסמך לחלוטין". נדבר על כך יותר מאוחר יותר כאשר ננתח את רצף בדיקת ה-DNS.

בוא נראה מה קורה כשנשאל mrkaran.dev בתרמיל:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

עבור הניסוי הזה, הגדרתי את רמת הרישום CoreDNS ל all (מה שהופך את זה די מילולי). בואו נסתכל על היומנים של התרמיל coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

פיו. שני דברים מושכים את תשומת לבך כאן:

• הבקשה עוברת את כל שלבי החיפוש עד שהתגובה מכילה את הקוד NOERROR (לקוחות DNS מבינים זאת ומאחסנים אותו כתוצאה מכך). NXDOMAIN פירושו שלא נמצאה רשומה עבור שם הדומיין הנתון. בגלל ה mrkaran.dev אינו שם FQDN (לפי ndots=5), פותר מסתכל על נתיב החיפוש וקובע את סדר הבקשות;
• הקלטות А и АААА להגיע במקביל. העובדה היא שבקשות חד פעמיות נכנסות /etc/resolv.conf כברירת מחדל, הם מוגדרים כך שחיפושים מקבילים מבוצעים באמצעות פרוטוקולי IPv4 ו-IPv6. אתה יכול לבטל התנהגות זו על ידי הוספת האפשרות single-request в resolv.conf.

הערה: glibc ניתן להגדיר לשלוח בקשות אלה ברצף, וכן musl - לא, אז משתמשים באלפין צריכים לשים לב.

ניסוי עם נקודות

בואו נתנסה קצת יותר עם ndots ובואו נראה איך הפרמטר הזה מתנהג. הרעיון פשוט: ndots קובע אם לקוח ה-DNS יתייחס לתחום כאל מוחלט או יחסי. לדוגמה, במקרה של לקוח DNS פשוט של גוגל, איך הוא יודע אם התחום הזה הוא מוחלט? אם תגדיר ndots שווה ל-1, הלקוח יגיד: "אה, ב google אין נקודה אחת; אני מניח שאעבור על כל רשימת החיפושים." עם זאת, אם אתה שואל google.com, רשימת הסיומות תתעלם לחלוטין מכיוון שהשם המבוקש עומד בסף ndots (יש לפחות נקודה אחת).

בואו נוודא את זה:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

יומני CoreDNS:

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

מאז ב mrkaran אין נקודה אחת, החיפוש בוצע על פני כל רשימת הסיומות.

הערה: בפועל הערך המקסימלי ndots מוגבל ל-15; כברירת מחדל ב- Kubernetes זה 5.

יישום בייצור

אם אפליקציה מבצעת הרבה שיחות רשת חיצוניות, DNS יכול להפוך לצוואר בקבוק במקרה של תעבורה פעילה, שכן פתרון שמות גורם להרבה שאילתות מיותרות (לפני שהמערכת מגיעה לזו הנכונה). יישומים בדרך כלל לא מוסיפים אזור שורש לשמות דומיין, אבל זה נשמע כמו פריצה. כלומר, במקום לשאול api.twitter.com, אתה יכול קוד קשיח api.twitter.com. (עם נקודה) באפליקציה, שתנחה לקוחות DNS לבצע חיפושים סמכותיים ישירות על התחום המוחלט.

בנוסף, החל מגרסה 1.14 של Kubernetes, הרחבות dnsConfig и dnsPolicy קיבל מצב יציב. לפיכך, בעת פריסת פוד, אתה יכול להפחית את הערך ndots, נניח, עד 3 (ואפילו עד 1!). בגלל זה, כל הודעה בתוך צומת תצטרך לכלול את הדומיין המלא. זהו אחד מהפשרות הקלאסיות כאשר אתה צריך לבחור בין ביצועים וניידות. נראה לי שאתה צריך לדאוג לגבי זה רק אם זמן אחזור נמוך במיוחד הוא חיוני ליישום שלך, מכיוון שתוצאות ה-DNS נשמרות גם באופן פנימי.

תזכור

למדתי לראשונה על התכונה הזו ב- מפגש K8s, שנערך ב-25 בינואר. היה דיון על בעיה זו, בין היתר.

הנה כמה קישורים לחקירה נוספת:

• הסבר, למה ndots=5 ב-Kubernetes;
• חומר מעולה כיצד שינוי נקודות משפיע על ביצועי האפליקציה;
• אי התאמות בין רזולורי musl ו-glibc.

הערה: בחרתי לא להשתמש dig במאמר זה. dig מוסיף אוטומטית נקודה (מזהה אזור שורש), מה שהופך את הדומיין ל"מוסמך לחלוטין" (FQDN), לא על ידי הפעלתו תחילה ברשימת החיפוש. כתב על זה ב אחד הפרסומים הקודמים. עם זאת, זה די מפתיע שבאופן כללי, יש לציין דגל נפרד עבור ההתנהגות הסטנדרטית.

DNSing שמח! נתראה אחר כך!

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «Calico לנטוורקינג ב-Kubernetes: היכרות וקצת ניסיון";
• «CoreDNS - שרת DNS לעולם הילידים בענן ו-Service Discovery עבור Kubernetes";
• "מדריך מאויר לרשת ב-Kubernetes": חלקים 1 ו-2 (דגם רשת, רשתות שכבת על), חלק 3 (שירותים ועיבוד תעבורה).

מקור: www.habr.com