🥇/etc/resolv.conf pre Kubernetes pody, voľba 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, počas plynulého nasadzovania nového prevádzkového prenosu na našich najväčších Kubernetes klastroch, som začal zaznamenávať nezvyčajné chyby pri DNS rozlíšení, ktoré zaznamenovalo naše aplikácie.

O tom sa na GitHube diskutovalo pomerne dlho, takže som sa rozhodol, že to preskúmam aj ja. Nakoniec som pochopil, že v našom prípade to bolo spôsobené zvýšenou záťažou nakube-dns. Najzaujímavejšou a najnovšou vecou pre mňa bola sama príčina významného nárastu prevádzky DNS dopytov. O tom a o tom, čo s tým robiť, píšem v tomto príspevku. a dnsmasqDNS rozlíšenie vo vnútri kontajnera — rovnako ako v každom systéme Linux — je definované konfiguračným súborom.

Predvolene Kubernetes /etc/resolv.confpoužíva dnsPolicy to ClusterFirst,čo znamená, že každý DNS dopyt bude presmerovaný na dnsmasq, bežiaci v pode Najzaujímavejšou a najnovšou vecou pre mňa bola sama príčina významného nárastu prevádzky DNS dopytov. O tom a o tom, čo s tým robiť, píšem v tomto príspevku. vo vnútri klastru, ktorý následne presmeruje dopyt na aplikáciu Najzaujímavejšou a najnovšou vecou pre mňa bola sama príčina významného nárastu prevádzky DNS dopytov. O tom a o tom, čo s tým robiť, píšem v tomto príspevku., ak meno končí suffixom klastra, alebo inak na vyššie úrovňový DNS server.

Súbor /etc/resolv.conf Vo vnútri každého kontajnera to predvolene vyzerá 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 môžete vidieť, sú tu tri direktívy:

DNS server — je to IP adresa služby Najzaujímavejšou a najnovšou vecou pre mňa bola sama príčina významného nárastu prevádzky DNS dopytov. O tom a o tom, čo s tým robiť, píšem v tomto príspevku.
Sú uvedené 4 lokálne vyhľadávacie domény. search
Existuje voľba ndots:5.

Zaujímavou časťou tejto konfigurácie je, ako lokálne vyhľadávacie domény a nastavenia ndots:5. spolupracujú. Aby ste to pochopili, musíte si objasniť, ako funguje DNS rozlíšenie pre neúplné mená.

Čo je úplné meno?

Úplne určené meno je meno, pre ktoré nebude vykonané lokálne vyhľadávanie, a meno bude považované za absolútne počas rozlíšenia mien. Podľa dohody, softvér DNS považuje meno za úplne určené, ak končí bodkou (.), A nie ako úplne určené inak. To znamená, google.com. je úplne určené, zatiaľ čo google.com — nie.

Ako sa spracováva neúplné meno?

Keď sa aplikácia pripojí k vzdialenému hostiteľovi uvedenému v mene, zvyčajne sa rozlíšenie mien DNS vykonáva pomocou systémového volania, ako napríklad getaddrinfo().Zaujímavé je, že ak je meno neúplné (nekončí bodkou), pokúsi sa systémové volanie najprv rozlíšiť meno ako absolútne, alebo sa najprv prejde cez lokálne vyhľadávacie domény? Závisí to od voľby ndots.

Z manuálu k resolv.conf:

ndots:n

nastavuje prah pre počet bodiek, ktoré sa musia objaviť v názve, skôr než sa vykoná počiatočný absolútny dotaz. Predvolená hodnota pre n je 1, čo znamená, že ak názov obsahuje akékoľvek bodky, názov sa najprv vyskúša ako absolútny názov, skôr než mu budú pridané akékoľvek prvky zo zoznamu vyhľadávania.

To znamená, že ak je ndots nastavená hodnota 5 a názov obsahuje menej ako 5 bodiek, systémový hovor sa pokúsi ho postupne vyriešiť, najprv prechádzajúc všetkými miestnymi vyhľadávacími doménami, a v prípade neúspechu nakoniec vyrieši jeho ako absolútny názov.

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

Ako rozumiete, ak vaša aplikácia používa veľa externého dopravy, pre každý nastavený TCP pripojenie (alebo presnejšie, pre každý povolený názov) vykoná 5 DNS dotazov, skôr než bude názov správne vyriešený, pretože najprv prejde cez 4 miestne vyhľadávacie domény a nakoniec vygeneruje dotaz na absolútny názov.

Na nasledujúcom diagrame je zobrazený kumulatívny prenos na našich 3 moduloch kube-dns pred a po tom, čo sme prepli niekoľko názvov hostiteľov nastavených v našej aplikácii na úplne definované.

Na nasledujúcom diagrame je zobrazená latencia aplikácie pred a po tom, čo sme prepli niekoľko názvov hostiteľov nastavených v našej aplikácii na úplné (vertikálna modrá čiara je nasadenie):

Riešenie #1 — použitie úplne definovaných názvov

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 pripojení, najjednoduchším riešením môže byť prepnúť ich na úplne definované, jednoducho pridávaním . na koniec.

Nie je to definitívne riešenie, ale pomáha rýchlo, aj keď nie čisto, zlepšiť situáciu. Tento patch sme aplikovali na vyriešenie našej problém, výsledky čoho boli zobrazené na snímkach vyššie.

Riešenie #2 — prispôsobenie `ndots` v `dnsConfig`

V Kubernetes 1.9 v alfa režime sa objavila funkcia (beta verzia v1.10), ktorá umožňuje lepšie kontrolovať parametre DNS prostredníctvom vlastnosti podu v dnsConfig. Medzi ostatnými, umožňuje nakonfigurovať 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"