/etc/resolv.conf untuk pod Kubernetes, pilihan ndots:5, bagaimana ini boleh menjejaskan prestasi aplikasi secara negatif

Kami baru-baru ini melancarkan Kubernetes 1.9 pada AWS menggunakan Kops. Semalam, semasa melancarkan trafik baharu dengan lancar ke kluster Kubernetes kami yang terbesar, saya mula melihat ralat resolusi nama DNS yang luar biasa yang dilog oleh aplikasi kami.

Terdapat banyak perkara tentang ini di GitHub bercakap, jadi saya memutuskan untuk memikirkannya juga. Pada akhirnya, saya menyedari bahawa dalam kes kami ini disebabkan oleh peningkatan beban pada kube-dns и dnsmasq. Perkara yang paling menarik dan baharu bagi saya ialah sebab peningkatan ketara dalam trafik permintaan DNS. Catatan saya adalah mengenai perkara ini dan apa yang perlu dilakukan mengenainya.

Resolusi DNS di dalam bekas - seperti dalam mana-mana sistem Linux - ditentukan oleh fail konfigurasi /etc/resolv.conf. Kubernetes lalai dnsPolicy это ClusterFirst, yang bermaksud bahawa sebarang permintaan DNS akan dimajukan kepada dnsmasq, berlari dalam pod kube-dns di dalam kelompok, yang seterusnya akan memajukan permintaan kepada aplikasi kube-dns, jika nama berakhir dengan akhiran kelompok, atau, sebaliknya, ke pelayan DNS peringkat lebih tinggi.

fail /etc/resolv.conf di dalam setiap bekas lalai akan kelihatan 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, terdapat tiga arahan:

1. Pelayan nama ialah IP perkhidmatan kube-dns
2. 4 domain carian tempatan ditentukan search
3. Ada pilihan ndots:5

Bahagian yang menarik dalam konfigurasi ini ialah bagaimana domain dan tetapan carian tempatan ndots:5 bergaul bersama. Untuk memahami perkara ini, anda perlu memahami cara resolusi DNS untuk nama yang tidak layak berfungsi.

Apakah nama penuh?

Nama yang layak sepenuhnya ialah nama yang tiada carian tempatan akan dilakukan dan nama itu akan dianggap mutlak semasa resolusi nama. Mengikut konvensyen, perisian DNS menganggap nama layak sepenuhnya jika ia berakhir dengan titik (.), dan tidak layak sepenuhnya sebaliknya. Itu dia google.com. ditakrifkan sepenuhnya dan google.com - Tidak.

Bagaimanakah nama yang tidak layak dikendalikan?

Apabila aplikasi bersambung ke hos jauh yang dinyatakan dalam nama, resolusi nama DNS biasanya dilakukan menggunakan panggilan sistem, mis. getaddrinfo(). Tetapi jika nama itu tidak layak (tidak berakhir dengan .), Saya tertanya-tanya sama ada panggilan sistem akan cuba menyelesaikan nama sebagai nama mutlak terlebih dahulu, atau melalui domain carian setempat terlebih dahulu? Ia bergantung kepada pilihan ndots.

Dari manual resolv.conf:

ndots:n

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

Ini bermakna jika untuk ndots diberi nilai 5 dan nama itu mengandungi kurang daripada 5 titik, panggilan sistem akan cuba menyelesaikannya secara berurutan, mula-mula merentasi semua domain carian setempat dan, jika tidak berjaya, akhirnya menyelesaikannya sebagai nama mutlak.

Kenapa begitu ndots:5 adakah ia boleh menjejaskan prestasi aplikasi secara negatif?

Seperti yang anda boleh bayangkan, jika aplikasi anda menggunakan banyak trafik luaran, untuk setiap sambungan TCP yang diwujudkan (atau lebih tepat lagi, untuk setiap nama yang diselesaikan), ia akan mengeluarkan 5 pertanyaan DNS sebelum nama itu diselesaikan dengan betul, kerana ia akan terlebih dahulu melalui 4 domain carian tempatan, dan pada akhirnya akan mengeluarkan permintaan resolusi nama mutlak.

Carta berikut menunjukkan jumlah trafik pada 3 modul kube-dns kami sebelum dan selepas kami menukar beberapa nama hos yang dikonfigurasikan dalam aplikasi kami kepada yang layak sepenuhnya.

Rajah berikut menunjukkan kependaman aplikasi sebelum dan selepas kami menukar beberapa nama hos yang dikonfigurasikan dalam aplikasi kami kepada nama penuh (garis biru menegak ialah penggunaan):

Penyelesaian #1 - Gunakan nama yang layak sepenuhnya

Jika anda mempunyai beberapa nama luaran statik (iaitu ditakrifkan dalam konfigurasi aplikasi) yang mana anda mencipta sejumlah besar sambungan, mungkin penyelesaian paling mudah ialah menukarnya kepada yang layak sepenuhnya dengan hanya menambahkannya. pada penghujungnya.

Ini bukan penyelesaian muktamad, tetapi ia membantu dengan cepat, walaupun tidak bersih, memperbaiki keadaan. Kami menggunakan tampung ini untuk menyelesaikan masalah kami, yang hasilnya ditunjukkan dalam tangkapan skrin di atas.

Penyelesaian #2 - penyesuaian ndots в dnsConfig

Dalam Kubernetes 1.9, kefungsian muncul dalam mod alfa (versi beta v1.10), yang membolehkan anda mengawal parameter DNS dengan lebih baik melalui sifat pod dalam dnsConfig. Antara lain, ia membolehkan anda mengkonfigurasi nilai ndots untuk pod tertentu, i.e.

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

sumber

• Apakah kelayakan nama DNS
• Kubernetes: DNS untuk Perkhidmatan dan Pod

Baca juga artikel lain di blog kami:

• Memahami pakej Konteks di Golang
• Tiga Helah Mudah untuk Mengecilkan Imej Docker
• Sandaran stateful dalam Kubernetes
• Sandaran sejumlah besar projek web heterogen
• Bot Telegram untuk Redmine. Bagaimana untuk memudahkan hidup untuk diri sendiri dan orang lain

Sumber: www.habr.com