រកមើល DNS នៅក្នុង Kubernetes

ចំណាំ។ បកប្រែ៖ បញ្ហា DNS នៅក្នុង Kubernetes ឬកាន់តែច្បាស់ជាងនេះ ការកំណត់ប៉ារ៉ាម៉ែត្រ ndotsមានការពេញនិយមគួរឱ្យភ្ញាក់ផ្អើល និងរួចទៅហើយ មិនមែនដំបូងទេ។ год. នៅក្នុងកំណត់ចំណាំមួយផ្សេងទៀតលើប្រធានបទនេះ អ្នកនិពន្ធរបស់ខ្លួនដែលជាវិស្វករ DevOps មកពីក្រុមហ៊ុនឈ្មួញកណ្តាលដ៏ធំមួយនៅក្នុងប្រទេសឥណ្ឌា ពិភាក្សាយ៉ាងសាមញ្ញ និងសង្ខេបអំពីអ្វីដែលមានប្រយោជន៍សម្រាប់សហការីដែលកំពុងប្រតិបត្តិការ Kubernetes ដើម្បីដឹង។

អត្ថប្រយោជន៍ចម្បងមួយនៃការដាក់ពង្រាយកម្មវិធីនៅលើ Kubernetes គឺការរកឃើញកម្មវិធីគ្មានថ្នេរ។ អន្តរកម្មក្នុងចង្កោមត្រូវបានសម្រួលយ៉ាងខ្លាំង ដោយសារគំនិតសេវាកម្ម (សេវាកម្ម) ដែលជា IP និម្មិតដែលគាំទ្រសំណុំនៃអាសយដ្ឋាន pod IP ។ ឧទាហរណ៍ប្រសិនបើសេវាកម្ម vanilla មានបំណងចង់ទាក់ទងសេវាកម្ម chocolateវាអាចចូលប្រើ IP និម្មិតដោយផ្ទាល់សម្រាប់ chocolate. សំណួរកើតឡើង: តើអ្នកណាក្នុងករណីនេះនឹងដោះស្រាយសំណើ DNS ទៅ chocolate ហើយដោយរបៀបណា?

ដំណោះស្រាយឈ្មោះ DNS ត្រូវបានកំណត់រចនាសម្ព័ន្ធនៅលើចង្កោម Kubernetes ដោយប្រើ CoreDNS. Kubelet ចុះឈ្មោះ pod ជាមួយ CoreDNS ជា nameserver នៅក្នុងឯកសារ /etc/resolv.conf pods ទាំងអស់។ ប្រសិនបើអ្នកក្រឡេកមើលខ្លឹមសារ /etc/resolv.conf pod ណាមួយ វានឹងមើលទៅដូចនេះ៖

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

ការកំណត់រចនាសម្ព័ន្ធនេះត្រូវបានប្រើដោយម៉ាស៊ីនភ្ញៀវ DNS ដើម្បីបញ្ជូនសំណើទៅកាន់ម៉ាស៊ីនមេ DNS ។ នៅក្នុងឯកសារ resolv.conf មានព័ត៌មានដូចខាងក្រោមៈ

