{"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 Kopsiga. Eile, kui uue liikluse sujuv juurutamine meie suurimasse Kubernetes klastrisse k\u00e4is, hakkasin m\u00e4rkama ebatavalisi DNS-i nimetuse lahendamise vigu, mida meie rakendus logis.<\/p>\n

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

GitHubis on sellest juba pikka aega r\u00e4\u00e4gitud<\/a><\/noindex>, seega otsustasin ka ise asja uurida. L\u00f5puks sain aru, et meie puhul on see p\u00f5hjustatud suurenenud koormusest kube-dns<\/code> ja dnsmasq<\/code>. K\u00f5ige huvitavam ja uus minu jaoks oli ise p\u00f5hjus, miks DNS-i p\u00e4ringute liiklus on m\u00e4rgatavalt suurenenud. Sellest ja sellest, mida sellega teha, r\u00e4\u00e4gin oma postituses.<\/p>\n

<\/p>\n

DNS-i lahendamine konteineris \u2014 nagu igas Linuxi s\u00fcsteemis \u2014 m\u00e4\u00e4ratakse konfiguratsioonifailiga \/etc\/resolv.conf<\/code>. Vaikimisi on Kubernetes'i dnsPolicy<\/code> see ClusterFirst<\/code>, mis t\u00e4hendab, et iga DNS-i p\u00e4ring suunatakse v\u00e4lja dnsmasq<\/code>, mis k\u00e4ivitatakse podis kube-dns<\/code> klastris, mis omakorda suunab p\u00e4ringu rakendusse kube-dns<\/code>, kui nimi l\u00f5ppeb klastri sufiksiga, muudel juhtudel aga k\u00f5rgema taseme DNS-serverisse.<\/p>\n

<\/p>\n

Fail \/etc\/resolv.conf<\/code> Iga konteineri sees n\u00e4eb see vaikimisi 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. Tuginedes on m\u00e4\u00e4ratud 4 kohalikku otsingu domeeni search<\/code><\/li>\n
  3. On olemas valik ndots:5<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Huvitav osa sellest konfiguratsioonist on see, kuidas kohalikud otsingu domeenid ja seaded ndots:5<\/code> koos eksisteerivad. Selle m\u00f5istmiseks tuleb aru saada, kuidas DNS-i lahendamine toimib osaliste nimede korral.<\/p>\n
    <\/p>\n
    Mis on t\u00e4ielik nimi?<\/h3>\n
    <\/p>\n
    T\u00e4ielikult m\u00e4\u00e4ratletud nimi on nimi, mille puhul ei toimu kohalikku otsingut ja nime peetakse nime lahendamise ajal absoluutseks. \u00dcheks reegliks on, et DNS-i tarkvara arvab, et nimi on t\u00e4ielikult m\u00e4\u00e4ratletud, kui see l\u00f5peb punktiga (.), ja mitte t\u00e4ielikult m\u00e4\u00e4ratletud muul juhul. 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 t\u00f6\u00f6deldakse osalist nime?<\/h3>\n
    <\/p>\n
    Kui rakendus \u00fchendub kaughostiga, mille nimi on n\u00e4idatud, toimub DNS-i nimetuse lahendamine tavaliselt s\u00fcsteemi kutsumise abil, n\u00e4iteks getaddrinfo()<\/code>. Kui nimi on osaline (ei l\u00f5ppe punktiga), siis huvitav, kas s\u00fcsteemi kutse p\u00fc\u00fcab k\u00f5igepealt lahendada nime absoluutseks v\u00f5i l\u00e4bib esmalt kohalikud otsingudomeenid? See s\u00f5ltub valikust ndots<\/code>.<\/p>\n
    <\/p>\n
    K\u00e4iguteabe p\u00f5hjal resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\nseabub seadistab piirv\u00e4\u00e4rtuse, kui palju punkte peab nimes olema, enne kui tehakse algne absoluutne p\u00e4ring. Vaikev\u00e4\u00e4rtus n on 1, mis t\u00e4hendab, et kui nime sees on \u00fcldse punkte, proovib s\u00fcsteem k\u00f5igepealt seda absoluutse nimega, enne kui sellele lisatakse mingeid otsingulisti elemente.<\/code><\/pre>\n
    <\/p>\n
    See t\u00e4hendab, et kui ndots<\/code> on m\u00e4\u00e4ratud v\u00e4\u00e4rtuseks 5 ja nimi sisaldab v\u00e4hem kui 5 punkti, proovib s\u00fcsteemikutse seda j\u00e4rjestikku lahendada, alustades k\u00f5igist kohalikest otsingudomeenidest ja vajadusel lahendab selle l\u00f5puks absoluutse nimega.<\/p>\n
    <\/p>\n
    Miks ndots:5<\/code> v\u00f5ib negatiivselt m\u00f5jutada rakenduse j\u00f5udlust?<\/h3>\n
    <\/p>\n
    Kuidas te teate, kui teie rakendus kasutab palju v\u00e4list liiklust, teeb iga uue TCP-\u00fchenduse (v\u00f5i t\u00e4psemalt, iga lahendatud nime) see 5 DNS-p\u00e4ringut enne, kui nimi on \u00f5igesti lahendatud, kuna see l\u00e4bib k\u00f5igepealt 4 kohalikku otsingudomeeni ja l\u00f5puks annab absoluutse nime lahendamise p\u00e4ringu.<\/p>\n
    <\/p>\n
    J\u00e4rgmises diagrammis on kujutatud meie 3 kube-dns mooduli koguliiklust enne ja p\u00e4rast seda, kui me l\u00fclitasime mitu meie rakenduses seadistatud hostinime t\u00e4ielikult m\u00e4\u00e4ratletud nimele.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    J\u00e4rgmises diagrammis on kujutatud rakenduse viivitust enne ja p\u00e4rast seda, kui me l\u00fclitasime mitu meie rakenduses seadistatud hostinime t\u00e4ielikult m\u00e4\u00e4ratletud nimele (vertikaalne sinine joon on juurutamine):<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Lahendus #1 - kasutada t\u00e4ielikult m\u00e4\u00e4ratud nimesid<\/h3>\n
    <\/p>\n
    Kui teil on v\u00e4he staatilisi v\u00e4liseid nimesid (st, mis on m\u00e4\u00e4ratud rakenduse konfiguratsioonis), millele teete palju \u00fchendusi, siis v\u00f5ib k\u00f5ige lihtsam lahendus olla l\u00fclitada need t\u00e4ielikult m\u00e4\u00e4ratletud nimele, lihtsalt lisades. l\u00f5puks.<\/p>\n
    <\/p>\n
    See ei ole l\u00f5plik lahendus, kuid aitab kiiresti, kuigi mitte puhtalt, olukorda parandada. Seda plaanime rakendasime meie probleemi lahendamiseks, mille tulemused on n\u00e4idatud \u00fclaltoodud ekraanipiltides.<\/p>\n
    <\/p>\n
    Lahendus #2 - kohandamine ndots<\/code> ja dnsConfig<\/code><\/h3>\n
    <\/p>\n
    Kubernetes 1.9 alfas re\u017eiimis, alates beta-versioonist v1.10, ilmus funktsionaalsus, mis v\u00f5imaldab paremini kontrollida DNS-i parameetreid podi omaduste kaudu dnsConfig<\/code>. Muuhulgas v\u00f5imaldab see m\u00e4\u00e4rata v\u00e4\u00e4rtuse ndots<\/code> konkreetse podi jaoks, 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