Catetan. narjamahkeun.: Masalah DNS di Kubernetes, atawa leuwih tepatna, setélan parameter ndots, nyaeta heran populér, sarta geus . Dina catetan anu sanés ngeunaan topik ieu, panulisna, insinyur DevOps ti perusahaan brokerage ageung di India, nyarioskeun dina cara anu saderhana sareng singket ngeunaan naon anu mangpaat pikeun kolega anu ngajalankeun Kubernetes terang.
Salah sahiji kauntungan utama nyebarkeun aplikasi dina Kubernetes nyaéta penemuan aplikasi anu mulus. Interaksi intra-cluster disederhanakeun pisan berkat konsep jasa (), nu mangrupakeun IP virtual nu ngarojong sakumpulan alamat IP pod. Contona, upami jasa vanilla hoyong ngahubungan jasa chocolate, eta bisa langsung ngakses IP virtual pikeun chocolate. Patarosan timbul: saha dina hal ieu bakal ngabéréskeun pamundut DNS ka chocolate Jeung Kumaha?
Resolusi ngaran DNS dikonpigurasi dina klaster Kubernetes ngagunakeun . Kubelet ngadaptar pod kalawan CoreDNS salaku nameserver dina file /etc/resolv.conf kabéh pods. Lamun nilik kana eusina /etc/resolv.conf pod naon waé, éta bakal katingali sapertos kieu:
search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5
Konfigurasi ieu dianggo ku klien DNS pikeun neraskeun pamundut ka pangladén DNS. Dina file resolv.conf ngandung inpormasi di handap ieu:
- nameserver: server nu requests DNS bakal dikirim. Dina kasus urang, ieu mangrupikeun alamat jasa CoreDNS;
- neangan: Nangtukeun jalur pilarian pikeun domain husus. Éta metot éta
google.comatawamrkaran.devsanés FQDN (). Numutkeun konvénsi standar anu diturutan ku kalolobaan résolusi DNS, ngan ukur anu ditungtungan ku titik ".", ngalambangkeun zona akar, dianggap domain mumpuni (FDQN). Sababaraha solvers bisa nambahkeun titik sorangan. Ku kituna,mrkaran.dev.nyaeta nami domain mumpuni pinuh (FQDN), jeungmrkaran.dev- Henteu; - titik-titik: Parameter paling narik (artikel ieu ngeunaan eta).
ndotsnangtukeun jumlah bangbarung titik-titik dina ngaran pamundut saméméh dianggap ngaran domain "mumpuni pinuh". Urang bakal ngobrol langkung seueur ngeunaan ieu engké nalika urang nganalisis sekuen DNS lookup.
Hayu urang tingali naon anu lumangsung nalika urang nanya mrkaran.dev dina 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
Pikeun percobaan ieu, kuring nyetel tingkat logging CoreDNS ka all (anu ngajadikeun eta rada verbose). Hayu urang nempo log pod urang 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.145091744sPéh. Dua hal anu narik perhatian anjeun di dieu:
- Paménta ngalangkungan sadaya tahapan milarian dugi ka résponna ngandung kodeu
NOERROR(Klien DNS ngartos eta jeung nyimpen salaku hasilna).NXDOMAINhartina euweuh catetan kapanggih pikeun ngaran domain dibikeun. Kusabab étamrkaran.devsanes nami FQDN (nurutkeunndots=5), resolver kasampak di jalur pilarian sarta nangtukeun urutan requests; - Tulisan
АиААААanjog di paralel. Kanyataan yén hiji-waktos requests di/etc/resolv.confSacara standar, aranjeunna dikonpigurasi ku cara anu maluruh paralel dilakukeun nganggo protokol IPv4 sareng IPv6. Anjeun tiasa ngabatalkeun kabiasaan ieu ku nambihan pilihansingle-requestвresolv.conf.
Catetan: glibc bisa ngonpigurasi pikeun ngirim requests ieu sequentially, jeung musl - henteu, janten pangguna Alpine kedah perhatikeun.
Ékspérimén sareng titik-titik
Hayu urang ékspérimén saeutik deui kalawan ndots sarta hayu urang tingali kumaha parameter ieu behaves. Idena basajan: ndots nangtukeun naha klien DNS bakal ngubaran domain salaku mutlak atawa relatif. Contona, dina kasus hiji google DNS klien basajan, kumaha eta nyaho lamun domain ieu mutlak? Upami anjeun nyetél ndots sarua jeung 1, klien bakal nyebutkeun: "Oh, di google teu aya hiji titik; Kuring nyangka kuring bakal ngaliwat sadaya daptar panéangan. Sanajan kitu, lamun nanya google.com, daptar sufiks bakal sagemblengna dipaliré sabab ngaran nu dipénta meets bangbarung ndots (aya sahanteuna hiji titik).
Hayu urang pastikeun ieu:
$ 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: NXDOMAINCoreDNS 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
Kusabab di mrkaran teu aya hiji titik, panéangan dilaksanakeun dina sakabéh daptar sufiks.
Catetan: dina prakna nilai maksimum ndots dugi ka 15; sacara standar di Kubernetes éta 5.
Aplikasi dina produksi
Upami hiji aplikasi ngadamel seueur telepon jaringan éksternal, DNS tiasa janten bottleneck dina kasus lalu lintas aktip, sabab résolusi nami nyababkeun seueur patarosan anu teu dipikabutuh (sateuacan sistemna angkat ka anu leres). Aplikasi biasana henteu nambihan zona akar kana nami domain, tapi ieu sigana sapertos hack. Maksudna, tinimbang nanya api.twitter.com, Anjeun tiasa 'hardcode' eta api.twitter.com. (kalayan titik) dina aplikasi, anu bakal ajakan klien DNS pikeun ngalakukeun lookups otoritatif langsung dina domain mutlak.
Salaku tambahan, dimimitian ku Kubernetes versi 1.14, ekstensi dnsConfig и dnsPolicy narima status stabil. Ku kituna, nalika deploying pod a, Anjeun bisa ngurangan nilai ndots, sebutkeun, nepi ka 3 (komo nepi ka 1!). Kusabab ieu, unggal pesen dina hiji titik kedah ngalebetkeun domain lengkep. Ieu mangrupikeun salah sahiji trade-off klasik nalika anjeun kedah milih antara kinerja sareng portabilitas. Sigana mah anjeun ngan ukur kedah hariwang ngeunaan ieu upami latency ultra-low penting pisan pikeun aplikasi anjeun, sabab hasil DNS ogé disimpen sacara internal.
rujukan
Kuring mimiti diajar ngeunaan fitur ieu dina , dilaksanakeun dina 25 Januari. Aya sawala ngeunaan masalah ieu, antara séjén.
Ieu sababaraha tumbu pikeun éksplorasi salajengna:
- , naha ndots=5 di Kubernetes;
- kumaha ngarobah titik mangaruhan kinerja aplikasi;
- antara musl jeung glibc resolvers.
Catetan: Kuring milih teu make dig dina tulisan ieu. dig otomatis nambahkeun titik (root zone identifier), nyieun domain "sarat pinuh" (FQDN), teu ku mimiti ngajalankeun eta ngaliwatan daptar pilarian. Nulis ngeunaan ieu dina . Sanajan kitu, éta rada héran yén, sacara umum, hiji bandéra misah kudu dieusian pikeun kabiasaan baku.
Wilujeng DNSing! Pendak deui engké!
PS ti penerjemah
Baca ogé dina blog urang:
- «";
- «";
- "Panduan Gambar pikeun Jaringan di Kubernetes": , .
sumber: www.habr.com