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

F\u00f6r inte s\u00e5 l\u00e4nge sedan lanserade vi Kubernetes 1.9 p\u00e5 AWS med hj\u00e4lp av Kops. Ig\u00e5r, under en smidig rullning av ny trafik till en av v\u00e5ra st\u00f6rsta Kubernetes-kluster, b\u00f6rjade jag m\u00e4rka ovanliga DNS-namnuppslagningsfel som loggades av v\u00e5r applikation.<\/p>\n

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

P\u00e5 GitHub har detta diskuterats ganska l\u00e4nge och d\u00e4rf\u00f6r best\u00e4mde jag mig ocks\u00e5 f\u00f6r att unders\u00f6ka det. I slut\u00e4ndan ins\u00e5g jag att det i v\u00e5rt fall orsakades av \u00f6kad belastning p\u00e5<\/a><\/noindex>kube-dns. Det mest intressanta och nya f\u00f6r mig var sj\u00e4lva anledningen till den betydande \u00f6kningen av DNS-f\u00f6rfr\u00e5gningar. Om detta och vad man ska g\u00f6ra \u00e5t det handlar mitt inl\u00e4gg.<\/code> och dnsmasq<\/code>DNS-uppl\u00f6sning inuti containern \u2014 precis som i vilket Linux-system som helst \u2014 best\u00e4ms av konfigurationsfilen<\/p>\n

<\/p>\n

