ProHoster > බ්ලොග් > පරිපාලනය > Kubernetes හි DNS සෙවීම

Kubernetes හි DNS සෙවීම

සටහන. පරිවර්තනය.: Kubernetes හි DNS ගැටළුව, හෝ වඩාත් නිවැරදිව, පරාමිති සැකසුම් ndots, පුදුම හිතෙන තරම් ජනප්රියයි, සහ දැනටමත් පළමු නොවේ වසර. මෙම මාතෘකාව පිළිබඳ තවත් සටහනක, එහි කතුවරයා, ඉන්දියාවේ විශාල තැරැව්කාර සමාගමක DevOps ඉංජිනේරුවෙකු, Kubernetes ක්‍රියාත්මක කරන සගයන්ට දැන ගැනීමට ප්‍රයෝජනවත් දේ පිළිබඳව ඉතා සරල හා සංක්ෂිප්ත ආකාරයකින් කතා කරයි.

Kubernetes හි DNS සෙවීම

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 ඉල්ලීම් නාමයක් "සම්පූර්ණ සුදුසුකම් ලත්" වසම් නාමයක් ලෙස සැලකීමට පෙර එහි ඇති තිත් ගණන නියම කරයි. අපි DNS සෙවීම් අනුපිළිවෙල විශ්ලේෂණය කරන විට අපි මේ ගැන වැඩි විස්තර පසුව කතා කරමු.

Kubernetes හි 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 logging level ලෙස සකසා ඇත 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 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, ඔබට එය 'hardcode' කළ හැක api.twitter.com. (තිතක් සහිත) යෙදුමේ, එය නිරපේක්ෂ වසම මත සෘජුවම බලයලත් සෙවීම් සිදු කිරීමට DNS සේවාදායකයින් පොළඹවයි.

අතිරේකව, Kubernetes අනුවාදය 1.14, දිගු වලින් ආරම්භ වේ dnsConfig и dnsPolicy ස්ථාවර තත්ත්වය ලැබුණා. මේ අනුව, පොඩ් එකක් යෙදවීමේදී, ඔබට අගය අඩු කළ හැකිය ndots, කියන්න, 3 දක්වා (සහ පවා 1 දක්වා!). මේ නිසා, node එකක් තුළ ඇති සෑම පණිවිඩයක්ම සම්පූර්ණ වසම ඇතුළත් කිරීමට සිදුවේ. ඔබට කාර්ය සාධනය සහ අතේ ගෙන යා හැකි බව අතර තෝරා ගැනීමට සිදු වූ විට මෙය සම්භාව්‍ය වෙළඳාම් වලින් එකකි. DNS ප්‍රතිඵල අභ්‍යන්තරව ද හැඹිලිගත කර ඇති බැවින්, ඔබගේ යෙදුමට අතිශය අඩු ප්‍රමාදය අත්‍යවශ්‍ය නම් පමණක් ඔබ මේ ගැන කරදර විය යුතු බව මට පෙනේ.

යොමු

මම මුලින්ම මෙම විශේෂාංගය ගැන ඉගෙන ගත්තා K8s - හමුවීම, ජනවාරි 25 පැවැත්විණි. එහිදී ඔවුන් වෙනත් දේ අතර මෙම ගැටලුව ගැන සාකච්ඡා කළහ.

වැඩිදුර ගවේෂණය සඳහා සබැඳි කිහිපයක් මෙන්න:

සටහන: මම භාවිතා නොකිරීමට තීරණය කළෙමි dig මෙම ලිපියෙන්. dig ස්වයංක්‍රීයව තිතක් එකතු කරයි (මූල කලාප හඳුනාගැනීම), වසම "සම්පූර්ණ සුදුසුකම්" (FQDN) බවට පත් කරයි. නෑ මුලින්ම එය සෙවුම් ලැයිස්තුව හරහා ධාවනය කිරීමෙන්. මේ ගැන ලිව්වා පෙර ප්‍රකාශන වලින් එකක්. කෙසේ වෙතත්, සාමාන්යයෙන්, සම්මත හැසිරීම් සඳහා වෙනම ධජයක් නියම කිරීමට සිදු වීම පුදුමයට කරුණකි.

ප්‍රීතිමත් DNSing! ඔයාව පසුව හමුවෙන්නම්!

පරිවර්තකගෙන් PS

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න