Panelusuran DNS ing Kubernetes

Cathetan. nerjemahake.: Masalah DNS ing Kubernetes, utawa luwih tepat, setelan parameter ndots, kaget populer, lan wis Ora pisanan ngono. Ing cathetan liyane babagan topik iki, panulise, insinyur DevOps saka perusahaan perantara gedhe ing India, ngomong kanthi cara sing gampang lan ringkes babagan apa sing migunani kanggo ngerti para kolega sing ngoperasikake Kubernetes.

Salah sawijining mupangat utama nggunakake aplikasi ing Kubernetes yaiku panemuan aplikasi sing lancar. Interaksi intra-cluster disederhanakake amarga konsep layanan (Service), yaiku IP virtual sing ndhukung sakumpulan alamat IP pod. Contone, yen layanan vanilla pengin hubungi layanan chocolate, bisa langsung ngakses IP virtual kanggo chocolate. Pitakonan muncul: sing ing kasus iki bakal mutusake masalah panjalukan DNS kanggo chocolate Lan Piye?

Résolusi jeneng DNS dikonfigurasi ing kluster Kubernetes nggunakake CoreDNS. Kubelet ndhaptar pod karo CoreDNS minangka nameserver ing file /etc/resolv.conf kabeh polong. Yen katon ing isi /etc/resolv.conf sembarang pod, bakal katon kaya iki:

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

Konfigurasi iki digunakake dening klien DNS kanggo nerusake panjalukan menyang server DNS. Ing file resolv.conf ngemot informasi ing ngisor iki:

• nameserver: server sing njaluk DNS bakal dikirim. Ing kasus kita, iki alamat layanan CoreDNS;
• search: Nemtokake path panelusuran kanggo domain tartamtu. Iku menarik sing google.com utawa mrkaran.dev dudu FQDN (jeneng domain kanthi qualified). Miturut konvensi standar sing umume solvers DNS tindakake, mung sing diakhiri karo titik ".", sing makili zona oyod, dianggep minangka domain qualified (FDQN). Sawetara solvers bisa nambah titik dhewe. Mangkono, mrkaran.dev. iku jeneng domain kanthi qualified (FQDN), lan mrkaran.dev - Ora;
• titik: Parameter paling menarik (artikel iki babagan). ndots nemtokake nomer ambang titik ing jeneng panyuwunan sadurunge dianggep minangka jeneng domain "kualifikasi". Kita bakal ngomong luwih akeh babagan iki nalika nganalisa urutan golek DNS.

Ayo ndeleng apa sing kedadeyan nalika takon mrkaran.dev ing pod:

$ 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

Kanggo eksperimen iki, aku nyetel level logging CoreDNS all (sing ndadekake cukup verbose). Ayo katon ing log pod 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

Phew. Rong perkara sing narik perhatian sampeyan ing kene:

• Panjaluk kasebut ngliwati kabeh tahap telusuran nganti tanggepan ngemot kode kasebut NOERROR (Klien DNS ngerti lan nyimpen minangka asil). NXDOMAIN tegese ora ana rekaman sing ditemokake kanggo jeneng domain sing diwenehake. Amarga ing mrkaran.dev dudu jeneng FQDN (miturut ndots=5), solver katon ing path panelusuran lan nemtokake urutan panjalukan;
• Р - Р ° РїРёС --Рё А и АААА teka ing podo karo. Kasunyatan iku siji-wektu panjalukan ing /etc/resolv.conf Kanthi gawan, padha dikonfigurasi kanthi cara supaya telusuran paralel ditindakake kanthi nggunakake protokol IPv4 lan IPv6. Sampeyan bisa mbatalake prilaku iki kanthi nambah pilihan single-request в resolv.conf.

Wigati: glibc bisa diatur kanggo ngirim panjalukan iki sequentially, lan musl - ora, supaya pangguna Alpine kudu njupuk cathetan.