. Som standard \u00e4r Kubernetes \/etc\/resolv.conf<\/code>dnsPolicy ClusterFirst<\/code> detta , vilket inneb\u00e4r att varje DNS-f\u00f6rfr\u00e5gan kommer att omdirigeras till<\/code>, som k\u00f6rs i en pod dnsmasq<\/code>inuti klustret, som i sin tur kommer att omdirigera f\u00f6rfr\u00e5gan till applikationen Det mest intressanta och nya f\u00f6r mig var sj\u00e4lva anledningen till den betydande \u00f6kningen av DNS-f\u00f6rfr\u00e5gningar. Om detta och vad man ska g\u00f6ra \u00e5t det handlar mitt inl\u00e4gg.<\/code> , om namnet slutar med klustersuffixet, eller, i annat fall, till DNS-servern p\u00e5 en h\u00f6gre niv\u00e5. Det mest intressanta och nya f\u00f6r mig var sj\u00e4lva anledningen till den betydande \u00f6kningen av DNS-f\u00f6rfr\u00e5gningar. Om detta och vad man ska g\u00f6ra \u00e5t det handlar mitt inl\u00e4gg.<\/code>Inuti varje container kommer det som standard att se ut s\u00e5 h\u00e4r:<\/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 h\u00e4r finns det tre direktiv:<\/code><\/pre>\n
<\/p>\n
Namserver \u2014 detta \u00e4r IP-adressen till tj\u00e4nsten<\/p>\n
<\/p>\n
    \n
  1. Fyra lokala s\u00f6kdom\u00e4ner anges Det mest intressanta och nya f\u00f6r mig var sj\u00e4lva anledningen till den betydande \u00f6kningen av DNS-f\u00f6rfr\u00e5gningar. Om detta och vad man ska g\u00f6ra \u00e5t det handlar mitt inl\u00e4gg.<\/code><\/li>\n
  2. search Det finns en option<\/code><\/li>\n
  3. ndots:5 En intressant del av denna konfiguration \u00e4r hur de lokala s\u00f6kdom\u00e4nerna och inst\u00e4llningarna<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    samexisterar. F\u00f6r att f\u00f6rst\u00e5 detta, m\u00e5ste man reda ut hur DNS-uppl\u00f6sning f\u00f6r ofullst\u00e4ndiga namn fungerar. En intressant del av denna konfiguration \u00e4r hur de lokala s\u00f6kdom\u00e4nerna och inst\u00e4llningarna<\/code> Vad \u00e4r ett fullst\u00e4ndigt namn?<\/p>\n
    <\/p>\n
    Ett fullst\u00e4ndigt angivet namn \u00e4r ett namn f\u00f6r vilket ingen lokal s\u00f6kning kommer att utf\u00f6ras, och namnet kommer att anses vara absolut under namnuppslagningsprocessen. Enligt konventionen anser DNS-programvaran att ett namn \u00e4r fullst\u00e4ndigt angivet om det slutar med en punkt (.), och inte fullst\u00e4ndigt angivet i motsatt fall. Det vill s\u00e4ga<\/h3>\n
    <\/p>\n
    \u00e4r fullst\u00e4ndigt angivet, men google.com.<\/code> \u00e4r det inte. google.com<\/code> Hur hanteras ett ofullst\u00e4ndigt namn? <\/p>\n
    <\/p>\n
    N\u00e4r applikationen kopplar upp sig mot en fj\u00e4rrv\u00e4rd som anges i namnet g\u00f6rs namnuppslagningsprocessen vanligtvis med ett systemanrop, som till exempel<\/h3>\n
    <\/p>\n
    getaddrinfo() . Men om namnet \u00e4r ofullst\u00e4ndigt (inte slutar p\u00e5 .), \u00e4r det intressant om systemanropet f\u00f6rst f\u00f6rs\u00f6ker att l\u00f6sa namnet som absolut, eller f\u00f6rst g\u00e5r igenom de lokala s\u00f6kdom\u00e4nerna? Det beror p\u00e5 optionen<\/code>ndots. Fr\u00e5n manualen f\u00f6r<\/code>.<\/p>\n
    <\/p>\n
    resolv.conf resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\nangerar en gr\u00e4ns f\u00f6r antalet punkter som m\u00e5ste f\u00f6rekomma i namnet innan en initial absolut f\u00f6rfr\u00e5gan g\u00f6rs. Standardv\u00e4rdet f\u00f6r n \u00e4r 1, vilket betyder att om namnet inneh\u00e5ller n\u00e5gra punkter, kommer namnet f\u00f6rst att testas som ett absolut namn innan n\u00e5gra element fr\u00e5n s\u00f6klistan l\u00e4ggs till.<\/code><\/pre>\n
    <\/p>\n
    Detta inneb\u00e4r att om Fr\u00e5n manualen f\u00f6r<\/code> v\u00e4rdet 5 anges och namnet inneh\u00e5ller f\u00e4rre \u00e4n 5 punkter, kommer systemanropet att f\u00f6rs\u00f6ka l\u00f6sa det sekventiellt, f\u00f6rst genom att g\u00e5 igenom alla lokala s\u00f6kdomen, och om det misslyckas, till slut l\u00f6sa det som ett absolut namn.<\/p>\n
    <\/p>\n
    Varf\u00f6r kan En intressant del av denna konfiguration \u00e4r hur de lokala s\u00f6kdom\u00e4nerna och inst\u00e4llningarna<\/code> negativt p\u00e5verka applikationens prestanda?<\/h3>\n
    <\/p>\n
    Som du f\u00f6rst\u00e5r, om din applikation anv\u00e4nder mycket extern trafik, kommer det f\u00f6r varje etablerad TCP-anslutning (eller, mer exakt, f\u00f6r varje l\u00f6st namn) att generera 5 DNS-f\u00f6rfr\u00e5gningar innan namnet korrekt l\u00f6ses, eftersom det f\u00f6rst kommer att g\u00e5 igenom 4 lokala s\u00f6kdomen och i slutet generera en f\u00f6rfr\u00e5gan f\u00f6r att l\u00f6sa det absoluta namnet.<\/p>\n
    <\/p>\n
    I n\u00e4sta diagram visas den totala trafiken p\u00e5 v\u00e5ra 3 kube-dns-moduler f\u00f6re och efter att vi bytte flera v\u00e4rdnamn som konfigurerats i v\u00e5r applikation till helt kvalificerade.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    I n\u00e4sta diagram visas applikationsf\u00f6rdr\u00f6jningen f\u00f6re och efter att vi bytte flera v\u00e4rdnamn som konfigurerats i v\u00e5r applikation till fullst\u00e4ndiga (den vertikala bl\u00e5 linjen \u00e4r distributionen):<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    L\u00f6sning #1 \u2014 anv\u00e4nd helt kvalificerade namn<\/h3>\n
    <\/p>\n
    Om du har f\u00e5 statiska externa namn (dvs. definierade i applikationskonfigurationen) som du g\u00f6r m\u00e5nga anslutningar till, kan den enklaste l\u00f6sningen vara att byta dem till helt kvalificerade genom att bara l\u00e4gga till.<\/p>\n
    <\/p>\n
    Detta \u00e4r ingen definitiv l\u00f6sning, men det hj\u00e4lper snabbt, om \u00e4n inte rent, att f\u00f6rb\u00e4ttra situationen. Denna patch till\u00e4mpade vi f\u00f6r att l\u00f6sa v\u00e5rt problem, vars resultat visades p\u00e5 sk\u00e4rmdumparna ovan.<\/p>\n
    <\/p>\n
    L\u00f6sning #2 \u2014 Anpassning av Fr\u00e5n manualen f\u00f6r<\/code> p\u00e5 dnsConfig<\/code><\/h3>\n
    <\/p>\n
    I Kubernetes 1.9 introducerades en funktion i alfa-l\u00e4ge (beta-version v1.10) som g\u00f6r det m\u00f6jligt att b\u00e4ttre styra DNS-parametrarna genom pod-egenskapen i dnsConfig<\/code>. Bland annat till\u00e5ter den att konfigurera v\u00e4rdet Fr\u00e5n manualen f\u00f6r<\/code> f\u00f6r en specifik pod, d.v.s.<\/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
    K\u00e4llor<\/h3>\n
    <\/p>\n