🥇 /etc/resolv.conf Kubernetesi podide jaoks, valik ndots:5, kuidas see võib negatiivselt mõjutada rakenduse jõudlust

Hiljuti käivitasime Kubernetes 1.9 AWS-is Kopsiga. Eile, kui uue liikluse sujuv juurutamine meie suurimasse Kubernetes klastrisse käis, hakkasin märkama ebatavalisi DNS-i nimetuse lahendamise vigu, mida meie rakendus logis.

GitHubis on sellest juba pikka aega räägitud, seega otsustasin ka ise asja uurida. Lõpuks sain aru, et meie puhul on see põhjustatud suurenenud koormusest kube-dns ja dnsmasq. Kõige huvitavam ja uus minu jaoks oli ise põhjus, miks DNS-i päringute liiklus on märgatavalt suurenenud. Sellest ja sellest, mida sellega teha, räägin oma postituses.

DNS-i lahendamine konteineris — nagu igas Linuxi süsteemis — määratakse konfiguratsioonifailiga /etc/resolv.conf. Vaikimisi on Kubernetes'i dnsPolicy see ClusterFirst, mis tähendab, et iga DNS-i päring suunatakse välja dnsmasq, mis käivitatakse podis kube-dns klastris, mis omakorda suunab päringu rakendusse kube-dns, kui nimi lõppeb klastri sufiksiga, muudel juhtudel aga kõrgema taseme DNS-serverisse.

Fail /etc/resolv.conf Iga konteineri sees näeb see vaikimisi välja niimoodi:

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

Nagu näha, on siin kolm direktiivi:

Nimiserver on teenuse IP kube-dns
Tuginedes on määratud 4 kohalikku otsingu domeeni search
On olemas valik ndots:5

Huvitav osa sellest konfiguratsioonist on see, kuidas kohalikud otsingu domeenid ja seaded ndots:5 koos eksisteerivad. Selle mõistmiseks tuleb aru saada, kuidas DNS-i lahendamine toimib osaliste nimede korral.

Mis on täielik nimi?

Täielikult määratletud nimi on nimi, mille puhul ei toimu kohalikku otsingut ja nime peetakse nime lahendamise ajal absoluutseks. Üheks reegliks on, et DNS-i tarkvara arvab, et nimi on täielikult määratletud, kui see lõpeb punktiga (.), ja mitte täielikult määratletud muul juhul. See tähendab, et google.com. on täielikult määratletud, aga google.com — ei ole.

Kuidas töödeldakse osalist nime?

Kui rakendus ühendub kaughostiga, mille nimi on näidatud, toimub DNS-i nimetuse lahendamine tavaliselt süsteemi kutsumise abil, näiteks getaddrinfo(). Kui nimi on osaline (ei lõppe punktiga), siis huvitav, kas süsteemi kutse püüab kõigepealt lahendada nime absoluutseks või läbib esmalt kohalikud otsingudomeenid? See sõltub valikust ndots.

Käiguteabe põhjal resolv.conf:

ndots:n

seabub seadistab piirväärtuse, kui palju punkte peab nimes olema, enne kui tehakse algne absoluutne päring. Vaikeväärtus n on 1, mis tähendab, et kui nime sees on üldse punkte, proovib süsteem kõigepealt seda absoluutse nimega, enne kui sellele lisatakse mingeid otsingulisti elemente.

See tähendab, et kui ndots on määratud väärtuseks 5 ja nimi sisaldab vähem kui 5 punkti, proovib süsteemikutse seda järjestikku lahendada, alustades kõigist kohalikest otsingudomeenidest ja vajadusel lahendab selle lõpuks absoluutse nimega.

Miks `ndots:5` võib negatiivselt mõjutada rakenduse jõudlust?

Kuidas te teate, kui teie rakendus kasutab palju välist liiklust, teeb iga uue TCP-ühenduse (või täpsemalt, iga lahendatud nime) see 5 DNS-päringut enne, kui nimi on õigesti lahendatud, kuna see läbib kõigepealt 4 kohalikku otsingudomeeni ja lõpuks annab absoluutse nime lahendamise päringu.

Järgmises diagrammis on kujutatud meie 3 kube-dns mooduli koguliiklust enne ja pärast seda, kui me lülitasime mitu meie rakenduses seadistatud hostinime täielikult määratletud nimele.

Järgmises diagrammis on kujutatud rakenduse viivitust enne ja pärast seda, kui me lülitasime mitu meie rakenduses seadistatud hostinime täielikult määratletud nimele (vertikaalne sinine joon on juurutamine):

Lahendus #1 - kasutada täielikult määratud nimesid

Kui teil on vähe staatilisi väliseid nimesid (st, mis on määratud rakenduse konfiguratsioonis), millele teete palju ühendusi, siis võib kõige lihtsam lahendus olla lülitada need täielikult määratletud nimele, lihtsalt lisades. lõpuks.

See ei ole lõplik lahendus, kuid aitab kiiresti, kuigi mitte puhtalt, olukorda parandada. Seda plaanime rakendasime meie probleemi lahendamiseks, mille tulemused on näidatud ülaltoodud ekraanipiltides.

Lahendus #2 - kohandamine `ndots` ja `dnsConfig`

Kubernetes 1.9 alfas režiimis, alates beta-versioonist v1.10, ilmus funktsionaalsus, mis võimaldab paremini kontrollida DNS-i parameetreid podi omaduste kaudu dnsConfig. Muuhulgas võimaldab see määrata väärtuse ndots konkreetse podi jaoks, st.

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