Pencarian DNS di Kubernetes

Catatan. terjemahan: Masalah DNS di Kubernetes, atau lebih tepatnya, pengaturan parameter ndots, ternyata sangat populer, dan sudah Bukan yang pertama tahun. Dalam catatan lain tentang topik ini, penulisnya, seorang insinyur DevOps dari sebuah perusahaan pialang besar di India, berbicara dengan cara yang sangat sederhana dan ringkas tentang apa yang berguna untuk diketahui oleh rekan-rekan yang mengoperasikan Kubernetes.

Salah satu manfaat utama penerapan aplikasi di Kubernetes adalah penemuan aplikasi yang lancar. Interaksi intra-cluster sangat disederhanakan berkat konsep layanan (Pelayanan), yang merupakan IP virtual yang mendukung sekumpulan alamat IP pod. Misalnya saja jika layanan vanilla ingin menghubungi layanan tersebut chocolate, ia dapat langsung mengakses IP virtualnya chocolate. Timbul pertanyaan: siapa dalam hal ini yang akan menyelesaikan permintaan DNS chocolate Dan bagaimana?

Resolusi nama DNS dikonfigurasi pada cluster Kubernetes menggunakan intiDNS. Kubelet mendaftarkan sebuah pod dengan CoreDNS sebagai server nama dalam file /etc/resolv.conf semua pod. Jika Anda melihat isinya /etc/resolv.conf pod apa pun, tampilannya akan 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 meneruskan permintaan ke server DNS. Dalam berkas resolv.conf berisi informasi berikut:

• nama server: server tujuan pengiriman permintaan DNS. Dalam kasus kami, ini adalah alamat layanan CoreDNS;
• Cari: Mendefinisikan jalur pencarian untuk domain tertentu. Menarik sekali google.com или mrkaran.dev bukan FQDN (nama domain yang sepenuhnya memenuhi syarat). Menurut konvensi standar yang diikuti oleh sebagian besar penyelesai DNS, hanya domain yang diakhiri dengan titik ".", yang mewakili zona akar, yang dianggap sebagai domain yang sepenuhnya memenuhi syarat (FDQN). Beberapa penyelesai dapat menambahkan poin sendiri. Dengan demikian, mrkaran.dev. adalah nama domain yang sepenuhnya memenuhi syarat (FQDN), dan mrkaran.dev - TIDAK;
• titik: Parameter paling menarik (artikel ini membahasnya). ndots menentukan jumlah titik ambang dalam nama permintaan sebelum dianggap sebagai nama domain yang “memenuhi syarat penuh”. Kami akan membicarakan hal ini lebih lanjut nanti ketika kami menganalisis urutan pencarian DNS.

Mari kita lihat apa yang terjadi jika kita bertanya mrkaran.dev di 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

Untuk percobaan ini, saya menyetel level logging CoreDNS ke all (yang membuatnya cukup bertele-tele). Mari kita lihat log podnya 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

Fiuh. Dua hal menarik perhatian Anda di sini:

• Permintaan melewati semua tahapan pencarian hingga respons berisi kode NOERROR (Klien DNS memahaminya dan menyimpannya sebagai hasilnya). NXDOMAIN berarti tidak ada catatan yang ditemukan untuk nama domain yang diberikan. Karena mrkaran.dev bukan nama FQDN (menurut ndots=5), penyelesai melihat jalur pencarian dan menentukan urutan permintaan;
• Posting А и АААА tiba secara paralel. Faktanya adalah permintaan satu kali masuk /etc/resolv.conf Secara default, mereka dikonfigurasi sedemikian rupa sehingga pencarian paralel dilakukan menggunakan protokol IPv4 dan IPv6. Anda dapat membatalkan perilaku ini dengan menambahkan opsi single-request в resolv.conf.

Catatan: glibc dapat dikonfigurasi untuk mengirim permintaan ini secara berurutan, dan musl - tidak, jadi pengguna Alpine harus memperhatikannya.

