Kubernetes podları üçün /etc/resolv.conf, seçim ndots:5, bunun tətbiqin performansına necə mənfi təsir göstərə bilər

Kubernetes podları üçün /etc/resolv.conf, seçim ndots:5, bunun tətbiqin performansına necə mənfi təsir göstərə bilər

Bu yaxınlarda Kops istifadə edərək AWS-də Kubernetes 1.9-u işə saldıq. Dünən, Kubernetes klasterlərimizin ən böyüyünə rəvan yeni trafik yayarkən, tətbiqimiz tərəfindən daxil edilmiş qeyri-adi DNS ad həlli xətalarını görməyə başladım.

GitHub-da bununla bağlı çox şey var danışdı, mən də bunu başa düşmək qərarına gəldim. Sonda başa düşdüm ki, bizim vəziyyətimizdə buna artan yük səbəb olur kube-dns и dnsmasq. Mənim üçün ən maraqlı və yeni şey DNS sorğu trafikinin əhəmiyyətli dərəcədə artmasının səbəbi idi. Mənim postum bu barədə və bununla bağlı nə etmək lazımdır.

Konteynerin içərisindəki DNS həlli - hər hansı bir Linux sistemində olduğu kimi - konfiqurasiya faylı ilə müəyyən edilir /etc/resolv.conf. Defolt Kubernetes dnsPolicy bu ClusterFirst, yəni istənilən DNS sorğusu yönləndiriləcək dnsmasq, podda çalışan kube-dns klaster daxilində, bu da öz növbəsində sorğunu tətbiqə yönləndirəcək kube-dns, ad klaster şəkilçisi ilə bitirsə və ya başqa halda daha yüksək səviyyəli DNS serverinə.

Файл /etc/resolv.conf hər bir konteynerin içərisində standart belə görünəcək:

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

Gördüyünüz kimi, üç direktiv var:

  1. Ad serveri xidmətin IP-sidir kube-dns
  2. 4 yerli axtarış domeni qeyd edildi search
  3. Variant var ndots:5

Bu konfiqurasiyanın maraqlı hissəsi yerli axtarış domenləri və parametrləridir ndots:5 birlikdə olmaq. Bunu başa düşmək üçün uyğun olmayan adlar üçün DNS həllinin necə işlədiyini başa düşməlisiniz.

Tam ad nədir?

Tam uyğunlaşdırılmış ad heç bir yerli axtarışın aparılmayacağı və ad həlli zamanı mütləq ad sayılacaq addır. Konvensiyaya görə, DNS proqramı adın sonu nöqtə (.) ilə bitərsə, onu tam uyğun hesab edir, əks halda tam uyğun deyil. Yəni google.com. tam müəyyən edilmiş və google.com - yox.

Qeyri-peşəkar ad necə idarə olunur?

Tətbiq adda göstərilən uzaq hosta qoşulduqda, DNS adının həlli adətən sistem çağırışı ilə həyata keçirilir, məs. getaddrinfo(). Bəs ad qeyri-müəyyəndirsə (. ilə bitmir), görəsən sistem çağırışı əvvəlcə adı mütləq ad kimi həll etməyə çalışacaq, yoxsa əvvəlcə yerli axtarış domenlərindən keçəcək? Bu seçimdən asılıdır ndots.

Təlimatdan resolv.conf:

ndots:n

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

Bu o deməkdir ki, əgər üçün ndots 5 dəyəri verildikdə və adda 5 nöqtədən az olarsa, sistem çağırışı onu ardıcıl olaraq həll etməyə çalışacaq, əvvəlcə bütün yerli axtarış domenlərini keçəcək və uğursuz olarsa, nəticədə onu mütləq ad kimi həll edəcək.

Niyə belə ndots:5 tətbiqin performansına mənfi təsir göstərə bilərmi?

Təsəvvür etdiyiniz kimi, tətbiqiniz çoxlu xarici trafikdən istifadə edirsə, qurulan hər bir TCP bağlantısı üçün (daha doğrusu, həll olunan hər ad üçün) ad düzgün həll edilməmişdən əvvəl 5 DNS sorğusu verəcək, çünki əvvəlcə o, 4 yerli axtarış domeni və sonunda mütləq ad həlli sorğusu verəcəkdir.

Aşağıdakı diaqram, tətbiqimizdə konfiqurasiya edilmiş bir neçə host adını tam uyğun olanlara keçirməmişdən əvvəl və sonra 3 kube-dns modulumuzda ümumi trafiki göstərir.

Kubernetes podları üçün /etc/resolv.conf, seçim ndots:5, bunun tətbiqin performansına necə mənfi təsir göstərə bilər

Aşağıdakı diaqram, tətbiqimizdə konfiqurasiya edilmiş bir neçə host adını tam adlara keçirməmişdən əvvəl və sonrakı tətbiq gecikməsini göstərir (şaquli mavi xətt yerləşdirmədir):

Kubernetes podları üçün /etc/resolv.conf, seçim ndots:5, bunun tətbiqin performansına necə mənfi təsir göstərə bilər

Həll №1 - Tam uyğun adlardan istifadə edin

Çox sayda əlaqə yaratdığınız bir neçə statik xarici adınız varsa (yəni proqram konfiqurasiyasında müəyyən edilmişdir), bəlkə də ən sadə həll yolu onları sadəcə əlavə etməklə tam uyğun olanlara keçirməkdir. Sonda.

Bu, son bir həll deyil, amma təmiz olmasa da, vəziyyəti tez bir zamanda yaxşılaşdırmağa kömək edir. Problemimizi həll etmək üçün bu yamağı tətbiq etdik, nəticələri yuxarıdakı ekran görüntülərində göstərildi.

Həll №2 - fərdiləşdirmə ndots в dnsConfig

Kubernetes 1.9-da funksionallıq alfa rejimində (beta versiyası v1.10) ortaya çıxdı, bu da pod mülkü vasitəsilə DNS parametrlərini daha yaxşı idarə etməyə imkan verir. dnsConfig. Digər şeylər arasında, dəyəri konfiqurasiya etməyə imkan verir ndots müəyyən bir pod üçün, yəni.

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

İnformasiya qaynaqları

Bloqumuzdakı digər məqalələri də oxuyun:

Mənbə: www.habr.com

Добавить комментарий