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

Hiljuti k\u00e4ivitasime Kubernetes 1.9 AWS-is Kopsi abil. Eile, kui jagasime uut liiklust meie suurimasse Kubernetes klastrisse, hakkasin m\u00e4rkama ebatavalisi DNS-i nimede lahendamise vigu, mida meie rakendus logis.<\/p>\n

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

GitHubis on sellest juba pikemat aega kirjutatud kuidas ettev\u00f5tted saavad kaitsta oma v\u00f5rgustikku, kui suur osa t\u00f6\u00f6tajatest t\u00f6\u00f6tab kaugt\u00f6\u00f6 vormis ja<\/a><\/noindex>, seega otsustasin ka ise s\u00fcveneda. Selgus, et meie juhul p\u00f5hjustas selle k\u00f5rgenenud koormus kube-dns<\/code> ja dnsmasq<\/code>. K\u00f5ige huvitavam ja uutmoodi mulle oli p\u00f5hjus, miks DNS-i p\u00e4ringute liiklus oluliselt suurenes. Siin on minu postitus sellest ja sellest, mida sellega ette v\u00f5tta.<\/p>\n

<\/p>\n

DNS-i lahendamine konteineris \u2014 nagu igas Linuxi s\u00fcsteemis \u2014 m\u00e4\u00e4ratakse konfigureerimisfailiga \/etc\/resolv.conf<\/code>. Vaikimisi on Kubernetes dnsPolicy<\/code> see ClusterFirst<\/code>, mis t\u00e4hendab, et k\u00f5ik DNS-i p\u00e4ringud suunatakse dnsmasq<\/code>konteinerisse, kube-dns<\/code> mis omakorda suunab p\u00e4ringu rakendusele kube-dns<\/code>, kui nimi l\u00f5peb klastrisufiksiga, v\u00f5i muul juhul k\u00f5rgema taseme DNS serverisse.<\/p>\n

<\/p>\n

