🥇/etc/resolv.conf Kubernetes leketarako, ndots:5 aukera, nola eragin dezakeen honek aplikazioen errendimenduan

Duela gutxi Kubernetes 1.9 abiarazi dugu AWS-n Kops erabiliz. Atzo, gure Kubernetes kluster handienetara trafiko berria leunki zabaltzen ari nintzela, gure aplikazioak erregistratutako DNS izenak ebazteko errore ezohikoak sumatzen hasi nintzen.

GitHub-en dezente dago honi buruz esan, beraz, nik ere asmatzea erabaki nuen. Azkenean, konturatu nintzen gure kasuan hau karga handitzeak eragiten duela kube-dns и dnsmasq. Niretzat gauzarik interesgarriena eta berriena DNS eskaera-trafikoa handitzearen arrazoia izan zen. Nire mezua honi buruzkoa da eta zer egin behar den.

Edukiontzi barruko DNS bereizmena - Linux sistema guztietan bezala - konfigurazio fitxategiak zehazten du /etc/resolv.conf. Kubernetes lehenetsia dnsPolicy honetan ClusterFirst, hau da, edozein DNS eskaera bertara birbidaliko da dnsmasq, leka batean korrika kube-dns klusterraren barruan, eta, aldi berean, eskaera aplikaziora helaraziko du kube-dns, izena cluster atzizki batekin amaitzen bada, edo, bestela, goi mailako DNS zerbitzari batera.

fitxategia /etc/resolv.conf Edukiontzi bakoitzaren barruan lehenetsitako itxura hau izango da:

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

Ikus dezakezunez, hiru zuzentarau daude:

Izen zerbitzaria zerbitzuaren IPa da kube-dns
4 tokiko bilaketa-domeinu zehaztuta search
Aukera bat dago ndots:5

Konfigurazio honen zati interesgarria da tokiko bilaketa-domeinuak eta ezarpenak nola egiten diren ndots:5 elkarrekin elkartu. Hori ulertzeko, kualifikaziorik gabeko izenen DNS ebazpenak nola funtzionatzen duen ulertu behar duzu.

Zer da izen osoa?

Izen guztiz kualifikatua bilaketa lokalik egingo ez den izena da eta izena erabatekotzat hartuko da izena ebazteko garaian. Konbentzioz, DNS softwareak izen bat guztiz kalifikatutzat jotzen du puntu batekin amaitzen bada (.), eta ez da guztiz kalifikatu bestela. Hori da google.com. guztiz definitu eta google.com - Ez.

Nola tratatzen da kualifikaziorik gabeko izen bat?

Aplikazio bat izenan zehaztutako urruneko ostalarira konektatzen denean, DNS izenaren ebazpena sistema-dei bat erabiliz egiten da normalean, adibidez. getaddrinfo(). Baina izena kalifikatua ez bada (ez amaitzen da.), galdetzen diot sistema-deiak izena izen absolutu gisa ebazten saiatuko ote den lehenik, edo tokiko bilaketa-domeinuetatik igaroko den lehenik? Aukeraren araberakoa da ndots.

Eskuliburutik resolv.conf:

ndots:n

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

Horrek esan nahi du bada ndots 5 balioa emanda eta izenak 5 puntu baino gutxiago dituela, sistema-deiak sekuentzialki ebazten saiatuko da, lehenik eta behin tokiko bilaketa-domeinu guztiak zeharkatuz, eta, arrakastarik ez badu, azkenean izen absolutu gisa ebatziko du.

Zergatik orduan `ndots:5` eragin negatiboa izan al dezake aplikazioen errendimenduan?

Imajina dezakezun bezala, zure aplikazioak kanpoko trafiko asko erabiltzen badu, ezartzen den TCP konexio bakoitzeko (edo zehatzago, ebatzitako izen bakoitzeko), 5 DNS kontsulta emango ditu izena behar bezala konpondu baino lehen, lehenik igaroko delako. 4 bilaketa lokaleko domeinua, eta amaieran izena ebazteko eskaera absolutua emango du.

Hurrengo grafikoan gure 3 kube-dns moduluen trafiko osoa erakusten da gure aplikazioan konfiguratutako ostalari-izen gutxi batzuk guztiz kualifikatuetara aldatu aurretik eta ondoren.

Hurrengo diagramak aplikazioaren latentzia erakusten du gure aplikazioan konfiguratutako hainbat ostalari-izen izen osoetara aldatu aurretik eta ondoren (lerro urdin bertikala inplementazioa da):

1. irtenbidea - Erabili izen guztiz kualifikatuak

Kanpo-izen estatiko gutxi badituzu (hau da, aplikazioaren konfigurazioan definitu direnak) eta haiekin konexio kopuru handia sortzen baduzu, agian irtenbiderik errazena guztiz kualifikatuetara aldatzea izango da, besterik gabe, erantsiz. amaieran.

Hau ez da azken konponbidea, baina azkar, garbi ez bada ere, egoera hobetzen laguntzen du. Adabaki hau gure arazoa konpontzeko aplikatu genuen, eta horren emaitzak goiko pantaila-argazkietan erakutsi ziren.

2. irtenbidea - pertsonalizazioa `ndots` в `dnsConfig`

Kubernetes 1.9-n, funtzionaltasuna alfa moduan agertu zen (v1.10 beta bertsioa), eta horri esker DNS parametroak hobeto kontrola ditzakezu pod propietatearen bidez. dnsConfig. Besteak beste, balioa konfiguratzeko aukera ematen du ndots leka zehatz baterako, alegia.

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