Kubernetesте DNS издөө

Эскертүү. котормо.: Kubernetesтеги DNS көйгөйү, тагыраак айтканда, параметр жөндөөлөрү ndots, таң калыштуу популярдуу жана буга чейин Биринчи эмес жыл. Бул тема боюнча дагы бир эскертүүдө, анын автору, Индиядагы ири брокердик компаниянын DevOps инженери, Kubernetesти иштеткен кесиптештер үчүн эмнелер пайдалуу экендиги жөнүндө абдан жөнөкөй жана кыска сүйлөйт.

Kubernetes'те тиркемелерди жайгаштыруунун негизги артыкчылыктарынын бири - бул тиркемелердин үзгүлтүксүз ачылышы. Кызмат концепциясы аркасында кластер ичиндеги өз ара аракеттенүү абдан жөнөкөйлөштүрүлгөн (кызмат), бул поддон IP даректеринин топтомун колдогон виртуалдык IP. Мисалы, кызмат болсо vanilla кызматы менен байланышкысы келет chocolate, ал үчүн виртуалдык IP түз кире алат chocolate. Суроо туулат: бул учурда DNS өтүнүчүн ким чечет chocolate Анан кандай?

DNS аталышынын чечилиши Kubernetes кластеринде конфигурацияланган CoreDNS. Kubelet файлдардагы ат сервери катары CoreDNS менен подкукту каттайт /etc/resolv.conf бардык кабыктар. Эгер мазмунун карасаңыз /etc/resolv.conf кандайдыр бир подъезд, ал төмөнкүдөй көрүнөт:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

Бул конфигурация сурамдарды DNS серверине жөнөтүү үчүн DNS кардарлары тарабынан колдонулат. Файлда resolv.conf төмөнкү маалыматтарды камтыйт:

• ысым сервери: DNS сурамдары жөнөтүлө турган сервер. Биздин учурда, бул CoreDNS кызматынын дареги;
• издөө: Белгилүү бир домен үчүн издөө жолун аныктайт. Ошол кызык экен google.com же mrkaran.dev FQDN эмес (толук квалификациялуу домендик аталыштар). Көпчүлүк DNS чечүүчүлөрү карманган стандарттуу конвенцияга ылайык, түпкү зонаны билдирген чекит "." менен аяктагандар гана толук квалификациялуу (FDQN) домендери болуп эсептелет. Кээ бир чечүүчү пункттарды өздөрү кошо алышат. Ошентип, mrkaran.dev. толук квалификациялуу домендик аталыш (FQDN) жана mrkaran.dev - Жок;
• ndots: Эң кызыктуу параметр (бул макалада ал жөнүндө). ndots "толук квалификациялуу" домендик аталыш болуп эсептелгенге чейин суроонун аталышындагы чекиттердин босого санын көрсөтөт. Бул тууралуу кийинчерээк DNS издөө ырааттуулугун талдоодо сүйлөшөбүз.

Сураганда эмне болорун карап көрөлү mrkaran.dev капчыкта:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

Бул эксперимент үчүн мен CoreDNS каттоо деңгээлин койдум all (бул аны абдан кенен кылат). Келгиле, поддондун журналдарын карап көрөлү coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

Фу. Бул жерде эки нерсе көңүлүңүздү бурат:

• Сурам жоопко код камтылганга чейин издөөнүн бардык этаптарынан өтөт NOERROR (DNS кардарлары аны түшүнүп, натыйжада сакташат). NXDOMAIN берилген домендик аталыш үчүн эч кандай жазуу табылган жок дегенди билдирет. Себеби mrkaran.dev FQDN аталышы эмес ( ndots=5), чечүүчү издөө жолун карайт жана суроо-талаптардын тартибин аныктайт;
• Жазуулар А и АААА параллелдүү келет. Чындыгында, бир жолку өтүнүчтөр /etc/resolv.conf Демейки боюнча, алар параллелдүү издөөлөр IPv4 жана IPv6 протоколдорунун жардамы менен аткарыла тургандай конфигурацияланган. Сиз опцияны кошуу менен бул жүрүм-турумду жокко чыгара аласыз single-request в resolv.conf.

Эскертүү: glibc бул суроо-талаптарды ырааттуу жөнөтүү үчүн конфигурацияланышы мүмкүн жана musl - жок, ошондуктан Alpine колдонуучулар көңүл бурушу керек.

