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

Hiljuti käivitasime AWS-is Kubernetes 1.9, kasutades Kopsi. Eile, kui levitasin sujuvalt uut liiklust meie suurimatele Kubernetese klastritele, hakkasin märkama ebatavalisi meie rakenduse logitud DNS-i nimede lahendamise vigu.

GitHubis on selle kohta üsna palju teavet rääkis, seega otsustasin ka selle välja mõelda. Lõpuks sain aru, et meie puhul on selle põhjuseks suurenenud koormus kube-dns и dnsmasq. Minu jaoks oli kõige huvitavam ja uudsem just DNS-i päringute liikluse olulise suurenemise põhjus. Minu postitus räägib sellest ja sellest, mida sellega teha.

DNS-i eraldusvõime konteineris – nagu igas Linuxi süsteemis – määratakse konfiguratsioonifaili järgi /etc/resolv.conf. Vaikimisi Kubernetes dnsPolicy это ClusterFirst, mis tähendab, et kõik DNS-i päringud edastatakse aadressile dnsmasq, jookseb kaunas kube-dns klastri sees, mis omakorda edastab päringu rakendusele kube-dns, kui nimi lõpeb klastri järelliitega, või muul juhul kõrgema taseme DNS-serverisse.

fail /etc/resolv.conf iga konteineri sees näeb vaikimisi välja järgmine:

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äete, on kolm direktiivi:

Nimeserver on teenuse IP kube-dns
Määratud 4 kohaliku otsingu domeeni search
Võimalus on olemas ndots:5

Selle konfiguratsiooni huvitav osa on see, kuidas kohalik otsing domeenid ja seaded ndots:5 kokku saama. Selle mõistmiseks peate mõistma, kuidas kvalifitseerimata nimede DNS-i lahendamine töötab.

Mis on täisnimi?

Täielikult kvalifitseeritud nimi on nimi, mille kohta kohalikku otsingut ei tehta ja nime peetakse nime lahendamise ajal absoluutseks. Kokkuleppeliselt loeb DNS-tarkvara nime täielikult kvalifitseerituks, kui see lõpeb punktiga (.), ja muidu ei ole see täielikult kvalifitseeritud. See on google.com. täielikult määratletud ja google.com - mitte.

Kuidas käsitletakse määratlemata nime?

Kui rakendus loob ühenduse nimes määratud kaughostiga, tehakse DNS-i nime lahendamine tavaliselt süsteemikõne abil, nt. getaddrinfo(). Aga kui nimi on kvalifitseerimata (ei lõpe tähega .), siis ma ei tea, kas süsteemikutse proovib kõigepealt nime lahendada absoluutnimena või läbib kõigepealt kohalikud otsingudomeenid? Oleneb valikust ndots.

Käsiraamatust resolv.conf:

ndots:n

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

See tähendab, et kui ndots kui väärtus on 5 ja nimi sisaldab vähem kui 5 punkti, proovib süsteemikutse seda lahendada järjestikku, läbides esmalt kõik kohalikud otsingudomeenid ja kui see ei õnnestu, lahendades selle lõpuks absoluutnimena.

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

Nagu võite ette kujutada, kui teie rakendus kasutab palju välist liiklust, siis iga loodud TCP-ühenduse (või täpsemalt iga lahendatud nime) korral väljastab see 5 DNS-päringut, enne kui nimi on õigesti lahendatud, kuna see läbib kõigepealt 4 kohaliku otsingu domeeni ja lõpus väljastab absoluutse nime resolutsiooni taotluse.

Järgmine diagramm näitab meie 3 kube-dns-mooduli koguliiklust enne ja pärast seda, kui vahetasime mõned meie rakenduses konfigureeritud hostinimed täielikult kvalifitseeritud hostinimede vastu.

Järgmine diagramm näitab rakenduse latentsust enne ja pärast seda, kui lülitasime mitmed meie rakenduses konfigureeritud hostinimed täisnimedele (vertikaalne sinine joon on juurutus):

Lahendus nr 1 – kasutage täisväärtuslikke nimesid

Kui teil on vähe staatilisi välisnimesid (st rakenduse konfiguratsioonis määratletud), millega loote suure hulga ühendusi, on võib-olla kõige lihtsam lahendus need lihtsalt lisades täielikult kvalifitseeritud nimedeks vahetada. lõpus.

See ei ole lõplik lahendus, kuid aitab olukorda kiiresti, kuigi mitte puhtalt, parandada. Rakendasime selle plaastri oma probleemi lahendamiseks, mille tulemused on näidatud ülaltoodud ekraanipiltidel.

Lahendus nr 2 – kohandamine `ndots` в `dnsConfig`

Kubernetes 1.9-s ilmus funktsionaalsus alfarežiimis (beetaversioon v1.10), mis võimaldab teil DNS-i parameetreid paremini juhtida podatribuudi kaudu dnsConfig. Muuhulgas võimaldab see väärtust konfigureerida ndots konkreetse kauna jaoks, st.

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

allikatest

Loe ka teisi meie ajaveebi artikleid:

Allikas: www.habr.com

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