કુબરનેટ્સમાં DNS લુકઅપ

નૉૅધ. અનુવાદ: કુબરનેટ્સમાં DNS સમસ્યા, અથવા વધુ સ્પષ્ટ રીતે, પેરામીટર સેટિંગ્સ ndots, આશ્ચર્યજનક રીતે લોકપ્રિય છે, અને પહેલેથી જ પ્રથમ નહીં Год. આ વિષય પરની બીજી નોંધમાં, તેના લેખક, ભારતની એક મોટી બ્રોકરેજ કંપનીના DevOps એન્જિનિયર, કુબરનેટ્સનું સંચાલન કરતા સહકાર્યકરોને જાણવા માટે શું ઉપયોગી છે તે વિશે ખૂબ જ સરળ અને સંક્ષિપ્તમાં વાત કરે છે.

કુબરનેટ્સ પર એપ્લીકેશન જમાવવાના મુખ્ય ફાયદાઓમાંનો એક સીમલેસ એપ્લિકેશન શોધ છે. ઇન્ટ્રા-ક્લસ્ટર ક્રિયાપ્રતિક્રિયા ખૂબ જ સરળ છે સેવા ખ્યાલને આભારી છે (સેવા), જે એક વર્ચ્યુઅલ IP છે જે પોડ IP એડ્રેસના સમૂહને સપોર્ટ કરે છે. ઉદાહરણ તરીકે, જો સેવા vanilla સેવાનો સંપર્ક કરવા ઈચ્છે છે chocolate, તે માટે વર્ચ્યુઅલ IP ને સીધું જ એક્સેસ કરી શકે છે chocolate. પ્રશ્ન ઊભો થાય છે: આ કિસ્સામાં કોણ DNS વિનંતીનું નિરાકરણ કરશે chocolate અને કેવી રીતે?

DNS નામનું રિઝોલ્યુશન કુબરનેટ્સ ક્લસ્ટરનો ઉપયોગ કરીને ગોઠવેલું છે CoreDNS. કુબેલેટ ફાઈલોમાં નેમસર્વર તરીકે 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 - ના, તેથી આલ્પાઇન વપરાશકર્તાઓએ નોંધ લેવી જોઈએ.

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 સુધી મર્યાદિત; કુબરનેટ્સમાં મૂળભૂત રીતે તે 5 છે.

ઉત્પાદનમાં એપ્લિકેશન

જો એપ્લિકેશન ઘણા બધા બાહ્ય નેટવર્ક કૉલ્સ કરે છે, તો DNS સક્રિય ટ્રાફિકના કિસ્સામાં અડચણ બની શકે છે, કારણ કે નામ રીઝોલ્યુશન ઘણી બિનજરૂરી ક્વેરીઝ બનાવે છે (સિસ્ટમ યોગ્ય રીતે પહોંચે તે પહેલાં). એપ્લિકેશનો સામાન્ય રીતે ડોમેન નામોમાં રૂટ ઝોન ઉમેરતી નથી, પરંતુ આ હેક જેવું લાગે છે. એટલે કે પૂછવાને બદલે api.twitter.com, તમે હાર્ડકોડ કરી શકો છો api.twitter.com. એપ્લિકેશનમાં (બિંદુ સાથે), જે DNS ક્લાયંટને સંપૂર્ણ ડોમેન પર સીધા જ અધિકૃત લુકઅપ કરવા માટે પ્રોમ્પ્ટ કરશે.

વધુમાં, Kubernetes આવૃત્તિ 1.14 થી શરૂ કરીને, એક્સ્ટેંશન dnsConfig и dnsPolicy સ્થિર સ્થિતિ પ્રાપ્ત કરી. આમ, પોડ જમાવતી વખતે, તમે મૂલ્ય ઘટાડી શકો છો ndots, કહો, 3 સુધી (અને 1 સુધી પણ!). આને કારણે, નોડની અંદરના દરેક સંદેશામાં સંપૂર્ણ ડોમેન શામેલ કરવું પડશે. જ્યારે તમારે પર્ફોર્મન્સ અને પોર્ટેબિલિટી વચ્ચે પસંદગી કરવાની હોય ત્યારે આ ક્લાસિક ટ્રેડ-ઓફ્સમાંનું એક છે. મને એવું લાગે છે કે તમારે આ વિશે માત્ર ત્યારે જ ચિંતા કરવી જોઈએ જો તમારી એપ્લિકેશન માટે અલ્ટ્રા-લો લેટન્સી મહત્વપૂર્ણ હોય, કારણ કે DNS પરિણામો પણ આંતરિક રીતે કેશ કરેલા છે.

સંદર્ભો

મેં આ સુવિધા વિશે સૌપ્રથમ જાણ્યું K8s-મીટઅપ, 25 જાન્યુઆરીના રોજ યોજાયો હતો. અન્ય બાબતોની સાથે આ સમસ્યા અંગે પણ ચર્ચા થઈ હતી.

વધુ સંશોધન માટે અહીં કેટલીક લિંક્સ છે:

• સમજૂતી, શા માટે ndots=5 Kubernetes માં;
• મહાન સામગ્રી કેવી રીતે બદલાતા ndots એપ્લિકેશન પ્રભાવને અસર કરે છે;
• વિસંગતતાઓ musl અને glibc રિઝોલ્વર વચ્ચે.

નોંધ: મેં ઉપયોગ ન કરવાનું પસંદ કર્યું dig આ લેખમાં. dig ડોમેનને "ફુલ ક્વોલિફાઇડ" (FQDN) બનાવીને આપમેળે ડોટ (રુટ ઝોન ઓળખકર્તા) ઉમેરે છે, નથી પ્રથમ તેને શોધ સૂચિ દ્વારા ચલાવીને. માં આ વિશે લખ્યું અગાઉના પ્રકાશનોમાંથી એક. જો કે, તે ખૂબ જ આશ્ચર્યજનક છે કે, સામાન્ય રીતે, પ્રમાણભૂત વર્તન માટે એક અલગ ધ્વજનો ઉલ્લેખ કરવો જરૂરી છે.

હેપ્પી DNSing! પછી મળીશું!

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• «કુબરનેટ્સમાં નેટવર્કિંગ માટે કેલિકો: પરિચય અને થોડો અનુભવ»;
• «CoreDNS - ક્લાઉડ નેટિવ વર્લ્ડ માટે DNS સર્વર અને કુબરનેટ્સ માટે સર્વિસ ડિસ્કવરી»;
• "કુબરનેટ્સમાં નેટવર્કીંગ માટે એક સચિત્ર માર્ગદર્શિકા": ભાગો 1 અને 2 (નેટવર્ક મોડેલ, ઓવરલે નેટવર્ક્સ), ભાગ 3 (સેવાઓ અને ટ્રાફિક પ્રક્રિયા).

સોર્સ: www.habr.com