Noat. transl.: DNS-probleem yn Kubernetes, of krekter, parameterynstellingen ndots, is ferrassend populêr, en al . Yn in oare notysje oer dit ûnderwerp fertelt har skriuwer, in DevOps-yngenieur fan in grut makelderbedriuw yn Yndia, op in heul ienfâldige en beknopte manier oer wat nuttich is foar kollega's dy't Kubernetes operearje om te witten.
Ien fan 'e wichtichste foardielen fan it ynsetten fan applikaasjes op Kubernetes is naadleaze ûntdekking fan applikaasjes. Yntra-cluster ynteraksje wurdt sterk ferienfâldige tank oan it tsjinst konsept (), dat is in firtuele IP dy't in set fan pod-IP-adressen stipet. Bygelyks, as de tsjinst vanilla wol kontakt opnimme mei de tsjinst chocolate, It kin direkt tagong ta de firtuele IP foar chocolate. De fraach ûntstiet: wa sil yn dit gefal it DNS-fersyk oplosse chocolate En hoe?
DNS-nammeresolúsje is konfigureare op in Kubernetes-kluster mei . Kubelet registrearret in pod mei CoreDNS as nammetsjinner yn bestannen /etc/resolv.conf alle poddestuollen. As jo sjogge nei de ynhâld /etc/resolv.conf elke pod, it sil der sa útsjen:
search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5
Dizze konfiguraasje wurdt brûkt troch DNS-kliïnten om fersiken troch te stjoeren nei de DNS-tsjinner. Yn triem resolv.conf befettet de folgjende ynformaasje:
- nammetsjinner: tsjinner dêr't DNS-oanfragen nei stjoerd wurde. Yn ús gefal is dit it adres fan 'e CoreDNS-tsjinst;
- sykje: Beskiedt it sykpaad foar in spesifyk domein. It is nijsgjirrich dat
google.comofmrkaran.devbinne net FQDN (). Neffens de standertkonvinsje dy't de measte DNS-resolvers folgje, wurde allinich dejingen dy't einigje mei in punt ".", dy't de rootsône fertsjintwurdigje, beskôge as folslein kwalifisearre (FDQN) domeinen. Guon resolvers kinne sels in punt tafoegje. Dus,mrkaran.dev.is de folslein kwalifisearre domeinnamme (FQDN), enmrkaran.dev- Nee; - ndots: De meast nijsgjirrige parameter (dit artikel giet deroer).
ndotsspesifisearret it drompel oantal punten yn in fersyknamme foardat it wurdt beskôge as in "folslein kwalifisearre" domeinnamme. Wy sille letter mear oer prate as wy de DNS-opsyksekwinsje analysearje.
Litte wy sjen wat der bart as wy freegje mrkaran.dev yn pod:
$ 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
Foar dit eksperimint haw ik it CoreDNS-loggingnivo ynsteld op all (wat makket it frij verbose). Litte wy nei de logboeken fan 'e pod sjen 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.145091744sPff. Twa dingen fange jo oandacht hjir:
- It fersyk giet troch alle stadia fan it sykjen oant it antwurd de koade befettet
NOERROR(DNS-kliïnten begripe it en bewarje it as gefolch).NXDOMAINbetsjut dat der gjin record waard fûn foar de opjûne domeinnamme. Fanwege demrkaran.devis gjin FQDN-namme (neffensndots=5), resolver sjocht nei it sykpaad en bepaalt de folchoarder fan oanfragen; - Berjochten
АиААААparallel oankomme. It feit is dat ienmalige fersiken yn/etc/resolv.confStandert binne se op sa'n manier konfigurearre dat parallelle sykopdrachten wurde útfierd mei de IPv4- en IPv6-protokollen. Jo kinne dit gedrach annulearje troch de opsje ta te foegjensingle-requestвresolv.conf.
Tink derom: glibc kin ynsteld wurde om dizze fersiken sequentially te stjoeren, en musl - nee, dus Alpine-brûkers moatte der rekken mei hâlde.
Eksperimintearjen mei ndots
Litte wy in bytsje mear eksperimintearje mei ndots en lit ús sjen hoe't dizze parameter gedraacht. It idee is ienfâldich: ndots bepaalt oft de DNS-kliïnt it domein as absolút of relatyf behannelje sil. Bygelyks, yn it gefal fan in ienfâldige google DNS-kliïnt, hoe wit it as dit domein absolút is? As jo ynstelle ndots lyk oan 1, sil de kliïnt sizze: "Oh, yn google der is gjin inkeld punt; Ik tink dat ik troch de hiele syklist sil gean." Lykwols, as jo freegje google.com, sil de list mei efterheaksels folslein negearre wurde, om't de frege namme oan de drompel foldocht ndots (der is op syn minst ien punt).
Litte wy der wis fan wêze:
$ 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: NXDOMAINCoreDNS logs:
[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
Sûnt yn mrkaran der is gjin inkeld punt, it sykjen waard útfierd oer de hiele list fan efterheaksels.
Opmerking: yn 'e praktyk de maksimale wearde ndots beheind ta 15; standert yn Kubernetes is it 5.
Applikaasje yn produksje
As in applikaasje in protte eksterne netwurkopropen makket, kin DNS in knelpunt wurde yn it gefal fan aktyf ferkear, om't nammeresolúsje in protte ûnnedige fragen makket (foardat it systeem nei de juste komt). Applikaasjes foegje normaal gjin rootsône ta oan domeinnammen, mar dit klinkt as in hack. Dat is, ynstee fan freegjen api.twitter.com, Jo kinne hardcode api.twitter.com. (mei in punt) yn 'e applikaasje, dy't DNS-kliïnten sil freegje om autoritative opsykjen direkt op it absolute domein út te fieren.
Derneist, begjinnend mei Kubernetes ferzje 1.14, útwreidingen dnsConfig и dnsPolicy krige stabile status. Sa kinne jo by it ynsetten fan in pod de wearde ferminderje ndots, sizze, oant 3 (en sels oant 1!). Hjirtroch sil elk berjocht binnen in knooppunt it folsleine domein moatte befetsje. Dit is ien fan 'e klassike trade-offs as jo moatte kieze tusken prestaasjes en portabiliteit. It liket my dat jo allinich soargen moatte oer dit as ultra-lege latency essensjeel is foar jo applikaasje, om't de DNS-resultaten ek yntern yn 'e cache binne.
referinsjes
Ik earst leard oer dizze funksje op , hâlden op 25 jannewaris. Der wie ûnder oare in diskusje oer dit probleem.
Hjir binne wat keppelings foar fierdere ferkenning:
- , wêrom ndots=5 yn Kubernetes;
- hoe't it feroarjen fan ndots beynfloedet applikaasje prestaasjes;
- tusken musl en glibc resolvers.
Opmerking: ik keas foar net te brûken dig yn dit artikel. dig foeget automatysk in punt ta (root zone identifier), wêrtroch it domein "folslein kwalifisearre" (FQDN), net troch it earst troch de syklist te rinnen. Skreau oer dit yn . It is lykwols frij ferrassend dat, yn 't algemien, in aparte flagge moat wurde oantsjutte foar it standertgedrach.
Lokkige DNSing! Sjoch dy letter!
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- "In yllustrearre gids foar netwurken yn Kubernetes": , .
Boarne: www.habr.com