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

Hiljuti käivitasime Kubernetes 1.9 AWS-is Kopsi abil. Eile, kui jagasime uut liiklust meie suurimasse Kubernetes klastrisse, hakkasin märkama ebatavalisi DNS-i nimede lahendamise vigu, mida meie rakendus logis.

GitHubis on sellest juba pikemat aega kirjutatud kuidas ettevõtted saavad kaitsta oma võrgustikku, kui suur osa töötajatest töötab kaugtöö vormis ja, seega otsustasin ka ise süveneda. Selgus, et meie juhul põhjustas selle kõrgenenud koormus kube-dns ja dnsmasq. Kõige huvitavam ja uutmoodi mulle oli põhjus, miks DNS-i päringute liiklus oluliselt suurenes. Siin on minu postitus sellest ja sellest, mida sellega ette võtta.

DNS-i lahendamine konteineris — nagu igas Linuxi süsteemis — määratakse konfigureerimisfailiga /etc/resolv.conf. Vaikimisi on Kubernetes dnsPolicy see ClusterFirst, mis tähendab, et kõik DNS-i päringud suunatakse dnsmasqkonteinerisse, kube-dns mis omakorda suunab päringu rakendusele kube-dns, kui nimi lõpeb klastrisufiksiga, või muul juhul kõrgema taseme DNS serverisse.

File /etc/resolv.conf Iga konteineri sees näeb vaikeväärtus 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
Määratud on 4 kohaliku otsingu domeeni. search
Saadaval on valik. ndots:5

Selle seadistuse huvitav osa on selles, kuidas kohalikud otsingud domeenid ja seaded. ndots:5 koos eksisteerivad. Selleks, et seda mõista, tuleb selgeks teha, kuidas DNS-i lahendamine töötab mittetäielike nimede puhul.

Mis on täielik nimi?

Täielikult määratletud nimi on nimi, mille korral kohalikku otsingut ei tehta ja nime peetakse resolutsiooni ajal absoluutseks. Nime peetakse täielikult määratletuks, kui see lõppeb punktiga (.), ja mitte täielikult määratletuks muidu. See tähendab, et google.com. on täielikult määratletud, aga google.com — ei ole.

Kuidas käsitletakse mittetäielikku nime?

Kui rakendus ühendub kaughostiga, mille on määranud nimi, toimub DNS-i nime lahendamine tavaliselt süsteemi kutse abil, näiteks getaddrinfo(). Kui nimi on mittetäielik (ei lõpe .-ga), on huvitav, kas süsteemikutse proovib alguses lahendada nime absoluutseks või läbib esmalt kohalikud otsingud domeenid? See sõltub valikust. ndots.

Käesolevast manuaalist resolv.conf:

ndots:n

määrab künnise punktide arvu jaoks, mis peavad nime ilmuma, enne kui tehakse algne absoluutne päring. Vaikeväärtus n on 1, mis tähendab, et kui nimes on mingeid punkte, proovib süsteem esialgu nime absoluutse nimega, enne kui sellele lisatakse loendiotsingu elemente.

See tähendab, et kui ndots on määratud väärtus 5 ja nimi sisaldab vähem kui 5 punkti, siis süsteemikõne püüab seda järjestikku lahendada, liikudes esmalt läbi kõikidele kohalikele otsingudomeenidele ning vajadusel lahendab lõpuks selle absoluutse nimega.

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

Kuidas te mõistate, kui teie rakendus kasutab palju välist liiklust, iga kehtestatud TCP-ühenduse (või täpsemalt, iga lahendatud nime) korral andke 5 DNS-päringut, enne kui nimi õigesti lahendatakse, kuna see läheb esmalt läbi 4 kohaliku otsingudomeeni ja lõpuks esitab absoluutse nime lahendamise päringu.

Järgmine diagramm näitab meie kolme kube-dns mooduli koguliiklust enne ja pärast seda, kui me lülitasime mitmed meie rakenduses määratud hostinimed täielikult määratletud nimedele.

Järgmine diagramm näitab rakenduse latentsust enne ja pärast seda, kui me lülitasime mitmed meie rakenduses määratud hostinimed täielikult määratletud nimedele (vertikaalne sinine joon tähistab juurutamist):

Lahendus #1 — kasutada täielikult määratletud nimesid

Kui teil on vähe staatilisi väliseid nimesid (st rakenduse konfiguratsioonis määratud), millele te loote palju ühendusi, võib kõige lihtsam lahendus olla lülitamine täielikult määratletud nimedele, lisades lihtsalt lõppu.

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

Lahendus #2 — kohandamine `ndots` ühes `dnsConfig`

Kubernetes 1.9-s tutvustati alfa režiimis funktsionaalsust (beta versioon v1.10), mis võimaldab paremat DNS-i parameetrite kontrollimist podi omaduse kaudu. dnsConfig. Muuhulgas võimaldab see määrata väärtuse ndots konkreetse poodi, st.

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