🥇/etc/resolv.conf pro pody Kubernetes, možnost ndots:5, jak to může negativně ovlivnit výkon aplikace

Nedávno jsme spustili Kubernetes 1.9 na AWS pomocí Kops. Včera, během plynulého nasazování nového provozu na našem největším Kubernetes clusteru, jsem začal zaznamenávat neobvyklé chyby v DNS rozlišení, které naše aplikace logovala.

Na GitHubu se o tom už nějakou dobu mluví, proto jsem se také rozhodl to prozkoumat. Nakonec jsem pochopil, že v našem případě to způsobila zvýšená zátěž na kube-dns a dnsmasq. Nejdůležitější a nejnovější věcí pro mě byla samotná příčina značného nárůstu provozu DNS dotazů. O tom a o tom, co s tím dělat, je můj příspěvek.

Rozlišení DNS uvnitř kontejneru — jako v jakémkoliv systému Linux — se určuje konfiguračním souborem /etc/resolv.conf. Výchozí nastavení Kubernetes dnsPolicy to ClusterFirst, což znamená, že jakýkoliv DNS dotaz bude přesměrován na dnsmasq, běžící v podu kube-dns uvnitř clusteru, který poté přesměruje dotaz na aplikaci kube-dns, pokud jméno končí suffixem clusteru, nebo jinak na DNS server vyšší úrovně.

Soubor /etc/resolv.conf Uvnitř každého kontejneru to bude vypadat takto:

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

Jak můžete vidět, jsou zde tři direktivy:

Server jmen — to je IP adresa služby kube-dns
Jsou uvedeny 4 místní vyhledávací domény search
Je zde volba ndots:5

Zajímavou částí této konfigurace je, jak se místní vyhledávací domény a nastavení ndots:5 spolu snášejí. Abychom to pochopili, je třeba se podívat na to, jak funguje rozlišení DNS pro neúplná jména.

Co je to úplné jméno?

Úplně kvalifikované jméno je jméno, u kterého nebude provedeno místní vyhledávání, a jméno bude považováno za absolutní během rozlišení jmen. Podle dohody považuje DNS software jméno za úplně kvalifikované, pokud končí tečkou (.), A neúplně kvalifikované v opačném případě. Tedy google.com. je úplně kvalifikováno, zatímco google.com není.

Jak se zpracovává neúplné jméno?

Když se aplikace připojuje k vzdálenému hostiteli, jehož jméno je uvedeno, obvykle se rozlišení DNS provádí pomocí systémového volání, jako je getaddrinfo(). A pokud je jméno neúplné (nekončí na .), je zajímavé, zda se systémové volání nejprve pokusí rozlišit jméno jako absolutní, nebo projde nejprve místními vyhledávacími doménami? To závisí na možnosti ndots.

Z manuálu k resolv.conf:

ndots:n

nastavuje práh pro počet teček, které se musí objevit v názvu, než dojde k provedení počátečního absolutního dotazu. Výchozí hodnota pro n je 1, což znamená, že pokud název obsahuje nějaké tečky, bude nejprve vyzkoušeno jako absolutní jméno, než k němu budou přidány jakékoli prvky seznamu hledání.

To znamená, že pokud je pro ndots nastavena hodnota 5 a název obsahuje méně než 5 teček, systémový volání se pokusí jej vyřešit postupně, nejprve projde všechny místní vyhledávací domény a v případě neúspěchu na konci nakonec jej vyřeší jako absolutní jméno.

Proč to `ndots:5` může negativně ovlivnit výkon aplikace?

Jak vidíte, pokud vaše aplikace používá hodně externího provozu, pro každé navázané TCP spojení (nebo přesněji, pro každé vyřešené jméno) vygeneruje 5 DNS dotazů, než bude název správně vyřešen, protože nejprve projde 4 místními vyhledávacími doménami a nakonec se provede dotaz na vyřešení absolutního jména.

Na následujícím diagramu je zobrazen celkový provoz na našich 3 modulech kube-dns před a po přepnutí několika názvů hostitelů nastavených v naší aplikaci na plně kvalifikované.

Na následujícím diagramu je zobrazeno zpoždění aplikace před a po přepnutí několika názvů hostitelů nastavených v naší aplikaci na plné (vertikální modrá čára je nasazení):

Řešení č. 1 — použít plně kvalifikované názvy

Pokud máte málo statických externích názvů (tj. definovaných v konfiguraci aplikace), ke kterým vytváříte velké množství připojení, nejjednodušší řešení může být přepnout je na plně kvalifikované, jednoduše přidáním. na konci.

Toto není konečné řešení, ale pomáhá rychle, byť ne čistě, vylepšit situaci. Tento patch jsme aplikovali na řešení našeho problému, jehož výsledky byly zobrazeny na výše uvedených snímcích obrazovky.

Řešení č. 2 — přizpůsobení `ndots` v `dnsConfig`

V Kubernetes 1.9 byl v alfa režimu představen funkční prvek (beta verze v1.10), který umožňuje lepší kontrolu nad parametry DNS prostřednictvím vlastnosti podu v dnsConfig. Mezi jiným umožňuje nastavit hodnotu ndots pro konkrétní pod, tj.

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