• nameserver៖ ម៉ាស៊ីនមេដែលសំណើ DNS នឹងត្រូវបានផ្ញើ។ ក្នុងករណីរបស់យើង នេះគឺជាអាសយដ្ឋាននៃសេវាកម្ម CoreDNS ។
• ការស្វែងរក៖ កំណត់ផ្លូវស្វែងរកសម្រាប់ដែនជាក់លាក់មួយ។ វាគួរឱ្យចាប់អារម្មណ៍ណាស់។ google.com ឬ mrkaran.dev មិនមែនជា FQDN (ឈ្មោះដែនដែលមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់ពេញលេញ) យោងតាមអនុសញ្ញាស្ដង់ដារដែលអ្នកដោះស្រាយ DNS ភាគច្រើនធ្វើតាម មានតែចំណុចដែលបញ្ចប់ដោយចំនុច "." ដែលតំណាងឱ្យតំបន់ឫសគល់ ត្រូវបានគេចាត់ទុកថាមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់ពេញលេញ (FDQN) ដែន។ អ្នកដោះស្រាយខ្លះអាចបន្ថែមចំណុចដោយខ្លួនឯង។ ដូច្នេះ mrkaran.dev. គឺជាឈ្មោះដែនដែលមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់ពេញលេញ (FQDN) និង mrkaran.dev - ទេ;
• ចំណុច៖ ប៉ារ៉ាម៉ែត្រគួរឱ្យចាប់អារម្មណ៍បំផុត (អត្ថបទនេះគឺអំពីវា) ។ 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 នឹងចាត់ទុកដែនជាដាច់ខាត ឬទាក់ទង។ ឧទាហរណ៍ ក្នុងករណីម៉ាស៊ីនភ្ញៀវ DNS របស់ Google សាមញ្ញ តើវាដឹងដោយរបៀបណាថាតើដែននេះគឺដាច់ខាត? ប្រសិនបើអ្នកកំណត់ 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 ទទួលបានស្ថានភាពស្ថិរភាព។ ដូច្នេះនៅពេលដាក់ពង្រាយ pod អ្នកអាចកាត់បន្ថយតម្លៃ ndotsនិយាយថារហូតដល់ 3 (និងសូម្បីតែរហូតដល់ 1!) ។ ដោយសារតែនេះ រាល់សារនៅក្នុង node នឹងត្រូវបញ្ចូលដែនពេញលេញ។ នេះ​គឺ​ជា​ការ​ដោះដូរ​បែប​បុរាណ​មួយ​នៅ​ពេល​ដែល​អ្នក​ត្រូវ​ជ្រើសរើស​រវាង​ការ​អនុវត្ត​និង​ការ​ចល័ត។ វាហាក់ដូចជាខ្ញុំដែលអ្នកគួរព្រួយបារម្ភអំពីបញ្ហានេះ ប្រសិនបើភាពយឺតយ៉ាវទាបបំផុតមានសារៈសំខាន់ចំពោះកម្មវិធីរបស់អ្នក ដោយសារលទ្ធផល DNS ក៏ត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់ផងដែរ។

សេចក្តីយោង

ដំបូងខ្ញុំបានរៀនអំពីលក្ខណៈពិសេសនេះនៅលើ K8s-ជួបដែលប្រារព្ធឡើងនៅថ្ងៃទី 25 ខែមករា។ មានការពិភាក្សាអំពីបញ្ហានេះ ក្នុងចំណោមរឿងផ្សេងៗទៀត។

នេះគឺជាតំណភ្ជាប់មួយចំនួនសម្រាប់ការរុករកបន្ថែម៖

• ការពន្យល់, ហេតុអ្វីបានជា ndots=5 នៅក្នុង Kubernetes;
• វត្ថុ​ដ៏​អស្ចារ្យ របៀបដែលការផ្លាស់ប្តូរ ndots ប៉ះពាល់ដល់ដំណើរការកម្មវិធី;
• ភាពខុសគ្នា រវាងអ្នកដោះស្រាយ musl និង glibc ។

ចំណាំ៖ ខ្ញុំជ្រើសរើសមិនប្រើ dig នៅក្នុងអត្ថបទនេះ។ dig បន្ថែមចំនុចដោយស្វ័យប្រវត្តិ (ឧបករណ៍កំណត់តំបន់ឫស) ធ្វើឱ្យដែន "មានលក្ខណៈគ្រប់គ្រាន់" (FQDN) មិនមាន ដោយដំណើរការវាជាលើកដំបូងតាមរយៈបញ្ជីស្វែងរក។ បានសរសេរអំពីរឿងនេះនៅក្នុង មួយនៃការបោះពុម្ពផ្សាយមុន។. ទោះជាយ៉ាងណាក៏ដោយ វាពិតជាគួរឱ្យភ្ញាក់ផ្អើលណាស់ដែលថា ជាទូទៅ ទង់ជាតិដាច់ដោយឡែកត្រូវតែបញ្ជាក់សម្រាប់ឥរិយាបថស្តង់ដារ។

រីករាយ DNSing! ជួប​គ្នា​ពេល​ក្រោយ!

PS ពីអ្នកបកប្រែ

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «Calico សម្រាប់បណ្តាញនៅក្នុង Kubernetes៖ ការណែនាំ និងបទពិសោធន៍តិចតួច»
• «CoreDNS - ម៉ាស៊ីនមេ DNS សម្រាប់ពិភពដើមពពក និងការស្វែងរកសេវាកម្មសម្រាប់ Kubernetes»
• "មគ្គុទ្ទេសក៍គំនូរលើបណ្តាញនៅក្នុង Kubernetes"៖ ផ្នែកទី 1 និងទី 2 (គំរូបណ្តាញ បណ្តាញត្រួតលើគ្នា), ផ្នែកទី 3 (សេវាកម្ម និងដំណើរការចរាចរណ៍).

ប្រភព: www.habr.com