File \/etc\/resolv.conf<\/code> Iga konteineri sees n\u00e4eb vaikev\u00e4\u00e4rtus v\u00e4lja niimoodi:<\/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
Nagu n\u00e4ha, on siin kolm direktiivi:<\/p>\n
<\/p>\n
    \n
  1. Nimiserver on teenuse IP. kube-dns<\/code><\/li>\n
  2. M\u00e4\u00e4ratud on 4 kohaliku otsingu domeeni. search<\/code><\/li>\n
  3. Saadaval on valik. ndots:5<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Selle seadistuse huvitav osa on selles, kuidas kohalikud otsingud domeenid ja seaded. ndots:5<\/code> koos eksisteerivad. Selleks, et seda m\u00f5ista, tuleb selgeks teha, kuidas DNS-i lahendamine t\u00f6\u00f6tab mittet\u00e4ielike nimede puhul.<\/p>\n
    <\/p>\n
    Mis on t\u00e4ielik nimi?<\/h3>\n
    <\/p>\n
    T\u00e4ielikult m\u00e4\u00e4ratletud nimi on nimi, mille korral kohalikku otsingut ei tehta ja nime peetakse resolutsiooni ajal absoluutseks. Nime peetakse t\u00e4ielikult m\u00e4\u00e4ratletuks, kui see l\u00f5ppeb punktiga (.), ja mitte t\u00e4ielikult m\u00e4\u00e4ratletuks muidu. See t\u00e4hendab, et google.com.<\/code> on t\u00e4ielikult m\u00e4\u00e4ratletud, aga google.com<\/code> \u2014 ei ole. <\/p>\n
    <\/p>\n
    Kuidas k\u00e4sitletakse mittet\u00e4ielikku nime?<\/h3>\n
    <\/p>\n
    Kui rakendus \u00fchendub kaughostiga, mille on m\u00e4\u00e4ranud nimi, toimub DNS-i nime lahendamine tavaliselt s\u00fcsteemi kutse abil, n\u00e4iteks getaddrinfo()<\/code>. Kui nimi on mittet\u00e4ielik (ei l\u00f5pe .-ga), on huvitav, kas s\u00fcsteemikutse proovib alguses lahendada nime absoluutseks v\u00f5i l\u00e4bib esmalt kohalikud otsingud domeenid? See s\u00f5ltub valikust. ndots<\/code>.<\/p>\n
    <\/p>\n
    K\u00e4esolevast manuaalist resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\nm\u00e4\u00e4rab k\u00fcnnise punktide arvu jaoks, mis peavad nime ilmuma, enne kui tehakse algne absoluutne p\u00e4ring. Vaikev\u00e4\u00e4rtus n on 1, mis t\u00e4hendab, et kui nimes on mingeid punkte, proovib s\u00fcsteem esialgu nime absoluutse nimega, enne kui sellele lisatakse loendiotsingu elemente.<\/code><\/pre>\n
    <\/p>\n
    See t\u00e4hendab, et kui ndots<\/code> on m\u00e4\u00e4ratud v\u00e4\u00e4rtus 5 ja nimi sisaldab v\u00e4hem kui 5 punkti, siis s\u00fcsteemik\u00f5ne p\u00fc\u00fcab seda j\u00e4rjestikku lahendada, liikudes esmalt l\u00e4bi k\u00f5ikidele kohalikele otsingudomeenidele ning vajadusel lahendab l\u00f5puks selle absoluutse nimega.<\/p>\n
    <\/p>\n
    Kuidas see ndots:5<\/code> v\u00f5ib negatiivselt m\u00f5jutada rakenduse j\u00f5udlust?<\/h3>\n
    <\/p>\n
    Kuidas te m\u00f5istate, kui teie rakendus kasutab palju v\u00e4list liiklust, iga kehtestatud TCP-\u00fchenduse (v\u00f5i t\u00e4psemalt, iga lahendatud nime) korral andke 5 DNS-p\u00e4ringut, enne kui nimi \u00f5igesti lahendatakse, kuna see l\u00e4heb esmalt l\u00e4bi 4 kohaliku otsingudomeeni ja l\u00f5puks esitab absoluutse nime lahendamise p\u00e4ringu.<\/p>\n
    <\/p>\n
    J\u00e4rgmine diagramm n\u00e4itab meie kolme kube-dns mooduli koguliiklust enne ja p\u00e4rast seda, kui me l\u00fclitasime mitmed meie rakenduses m\u00e4\u00e4ratud hostinimed t\u00e4ielikult m\u00e4\u00e4ratletud nimedele.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    J\u00e4rgmine diagramm n\u00e4itab rakenduse latentsust enne ja p\u00e4rast seda, kui me l\u00fclitasime mitmed meie rakenduses m\u00e4\u00e4ratud hostinimed t\u00e4ielikult m\u00e4\u00e4ratletud nimedele (vertikaalne sinine joon t\u00e4histab juurutamist):<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Lahendus #1 \u2014 kasutada t\u00e4ielikult m\u00e4\u00e4ratletud nimesid<\/h3>\n
    <\/p>\n
    Kui teil on v\u00e4he staatilisi v\u00e4liseid nimesid (st rakenduse konfiguratsioonis m\u00e4\u00e4ratud), millele te loote palju \u00fchendusi, v\u00f5ib k\u00f5ige lihtsam lahendus olla l\u00fclitamine t\u00e4ielikult m\u00e4\u00e4ratletud nimedele, lisades lihtsalt l\u00f5ppu.<\/p>\n
    <\/p>\n
    See ei ole l\u00f5plik lahendus, kuid see aitab kiiresti, kuigi mitte puhtalt, olukorda parandada. Seda plaastrit kasutasime oma probleemi lahendamiseks, mille tulemused on n\u00e4idatud \u00fclaltoodud ekraanipiltidel.<\/p>\n
    <\/p>\n
    Lahendus #2 \u2014 kohandamine ndots<\/code> \u00fches dnsConfig<\/code><\/h3>\n
    <\/p>\n
    Kubernetes 1.9-s tutvustati alfa re\u017eiimis funktsionaalsust (beta versioon v1.10), mis v\u00f5imaldab paremat DNS-i parameetrite kontrollimist podi omaduse kaudu. dnsConfig<\/code>. Muuhulgas v\u00f5imaldab see m\u00e4\u00e4rata v\u00e4\u00e4rtuse ndots<\/code> konkreetse poodi, st.<\/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
    Allikad<\/h3>\n
    <\/p>\n