🥇/etc/resolv.conf, skirta Kubernetes podams, ndots:5 parinktis, kaip tai gali neigiamai paveikti programos našumą

Neseniai paleidome Kubernetes 1.9 AWS naudodami Kops. Vakar, sklandžiai siųsdamas naują srautą į didžiausią mūsų „Kubernetes“ grupes, pastebėjau neįprastas DNS vardo skyrimo klaidas, kurias užregistravo mūsų programa.

„GitHub“ yra gana daug apie tai kalbėjo, todėl nusprendžiau išsiaiškinti ir aš. Galų gale supratau, kad mūsų atveju tai lemia padidėjęs krūvis kube-dns и dnsmasq. Man įdomiausia ir nauja buvo pati priežastis, dėl kurios labai padidėjo DNS užklausų srautas. Mano įrašas yra apie tai ir ką su tuo daryti.

DNS skiriamoji geba konteinerio viduje – kaip ir bet kurioje „Linux“ sistemoje – nustatoma pagal konfigūracijos failą /etc/resolv.conf. Numatytoji Kubernetes dnsPolicy tai ClusterFirst, o tai reiškia, kad bet kuri DNS užklausa bus persiųsta į dnsmasq, veikia ankštyje kube-dns klasterio viduje, o tai savo ruožtu perduos užklausą programai kube-dns, jei pavadinimas baigiasi klasterio priesaga arba, kitu atveju, į aukštesnio lygio DNS serverį.

byla /etc/resolv.conf kiekviename konteineryje numatytasis nustatymas atrodys taip:

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

Kaip matote, yra trys direktyvos:

Vardų serveris yra paslaugos IP kube-dns
Nustatyti 4 vietinės paieškos domenai search
Yra galimybė ndots:5

Įdomi šios konfigūracijos dalis yra vietinės paieškos domenai ir nustatymai ndots:5 susitarti kartu. Norėdami tai suprasti, turite suprasti, kaip veikia nekvalifikuotų vardų DNS skyra.

Kas yra pilnas vardas?

Visiškai apibrėžtas vardas yra pavadinimas, kurio vietinė paieška nebus atliekama ir pavadinimas bus laikomas absoliučiu sprendžiant pavadinimą. Pagal susitarimą DNS programinė įranga laiko pavadinimą visiškai kvalifikuotu, jei jis baigiasi tašku (.), o kitu atveju jis nėra visiškai apibrėžtas. Tai yra google.com. visiškai apibrėžtas ir google.com – Ne.

Kaip tvarkomas beribis vardas?

Kai programa prisijungia prie pavadinime nurodyto nuotolinio pagrindinio kompiuterio, DNS vardo sprendimas paprastai atliekamas naudojant sistemos iškvietimą, pvz. getaddrinfo(). Bet jei vardas yra nekvalifikuotas (nesibaigia .), įdomu, ar sistemos skambutis pirmiausia bandys nustatyti pavadinimą kaip absoliutų pavadinimą, ar pirmiausia pereis per vietinės paieškos domenus? Tai priklauso nuo pasirinkimo ndots.

Iš vadovo resolv.conf:

ndots:n

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

Tai reiškia, kad jei už ndots Jei reikšmė yra 5, o pavadinime yra mažiau nei 5 taškai, sistemos iškvietimas bandys jį išspręsti nuosekliai, pirmiausia perkeldamas visus vietinės paieškos domenus ir, jei nepavyks, galiausiai nustatydamas kaip absoliutų pavadinimą.

Kodėl taip `ndots:5` ar tai gali turėti neigiamos įtakos programos veikimui?

Kaip galite įsivaizduoti, jei jūsų programa naudoja daug išorinio srauto, už kiekvieną užmegztą TCP ryšį (arba tiksliau, už kiekvieną išspręstą pavadinimą), ji pateiks 5 DNS užklausas, kol pavadinimas bus tinkamai išspręstas, nes pirmiausia bus atliktas 4 vietinės paieškos domeną, o pabaigoje išduos absoliutų vardo sprendimo užklausą.

Šioje diagramoje parodytas bendras srautas mūsų 3 kube-dns moduliuose prieš ir po to, kai keletą programoje sukonfigūruotų prieglobos serverių pavadinimų perjungėme į visiškai tinkamus.

Šioje diagramoje parodyta programos delsa prieš ir po to, kai perjungiame kelis mūsų programoje sukonfigūruotus pagrindinio kompiuterio pavadinimus į pilnus pavadinimus (vertikali mėlyna linija yra diegimas):

1 sprendimas – naudokite visiškai tinkamus pavadinimus

Jei turite keletą statinių išorinių pavadinimų (t. y. apibrėžtų programos konfigūracijoje), prie kurių sukuriate daug jungčių, galbūt paprasčiausias sprendimas yra pakeisti juos į visiškai tinkamus, tiesiog juos pridedant. pabaigoje.

Tai nėra galutinis sprendimas, tačiau padeda greitai, nors ir ne švariai, pagerinti situaciją. Pritaikėme šį pataisą, kad išspręstume problemą, kurios rezultatai buvo parodyti aukščiau esančiose ekrano kopijose.

2 sprendimas – pritaikymas `ndots` в `dnsConfig`

„Kubernetes 1.9“ funkcionalumas pasirodė alfa režimu (beta versija v1.10), kuris leidžia geriau valdyti DNS parametrus per pod nuosavybę dnsConfig. Be kita ko, tai leidžia konfigūruoti vertę ndots už konkrečią ankštį, t.y.

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

Informacijos šaltiniai

Taip pat skaitykite kitus mūsų tinklaraščio straipsnius:

Šaltinis: www.habr.com

/etc/resolv.conf, skirta Kubernetes podams, ndots:5 parinktis, kaip tai gali neigiamai paveikti programos našumą