/etc/resolv.conf សម្រាប់ Kubernetes pods, ndots:5 ជម្រើស របៀបដែលវាអាចប៉ះពាល់អវិជ្ជមានដល់ដំណើរការកម្មវិធី

ថ្មីៗនេះ យើងបានចាប់ផ្តើម Kubernetes 1.9 នៅលើ AWS ដោយប្រើ Kops ។ កាលពីម្សិលមិញ ខណៈពេលដែលកំពុងដំណើរការចរាចរណ៍ថ្មីយ៉ាងរលូនទៅកាន់ក្រុម Kubernetes ដ៏ធំបំផុតរបស់យើង ខ្ញុំបានចាប់ផ្តើមកត់សម្គាល់កំហុសក្នុងការដោះស្រាយឈ្មោះ DNS មិនធម្មតាដែលបានចូលដោយកម្មវិធីរបស់យើង។

មានច្រើនណាស់អំពីរឿងនេះនៅលើ GitHub បាននិយាយដូច្នេះហើយ ខ្ញុំក៏សម្រេចចិត្តរកវាចេញ។ នៅទីបញ្ចប់ខ្ញុំបានដឹងថានៅក្នុងករណីរបស់យើងនេះគឺបណ្តាលមកពីការកើនឡើងការផ្ទុកនៅលើ kube-dns и dnsmasq. អ្វីដែលគួរឱ្យចាប់អារម្មណ៍ និងថ្មីបំផុតសម្រាប់ខ្ញុំគឺជាហេតុផលសម្រាប់ការកើនឡើងយ៉ាងខ្លាំងនៃចរាចរសំណើ DNS ។ ប្រកាសរបស់ខ្ញុំគឺអំពីរឿងនេះ និងអ្វីដែលត្រូវធ្វើអំពីវា។

ដំណោះស្រាយ DNS នៅខាងក្នុងធុង - ដូចនៅក្នុងប្រព័ន្ធលីនុចណាមួយ - ត្រូវបានកំណត់ដោយឯកសារកំណត់រចនាសម្ព័ន្ធ /etc/resolv.conf. Kubernetes លំនាំដើម dnsPolicy វា ClusterFirstដែលមានន័យថាសំណើ DNS ណាមួយនឹងត្រូវបានបញ្ជូនបន្តទៅ dnsmasq, កំពុងរត់នៅក្នុងផត kube-dns នៅខាងក្នុងចង្កោម ដែលនៅក្នុងវេននឹងបញ្ជូនសំណើទៅកម្មវិធី kube-dnsប្រសិនបើឈ្មោះបញ្ចប់ដោយបច្ច័យចង្កោម ឬបើមិនដូច្នេះទេ ទៅម៉ាស៊ីនមេ DNS កម្រិតខ្ពស់។

ឯកសារ /etc/resolv.conf នៅខាងក្នុងធុងនីមួយៗ លំនាំដើមនឹងមើលទៅដូចនេះ៖

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

ដូចដែលអ្នកអាចឃើញមានការណែនាំបី:

1. ឈ្មោះម៉ាស៊ីនមេគឺជា IP នៃសេវាកម្ម kube-dns
2. ដែនស្វែងរកក្នុងស្រុកចំនួន 4 បានបញ្ជាក់ search
3. មានជម្រើសមួយ។ ndots:5

ផ្នែកគួរឱ្យចាប់អារម្មណ៍នៃការកំណត់រចនាសម្ព័ន្ធនេះគឺជារបៀបដែលដែនស្វែងរកក្នុងតំបន់ និងការកំណត់ ndots:5 រួមគ្នា។ ដើម្បីយល់ពីបញ្ហានេះ អ្នកត្រូវយល់ពីរបៀបដែលដំណោះស្រាយ DNS សម្រាប់ឈ្មោះដែលមិនមានលក្ខណៈសម្បត្តិដំណើរការ។

តើឈ្មោះពេញជាអ្វី?