Ndots менен эксперимент

Келгиле, дагы бир аз эксперимент жасайлы ndots жана бул параметр кандай иштээрин карап көрөлү. Идея жөнөкөй: ndots DNS кардары доменди абсолюттук же салыштырмалуу катары карай турганын аныктайт. Мисалы, жөнөкөй Google DNS кардары үчүн, ал бул домен абсолюттук экенин кантип билет? Эгер орнотсоңуз ndots 1ге барабар болсо, кардар мындай дейт: "Ой, ичинде google бир чекит жок; Мен бүт издөө тизмесин карап чыгам деп ойлойм." Бирок, сурасаңыз google.com, суралган ат босогого туура келгендиктен, суффикстердин тизмеси толугу менен этибарга алынбайт ndots (жок дегенде бир пункт бар).

Буга ынаналы:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

CoreDNS журналдары:

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

Бери mrkaran бир пункт жок, издөө суффикстердин бүт тизмеси боюнча жүргүзүлгөн.

Эскертүү: иш жүзүндө максималдуу маани ndots 15 менен чектелген; демейки боюнча Kubernetesте бул 5.

Өндүрүштө колдонуу

Эгерде тиркеме көп тышкы тармактык чалууларды жасаса, DNS активдүү трафиктин шартында тоскоолдук болуп калышы мүмкүн, анткени аталыштын чечилиши көптөгөн керексиз суроолорду жаратат (система оң жагына жеткенге чейин). Тиркемелер, адатта, домендик аталыштарга тамыр зонасын кошпойт, бирок бул бузук сыяктуу угулат. Башкача айтканда, суроонун ордуна api.twitter.com, сиз аны "катуу код" кыла аласыз api.twitter.com. (чекит менен) тиркемеде, ал DNS кардарларына абсолюттук доменде авторитеттүү издөөлөрдү жасоого түрткү берет.

Андан тышкары, Kubernetes 1.14 версиясынан баштап, кеңейтүүлөр dnsConfig и dnsPolicy туруктуу статусун алган. Ошентип, подсткаларды жайгаштырууда сиз маанини азайта аласыз ndots, айталы, 3кө чейин (жана 1ге чейин!). Ушундан улам, түйүн ичиндеги ар бир билдирүү толук доменди камтышы керек. Бул сиз аткарууну жана көчүрүүнүн ортосунда тандоо керек болгондо классикалык соодалашуунун бири. Менин оюмча, эгерде сиз бул жөнүндө тынчсызданышыңыз керек окшойт, эгерде сиздин тиркемеңиз үчүн өтө төмөн күтүү убакыты маанилүү болсо, анткени DNS натыйжалары да ички кэште сакталган.

шилтемелер

Мен бул өзгөчөлүк жөнүндө биринчи жолу билдим K8s-meetup, 25-январда болгон. Башка маселелер менен катар ушул проблема боюнча да талкуу болду.

Бул жерде кошумча изилдөө үчүн кээ бир шилтемелер:

• Түшүндүрүү, эмне үчүн Kubernetesте ndots = 5;
• сонун нерселер ndotтарды өзгөртүү колдонмонун иштешине кандай таасир этет;
• айырмачылыктар musl жана glibc чечүүчүлөрү ортосунда.

Эскертүү: Мен колдонбоону чечтим dig ушул макалада. dig автоматтык түрдө доменди "толук квалификациялуу" кылып (FQDN) чекит (тамыр зонасы идентификатору) кошот, жок биринчи издөө тизмеси аркылуу аны иштетүү менен. Бул тууралуу жазган мурунку басылмалардын бири. Бирок, жалпысынан, стандарттык жүрүм-турум үчүн өзүнчө желек көрсөтүлүшү керек экендиги таң калыштуу.

Бактылуу DNSing! Көрүшкөнчө!

Котормочудан PS

Биздин блогдон дагы окуңуз:

• «Kubernetes тармагында Calico: киришүү жана бир аз тажрыйба";
• «CoreDNS - булуттун түпкү дүйнөсү үчүн DNS сервери жана Kubernetes үчүн Service Discovery";
• "Kubernetes тармагында иллюстрацияланган колдонмо": 1 жана 2 бөлүктөрү (тармак модели, кабаттуу тармактар), 3-бөлүк (кызматтар жана трафикти иштетүү).

Source: www.habr.com