DNS-zoekopdracht in Kubernetes

Opmerking. vert.: DNS-probleem in Kubernetes, of beter gezegd, parameterinstellingen ndots, is verrassend populair, en nu al Niet de eerste jaar. In een andere notitie over dit onderwerp vertelt de auteur, een DevOps-ingenieur van een groot beursvennootschap in India, op een zeer eenvoudige en beknopte manier over wat nuttig is voor collega's die met Kubernetes werken.

Een van de belangrijkste voordelen van het implementeren van applicaties op Kubernetes is het naadloos ontdekken van applicaties. Interactie tussen clusters wordt sterk vereenvoudigd dankzij het serviceconcept (Service), wat een virtueel IP-adres is dat een reeks pod-IP-adressen ondersteunt. Als de dienst bijvoorbeeld vanilla wil contact opnemen met de dienst chocolate, heeft het rechtstreeks toegang tot het virtuele IP-adres chocolate. De vraag rijst: aan wie zal in dit geval het DNS-verzoek worden opgelost chocolate En hoe?

DNS-naamomzetting wordt geconfigureerd op een Kubernetes-cluster met behulp van KernDNS. Kubelet registreert een pod met CoreDNS als naamserver in bestanden /etc/resolv.conf alle peulen. Als je naar de inhoud kijkt /etc/resolv.conf welke pod dan ook, het zal er ongeveer zo uitzien:

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

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

• naam server: server waarnaar DNS-verzoeken worden verzonden. In ons geval is dit het adres van de CoreDNS-service;
• search: definieert het zoekpad voor een specifiek domein. Het is interessant dat google.com of mrkaran.dev zijn geen FQDN (volledig gekwalificeerde domeinnamen). Volgens de standaardconventie die de meeste DNS-resolvers volgen, worden alleen degenen die eindigen op een punt ".", die de rootzone vertegenwoordigt, beschouwd als volledig gekwalificeerde (FDQN) domeinen. Sommige oplossers kunnen zelf een punt toevoegen. Dus, mrkaran.dev. is de volledig gekwalificeerde domeinnaam (FQDN), en mrkaran.dev - Nee;
• ndots: De meest interessante parameter (dit artikel gaat erover). ndots specificeert het drempelaantal punten in een aanvraagnaam voordat deze wordt beschouwd als een “volledig gekwalificeerde” domeinnaam. We zullen hier later meer over praten als we de DNS-opzoekreeks analyseren.

Laten we eens kijken wat er gebeurt als we erom vragen mrkaran.dev in peul:

$ 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 CoreDNS-logboekniveau ingesteld op all (wat het behoorlijk uitgebreid maakt). Laten we eens kijken naar de logboeken van de pod 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

Opluchting. Twee dingen trekken hier uw aandacht:

• Het verzoek doorloopt alle fasen van de zoekopdracht totdat het antwoord de code bevat NOERROR (DNS-clients begrijpen het en slaan het daarom op). NXDOMAIN betekent dat er geen record is gevonden voor de opgegeven domeinnaam. Omdat de mrkaran.dev is geen FQDN-naam (volgens ndots=5), de oplosser kijkt naar het zoekpad en bepaalt de volgorde van de verzoeken;
• Opnamen А и АААА parallel aankomen. Feit is dat eenmalige verzoeken binnenkomen /etc/resolv.conf Standaard zijn ze zo geconfigureerd dat parallelle zoekopdrachten worden uitgevoerd met behulp van de IPv4- en IPv6-protocollen. U kunt dit gedrag annuleren door de optie toe te voegen single-request в resolv.conf.

Opmerking: glibc kan worden geconfigureerd om deze verzoeken opeenvolgend te verzenden, en musl - nee, dus Alpine-gebruikers moeten er rekening mee houden.

Experimenteren met ndots

Laten we er nog wat mee experimenteren ndots en laten we eens kijken hoe deze parameter zich gedraagt. Het idee is simpel: ndots bepaalt of de DNS-client het domein als absoluut of relatief zal behandelen. Hoe weet een eenvoudige DNS-client van Google bijvoorbeeld of dit domein absoluut is? Als je instelt ndots gelijk is aan 1, zal de cliënt zeggen: "Oh, in google er is geen enkel punt; Ik denk dat ik de hele zoeklijst doorloop.’ Echter, als je het vraagt google.com, wordt de lijst met achtervoegsels volledig genegeerd omdat de gevraagde naam aan de drempel voldoet ndots (er is minstens één punt).

Laten we hier zeker van zijn:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

CoreDNS-logboeken:

[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

Omdat in mrkaran er is geen enkel punt, de zoekopdracht is uitgevoerd over de hele lijst met achtervoegsels.

Let op: in de praktijk de maximale waarde ndots beperkt tot 15; standaard in Kubernetes is dit 5.

Toepassing in productie

Als een applicatie veel externe netwerkoproepen doet, kan DNS een knelpunt worden bij actief verkeer, omdat naamresolutie veel onnodige queries maakt (voordat het systeem de juiste heeft gevonden). Applicaties voegen meestal geen rootzone toe aan domeinnamen, maar dit klinkt als een hack. Dat wil zeggen, in plaats van te vragen api.twitter.com, je kunt het 'hardcoderen' api.twitter.com. (met een punt) in de applicatie, waardoor DNS-clients worden gevraagd gezaghebbende zoekopdrachten rechtstreeks op het absolute domein uit te voeren.

Bovendien, vanaf Kubernetes versie 1.14, extensies dnsConfig и dnsPolicy stabiele status gekregen. Wanneer u een pod implementeert, kunt u de waarde dus verlagen ndots, zeg maar tot 3 (en zelfs tot 1!). Hierdoor zal elk bericht binnen een knooppunt het volledige domein moeten bevatten. Dit is een van de klassieke afwegingen wanneer je moet kiezen tussen prestaties en draagbaarheid. Het lijkt mij dat je je hier alleen zorgen over hoeft te maken als een ultralage latentie essentieel is voor je applicatie, aangezien de DNS-resultaten ook intern in de cache worden opgeslagen.

referenties

Ik hoorde voor het eerst over deze functie op K8s-meetup, gehouden op 25 januari. Er ontstond onder meer discussie over dit probleem.

Hier zijn enkele links voor verdere verkenning:

• toelichting, waarom ndots=5 in Kubernetes;
• Uitstekend materiaal hoe het veranderen van ndots de prestaties van applicaties beïnvloedt;
• Discrepanties tussen musl- en glibc-resolvers.

Opmerking: ik heb ervoor gekozen om het niet te gebruiken dig in dit artikel. dig voegt automatisch een punt toe (rootzone-ID), waardoor het domein "volledig gekwalificeerd" (FQDN) wordt, geen door het eerst door de zoeklijst te laten lopen. Schreef hierover in een van de eerdere publicaties. Het is echter nogal verrassend dat er over het algemeen een aparte vlag moet worden opgegeven voor het standaardgedrag.

Veel DNS-plezier! Doei!

PS van vertaler

Lees ook op onze blog:

• «Calico voor netwerken in Kubernetes: introductie en een beetje ervaring";
• «CoreDNS - DNS-server voor de cloud-native wereld en Service Discovery voor Kubernetes";
• "Een geïllustreerde gids voor netwerken in Kubernetes": deel 1 en 2 (netwerkmodel, overlay-netwerken), deel 3 (diensten en verkeersverwerking).

Bron: www.habr.com