DNS-zoekopdracht in Kubernetes

Opmerking vertaler.: DNS-probleem in Kubernetes, of specifieker - het instellen van een parameter ndots, - is verrassend populair, en dat al voor de eerste keer. jaarIn een nieuw artikel over dit onderwerp vertelt de auteur - een DevOps-engineer van een groot makelaarskantoor in India - op een zeer eenvoudige en beknopte manier waar collega's die Kubernetes gebruiken rekening mee moeten houden.

Een van de belangrijkste voordelen van het implementeren van applicaties in Kubernetes is het probleemloze ontdekken van applicaties. De interne communicatie wordt sterk vereenvoudigd door het concept van een service (Service), die een virtueel IP is dat een set IP-adressen van pods ondersteunt. Bijvoorbeeld, als de service vanilla een verbinding met de service chocolatewil maken, kan deze rechtstreeks het virtuele IP aanspreken voor chocolate. De vraag rijst: wie lost de DNS-query naar chocolate op en hoe?

De DNS-naamgeving wordt in de Kubernetes-cluster ingesteld met behulp van CoreDNS. Kubelet schrijft de pod met CoreDNS in als de naamserver in de bestanden van /etc/resolv.conf alle pods. Als we naar de inhoud van /etc/resolv.conf een pod kijken, zal deze er ongeveer als volgt uitzien:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

Deze configuratie wordt gebruikt door DNS-clients om verzoeken naar de DNS-server te leiden. In het bestand resolv.conf staat de volgende informatie:

• nameserver: de server waar de DNS-verzoeken naartoe worden geleid. In ons geval is dit het adres van de CoreDNS-service;
• search: definieert het pad voor het zoeken naar een bepaald domein. Het is interessant dat google.com of mrkaran.dev geen FQDN (volledige domeinnamen). Volgens de standaardovereenkomst waar de meeste DNS-resolvers zich aan houden, worden alleen die domeinen als volledig (FQDN) beschouwd die eindigen op een punt «.», die de rootzone vertegenwoordigt. Sommige resolvers kunnen zelf een punt toevoegen. Dus, mrkaran.dev. is een volledig domeinnaam (FQDN), terwijl mrkaran.dev dat niet is;
• ndots: De meest interessante parameter (dit artikel gaat er juist over). ndots stelt het drempelgetal van punten in de aanvraagnaam in dat, wanneer bereikt, wordt beschouwd als een 'volledige' domeinnaam. Hierover zullen we later meer praten, wanneer we de volgorde van DNS-zoekopdrachten analyseren.

Laten we eens kijken wat er gebeurt wanneer we aanvragen mrkaran.dev in de pod:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

Voor dit experiment heb ik het loggingniveau van CoreDNS ingesteld op all (wat het erg uitvoerig maakt). Laten we naar de logs van de pod kijken coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

Poeh. Twee dingen vallen hier op:

• De aanvraag doorloopt alle fasen van het zoeken totdat het antwoord de code NOERROR (DNS-clients begrijpen dit en slaan het op als resultaat). NXDOMAIN betekent dat voor deze domeinnaam geen record is gevonden. Aangezien mrkaran.dev geen FQDN-naam is (volgens ndots=5), kijkt de resolver naar het zoekpad en bepaalt de volgorde van de aanvragen;
• Records A en AAAA worden parallel verwerkt. Het punt is dat eenmalige aanvragen in /etc/resolv.conf standaard zo zijn ingesteld dat er parallel wordt gezocht via de IPv4 en IPv6 protocollen. Dit gedrag kan worden gewijzigd door de optie single-request in resolv.conf.

Opmerking: glibc te configureren voor sequentiële verzending van deze aanvragen, terwijl musl dat niet kan, dus gebruikers van Alpine moeten hier rekening mee houden.

Experimenteren met ndots