ឈ្មោះដែលមានសមត្ថភាពពេញលេញគឺជាឈ្មោះដែលមិនមានការរកមើលក្នុងតំបន់នឹងត្រូវបានអនុវត្ត ហើយឈ្មោះនឹងត្រូវបានចាត់ទុកថាដាច់ខាតក្នុងអំឡុងពេលការដោះស្រាយឈ្មោះ។ តាមអនុសញ្ញា កម្មវិធី DNS ចាត់ទុកឈ្មោះមួយថាមានលក្ខណៈសម្បត្តិពេញលេញ ប្រសិនបើវាបញ្ចប់ដោយចំនុច (.) ហើយមិនមានលក្ខណៈសម្បត្តិពេញលេញ។ នោះគឺជា google.com. បានកំណត់យ៉ាងពេញលេញ និង google.com - ទេ។

តើ​ឈ្មោះ​ដែល​មិន​មាន​លក្ខណៈ​សម្បត្តិ​ត្រូវ​ចាត់​ចែង​ដោយ​របៀប​ណា?

នៅពេលដែលកម្មវិធីភ្ជាប់ទៅម៉ាស៊ីនពីចម្ងាយដែលបានបញ្ជាក់នៅក្នុងឈ្មោះ ដំណោះស្រាយឈ្មោះ DNS ជាធម្មតាត្រូវបានធ្វើដោយប្រើការហៅតាមប្រព័ន្ធ ឧ. getaddrinfo(). ប៉ុន្តែប្រសិនបើឈ្មោះមិនមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់ (មិនបញ្ចប់ដោយ .) ខ្ញុំឆ្ងល់ថាតើការហៅប្រព័ន្ធនឹងព្យាយាមដោះស្រាយឈ្មោះជាឈ្មោះដាច់ខាតជាមុន ឬឆ្លងកាត់ដែនស្វែងរកក្នុងតំបន់ជាមុនសិន? វាអាស្រ័យលើជម្រើស ndots.

ពីសៀវភៅដៃ resolv.conf:

ndots:n

устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.

នេះមានន័យថាប្រសិនបើសម្រាប់ ndots បានផ្តល់តម្លៃនៃ 5 ហើយឈ្មោះមានចំនុចតិចជាង 5 ការហៅជាប្រព័ន្ធនឹងព្យាយាមដោះស្រាយវាជាបន្តបន្ទាប់ ដោយដំបូងឆ្លងកាត់ដែនស្វែងរកក្នុងស្រុកទាំងអស់ ហើយប្រសិនបើមិនជោគជ័យ ទីបំផុតនឹងដោះស្រាយវាជាឈ្មោះដាច់ខាត។

ហេតុអ្វីអញ្ចឹង ndots:5 តើវាអាចប៉ះពាល់អវិជ្ជមានដល់ដំណើរការកម្មវិធីដែរឬទេ?

ដូចដែលអ្នកអាចស្រមៃបាន ប្រសិនបើកម្មវិធីរបស់អ្នកប្រើប្រាស់ចរាចរខាងក្រៅច្រើន រាល់ការភ្ជាប់ TCP ត្រូវបានបង្កើតឡើង (ឬត្រឹមត្រូវជាងនេះ សម្រាប់រាល់ឈ្មោះដែលបានដោះស្រាយ) វានឹងចេញសំណួរ DNS ចំនួន 5 មុនពេលដែលឈ្មោះត្រូវបានដោះស្រាយយ៉ាងត្រឹមត្រូវ ព្រោះវានឹងត្រូវឆ្លងកាត់ជាមុនសិន។ 4 ដែនស្វែងរកក្នុងស្រុក ហើយនៅចុងបញ្ចប់នឹងចេញសំណើរដំណោះស្រាយឈ្មោះដាច់ខាត។

