Kubernetes-da DNS qidiruvi

Eslatma. tarjima.: Kubernetesdagi DNS muammosi, aniqrog'i, parametr sozlamalari ndots, hayratlanarli darajada mashhur va allaqachon Birinchi emas yil. Ushbu mavzu bo'yicha boshqa eslatmada uning muallifi, Hindistondagi yirik brokerlik kompaniyasining DevOps muhandisi, Kubernetes bilan ishlaydigan hamkasblar bilishi kerak bo'lgan narsalar haqida juda sodda va qisqacha gapiradi.

Kubernetes-da ilovalarni joylashtirishning asosiy afzalliklaridan biri bu ilovalarni uzluksiz topishdir. Xizmat kontseptsiyasi tufayli klaster ichidagi o'zaro ta'sir ancha soddalashtirilgan (xizmat), bu pod IP manzillar to'plamini qo'llab-quvvatlaydigan virtual IP. Masalan, agar xizmat vanilla xizmatga murojaat qilishni xohlaydi chocolate, u virtual IP-ga bevosita kirishi mumkin chocolate. Savol tug'iladi: bu holda DNS so'rovini kim hal qiladi chocolate Xo'sh qanday?

DNS nomi ruxsati yordamida Kubernetes klasterida sozlangan CoreDNS. Kubelet podni CoreDNS bilan fayllarda nom serveri sifatida qayd qiladi /etc/resolv.conf barcha podalar. Agar tarkibga qarasangiz /etc/resolv.conf har qanday pod, u shunday ko'rinadi:

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

Ushbu konfiguratsiya DNS mijozlari tomonidan so'rovlarni DNS serveriga yo'naltirish uchun ishlatiladi. Fayl ichida resolv.conf quyidagi ma'lumotlarni o'z ichiga oladi:

• nom serveri: DNS so'rovlari yuboriladigan server. Bizning holatda, bu CoreDNS xizmatining manzili;
• qidiruv: Muayyan domen uchun qidiruv yo'lini belgilaydi. Bu qiziq google.com yoki mrkaran.dev FQDN emas (to'liq malakali domen nomlari). Ko'pgina DNS-resolverlar amal qiladigan standart konventsiyaga ko'ra, faqat ildiz zonasini ifodalovchi "." nuqta bilan tugaydiganlar to'liq malakali (FDQN) domenlar hisoblanadi. Ba'zi hal qiluvchilar o'zlari nuqta qo'shishlari mumkin. Shunday qilib, mrkaran.dev. to'liq malakali domen nomi (FQDN) va mrkaran.dev - Yo'q;
• ndots: Eng qiziqarli parametr (bu maqola bu haqda). ndots "to'liq malakali" domen nomi deb hisoblanishidan oldin so'rov nomidagi nuqtalarning chegara sonini belgilaydi. Bu haqda keyinroq DNS qidirish ketma-ketligini tahlil qilganimizda gaplashamiz.

Keling, so'raganimizda nima bo'lishini ko'rib chiqaylik mrkaran.dev podada:

$ 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

Ushbu tajriba uchun men CoreDNS logging darajasini o'rnatdim all (bu uni juda batafsil qiladi). Keling, podning jurnallarini ko'rib chiqaylik 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

Voy. Bu erda ikkita narsa e'tiboringizni tortadi:

• Javobda kod bo'lmaguncha so'rov qidiruvning barcha bosqichlaridan o'tadi NOERROR (DNS mijozlari buni tushunadilar va natijada saqlaydilar). NXDOMAIN berilgan domen nomi uchun hech qanday yozuv topilmaganligini bildiradi. Chunki mrkaran.dev FQDN nomi emas (ko'ra ndots=5), hal qiluvchi qidiruv yo'liga qaraydi va so'rovlar tartibini belgilaydi;
• Yozuvlar А и АААА parallel ravishda keladi. Gap shundaki, bir martalik so'rovlar /etc/resolv.conf Odatiy bo'lib, ular IPv4 va IPv6 protokollari yordamida parallel qidiruvlar amalga oshiriladigan tarzda tuzilgan. Variantni qo'shish orqali bu xatti-harakatni bekor qilishingiz mumkin single-request в resolv.conf.

Eslatma: glibc ushbu so'rovlarni ketma-ket yuborish uchun sozlanishi mumkin va musl - yo'q, shuning uchun Alp tog'lari foydalanuvchilari e'tiborga olishlari kerak.

Ndots bilan tajriba o'tkazish

