Kubernetes-də DNS axtarışı

Qeyd. tərcümə.: Kubernetes-də DNS problemi, daha dəqiq desək, parametr parametrləri ndots, təəccüblü dərəcədə məşhurdur və artıq İlk deyil il. Bu mövzu ilə bağlı başqa bir qeyddə onun müəllifi, Hindistandakı böyük bir broker şirkətinin DevOps mühəndisi, Kubernetes-i idarə edən həmkarlarının bilməsi üçün nəyin faydalı olduğu barədə çox sadə və qısa şəkildə danışır.

Kubernetes-də tətbiqlərin yerləşdirilməsinin əsas üstünlüklərindən biri problemsiz tətbiq kəşfidir. Klasterdaxili qarşılıqlı əlaqə xidmət konsepsiyası sayəsində çox sadələşdirilmişdir (xidmət), bir sıra pod IP ünvanlarını dəstəkləyən virtual IP-dir. Məsələn, əgər xidmət vanilla xidmətlə əlaqə saxlamaq istəyir chocolateüçün virtual IP-yə birbaşa daxil ola bilər chocolate. Sual yaranır: bu halda DNS sorğusunu kimə həll edəcək chocolate Və necə?

DNS adının həlli istifadə edərək Kubernetes klasterində konfiqurasiya edilir CoreDNS. Kubelet CoreDNS ilə podu fayllarda ad serveri kimi qeyd edir /etc/resolv.conf bütün qabıqlar. Məzmuna baxsanız /etc/resolv.conf hər hansı bir pod, bu kimi görünəcək:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

Bu konfiqurasiya DNS müştəriləri tərəfindən sorğuları DNS serverinə yönləndirmək üçün istifadə olunur. Faylda resolv.conf aşağıdakı məlumatları ehtiva edir:

• ad serveri: DNS sorğularının göndəriləcəyi server. Bizim vəziyyətimizdə bu, CoreDNS xidmətinin ünvanıdır;
• axtarış: Müəyyən bir domen üçün axtarış yolunu müəyyən edir. Maraqlıdır ki google.com və ya mrkaran.dev FQDN deyil (tam ixtisaslı domen adları). Əksər DNS həlledicilərinin əməl etdiyi standart konvensiyaya əsasən, yalnız kök zonanı təmsil edən “.” nöqtəsi ilə bitənlər tam ixtisaslı (FDQN) domenlər hesab olunur. Bəzi həlledicilər özləri bir nöqtə əlavə edə bilərlər. Beləliklə, mrkaran.dev. tam ixtisaslı domen adıdır (FQDN) və mrkaran.dev - Yox;
• ndots: Ən maraqlı parametr (bu məqalə bu barədədir). ndots sorğu adında "tam uyğun" domen adı hesab edilməzdən əvvəl nöqtələrin həddi sayını müəyyən edir. Bu barədə daha sonra DNS axtarış ardıcıllığını təhlil edərkən danışacağıq.

Soruşanda görək nə olacaq mrkaran.dev podda:

$ 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

Bu təcrübə üçün mən CoreDNS giriş səviyyəsini təyin etdim all (bu onu olduqca ətraflı edir). Gəlin podun qeydlərinə baxaq 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

vay. Burada iki şey diqqətinizi çəkir:

• Cavab kodu ehtiva edənə qədər sorğu axtarışın bütün mərhələlərindən keçir NOERROR (DNS müştəriləri bunu başa düşür və nəticədə saxlayır). NXDOMAIN o deməkdir ki, verilmiş domen adı üçün heç bir qeyd tapılmamışdır. Çünki mrkaran.dev FQDN adı deyil ( ndots=5), həlledici axtarış yoluna baxır və sorğuların sırasını müəyyən edir;
• Entries А и АААА paralel olaraq gəlir. Fakt budur ki, birdəfəlik tələblər daxil olur /etc/resolv.conf Varsayılan olaraq, onlar IPv4 və IPv6 protokollarından istifadə edərək paralel axtarışların aparılacağı şəkildə konfiqurasiya edilir. Seçim əlavə etməklə bu davranışı ləğv edə bilərsiniz single-request в resolv.conf.

Qeyd: glibc bu sorğuları ardıcıl olaraq göndərmək üçün konfiqurasiya edilə bilər və musl - yox, ona görə də Alp istifadəçiləri qeyd etməlidir.

Ndots ilə təcrübə

