การค้นหา DNS ใน Kubernetes

บันทึก. แปล: ปัญหา DNS ใน Kubernetes หรือถ้าให้เจาะจงกว่านั้นคือการตั้งค่าพารามิเตอร์ ndotsได้รับความนิยมอย่างน่าประหลาดใจอยู่แล้ว ไม่ใช่ครั้งแรก ปี. ในหมายเหตุอีกประการหนึ่งของหัวข้อนี้ ผู้เขียนซึ่งเป็นวิศวกร DevOps จากบริษัทนายหน้ารายใหญ่ในอินเดีย พูดคุยในลักษณะที่เรียบง่ายและกระชับเกี่ยวกับสิ่งที่ควรรู้สำหรับเพื่อนร่วมงานที่ทำงาน Kubernetes

ประโยชน์หลักอย่างหนึ่งของการปรับใช้แอปพลิเคชันบน Kubernetes คือการค้นพบแอปพลิเคชันที่ราบรื่น การโต้ตอบภายในคลัสเตอร์นั้นง่ายขึ้นอย่างมากด้วยแนวคิดการบริการ (Service) ซึ่งเป็น 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
• ค้นหา: กำหนดเส้นทางการค้นหาสำหรับโดเมนเฉพาะ มันน่าสนใจตรงที่ 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 - ไม่ ดังนั้นผู้ใช้ Alpine ควรรับทราบ

การทดลองกับ ndots

มาทดลองกันอีกสักหน่อยกับ ndots และมาดูกันว่าพารามิเตอร์นี้ทำงานอย่างไร แนวคิดนั้นง่าย: ndots กำหนดว่าไคลเอ็นต์ DNS จะถือว่าโดเมนเป็นแบบสัมบูรณ์หรือแบบสัมพันธ์ ตัวอย่างเช่น ในกรณีของไคลเอนต์ Google 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 ทำการค้นหาที่เชื่อถือได้โดยตรงบนโดเมนสัมบูรณ์

นอกจากนี้ เริ่มต้นด้วยส่วนขยาย Kubernetes เวอร์ชัน 1.14 dnsConfig и dnsPolicy ได้รับสถานะที่มั่นคง ดังนั้นเมื่อปรับใช้พ็อด คุณสามารถลดมูลค่าได้ ndotsพูดได้ถึง 3 (และถึง 1 ด้วยซ้ำ!) ด้วยเหตุนี้ ทุกข้อความภายในโหนดจะต้องมีโดเมนแบบเต็ม นี่เป็นหนึ่งในการแลกเปลี่ยนแบบคลาสสิกเมื่อคุณต้องเลือกระหว่างประสิทธิภาพและการพกพา สำหรับฉันดูเหมือนว่าคุณควรกังวลเกี่ยวกับเรื่องนี้เฉพาะในกรณีที่เวลาแฝงต่ำเป็นพิเศษมีความสำคัญต่อแอปพลิเคชันของคุณ เนื่องจากผลลัพธ์ DNS จะถูกแคชไว้ภายในด้วย

การอ้างอิง

ฉันได้เรียนรู้เกี่ยวกับคุณลักษณะนี้เป็นครั้งแรกใน K8s-มีตติ้งซึ่งจัดขึ้นเมื่อวันที่ 25 มกราคม มีการอภิปรายเกี่ยวกับปัญหานี้เหนือสิ่งอื่นใด

นี่คือลิงค์บางส่วนสำหรับการสำรวจเพิ่มเติม:

• คำอธิบายทำไม ndots=5 ใน Kubernetes
• สิ่งดีๆ การเปลี่ยนแปลง ndots ส่งผลต่อประสิทธิภาพของแอปพลิเคชันอย่างไร
• ความคลาดเคลื่อน ระหว่างตัวแก้ไข musl และ glibc

หมายเหตุ: ฉันเลือกที่จะไม่ใช้ dig ในบทความนี้ dig เพิ่มจุด (ตัวระบุโซนราก) โดยอัตโนมัติ ทำให้โดเมน "มีคุณสมบัติครบถ้วน" (FQDN) ไม่ โดยเรียกใช้ผ่านรายการค้นหาก่อน เขียนเกี่ยวกับเรื่องนี้ใน หนึ่งในสิ่งพิมพ์ก่อนหน้านี้. อย่างไรก็ตาม ค่อนข้างน่าแปลกใจที่โดยทั่วไปแล้ว จะต้องระบุแฟล็กแยกต่างหากสำหรับการทำงานมาตรฐาน

ขอให้มีความสุขกับ DNS! แล้วพบกันใหม่!

ปล.จากผู้แปล

อ่านเพิ่มเติมในบล็อกของเรา:

• «Calico สำหรับการสร้างเครือข่ายใน Kubernetes: บทนำและประสบการณ์เล็กน้อย";
• «CoreDNS - เซิร์ฟเวอร์ DNS สำหรับโลกคลาวด์เนทีฟและ Service Discovery สำหรับ Kubernetes";
• "ภาพประกอบคู่มือการสร้างเครือข่ายใน Kubernetes": ส่วนที่ 1 และ 2 (โมเดลเครือข่าย, เครือข่ายโอเวอร์เลย์), ส่วนที่ 3 (บริการและการประมวลผลการรับส่งข้อมูล).

ที่มา: will.com