Kubernetes дахь DNS хайлт

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

Kubernetes дээр програмуудыг байрлуулах гол давуу талуудын нэг нь програмыг тасралтгүй илрүүлэх явдал юм. Үйлчилгээний үзэл баримтлалын ачаар кластер доторх харилцан үйлчлэл нь ихээхэн хялбаршуулсан (үйлчилгээ), энэ нь олон тооны pod IP хаягуудыг дэмждэг виртуал IP юм. Жишээлбэл, хэрэв үйлчилгээ vanilla үйлчилгээтэй холбогдохыг хүсч байна chocolate, энэ нь виртуал IP руу шууд хандах боломжтой chocolate. Энэ тохиолдолд DNS хүсэлтийг хэн шийдэх вэ гэсэн асуулт гарч ирнэ chocolate Мөн хэрхэн?

DNS нэрийн нарийвчлалыг ашиглан Kubernetes кластер дээр тохируулсан CoreDNS. Кубелет CoreDNS-тэй pod-ыг файлын нэрийн сервер болгон бүртгэдэг /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 - үгүй, тиймээс Альпийн хэрэглэгчид анхааралдаа авах хэрэгтэй.

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 нь идэвхтэй траффикийн үед саад болж болзошгүй, учир нь нэрний нарийвчлал нь олон шаардлагагүй асуулга үүсгэдэг (систем зөв рүү орохоос өмнө). Програмууд нь ихэвчлэн домэйн нэрэнд root бүс нэмдэггүй, гэхдээ энэ нь хакердсан мэт сонсогдож байна. Энэ нь асуухын оронд api.twitter.com, та үүнийг "хатуу кодлох" боломжтой api.twitter.com. (цэгтэй) аппликешнд байгаа бөгөөд энэ нь DNS үйлчлүүлэгчдэд үнэмлэхүй домэйн дээр шууд эрх бүхий хайлт хийхийг уриалах болно.

Нэмж хэлэхэд, Kubernetes 1.14 хувилбараас эхлээд өргөтгөлүүд dnsConfig и dnsPolicy тогтвортой байдлыг хүлээн авсан. Тиймээс, подыг байрлуулахдаа та утгыг бууруулж болно ndots, 3 хүртэл (тэр ч байтугай 1 хүртэл!). Үүнээс болж зангилаа доторх мессеж бүр бүтэн домэйныг агуулсан байх ёстой. Гүйцэтгэл болон зөөвөрлөх чадвар хоёрын аль нэгийг сонгоход энэ бол сонгодог сонголтуудын нэг юм. DNS-ийн үр дүн нь дотооддоо хадгалагддаг тул хэт бага хоцролт нь таны програмд ​​чухал ач холбогдолтой бол энэ талаар санаа зовох хэрэгтэй юм шиг санагдаж байна.

лавлагаа

Би энэ функцийн талаар анх мэдсэн K8s-уулзалт, 25-р сарын XNUMX-нд болсон. Энэ асуудлын талаар ярилцаж байсан.

Энд нэмэлт хайгуул хийх зарим холбоосууд байна:

• Тайлбар, яагаад Кубернетес дэх ndots=5;
• Гайхалтай ажилтан Ndots-ийг өөрчлөх нь програмын гүйцэтгэлд хэрхэн нөлөөлдөг;
• Зөрчил musl болон glibc уусмалуудын хооронд.

Жич: Би ашиглахгүй байхаар сонгосон dig энэ нийтлэлд. dig автоматаар цэг (үндэс бүсийн танигч) нэмж, домэйныг "бүрэн шаардлага хангасан" (FQDN) болгож, үгүй эхлээд хайлтын жагсаалтаар дамжуулан ажиллуулна. Энэ тухай бичжээ өмнөх хэвлэлүүдийн нэг. Гэсэн хэдий ч ерөнхийдөө стандарт зан үйлийн хувьд тусдаа туг зааж өгөх шаардлагатай байгаа нь үнэхээр гайхмаар юм.

Аз жаргалтай DNS! Дараа уулзацгаая!

Орчуулагчийн жич

Мөн манай блог дээрээс уншина уу:

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

Эх сурвалж: www.habr.com