តារាងខាងក្រោមបង្ហាញពីចរាចរណ៍សរុបនៅលើម៉ូឌុល kube-dns ចំនួន 3 របស់យើងមុន និងបន្ទាប់ពីយើងប្តូរឈ្មោះម៉ាស៊ីនមួយចំនួនដែលបានកំណត់រចនាសម្ព័ន្ធនៅក្នុងកម្មវិធីរបស់យើងទៅជាកម្មវិធីដែលមានសមត្ថភាពពេញលេញ។

ដ្យាក្រាមខាងក្រោមបង្ហាញពីភាពយឺតយ៉ាវនៃកម្មវិធីមុន និងក្រោយពេលដែលយើងប្តូរឈ្មោះម៉ាស៊ីនជាច្រើនដែលបានកំណត់រចនាសម្ព័ន្ធនៅក្នុងកម្មវិធីរបស់យើងទៅជាឈ្មោះពេញ (បន្ទាត់ពណ៌ខៀវបញ្ឈរគឺជាការដាក់ពង្រាយ)៖

ដំណោះស្រាយទី 1 - ប្រើឈ្មោះដែលមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់

ប្រសិនបើអ្នកមានឈ្មោះខាងក្រៅឋិតិវន្តតិចតួច (ឧ. បានកំណត់ក្នុងការកំណត់រចនាសម្ព័ន្ធកម្មវិធី) ដែលអ្នកបង្កើតការតភ្ជាប់មួយចំនួនធំ ប្រហែលជាដំណោះស្រាយដ៏សាមញ្ញបំផុតគឺត្រូវប្តូរពួកវាទៅឈ្មោះដែលមានសមត្ថភាពពេញលេញដោយគ្រាន់តែបន្ថែមពួកវា។ នៅ​ចុង​បញ្ចប់។

នេះមិនមែនជាដំណោះស្រាយចុងក្រោយទេ ប៉ុន្តែវាអាចជួយបានយ៉ាងឆាប់រហ័ស ទោះបីមិនស្អាតក៏ដោយ ធ្វើអោយស្ថានភាពប្រសើរឡើង។ យើងបានអនុវត្តបំណះនេះដើម្បីដោះស្រាយបញ្ហារបស់យើង ដែលលទ្ធផលត្រូវបានបង្ហាញនៅក្នុងរូបថតអេក្រង់ខាងលើ។

ដំណោះស្រាយទី 2 - ការប្តូរតាមបំណង ndots в dnsConfig

នៅក្នុង Kubernetes 1.9 មុខងារបានបង្ហាញខ្លួននៅក្នុងរបៀបអាល់ហ្វា (កំណែបែតា v1.10) ដែលអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងប៉ារ៉ាម៉ែត្រ DNS កាន់តែប្រសើរឡើងតាមរយៈលក្ខណៈសម្បត្តិផតនៅក្នុង dnsConfig. ក្នុងចំណោមរបស់ផ្សេងទៀតវាអនុញ្ញាតឱ្យអ្នកកំណត់រចនាសម្ព័ន្ធតម្លៃ ndots សម្រាប់ pod ជាក់លាក់មួយ, i.e.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

ប្រភព។

• តើអ្វីទៅជាគុណវុឌ្ឍិឈ្មោះ DNS
• Kubernetes៖ DNS សម្រាប់សេវាកម្ម និងផត

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

• ការយល់ដឹងអំពីកញ្ចប់បរិបទនៅក្នុង Golang
• ល្បិចសាមញ្ញចំនួនបីដើម្បីបង្រួមរូបភាព Docker
• ការបម្រុងទុកដែលមានស្ថានភាពនៅក្នុង Kubernetes
• ការ​បម្រុង​ទុក​នៃ​គម្រោង​បណ្ដាញ​ខុស​គ្នា​មួយ​ចំនួន​ធំ
• Telegram bot សម្រាប់ Redmine ។ វិធីធ្វើឱ្យជីវិតសាមញ្ញសម្រាប់ខ្លួនអ្នក និងអ្នកដទៃ

ប្រភព: www.habr.com