Keling, biroz ko'proq tajriba qilaylik ndots va keling, ushbu parametr qanday ishlashini ko'rib chiqaylik. Fikr oddiy: ndots DNS mijozi domenga mutlaq yoki nisbiy munosabatda bo'lishini aniqlaydi. Misol uchun, oddiy Google DNS mijozi bo'lsa, u bu domen mutlaq ekanligini qanday biladi? Agar siz o'rnatsangiz ndots 1 ga teng bo'lsa, mijoz aytadi: "Oh, in google bitta nuqta yo'q; O'ylaymanki, men butun qidiruv ro'yxatini ko'rib chiqaman." Biroq, agar so'rasangiz google.com, qo'shimchalar ro'yxati butunlay e'tiborga olinmaydi, chunki so'ralgan nom chegaraga mos keladi ndots (kamida bitta nuqta bor).

Keling, bunga ishonch hosil qilaylik:

$ 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 jurnallari:

[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

Yildan beri mrkaran bitta nuqta yo'q, qidiruv butun qo'shimchalar ro'yxati bo'ylab amalga oshirildi.

Eslatma: amalda maksimal qiymat ndots 15 ta bilan cheklangan; Kubernetesda sukut bo'yicha u 5 ga teng.

Ishlab chiqarishda qo'llanilishi

Agar dastur juda ko'p tashqi tarmoq qo'ng'iroqlarini amalga oshirsa, DNS faol trafik holatida muammo bo'lib qolishi mumkin, chunki nomni aniqlash ko'plab keraksiz so'rovlarni keltirib chiqaradi (tizim to'g'ri qo'ng'iroq qilishdan oldin). Ilovalar odatda domen nomlariga ildiz zonasini qo'shmaydi, lekin bu xakerlik kabi ko'rinadi. Ya'ni, so'rash o'rniga api.twitter.com, siz qattiq kodlashingiz mumkin api.twitter.com. (nuqta bilan) ilovada, bu DNS mijozlarini to'g'ridan-to'g'ri mutlaq domenda vakolatli qidiruvlarni amalga oshirishga undaydi.

Bundan tashqari, Kubernetes 1.14 versiyasidan boshlab, kengaytmalar dnsConfig и dnsPolicy barqaror holatni oldi. Shunday qilib, podkastni joylashtirishda siz qiymatni kamaytirishingiz mumkin ndots, aytaylik, 3 tagacha (va hatto 1 gacha!). Shu sababli, tugun ichidagi har bir xabar to'liq domenni o'z ichiga olishi kerak. Bu ishlash va portativlik o'rtasida tanlov qilish kerak bo'lganda klassik kelishuvlardan biridir. Menimcha, agar ilovangiz uchun ultra past kechikish juda muhim bo'lsa, bu haqda tashvishlanishingiz kerak, chunki DNS natijalari ham ichki keshda saqlanadi.

Manbalar

Men bu xususiyat haqida birinchi marta bilib oldim K8s-uchrashuv, 25 yanvar kuni bo'lib o'tdi. Shu bilan bir qatorda, ushbu muammo haqida ham muhokama qilindi.

Qo'shimcha tadqiqotlar uchun ba'zi havolalar:

• Izoh, nima uchun Kubernetesda ndots=5;
• Ajoyib narsalar ndotlarni o'zgartirish dastur ishlashiga qanday ta'sir qiladi;
• Qarama-qarshiliklar musl va glibc rezolyutsiyalari o'rtasida.

Eslatma: Men foydalanmaslikni tanladim dig ushbu maqolada. dig avtomatik ravishda nuqta (ildiz zonasi identifikatori) qo'shib, domenni "to'liq malakali" (FQDN) qiladi, yo'q avval uni qidiruv ro'yxati orqali ishga tushirish orqali. Bu haqda yozgan oldingi nashrlardan biri. Biroq, umuman olganda, standart xatti-harakatlar uchun alohida bayroq ko'rsatilishi kerakligi ajablanarli.

Baxtli DNS! Ko'rishguncha!

Tarjimondan PS

Shuningdek, bizning blogimizda o'qing:

• «Kubernetesda tarmoq yaratish uchun Calico: kirish va ozgina tajriba";
• «CoreDNS - bulutli dunyo uchun DNS server va Kubernetes uchun Service Discovery";
• "Kubernetesda tarmoqqa ulanish bo'yicha tasvirlangan qo'llanma": 1 va 2-qismlar (tarmoq modeli, qatlamli tarmoqlar), 3-qism (xizmatlar va trafikni qayta ishlash).

Manba: www.habr.com