Bir az daha təcrübə edək ndots və bu parametrin necə davrandığını görək. Fikir sadədir: ndots DNS müştərisinin domeni mütləq və ya nisbi kimi qəbul edəcəyini müəyyən edir. Məsələn, sadə bir Google DNS müştərisi vəziyyətində, bu domenin mütləq olub olmadığını necə bilir? Əgər təyin etsəniz ndots 1-ə bərabər olan müştəri deyəcək: "Oh, in google bir nöqtə yoxdur; Güman edirəm ki, bütün axtarış siyahısını nəzərdən keçirəcəyəm." Ancaq soruşsanız google.com, tələb olunan ad həddi üstələdiyi üçün şəkilçilərin siyahısı tamamilə nəzərə alınmayacaq ndots (ən azı bir nöqtə var).

Buna əmin olaq:

$ 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

CoreDNS qeydləri:

[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

İldən mrkaran bir nöqtə yoxdur, axtarış bütün şəkilçilər siyahısı üzrə aparılmışdır.

Qeyd: praktikada maksimum dəyər ndots 15 ilə məhdudlaşır; Kubernetes-də standart olaraq 5-dir.

İstehsalda tətbiq

Tətbiq çoxlu xarici şəbəkə zəngləri edərsə, DNS aktiv trafik vəziyyətində darboğaza çevrilə bilər, çünki ad həlli bir çox lazımsız sorğular verir (sistem doğruya çatmazdan əvvəl). Tətbiqlər adətən domen adlarına kök zona əlavə etmir, lakin bu hack kimi səslənir. Yəni soruşmaq əvəzinə api.twitter.com, siz onu 'sabit kodlaşdıra' bilərsiniz api.twitter.com. (nöqtə ilə) tətbiqdə, bu, DNS müştərilərini birbaşa mütləq domendə səlahiyyətli axtarışlar aparmağa sövq edəcək.

Bundan əlavə, Kubernetes 1.14 versiyasından başlayaraq uzantılar dnsConfig и dnsPolicy stabil status almışdır. Beləliklə, bir pod yerləşdirərkən dəyəri azalda bilərsiniz ndots, deyək ki, 3-ə qədər (və hətta 1-ə qədər!). Buna görə, bir node daxilindəki hər mesaj tam domeni daxil etməli olacaq. Performans və daşınma arasında seçim etməli olduğunuz zaman bu, klassik güzəştlərdən biridir. Mənə elə gəlir ki, yalnız ultra aşağı gecikmə tətbiqiniz üçün çox vacibdirsə, bu barədə narahat olmalısınız, çünki DNS nəticələri də daxili yaddaşda saxlanılır.

References

Bu xüsusiyyət haqqında ilk dəfə öyrəndim K8s-görüş, yanvarın 25-də keçirilib. Digər məsələlərlə yanaşı, bu problemlə bağlı da müzakirələr aparılıb.

Əlavə kəşfiyyat üçün bəzi bağlantılar bunlardır:

• İzahat, niyə Kubernetesdə ndots=5;
• Əla şeylər ndotların dəyişdirilməsi tətbiqin performansına necə təsir edir;
• Uyğunsuzluqlar musl və glibc həllediciləri arasında.

Qeyd: İstifadə etməməyi seçdim dig bu məqalədə. dig avtomatik olaraq nöqtə (kök zonası identifikatoru) əlavə edərək, domeni "tam ixtisaslı" edir (FQDN), heç bir əvvəlcə onu axtarış siyahısından keçirərək. Bu barədə yazıb əvvəlki nəşrlərdən biridir. Bununla belə, olduqca təəccüblüdür ki, ümumiyyətlə, standart davranış üçün ayrıca bir bayraq göstərilməlidir.

Xoşbəxt DNSing! Sonra görüşənədək!

Tərcüməçidən PS

Bloqumuzda da oxuyun:

• «Kubernetesdə şəbəkə qurmaq üçün Calico: giriş və bir az təcrübə";
• «CoreDNS - Doğma bulud dünyası üçün DNS serveri və Kubernetes üçün Xidmət Kəşfi";
• "Kubernetes-də Şəbəkə üçün İllüstrasiyalı Bələdçi": hissə 1 və 2 (şəbəkə modeli, üst-üstə düşən şəbəkələr), hissə 3 (xidmətlər və trafikin işlənməsi).

Mənbə: www.habr.com