{"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\/da\/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

For ikke s\u00e5 l\u00e6nge siden lancerede vi Kubernetes 1.9 p\u00e5 AWS ved hj\u00e6lp af Kops. I g\u00e5r, under en bl\u00f8d udrulning af ny trafik til den st\u00f8rste af vores Kubernetes-klynger, begyndte jeg at bem\u00e6rke us\u00e6dvanlige DNS-navn opl\u00f8sning fejl, der blev logget af vores applikation.<\/p>\n

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

Der har v\u00e6ret en del snak om dette p\u00e5 GitHub i et stykke tid s\u00e5 jeg besluttede mig ogs\u00e5 for at unders\u00f8ge sagen. Jeg fandt ud af, at det i vores tilf\u00e6lde skyldtes en h\u00f8j belastning p\u00e5<\/a><\/noindex>. Det mest interessante og nye for mig var selve \u00e5rsagen til den markante stigning i trafik af DNS-foresp\u00f8rgsler. Dette, samt hvad man skal g\u00f8re ved det, er emnet for mit indl\u00e6g. kube-dns<\/code> og dnsmasq<\/code>Opl\u00f8sning af DNS inden i containere \u2013 ligesom i ethvert Linux-system \u2013 bestemmes af konfigurationsfilen<\/p>\n

<\/p>\n

. Som standard er Kubernetes \/etc\/resolv.conf<\/code>ClusterFirst dnsPolicy<\/code> dette , hvilket betyder, at enhver DNS-foresp\u00f8rgsel vil blive omdirigeret til<\/code>, som k\u00f8rer i en pod dnsmasq<\/code>inden for klyngen, som igen vil omdirigere foresp\u00f8rgslen til applikationen kube-dns<\/code> , hvis navnet slutter med klynge-suffikset, eller ellers til en h\u00f8jere niveau DNS-server. kube-dns<\/code>Inden i hver container vil det som standard se s\u00e5dan ud:<\/p>\n

<\/p>\n

Fil \/etc\/resolv.conf<\/code> nameserver 100.64.0.10\nsearch namespace.svc.cluster.local svc.cluster.local cluster.local \neu-west-1.compute.internal\noptions ndots:5<\/p>\n

<\/p>\n

Som man kan se, her er der tre direktiver:<\/code><\/pre>\n
<\/p>\n
Navneserver \u2013 dette er IP\u2019en for servicen<\/p>\n
<\/p>\n
    \n
  1. Der er angivet 4 lokale s\u00f8gedom\u00e6ner kube-dns<\/code><\/li>\n
  2. Der er en mulighed search<\/code><\/li>\n
  3. ndots:5 En interessant del af denne konfiguration er, hvordan lokale s\u00f8gedom\u00e6ner og indstillinger<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    lever sammen. For at forst\u00e5 dette, skal man f\u00f8rst forst\u00e5, hvordan DNS-oplevelsen fungerer for ufuldst\u00e6ndige navne. En interessant del af denne konfiguration er, hvordan lokale s\u00f8gedom\u00e6ner og indstillinger<\/code> Hvad er et fuldt navn?<\/p>\n
    <\/p>\n
    Et helt kvalificeret navn er et navn, for hvilket der ikke vil blive udf\u00f8rt lokal s\u00f8gning, og navnet vil blive betragtet som absolut under opl\u00f8sning af navne. Efter aftale anser DNS-software et navn som fuldt kvalificeret, hvis det slutter med et punktum (.), og ikke fuldt kvalificeret ellers. Det vil sige<\/h3>\n
    <\/p>\n
    er fuldt kvalificeret, men google.com.<\/code> er ikke. google.com<\/code> Hvordan h\u00e5ndteres et ufuldst\u00e6ndigt navn? <\/p>\n
    <\/p>\n
    N\u00e5r applikationen forbinder til en ekstern v\u00e6rt, der er angivet i navnet, udf\u00f8res navneopl\u00f8sning normalt via et systemkald, s\u00e5som<\/h3>\n
    <\/p>\n
    getaddrinfo() . Men hvis navnet er ufuldst\u00e6ndigt (ikke slutter p\u00e5 .), er det interessant, om systemkaldet f\u00f8rst vil fors\u00f8ge at opl\u00f8se navnet som absolut, eller om det f\u00f8rst vil g\u00e5 gennem de lokale s\u00f8gedom\u00e6ner? Det afh\u00e6nger af indstillingen<\/code>Fra manualen om ndots<\/code>.<\/p>\n
    <\/p>\n
    Fra manualen om resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\ns\u00e6tter gr\u00e6nsen for antallet af punkter, der skal v\u00e6re i navnet, f\u00f8r der foretages en initial absolut anmodning. Standardv\u00e6rdien for n er 1, hvilket betyder, at hvis der er nogen punkter i navnet, vil navnet f\u00f8rst blive pr\u00f8vet som et absolut navn, f\u00f8r der tilf\u00f8jes nogen elementer fra s\u00f8gelisten.<\/code><\/pre>\n
    <\/p>\n
    Det betyder, at hvis der ndots<\/code> er angivet en v\u00e6rdi p\u00e5 5, og navnet indeholder mindre end 5 punkter, vil systemopkaldet fors\u00f8ge at opl\u00f8se det sekventielt, f\u00f8rst ved at g\u00e5 gennem alle lokale s\u00f8gedom\u00e6ner, og i tilf\u00e6lde af fejlslag vil det til sidst opl\u00f8se det som et absolut navn.<\/p>\n
    <\/p>\n
    Hvorfor kan En interessant del af denne konfiguration er, hvordan lokale s\u00f8gedom\u00e6ner og indstillinger<\/code> det negativt p\u00e5virke applikationens ydeevne?<\/h3>\n
    <\/p>\n
    Som du forst\u00e5r, hvis din applikation bruger meget ekstern trafik, vil den for hver etableret TCP-forbindelse (eller mere pr\u00e6cist for hvert opl\u00f8st navn) generere 5 DNS-anmodninger, f\u00f8r navnet bliver korrekt opl\u00f8st, fordi den f\u00f8rst vil g\u00e5 gennem 4 lokale s\u00f8gedom\u00e6ner og til sidst generere en anmodning om opl\u00f8sning af det absolutte navn.<\/p>\n
    <\/p>\n
    I det f\u00f8lgende diagram vises den samlede trafik p\u00e5 vores 3 kube-dns moduler f\u00f8r og efter, at vi skiftede flere v\u00e6rt-navne, der var konfigureret i vores applikation, til fuldt kvalificerede.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    I det f\u00f8lgende diagram vises forsinkelsen i applikationen f\u00f8r og efter, at vi skiftede flere v\u00e6rt-navne, der var konfigureret i vores applikation, til fuldt kvalificerede (den lodrette bl\u00e5 linje er implementeringen):<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    L\u00f8sning #1 \u2014 brug af fuldt kvalificerede navne<\/h3>\n
    <\/p>\n
    Hvis du har f\u00e5 statiske eksterne navne (dvs. defineret i applikationskonfigurationen), som du opretter et stort antal forbindelser til, kan den nemmeste l\u00f8sning v\u00e6re at skifte dem til fuldt kvalificerede ved blot at tilf\u00f8je. i slutningen.<\/p>\n
    <\/p>\n
    Dette er ikke en endelig l\u00f8sning, men det hj\u00e6lper hurtigt, omend ikke perfekt, med at forbedre situationen. Denne patch anvendte vi til at l\u00f8se vores problem, hvis resultater blev vist p\u00e5 sk\u00e6rmbillederne ovenfor.<\/p>\n
    <\/p>\n
    L\u00f8sning #2 \u2014 tilpasning ndots<\/code> i dnsConfig<\/code><\/h3>\n
    <\/p>\n
    I Kubernetes 1.9 blev der i alpha-tilstand indf\u00f8rt funktionalitet (beta-version v1.10), der giver bedre kontrol over DNS-parametre gennem pod-egenskaber i dnsConfig<\/code>. Blandt andet giver det mulighed for at justere v\u00e6rdien ndots<\/code> for en bestemt pod, dvs.<\/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
    Kilder<\/h3>\n
    <\/p>\n