🥇Pencarian DNS dalam Kubernetes

Catatan. terjemah: Masalah DNS dalam Kubernetes, atau lebih tepat lagi, tetapan parameter ndots, sangat popular dan sudah pun Bukan dulu tahun. Dalam nota lain mengenai topik ini, pengarangnya, seorang jurutera DevOps daripada syarikat broker besar di India, bercakap dengan cara yang sangat mudah dan padat tentang perkara yang berguna untuk diketahui oleh rakan sekerja yang mengendalikan Kubernetes.

Salah satu faedah utama menggunakan aplikasi pada Kubernetes ialah penemuan aplikasi yang lancar. Interaksi intra-kluster sangat dipermudahkan terima kasih kepada konsep perkhidmatan (Servis), iaitu IP maya yang menyokong set alamat IP pod. Sebagai contoh, jika perkhidmatan vanilla ingin menghubungi perkhidmatan tersebut chocolate, ia boleh terus mengakses IP maya untuk chocolate. Persoalannya timbul: siapa dalam kes ini akan menyelesaikan permintaan DNS chocolate Dan bagaimana?

Resolusi nama DNS dikonfigurasikan pada kelompok Kubernetes menggunakan CoreDNS. Kubelet mendaftarkan pod dengan CoreDNS sebagai pelayan nama dalam fail /etc/resolv.conf semua pod. Jika dilihat pada kandungannya /etc/resolv.conf mana-mana pod, ia akan kelihatan 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 memajukan permintaan ke pelayan DNS. Dalam fail resolv.conf mengandungi maklumat berikut:

pelayan nama: pelayan yang permintaan DNS akan dihantar. Dalam kes kami, ini ialah alamat perkhidmatan CoreDNS;
cari: Mentakrifkan laluan carian untuk domain tertentu. Memang menarik itu google.com atau mrkaran.dev bukan FQDN (nama domain yang layak sepenuhnya). Menurut konvensyen standard yang diikuti oleh kebanyakan penyelesai DNS, hanya yang berakhir dengan titik ".", mewakili zon akar, dianggap sebagai domain yang layak sepenuhnya (FDQN). Sesetengah penyelesai boleh menambah mata sendiri. Oleh itu, mrkaran.dev. ialah nama domain yang layak sepenuhnya (FQDN), dan mrkaran.dev - Tidak;
titik: Parameter yang paling menarik (artikel ini adalah mengenainya). ndots menentukan bilangan ambang titik dalam nama permintaan sebelum ia dianggap sebagai nama domain "layak sepenuhnya". Kami akan bercakap lebih lanjut mengenai perkara ini kemudian apabila kami menganalisis jujukan carian DNS.

Mari lihat apa yang berlaku apabila kita bertanya mrkaran.dev dalam 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 percubaan ini, saya menetapkan tahap pengelogan CoreDNS kepada all (yang menjadikannya agak verbose). Mari 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 perkara menarik perhatian anda di sini:

Permintaan itu melalui semua peringkat carian sehingga respons mengandungi kod NOERROR (Pelanggan DNS memahaminya dan menyimpannya sebagai hasilnya). NXDOMAIN bermakna tiada rekod ditemui untuk nama domain yang diberikan. Kerana ia mrkaran.dev bukan nama FQDN (mengikut ndots=5), penyelesai melihat laluan carian dan menentukan susunan permintaan;
Posts А и АААА tiba selari. Hakikatnya ialah permintaan sekali masuk /etc/resolv.conf Secara lalai, ia dikonfigurasikan sedemikian rupa sehingga carian selari dilakukan menggunakan protokol IPv4 dan IPv6. Anda boleh membatalkan tingkah laku ini dengan menambah pilihan single-request в resolv.conf.

Nota: glibc boleh dikonfigurasikan untuk menghantar permintaan ini secara berurutan, dan musl - tidak, jadi pengguna Alpine harus mengambil perhatian.

Bereksperimen dengan titik

Mari bereksperimen sedikit lagi ndots dan mari kita lihat bagaimana parameter ini berkelakuan. Ideanya mudah: ndots menentukan sama ada klien DNS akan menganggap domain sebagai mutlak atau relatif. Sebagai contoh, dalam kes klien DNS google yang mudah, bagaimanakah ia mengetahui sama ada domain ini adalah mutlak? Jika anda menetapkan ndots sama dengan 1, pelanggan akan berkata: "Oh, dalam google tidak ada satu pun titik; Saya rasa saya akan meneliti keseluruhan senarai carian.” Namun, jika anda bertanya google.com, senarai akhiran akan diabaikan sepenuhnya kerana nama yang diminta memenuhi ambang ndots (ada sekurang-kurangnya satu titik).

Mari 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 telah dilakukan di seluruh senarai akhiran.

Nota: dalam amalan nilai maksimum ndots terhad kepada 15; secara lalai dalam Kubernetes ia adalah 5.

Aplikasi dalam pengeluaran

Jika aplikasi membuat banyak panggilan rangkaian luaran, DNS boleh menjadi halangan dalam kes trafik aktif, kerana resolusi nama membuat banyak pertanyaan yang tidak perlu (sebelum sistem sampai ke yang betul). Aplikasi biasanya tidak menambah zon akar pada nama domain, tetapi ini kelihatan seperti penggodaman. Maksudnya, bukannya bertanya api.twitter.com, anda boleh 'hardcode'nya api.twitter.com. (dengan titik) dalam aplikasi, yang akan menggesa pelanggan DNS untuk melakukan carian berwibawa terus pada domain mutlak.

Selain itu, bermula dengan Kubernetes versi 1.14, sambungan dnsConfig и dnsPolicy menerima status stabil. Oleh itu, apabila menggunakan pod, anda boleh mengurangkan nilai ndots, katakan, sehingga 3 (dan juga sehingga 1!). Oleh sebab itu, setiap mesej dalam nod perlu memasukkan domain penuh. Ini adalah salah satu pertukaran klasik apabila anda perlu memilih antara prestasi dan mudah alih. Nampaknya anda hanya perlu bimbang tentang perkara ini jika kependaman ultra-rendah adalah penting untuk aplikasi anda, kerana keputusan DNS juga dicache secara dalaman.

rujukan

Saya mula-mula belajar tentang ciri ini pada K8s-pertemuan, diadakan pada 25 Januari. Terdapat perbincangan mengenai masalah ini, antara lain.

Berikut adalah beberapa pautan untuk penerokaan lanjut:

Penjelasan, mengapa ndots=5 dalam Kubernetes;
Barangan hebat cara menukar titik mempengaruhi prestasi aplikasi;
Percanggahan antara penyelesai musl dan glibc.

Nota: Saya memilih untuk tidak menggunakan dig dalam artikel ini. dig secara automatik menambah titik (pengecam zon akar), menjadikan domain "layak sepenuhnya" (FQDN), tiada dengan terlebih dahulu menjalankannya melalui senarai carian. Menulis tentang ini dalam salah satu penerbitan terdahulu. Walau bagaimanapun, agak mengejutkan bahawa, secara amnya, bendera yang berasingan perlu ditentukan untuk tingkah laku standard.

Selamat membuat DNS! Jumpa lagi!

Carian DNS dalam Kubernetes

Bereksperimen dengan titik

Aplikasi dalam pengeluaran

rujukan

PS daripada penterjemah

Tambah komen Batal reply