{"id":37372,"date":"2019-10-31T22:17:16","date_gmt":"2019-10-31T19:17:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya\/"},"modified":"2019-10-31T22:17:16","modified_gmt":"2019-10-31T19:17:16","slug":"etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya","title":{"rendered":"\/etc\/resolv.conf \u0434\u043b\u044f Kubernetes pods, \u043e\u043f\u0446\u0438\u044f ndots:5, \u043a\u0430\u043a \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u043d\u0435\u0433\u0430\u0442\u0438\u0432\u043d\u043e \u0441\u043a\u0430\u0437\u0430\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\/etc\/resolv.conf<\/p>\n

<\/p>\n

Onlangs hebben we Kubernetes 1.9 op AWS gelanceerd met behulp van Kops. Gisteren, tijdens een geleidelijke uitrol van nieuwe verkeer naar een van onze grootste Kubernetes-clusters, begon ik ongebruikelijke DNS-resolutiefouten op te merken die door onze applicatie werden gelogd.<\/p>\n

<\/a><\/noindex><\/p>\n

Dit is al een tijdje op GitHub besproken<\/a><\/noindex>, dus besloot ik ook het uit te zoeken. Uiteindelijk ontdekte ik dat dit in ons geval werd veroorzaakt door een verhoogde belasting op kube-dns<\/code> en dnsmasq<\/code>. Het meest interessante en nieuwe voor mij was de oorzaak van de aanzienlijke toename van DNS-verkeer. Daarover en wat we daaraan kunnen doen, gaat mijn post.<\/p>\n

<\/p>\n

De DNS-resolutie binnen een container - net als in elk Linux-systeem - wordt bepaald door een configuratiebestand \/etc\/resolv.conf<\/code>. Standaard heeft Kubernetes dnsPolicy<\/code> het ClusterFirst<\/code>, wat betekent dat elk DNS-verzoek wordt doorgestuurd naar dnsmasq<\/code>, dat binnen de pod is gestart kube-dns<\/code> in de cluster, dat het verzoek vervolgens zal doorsturen naar de applicatie kube-dns<\/code>, als de naam eindigt op de clustersuffix, of anders naar een hoger gelegen DNS-server.<\/p>\n

<\/p>\n

Bestand \/etc\/resolv.conf<\/code> Binnen elke container ziet het standaard er als volgt uit:<\/p>\n

<\/p>\n

nameserver 100.64.0.10\nsearch namespace.svc.cluster.local svc.cluster.local cluster.local \neu-west-1.compute.internal\noptions ndots:5<\/code><\/pre>\n
<\/p>\n
Zoals te zien is, zijn er drie richtlijnen:<\/p>\n
<\/p>\n
    \n
  1. De naamserver is het IP-adres van de service kube-dns<\/code><\/li>\n
  2. Er zijn 4 lokale zoekdomeinen opgegeven search<\/code><\/li>\n
  3. Er is een optie ndots:5<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Een interessant aspect van deze configuratie is hoe de lokale zoekdomeinen en instellingen ndots:5<\/code> samenleven. Om dit te begrijpen, is het nodig om te begrijpen hoe DNS-resolutie voor onvolledige namen werkt.<\/p>\n
    <\/p>\n
    Wat is een volledig naam?<\/h3>\n
    <\/p>\n
    Een volledig gekwalificeerde naam is een naam waarvoor geen lokale zoekopdracht wordt uitgevoerd, en de naam wordt als absoluut beschouwd tijdens de naamresolutie. Volgens afspraak beschouwt DNS-software een naam als volledig gekwalificeerd als deze eindigt op een punt (.), En als niet volledig gekwalificeerd in andere gevallen. Dat wil zeggen, google.com.<\/code> is volledig gekwalificeerd, en google.com<\/code> is dat niet. <\/p>\n
    <\/p>\n
    Hoe wordt een onvolledige naam verwerkt?<\/h3>\n
    <\/p>\n
    Wanneer een applicatie verbinding maakt met een externe host die in de naam is opgegeven, wordt de DNS-resolutie meestal uitgevoerd met een systeemaanroep, zoals getaddrinfo()<\/code>. Maar als de naam onvolledig is (niet eindigend op .), is het interessant of de systeemaanroep eerst zal proberen de naam als absoluut op te lossen, of dat deze eerst door de lokale zoekdomeinen gaat? Dit hangt af van de optie ndots<\/code>.<\/p>\n
    <\/p>\n
    Uit de handleiding voor resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\nstelt de drempel in voor het aantal punten dat in de naam moet verschijnen voordat er een initi\u00eble absolute aanvraag wordt gedaan. De standaardwaarde voor n is 1, wat betekent dat als er enige punten in de naam staan, de naam eerst als absolute naam wordt geprobeerd voordat er elementen van de zoeklijst aan worden toegevoegd.<\/code><\/pre>\n
    <\/p>\n
    Dit betekent dat als voor ndots<\/code> de waarde 5 is ingesteld en de naam minder dan 5 punten bevat, de systeembel wordt geprobeerd deze opeenvolgend te resolven, eerst door alle lokale zoekdomeinen en, in geval van mislukking, uiteindelijk als absolute naam.<\/p>\n
    <\/p>\n
    Waarom kan ndots:5<\/code> een negatieve impact hebben op de prestaties van de applicatie?<\/h3>\n
    <\/p>\n
    Zoals u begrijpt, als uw applicatie veel extern verkeer gebruikt, zal voor elke TCP-verbinding die is ingesteld (of, nauwkeuriger, voor elke opgeloste naam) het 5 DNS-verzoeken genereren voordat de naam correct wordt opgelost, omdat het eerst door 4 lokale zoekdomeinen gaat en uiteindelijk een verzoek voor de oplossing van de absolute naam genereert.<\/p>\n
    <\/p>\n
    In het volgende diagram wordt het totale verkeer op onze 3 kube-dns-modules weergegeven voor en na het schakelen van een aantal hostnamen die in onze applicatie zijn ingesteld naar volledig gedefinieerde namen.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    In het volgende diagram wordt de vertraging van de applicatie weergegeven voor en na het schakelen van een aantal hostnamen die in onze applicatie zijn ingesteld naar volledige namen (de verticale blauwe lijn is de implementatie):<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Oplossing #1 - gebruik volledig gedefinieerde namen<\/h3>\n
    <\/p>\n
    Als u weinig statische externe namen heeft (d.w.z. gedefinieerd in de applicatieconfiguratie) waar u een groot aantal verbindingen mee maakt, is het mogelijk de eenvoudigste oplossing om ze op volledig gedefinieerd te schakelen door gewoon aan het einde toe te voegen.<\/p>\n
    <\/p>\n
    Dit is geen definitieve oplossing, maar helpt snel, zij het niet perfect, om de situatie te verbeteren. Deze patch hebben we toegepast om ons probleem op te lossen, waarvan de resultaten in de bovenstaande screenshots zijn weergegeven.<\/p>\n
    <\/p>\n
    Oplossing #2 - maatwerk ndots<\/code> in dnsConfig<\/code><\/h3>\n
    <\/p>\n
    In Kubernetes 1.9 werd er in alpha-modus functionaliteit ge\u00efntroduceerd (beta-versie v1.10), die beter controle biedt over de DNS-instellingen via de pod-eigenschap in dnsConfig<\/code>. Onder andere stelt het in staat om de waarde ndots<\/code> voor een specifieke pod in te stellen, d.w.z.<\/p>\n
    <\/p>\n
    apiVersion: v1\nkind: Pod\nmetadata:\n  namespace: default\n  name: dns-example\nspec:\n  containers:\n    - name: test\n      image: nginx\n  dnsConfig:\n    options:\n      - name: ndots\n        value: \"1\"<\/code><\/pre>\n
    <\/p>\n
    Bronnen<\/h3>\n
    <\/p>\n