Eksperimen karo dot

Ayo dadi eksprimen sethitik liyane karo ndots lan ayo kang ndeleng carane parameter iki tumindak. Ide iki prasaja: ndots nemtokake manawa klien DNS bakal nganggep domain kasebut minangka absolut utawa relatif. Contone, ing kasus klien DNS google sing prasaja, kepiye carane ngerti yen domain iki mutlak? Yen sampeyan nyetel ndots padha karo 1, klien bakal ngomong: "Oh, ing google ora ana titik siji; Aku kira aku bakal mbukak kabeh dhaptar telusuran. Nanging, yen sampeyan takon google.com, dhaptar sufiks bakal diabaikan kabeh amarga jeneng sing dijaluk memenuhi ambang ndots (paling ora ana siji titik).

Ayo priksa iki:

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

[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

Wiwit ing mrkaran ora ana titik siji, telusuran ditindakake ing kabeh dhaptar sufiks.

Cathetan: ing laku nilai maksimum ndots winates kanggo 15; kanthi standar ing Kubernetes yaiku 5.

Aplikasi ing produksi

Yen aplikasi nggawe akeh panggilan jaringan eksternal, DNS bisa dadi kemacetan ing kasus lalu lintas aktif, amarga resolusi jeneng nggawe akeh pitakon sing ora perlu (sadurunge sistem tekan sing bener). Aplikasi biasane ora nambah zona ROOT kanggo jeneng domain, nanging iki muni kaya hack. Sing, tinimbang takon api.twitter.com, sampeyan bisa hardcode api.twitter.com. (kanthi titik) ing aplikasi, sing bakal njaluk klien DNS kanggo nindakake lookups wewenang langsung ing domain Absolute.

Kajaba iku, diwiwiti karo Kubernetes versi 1.14, ekstensi dnsConfig и dnsPolicy nampa status stabil. Mangkono, nalika nyebarake pod, sampeyan bisa nyuda regane ndots, ngomong, nganti 3 (lan malah nganti 1!). Amarga iki, saben pesen ing simpul kudu nyakup domain lengkap. Iki minangka salah sawijining trade-off klasik nalika sampeyan kudu milih antarane kinerja lan portabilitas. Kayane sampeyan mung kudu kuwatir babagan iki yen latensi ultra-rendah penting kanggo aplikasi sampeyan, amarga asil DNS uga di-cache ing njero.

referensi

Aku pisanan sinau babagan fitur iki ing K8s-ketemu, dianakaké ing 25 Januari. Ana diskusi babagan masalah iki, ing antarane liyane.

Ing ngisor iki sawetara tautan kanggo eksplorasi luwih lanjut:

• Panjelasan, kok ndots=5 ing Kubernetes;
• materi sing apik banget carane ngganti dot mengaruhi kinerja aplikasi;
• Bedane antarane musl lan glibc solvers.

Cathetan: Aku milih ora nggunakake dig ing artikel iki. dig kanthi otomatis nambah titik (pengenal zona ROOT), nggawe domain "kualifikasi lengkap" (FQDN), ora kanthi pisanan mbukak liwat dhaptar telusuran. Nulis babagan iki ing salah sawijining publikasi sadurunge. Nanging, cukup nggumunake, umume, gendéra sing kapisah kudu ditemtokake kanggo prilaku standar.

Sugeng DNSing! Ketemu maneh!

PS saka penerjemah

Waca uga ing blog kita:

• «Calico kanggo jaringan ing Kubernetes: introduksi lan pengalaman sethithik";
• «CoreDNS - Server DNS kanggo jagad asli awan lan Penemuan Layanan kanggo Kubernetes";
• "Pandhuan Ilustrasi kanggo Jaringan ing Kubernetes": bagean 1 lan 2 (model jaringan, jaringan overlay), bagean 3 (layanan lan pangolahan lalu lintas).

Source: www.habr.com