Catatan perev. : Masalah DNS di Kubernetes, atau lebih tepatnya, pengaturan parameter ndots, sangat populer, dan ini bukan tahun pertama . Dalam artikel lain tentang hal ini, penulisnya, insinyur DevOps dari sebuah perusahaan pialang besar di India, menceritakan dengan cara yang sangat sederhana dan ringkas tentang apa yang perlu diketahui untuk rekan kerja yang menggunakan Kubernetes.
Salah satu keuntungan utama penerapan aplikasi di Kubernetes adalah penemuan aplikasi yang mulus. Interaksi Intracluster sangat disederhanakan oleh konsep layanan ( Layanan ), yang merupakan IP virtual, mendukung satu set pod'ov IP-address. Misalnya, jika suatu layananvanillaingin menghubungi layanan tersebutchocolate, ia dapat mengakses IP virtual secara langsungchocolate. Muncul pertanyaan: kepada siapa dalam hal ini akan menyelesaikan permintaan DNS chocolatedan bagaimana?Resolusi nama DNS dikonfigurasi di cluster Kubernetes menggunakan CoreDNS . Kubelet mendaftarkan pod dengan CoreDNS sebagai server nama di file /etc/resolv.confsemua pod. Jika Anda melihat konten /etc/resolv.confpod apa pun, itu akan terlihat seperti ini:search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5
Konfigurasi ini digunakan oleh klien DNS untuk mengarahkan permintaan ke server DNS. File tersebut resolv.confberisi informasi berikut:- nameserver : server tempat kueri DNS akan dialihkan. Dalam kasus kami, ini adalah alamat layanan CoreDNS;
- search: . ,
google.com mrkaran.dev FQDN ( ). , resolver' DNS, (FDQN) , «.», . resolver' . , mrkaran.dev. — (FQDN), mrkaran.dev — ; - ndots: ( ).
ndots , «» . , DNS-.
Mari kita lihat apa yang terjadi ketika kita meminta mrkaran.devdi pod:$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10
Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001
Untuk percobaan ini, saya mengatur level logging CoreDNS ke all(yang membuatnya sangat verbose). Mari kita lihat 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
Fuh. Dua hal mendapat perhatian di sini:- Permintaan melewati semua tahap pencarian sampai respons berisi kode
NOERROR(klien DNS memahaminya dan menyimpannya sebagai hasilnya). NXDOMAINberarti tidak ada catatan yang ditemukan untuk nama domain ini. Karena mrkaran.devitu bukan nama FQDN (sesuai dengan ndots=5), resolver melihat pada jalur pencarian dan menentukan urutan kueri; /etc/resolv.conf , IPv4 IPv6. , single-request resolv.conf.
: glibc , musl — , Alpine .ndots
Mari kita bereksperimen dengan sedikit lebih banyak ndotsdan melihat bagaimana parameter ini berperilaku. Idenya sederhana: ndotsmenentukan apakah klien DNS menganggap domain absolut atau relatif. Misalnya, bagaimana, dalam kasus google sederhana, apakah klien DNS mengetahui apakah domain ini mutlak? Jika diatur ndotske 1, klien akan mengatakan: "Oh, googletidak ada satu titik pun; Saya mungkin akan membahas seluruh daftar pencarian. " Namun, jika diminta google.com, daftar sufiks akan sepenuhnya diabaikan, karena nama yang diminta memenuhi ambang batas ndots(setidaknya ada satu titik).Mari kita pastikan ini:$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10
** server can't find mrkaran: NXDOMAIN
Log 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
Karena mrkarantidak ada titik tunggal, pencarian dilakukan di seluruh daftar sufiks.Catatan: dalam praktiknya, nilai maksimum ndotsdibatasi hingga 15; Kubernetes default ke 5.Aplikasi produksi
Jika suatu aplikasi melakukan banyak panggilan jaringan eksternal, DNS dapat menjadi penghambat dalam hal lalu lintas aktif, karena ketika menyelesaikan suatu nama, banyak pertanyaan yang tidak perlu dilakukan (sebelum sistem mencapai yang benar). Aplikasi biasanya tidak menambahkan zona root ke nama domain, namun ini cukup meretas. Artinya, alih-alih bertanya api.twitter.com, Anda dapat melakukan hardcode api.twitter.com.(dengan titik) di aplikasi, yang akan mendorong klien DNS untuk segera melakukan pencarian otoritatif dalam domain absolut.Selanjutnya, dimulai dengan versi Kubernetes 1.14, ekstensi dnsConfigdan dnsPolicydiberikan status stabil. Dengan demikian, saat menggunakan pod, Anda dapat mengurangi nilainyandots, katakanlah, hingga 3 (dan bahkan hingga 1!). Karena itu, setiap pesan dalam simpul harus menyertakan domain lengkap. Ini adalah salah satu kompromi klasik ketika Anda harus memilih antara kinerja dan portabilitas. Bagi saya, mengkhawatirkan hal ini hanya diperlukan jika latensi sangat rendah sangat penting untuk aplikasi Anda, karena hasil DNS juga di-cache secara internal.Referensi
Untuk pertama kalinya saya mengetahui tentang fitur ini pada pertemuan K8 pada 25 Januari. Ada diskusi di sana, termasuk tentang masalah ini.Berikut ini beberapa tautan untuk studi lebih lanjut:- Penjelasan mengapa ndots = 5 di Kubernetes;
- Hal hebat tentang bagaimana mengubah ndots mempengaruhi kinerja aplikasi;
- Perbedaan antara resolusi musl dan glibc.
Catatan: Saya memilih untuk tidak menggunakan digartikel ini. digsecara otomatis menambahkan titik (pengidentifikasi zona root), menjadikan domain "penuh" (FQDN), tanpa terlebih dahulu menjalankannya melalui daftar pencarian. Dia menulis tentang ini di salah satu publikasi sebelumnya . Namun, agak mengejutkan bahwa, secara umum, bendera standar harus ditetapkan untuk perilaku standar.DNSing yang bagus! Sampai jumpa lagi!PS dari penerjemah
Baca juga di blog kami: