🥇/etc/resolv.conf pre Kubernetes pods, možnosť ndots:5, ako to môže negatívne ovplyvniť výkon aplikácie

Nedávno sme spustili Kubernetes 1.9 na AWS pomocou Kops. Včera, keď som hladko zavádzal novú návštevnosť do najväčšieho z našich klastrov Kubernetes, začal som si všímať nezvyčajné chyby v preklade názvov DNS zaznamenané našou aplikáciou.

Na GitHub je o tom dosť veľa povedal, tak som sa rozhodol prísť na to aj ja. Nakoniec som si uvedomil, že v našom prípade je to spôsobené zvýšenou záťažou na kube-dns и dnsmasq. Najzaujímavejší a nový bol pre mňa samotný dôvod výrazného nárastu návštevnosti DNS požiadaviek. Môj príspevok je o tom a čo s tým robiť.

Rozlíšenie DNS vo vnútri kontajnera - ako v každom systéme Linux - je určené konfiguračným súborom /etc/resolv.conf. Predvolený Kubernetes dnsPolicy это ClusterFirst, čo znamená, že každá požiadavka DNS bude presmerovaná na dnsmasq, beh v struku kube-dns vnútri klastra, ktorý následne prepošle požiadavku do aplikácie kube-dns, ak názov končí klastrovou príponou, alebo v opačnom prípade na server DNS vyššej úrovne.

súbor /etc/resolv.conf vo vnútri každého kontajnera bude predvolená hodnota vyzerať takto:

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

Ako vidíte, existujú tri smernice:

Menný server je adresa IP služby kube-dns
Boli zadané 4 domény lokálneho vyhľadávania search
Existuje možnosť ndots:5

Zaujímavou časťou tejto konfigurácie je spôsob lokálneho vyhľadávania domén a nastavení ndots:5 vychádzať spolu. Aby ste to pochopili, musíte pochopiť, ako funguje rozlíšenie DNS pre nekvalifikované názvy.

Aké je celé meno?

Plne kvalifikovaný názov je názov, pre ktorý sa nevykoná žiadne lokálne vyhľadávanie a názov sa bude počas rozlíšenia názvu považovať za absolútny. Podľa konvencie softvér DNS považuje názov za plne kvalifikovaný, ak končí bodkou (.), a inak nie je plne kvalifikovaný. Teda google.com. plne definované a google.com - Nie.

Ako sa zaobchádza s nekvalifikovaným menom?

Keď sa aplikácia pripojí k vzdialenému hostiteľovi špecifikovanému v názve, rozlíšenie názvu DNS sa zvyčajne vykonáva pomocou systémového volania, napr. getaddrinfo(). Ale ak je názov nekvalifikovaný (nekončí na .), zaujímalo by ma, či sa systémové volanie pokúsi najprv vyriešiť názov ako absolútny názov, alebo najprv prejde lokálne vyhľadávacie domény? Závisí to od možnosti ndots.

Z manuálu resolv.conf:

ndots:n

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

To znamená, že ak pre ndots ak je zadaná hodnota 5 a názov obsahuje menej ako 5 bodiek, systémové volanie sa ho pokúsi vyriešiť postupne, najskôr prejde všetky lokálne vyhľadávacie domény a v prípade neúspešnosti ho nakoniec vyhodnotí ako absolútny názov.

Prečo tak `ndots:5` môže to negatívne ovplyvniť výkon aplikácie?

Ako si viete predstaviť, ak vaša aplikácia využíva veľa externého prenosu, pri každom nadviazanom spojení TCP (alebo presnejšie pri každom vyriešenom názve) vydá 5 DNS dotazov, kým sa názov správne vyrieši, pretože najprv prejde 4 domény lokálneho vyhľadávania a na konci vydá požiadavku na rozlíšenie absolútneho názvu.

Nasledujúci graf zobrazuje celkovú návštevnosť našich 3 modulov kube-dns pred a po zmene niekoľkých názvov hostiteľov nakonfigurovaných v našej aplikácii na plne kvalifikované.

Nasledujúci diagram zobrazuje latenciu aplikácie pred a po tom, ako sme niekoľko názvov hostiteľov nakonfigurovaných v našej aplikácii zmenili na celé mená (vertikálna modrá čiara je nasadenie):

Riešenie č. 1 – Používajte plne kvalifikované názvy

Ak máte málo statických externých názvov (t.j. definovaných v konfigurácii aplikácie), ku ktorým vytvárate veľké množstvo spojení, asi najjednoduchším riešením je prepnúť ich na plne kvalifikované jednoduchým pripojením. nakoniec.

Nie je to konečné riešenie, ale pomáha rýchlo, aj keď nie čisto, zlepšiť situáciu. Túto opravu sme použili na vyriešenie nášho problému, ktorého výsledky sú zobrazené na snímkach obrazovky vyššie.

Riešenie #2 - prispôsobenie `ndots` в `dnsConfig`

V Kubernetes 1.9 sa funkcionalita objavila v režime alfa (beta verzia v1.10), ktorá umožňuje lepšie ovládať parametre DNS prostredníctvom vlastnosti pod v dnsConfig. Okrem iného umožňuje konfigurovať hodnotu ndots pre konkrétny pod, t.j.

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

zdroje

Prečítajte si aj ďalšie články na našom blogu:

Zdroj: hab.com

/etc/resolv.conf pre Kubernetes pods, možnosť ndots:5, ako to môže negatívne ovplyvniť výkon aplikácie