Laten we nog wat experimenteren met ndots en kijken hoe deze parameter zich gedraagt. Het idee is eenvoudig: ndots bepaalde of de DNS-client de domein als absoluut of relatief beschouwt. Hoe weet een eenvoudige Google DNS-client bijvoorbeeld of dit domein absoluut is? Als je ndots gelijk aan 1 stelt, zal de client zeggen: "Oh, er is geen punt; laat me maar door de hele zoeklijst lopen." Maar als je vraagt google , wordt de lijst met suffixen volledig genegeerd omdat de aangevraagde naam aan de drempel voldoet google.com(er is minstens één punt). ndots Laten we dit verifiëren:

$ cat /etc/resolv.conf options ndots:1 $ nslookup mrkaran Server: 10.152.183.10 Address: 10.152.183.10#53** server kan mrkaran niet vinden: NXDOMAIN

Logs van CoreDNS:

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s [INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s [INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s [INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

mrkaran

Aangezien in er is geen punt, de zoekopdracht werd uitgevoerd via de hele suffixlijst. Opmerking: in de praktijk is de maximale waarde

beperkt tot 15; standaard is dit 5 in Kubernetes. ndots Toepassing in productie

Toepassing in productie

Als een applicatie veel externe netwerkverzoeken uitvoert, kan DNS een bottleneck worden bij actieve verkeer, omdat er bij het oplossen van de naam verschillende onnodige verzoeken worden uitgevoerd (voordat het systeem de juiste bereikt). Applicaties voegen doorgaans geen rootzone toe aan domeinnamen, maar dit kan best als een hack worden beschouwd. Dat wil zeggen, in plaats van te vragen api.twitter.com, kunt u ‘hardcode’n api.twitter.com. met een punt) in de applicatie, wat DNS-clients zal aanzetten om een autoritatief zoekopdracht direct in het absolute domein uit te voeren.

Bovendien hebben extensies sinds versie Kubernetes 1.14 de status van stabiel gekregen. Dus bij het implementeren van een pod kan de waarde worden verlaagd tot dnsConfig en dnsPolicy , laten we zeggen, 3 (en zelfs tot 1!). Hierdoor moet elk bericht binnen de knoop het volledige domein bevatten. Dit is een van de klassieke compromissen waarbij je moet kiezen tussen prestaties en draagbaarheid. Ik denk dat je je hier pas echt zorgen over moet maken als extreem lage latencies cruciaal zijn voor je applicatie, omdat DNS-resultaten ook lokaal worden gecached. ndotsIk hoorde voor het eerst over deze functie op de

Links

K8s-meetup , die op 25 januari plaatsvond. Daar werd ook over dit probleem gesproken.Hier zijn een paar links voor verder onderzoek:

, waarom ndots=5 in Kubernetes;

• UitlegGeweldig materiaal
• over hoe de wijziging van ndots invloed heeft op de prestaties van de applicatie; Ongelijkheden
• tussen de resolvers musl en glibc. Opmerking: Ik heb ervoor gekozen om

dig niet in dit artikel te gebruiken. voegt automatisch een punt toe (identificator van de rootzone), waardoor het domein ‘volledig’ (FQDN) wordt, niet in dit artikel te gebruiken. door het vooraf door een zoeklijst te halen. Ik schreef hierover in niet een van mijn eerdere publicaties . Toch is het behoorlijk verrassend dat, over het algemeen, een aparte vlag moet worden ingesteld voor het standaard gedrag.Fijne DNS-ing! Tot ziens!

De app Play Store heeft ondersteuning voor de donkere modus geïntroduceerd

P.S. van de vertaler

Lees ook op onze blog:

• «Calico voor netwerken in Kubernetes: introductie en enkele ervaringen»;
• «CoreDNS - de DNS-server voor de cloud native wereld en Service Discovery voor Kubernetes»;
• «Geïllustreerde handleiding voor netwerkconfiguratie in Kubernetes»: delen 1 en 2 (netwerkmodel, overlay-netwerken), deel 3 (diensten en verkeersverwerking).

Bron: habr.com