/etc/resolv.conf untuk pod Kubernetes, opsi ndots:5, bagaimana hal ini dapat berdampak negatif terhadap kinerja aplikasi

Kami baru-baru ini meluncurkan Kubernetes 1.9 di AWS menggunakan Kops. Kemarin, saat meluncurkan lalu lintas baru dengan lancar ke cluster Kubernetes terbesar kami, saya mulai memperhatikan kesalahan resolusi nama DNS yang tidak biasa yang dicatat oleh aplikasi kami.

Ada banyak hal tentang ini di GitHub berbicara, jadi saya memutuskan untuk mencari tahu juga. Pada akhirnya, saya menyadari bahwa dalam kasus kami hal ini disebabkan oleh peningkatan beban kube-dns и dnsmasq. Hal yang paling menarik dan baru bagi saya adalah alasan peningkatan lalu lintas permintaan DNS yang signifikan. Postingan saya tentang ini dan apa yang harus dilakukan.

Resolusi DNS di dalam wadah - seperti di sistem Linux mana pun - ditentukan oleh file konfigurasi /etc/resolv.conf. Kubernet bawaan dnsPolicy ini ClusterFirst, yang berarti permintaan DNS apa pun akan diteruskan ke dnsmasq, berjalan di dalam pod kube-dns di dalam cluster, yang pada gilirannya akan meneruskan permintaan ke aplikasi kube-dns, jika nama diakhiri dengan akhiran cluster, atau, sebaliknya, ke server DNS tingkat yang lebih tinggi.

berkas /etc/resolv.conf di dalam setiap wadah defaultnya akan terlihat seperti ini:

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

Seperti yang Anda lihat, ada tiga arahan:

1. Server nama adalah IP layanan kube-dns
2. 4 domain pencarian lokal ditentukan search
3. Ada pilihan ndots:5

Yang menarik dari konfigurasi ini adalah bagaimana pencarian lokal domain dan settingnya ndots:5 bergaul bersama. Untuk memahami hal ini, Anda perlu memahami cara kerja resolusi DNS untuk nama yang tidak memenuhi syarat.

Apa nama lengkapnya?

Nama yang sepenuhnya memenuhi syarat adalah nama yang pencarian lokalnya tidak akan dilakukan dan nama tersebut akan dianggap mutlak selama resolusi nama. Berdasarkan konvensi, perangkat lunak DNS menganggap sebuah nama memenuhi syarat sepenuhnya jika diakhiri dengan titik (.), dan tidak sepenuhnya memenuhi syarat jika sebaliknya. Itu adalah google.com. didefinisikan sepenuhnya dan google.com - tidak.

Bagaimana cara menangani nama yang tidak memenuhi syarat?

Saat aplikasi terhubung ke host jarak jauh yang ditentukan dalam namanya, resolusi nama DNS biasanya dilakukan menggunakan panggilan sistem, misalnya. getaddrinfo(). Tetapi jika namanya tidak memenuhi syarat (tidak diakhiri dengan .), saya ingin tahu apakah panggilan sistem akan mencoba menyelesaikan nama tersebut sebagai nama absolut terlebih dahulu, atau melalui domain pencarian lokal terlebih dahulu? Itu tergantung pada pilihannya ndots.

Dari manual resolv.conf:

ndots:n

устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.

Artinya jika untuk ndots jika diberi nilai 5 dan nama berisi kurang dari 5 titik, panggilan sistem akan mencoba menyelesaikannya secara berurutan, pertama melintasi semua domain pencarian lokal, dan, jika tidak berhasil, pada akhirnya menyelesaikannya sebagai nama absolut.

Kenapa begitu ndots:5 apakah hal ini dapat berdampak negatif terhadap kinerja aplikasi?

Seperti yang dapat Anda bayangkan, jika aplikasi Anda menggunakan banyak lalu lintas eksternal, untuk setiap koneksi TCP yang dibuat (atau lebih tepatnya, untuk setiap nama yang diselesaikan), aplikasi akan mengeluarkan 5 kueri DNS sebelum nama tersebut diselesaikan dengan benar, karena aplikasi tersebut akan melewatinya terlebih dahulu. 4 domain pencarian lokal, dan pada akhirnya akan mengeluarkan permintaan resolusi nama absolut.

Bagan berikut menunjukkan total lalu lintas pada 3 modul kube-dns kami sebelum dan sesudah kami mengganti beberapa nama host yang dikonfigurasi dalam aplikasi kami ke yang sepenuhnya memenuhi syarat.

Diagram berikut menunjukkan latensi aplikasi sebelum dan sesudah kami mengganti beberapa nama host yang dikonfigurasi dalam aplikasi kami menjadi nama lengkap (garis biru vertikal adalah penerapan):

Solusi #1 - Gunakan nama yang sepenuhnya memenuhi syarat

Jika Anda memiliki beberapa nama eksternal statis (yaitu ditentukan dalam konfigurasi aplikasi) yang Anda gunakan untuk membuat koneksi dalam jumlah besar, mungkin solusi paling sederhana adalah mengalihkannya ke nama yang sepenuhnya memenuhi syarat hanya dengan menambahkannya. pada akhirnya.

Ini bukanlah solusi akhir, namun membantu memperbaiki situasi dengan cepat, meskipun tidak secara menyeluruh. Kami menerapkan tambalan ini untuk menyelesaikan masalah kami, yang hasilnya ditunjukkan pada tangkapan layar di atas.

Solusi #2 - penyesuaian ndots в dnsConfig

Di Kubernetes 1.9, fungsionalitas muncul dalam mode alfa (versi beta v1.10), yang memungkinkan Anda mengontrol parameter DNS dengan lebih baik melalui properti pod di dnsConfig. Antara lain, ini memungkinkan Anda untuk mengonfigurasi nilainya ndots untuk pod tertentu, mis.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

sumber

• Apa kualifikasi nama DNS itu
• Kubernetes: DNS untuk Layanan dan Pod

Baca juga artikel lainnya di blog kami:

• Memahami paket Konteks di Golang
• Tiga Trik Sederhana untuk Mengecilkan Gambar Docker
• Pencadangan stateful di Kubernetes
• Cadangan sejumlah besar proyek web yang heterogen
• Bot Telegram untuk Redmine. Bagaimana menyederhanakan hidup untuk diri sendiri dan orang lain

Sumber: www.habr.com