Bereksperimen dengan ndots

Mari kita bereksperimen lebih banyak lagi ndots dan mari kita lihat bagaimana parameter ini berperilaku. Idenya sederhana: ndots menentukan apakah klien DNS akan memperlakukan domain sebagai absolut atau relatif. Misalnya, dalam kasus klien DNS Google yang sederhana, bagaimana cara mengetahui apakah domain ini absolut? Jika Anda mengatur ndots sama dengan 1, klien akan berkata: “Oh, masuk google tidak ada satu poin pun; Saya kira saya akan memeriksa seluruh daftar pencarian.” Namun, jika Anda bertanya google.com, daftar sufiks akan diabaikan sepenuhnya karena nama yang diminta memenuhi ambang batas ndots (setidaknya ada satu poin).

Mari kita pastikan ini:

$ 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

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

Sejak di mrkaran tidak ada satu titik pun, pencarian dilakukan di seluruh daftar sufiks.

Catatan: dalam prakteknya nilai maksimal ndots terbatas pada 15; secara default di Kubernetes adalah 5.

Aplikasi dalam produksi

Jika aplikasi membuat banyak panggilan jaringan eksternal, DNS dapat menjadi penghambat jika lalu lintas aktif, karena resolusi nama membuat banyak pertanyaan yang tidak perlu (sebelum sistem mendapatkan yang benar). Aplikasi biasanya tidak menambahkan zona root ke nama domain, tapi ini terdengar seperti peretasan. Maksudnya, daripada bertanya api.twitter.com, Anda dapat melakukan 'hardcode' api.twitter.com. (dengan titik) pada aplikasi, yang akan meminta klien DNS untuk melakukan pencarian otoritatif langsung pada domain absolut.

Selain itu, dimulai dengan Kubernetes versi 1.14, ekstensi dnsConfig и dnsPolicy menerima status stabil. Jadi, saat men-deploy pod, Anda dapat mengurangi nilainya ndots, katakanlah, hingga 3 (dan bahkan hingga 1!). Oleh karena itu, setiap pesan dalam sebuah node harus menyertakan domain lengkap. Ini adalah salah satu trade-off klasik ketika Anda harus memilih antara kinerja dan portabilitas. Menurut saya, Anda hanya perlu mengkhawatirkan hal ini jika latensi sangat rendah sangat penting untuk aplikasi Anda, karena hasil DNS juga di-cache secara internal.

referensi

Saya pertama kali mengetahui tentang fitur ini di Pertemuan K8, diadakan pada tanggal 25 Januari. Ada diskusi mengenai masalah ini, antara lain.

Berikut ini beberapa tautan untuk eksplorasi lebih lanjut:

• Penjelasan, mengapa ndots=5 di Kubernetes;
• bahan yang sangat baik bagaimana perubahan ndots mempengaruhi kinerja aplikasi;
• Perbedaan antara penyelesai musl dan glibc.

Catatan: Saya memilih untuk tidak menggunakan dig dalam artikel ini. dig secara otomatis menambahkan titik (pengidentifikasi zona akar), menjadikan domain "sepenuhnya memenuhi syarat" (FQDN), tidak dengan terlebih dahulu menjalankannya melalui daftar pencarian. Menulis tentang ini di salah satu publikasi sebelumnya. Namun, cukup mengejutkan bahwa, secara umum, tanda terpisah harus ditentukan untuk perilaku standar.

Selamat DNS! Sampai jumpa lagi!

PS dari penerjemah

Baca juga di blog kami:

• «Calico untuk jaringan di Kubernetes: pengenalan dan sedikit pengalaman»;
• «CoreDNS - Server DNS untuk dunia cloud native dan Service Discovery untuk Kubernetes»;
• "Panduan Bergambar untuk Jaringan di Kubernetes": bagian 1 dan 2 (model jaringan, jaringan overlay), bagian 3 (layanan dan pemrosesan lalu lintas).

Sumber: www.habr.com