Nedavno smo pokrenuli Kubernetes 1.9 na AWS-u koristeći Kops. Jučer, tijekom postupnog puštanja novog prometa na najveći od naših Kubernetes klastera, primijetio sam neobične DNS greške u razrješavanju, koje je zabilježila naša aplikacija.
Na GitHubu se o tome dugo raspravljalo kube-dns. Najinteresantniji i najsvježiji dio koji sam otkrio je sama priroda značajnog povećanja prometa DNS upita. O tome i o tome što s tim učiniti, pišem u ovom postu. in dnsmasqRazrješavanje DNS-a unutar kontejnera — kao i u bilo kojem Linux sustavu — određuje se konfiguracijskom datotekom
. Prema zadanim postavkama, Kubernetes /etc/resolv.confdnsPolicy ClusterFirst it , što znači da će se svaki DNS upit preusmjeriti na, pokrenut u podu dnsmasqunutar klastera, koji će potom preusmjeriti upit prema aplikaciji Najinteresantniji i najsvježiji dio koji sam otkrio je sama priroda značajnog povećanja prometa DNS upita. O tome i o tome što s tim učiniti, pišem u ovom postu. , ako ime završava s klasterskim sufiksom, ili drugačije, prema DNS poslužitelju višeg nivoa. Najinteresantniji i najsvježiji dio koji sam otkrio je sama priroda značajnog povećanja prometa DNS upita. O tome i o tome što s tim učiniti, pišem u ovom postu.Datoteka
unutar svakog kontejnera prema zadanim postavkama će izgledati ovako: /etc/resolv.conf nameserver 100.64.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal options ndots:5
Kao što možete primijetiti, postoje tri direktive:Poslužitelj imena je IP usluge
- Navedena su 4 lokalna domena pretraživanja
Najinteresantniji i najsvježiji dio koji sam otkrio je sama priroda značajnog povećanja prometa DNS upita. O tome i o tome što s tim učiniti, pišem u ovom postu. - search
Postoji opcija - ndots:5
Zanimljiv dio ove konfiguracije je kako se lokalne domene pretraživanja i postavke
udružuju zajedno. Da bismo to shvatili, potrebno je razumjeti kako radi razrješavanje DNS-a za nepotpuna imena. Zanimljiv dio ove konfiguracije je kako se lokalne domene pretraživanja i postavke Što je potpuno ime?
Potpuno određeno ime je ime za koje se ne vrši lokalno pretraživanje, i ime će se smatrati apsolutnim tijekom razrješavanja imena. Prema dogovoru, DNS softver smatra ime potpuno određenim ako završava točkom (.), A ne potpuno određenim u suprotnom. Drugim riječima,
google.com. je potpuno određeno, a nije. google.com Kako se obrađuje nepotpuno ime?
Kada se aplikacija poveže na udaljeni host naveden u imenu, razrješavanje DNS imena obično se vrši putem sistemskog poziva, kao što je
getaddrinfo() . Međutim, ako je ime nepotpuno (ne završava s .), zanimljivo je hoće li sistemski poziv prvo pokušati razrješiti ime kao apsolutno, ili će prvo proći kroz lokalne domene pretraživanja? To ovisi o opcijindots Iz priručnika za.
resolv.conf resolv.conf:
ndots:n
nastavlja prag za broj tačaka koje se trebaju pojaviti u imenu pre nego što se izvrši inicijalni apsolutni zahtev. Podrazumevana vrednost za n je 1, što znači da ako ime sadrži bilo koje tačke, biće prvo isprobano kao apsolutno ime pre nego što mu se dodaju bilo koji elementi liste pretrage.To znači da ako je Iz priručnika za postavljena vrednost 5, a ime sadrži manje od 5 tačaka, sistemski poziv će pokušati da ga razreši sekvencijalno, prvo prolazeći kroz sve lokalne pretraživačke domene, a u slučaju neuspeha, na kraju će ga razrešiti kao apsolutno ime.
Zašto Zanimljiv dio ove konfiguracije je kako se lokalne domene pretraživanja i postavke može negativno uticati na performanse aplikacije?
Kao što možete zamisliti, ako vaša aplikacija koristi mnogo spoljnog saobraćaja, za svako uspostavljeno TCP povezivanje (ili, preciznije, za svako razrešeno ime) izdaće 5 DNS zahteva pre nego što se ime ispravno razreši, zato što prvo prolazi kroz 4 lokalna pretraživačka domena, a na kraju će izdati zahtev za razrešenje apsolutnog imena.
Na sledećem dijagramu prikazan je ukupni saobraćaj na naših 3 modula kube-dns pre i posle promene nekoliko imena hostova podešenih u našoj aplikaciji na potpuno određene.
Na sledećem dijagramu prikazana je latencija aplikacije pre i posle promene nekoliko imena hostova podešenih u našoj aplikaciji na pune (vertikalna plava linija predstavlja implementaciju):
Rešenje #1 — koristiti potpuno određena imena
Ako imate malo statičnih spoljnih imena (tj. definisanih u konfiguraciji aplikacije) na koja se povezujete u velikom broju, možda je najjednostavnije rešenje prebaciti ih na potpuno određena, jednostavno dodavanjem. na kraju.
Ovo nije konačno rešenje, ali pomaže u brzoj, iako ne potpuno čistoj, poboljšanju situacije. Ovu zakrpu smo primenili da bismo rešili naš problem, čiji su rezultati prikazani na slikama iznad.
Rešenje #2 — prilagođavanje Iz priručnika za u dnsConfig
U Kubernetesu 1.9 u alfa režimu pojavio se funkcionalnost (beta verzija v1.10), koja omogućava bolje upravljanje DNS parametrima putem osobine poda u dnsConfig. U međuvremenu, omogućava vam da podesite vrednost Iz priručnika za za konkretan pod, tj.
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsConfig:
options:
- name: ndots
value: "1"Izvori
Preberite tudi druge članke v našem blogu:
Izvor: habr.com
