🥇/etc/resolv.conf pro Kubernetes pody, 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, při hladkém zavádění nového provozu do největšího z našich clusterů Kubernetes, jsem si začal všímat neobvyklých chyb překladu názvů DNS zaznamenaných naší aplikací.

Na GitHubu je o tom docela dost promluvil, tak jsem se rozhodl na to přijít taky. Nakonec jsem si uvědomil, že v našem případě je to způsobeno zvýšenou zátěží na kube-dns и dnsmasq. Nejzajímavější a nejnověji pro mě byl samotný důvod výrazného nárůstu provozu požadavků DNS. Můj příspěvek je o tom a co s tím dělat.

Rozlišení DNS uvnitř kontejneru - stejně jako v jakémkoli systému Linux - je určeno konfiguračním souborem /etc/resolv.conf. Výchozí Kubernetes dnsPolicy tento ClusterFirst, což znamená, že jakýkoli DNS požadavek bude předán na dnsmasq, běžící v lusku kube-dns uvnitř clusteru, který zase předá požadavek aplikaci kube-dns, pokud název končí příponou clusteru, nebo v opačném případě na server DNS vyšší úrovně.

Soubor /etc/resolv.conf uvnitř každého kontejneru bude výchozí nastavení 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 vidíte, existují tři směrnice:

Jmenný server je adresa IP služby kube-dns
Byly zadány 4 domény místního vyhledávání search
Existuje možnost ndots:5

Zajímavou částí této konfigurace je způsob místního vyhledávání domén a nastavení ndots:5 vycházet spolu. Abyste tomu porozuměli, musíte pochopit, jak funguje překlad DNS pro nekvalifikované názvy.

Co je to celé jméno?

Plně kvalifikovaný název je název, pro který nebude prováděno žádné místní vyhledávání a název bude při překladu názvů považován za absolutní. Podle konvence software DNS považuje název za plně kvalifikovaný, pokud končí tečkou (.), a jinak není plně kvalifikovaný. To znamená google.com. plně definované a google.com - Ne.

Jak se nakládá s nekvalifikovaným jménem?

Když se aplikace připojí ke vzdálenému hostiteli uvedenému v názvu, překlad názvu DNS se obvykle provádí pomocí systémového volání, např. getaddrinfo(). Ale pokud je jméno nekvalifikované (nekončí na .), zajímalo by mě, zda se systémové volání pokusí nejprve přeložit jméno jako absolutní jméno, nebo nejprve projde místními vyhledávacími doménami? Záleží na variantě ndots.

Z manuálu resolv.conf:

ndots:n

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

To znamená, že pokud pro ndots je-li hodnota 5 a název obsahuje méně než 5 teček, systémové volání se pokusí vyřešit problém postupně, nejprve projde všemi doménami lokálního vyhledávání, a pokud nebude úspěšné, nakonec jej vyhodnotí jako absolutní název.

Proč `ndots:5` mohlo by to negativně ovlivnit výkon aplikace?

Jak si dokážete představit, pokud vaše aplikace používá velké množství externího provozu, pro každé navázané TCP spojení (nebo přesněji pro každé vyřešené jméno) vydá 5 DNS dotazů, než je název správně vyřešen, protože nejprve projde 4 lokální vyhledávací doménu a na konci vydá požadavek na rozlišení absolutního názvu.

Následující graf ukazuje celkový provoz na našich 3 modulech kube-dns před a poté, co jsme změnili několik názvů hostitelů nakonfigurovaných v naší aplikaci na plně kvalifikované.

Následující diagram ukazuje latenci aplikace před a poté, co jsme několik názvů hostitelů nakonfigurovaných v naší aplikaci přepnuli na celá jména (svislá modrá čára je nasazení):

Řešení č. 1 – Používejte 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í, asi nejjednodušším řešením je přepnout je na plně kvalifikovaná pouhým připojením. na konci.

Není to konečné řešení, ale pomáhá rychle, i když ne čistě, situaci zlepšit. Použili jsme tuto opravu, abychom vyřešili náš problém, jehož výsledky jsou zobrazeny na snímcích výše.

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

V Kubernetes 1.9 se funkce objevila v režimu alfa (beta verze v1.10), která umožňuje lépe ovládat parametry DNS prostřednictvím vlastnosti pod v dnsConfig. Mimo jiné umožňuje konfigurovat hodnotu ndots pro konkrétní pod, tzn.

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

zdroje

Přečtěte si také další články na našem blogu:

Zdroj: www.habr.com

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