🥇/etc/resolv.conf for Kubernetes pods, ndots:5 alternativ, hvordan dette kan påvirke applikasjonsytelsen negativt

Vi lanserte nylig Kubernetes 1.9 på AWS ved å bruke Kops. I går, mens jeg jevnt rullet ut ny trafikk til de største av våre Kubernetes-klynger, begynte jeg å legge merke til uvanlige DNS-navneoppløsningsfeil logget av applikasjonen vår.

Det er ganske mye om dette på GitHub sa, så jeg bestemte meg for å finne ut av det også. Til slutt innså jeg at i vårt tilfelle er dette forårsaket av økt belastning på kube-dns и dnsmasq. Det mest interessante og nye for meg var selve grunnen til den betydelige økningen i DNS-forespørselstrafikk. Innlegget mitt handler om dette og hva jeg skal gjøre med det.

DNS-oppløsning inne i beholderen - som i alle Linux-systemer - bestemmes av konfigurasjonsfilen /etc/resolv.conf. Standard Kubernetes dnsPolicy dette ClusterFirst, som betyr at enhver DNS-forespørsel vil bli videresendt til dnsmasq, løper i en pod kube-dns inne i klyngen, som igjen vil videresende forespørselen til søknaden kube-dns, hvis navnet slutter med et klyngesuffiks, eller på annen måte til en DNS-server på høyere nivå.

fil /etc/resolv.conf inne i hver beholder vil standarden se slik ut:

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

Som du kan se, er det tre direktiver:

Navneserveren er IP-en til tjenesten kube-dns
4 lokale søkedomener spesifisert search
Det er et alternativ ndots:5

Den interessante delen av denne konfigurasjonen er hvordan de lokale søkedomenene og innstillingene ndots:5 komme overens. For å forstå dette, må du forstå hvordan DNS-oppløsning for ukvalifiserte navn fungerer.

Hva er et fullt navn?

Et fullt kvalifisert navn er et navn som det ikke vil bli utført lokalt oppslag for, og navnet vil bli ansett som absolutt under navneløsning. Ved konvensjon anser DNS-programvare at et navn er fullt kvalifisert hvis det slutter med en prikk (.), og ellers ikke er fullstendig kvalifisert. Det er google.com. fullt definert og google.com - ikke.

Hvordan håndteres et ukvalifisert navn?

Når en applikasjon kobler til den eksterne verten som er spesifisert i navnet, gjøres DNS-navneoppløsning vanligvis ved å bruke et systemanrop, f.eks. getaddrinfo(). Men hvis navnet er ukvalifisert (slutter ikke med .), lurer jeg på om systemkallet vil prøve å løse navnet som et absolutt navn først, eller gå gjennom de lokale søkedomenene først? Det avhenger av alternativet ndots.

Fra manualen resolv.conf:

ndots:n

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

Dette betyr at hvis for ndots gitt en verdi på 5 og navnet inneholder mindre enn 5 punkter, vil systemkallet forsøke å løse det sekvensielt, først krysse alle lokale søkedomener, og, hvis det ikke lykkes, til slutt løse det som et absolutt navn.

Hvorfor det `ndots:5` kan det påvirke applikasjonsytelsen negativt?

Som du kan forestille deg, hvis applikasjonen din bruker mye ekstern trafikk, for hver TCP-tilkobling som er opprettet (eller mer nøyaktig, for hvert navn som er løst), vil den utstede 5 DNS-spørringer før navnet er riktig løst, fordi det først vil gå gjennom 4 lokale søkedomene, og vil på slutten utstede en absolutt forespørsel om navneløsning.

Følgende diagram viser den totale trafikken på våre 3 kube-dns-moduler før og etter at vi byttet de få vertsnavnene som er konfigurert i applikasjonen vår til fullt kvalifiserte.

Følgende diagram viser applikasjonsforsinkelsen før og etter at vi byttet flere vertsnavn konfigurert i applikasjonen vår til fulle navn (den vertikale blå linjen er distribusjonen):

Løsning #1 - Bruk fullt kvalifiserte navn

Hvis du har få statiske eksterne navn (dvs. definert i applikasjonskonfigurasjonen) som du oppretter et stort antall forbindelser til, er kanskje den enkleste løsningen å bytte dem til fullt kvalifiserte ved ganske enkelt å legge dem til. på slutten.

Dette er ikke en endelig løsning, men det hjelper å raskt, om enn ikke rent, forbedre situasjonen. Vi brukte denne oppdateringen for å løse problemet vårt, hvis resultater ble vist i skjermbildene ovenfor.

Løsning #2 - tilpasning `ndots` в `dnsConfig`

I Kubernetes 1.9 dukket funksjonalitet opp i alfamodus (betaversjon v1.10), som lar deg bedre kontrollere DNS-parametere gjennom pod-egenskapen i dnsConfig. Den lar deg blant annet konfigurere verdien ndots for en bestemt pod, dvs.

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

kilder

Les også andre artikler på bloggen vår:

Kilde: www.habr.com

/etc/resolv.conf for Kubernetes pods, ndots:5 alternativ, hvordan dette kan påvirke applikasjonsytelsen negativt