/etc/resolv.conf Kubernetes पॉड्ससाठी, ndots:5 पर्याय, हे ऍप्लिकेशनच्या कार्यक्षमतेवर कसा नकारात्मक परिणाम करू शकते

आम्ही अलीकडेच Kops वापरून AWS वर Kubernetes 1.9 लाँच केले. काल, आमच्या Kubernetes क्लस्टर्सपैकी सर्वात मोठ्या क्लस्टरवर नवीन रहदारी सहजतेने आणत असताना, आमच्या अनुप्रयोगाद्वारे लॉग केलेल्या असामान्य DNS नाव रिझोल्यूशन त्रुटी माझ्या लक्षात येऊ लागल्या.

GitHub वर याबद्दल बरेच काही आहे बोलले, म्हणून मी देखील ते शोधण्याचा निर्णय घेतला. शेवटी, मला समजले की आमच्या बाबतीत हे वाढलेल्या लोडमुळे होते kube-dns и dnsmasq. माझ्यासाठी सर्वात मनोरंजक आणि नवीन गोष्ट म्हणजे DNS विनंती रहदारीमध्ये लक्षणीय वाढ होण्याचे कारण. माझी पोस्ट याबद्दल आहे आणि त्याबद्दल काय करावे.

कंटेनरमधील DNS रिझोल्यूशन - कोणत्याही लिनक्स प्रणालीप्रमाणे - कॉन्फिगरेशन फाइलद्वारे निर्धारित केले जाते /etc/resolv.conf. डीफॉल्ट कुबर्नेट्स 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 रिझोल्यूशन कसे कार्य करते हे समजून घेणे आवश्यक आहे.

पूर्ण नाव काय आहे?

पूर्ण पात्र नाव हे असे नाव आहे ज्यासाठी कोणताही स्थानिक शोध केला जाणार नाही आणि नावाच्या ठरावादरम्यान हे नाव परिपूर्ण मानले जाईल. नियमानुसार, डीएनएस सॉफ्टवेअर एखादे नाव बिंदू (.) ने संपत असल्यास ते पूर्ण पात्र समजते आणि अन्यथा ते पूर्णपणे पात्र नसते. ते आहे google.com. पूर्णपणे परिभाषित आणि google.com - नाही.

अयोग्य नाव कसे हाताळले जाते?

जेव्हा एखादा अनुप्रयोग नावात निर्दिष्ट केलेल्या रिमोट होस्टशी कनेक्ट होतो, तेव्हा DNS नाव रिझोल्यूशन सामान्यत: सिस्टम कॉल वापरून केले जाते, उदा. getaddrinfo(). परंतु जर नाव अपात्र असेल (. सह समाप्त होत नाही), तर मला आश्चर्य वाटते की सिस्टम कॉल प्रथम नावाचे निरपेक्ष नाव म्हणून निराकरण करण्याचा प्रयत्न करेल किंवा प्रथम स्थानिक शोध डोमेनमधून जाईल? ते पर्यायावर अवलंबून असते ndots.

मॅन्युअल पासून resolv.conf:

ndots:n

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

याचा अर्थ असा की जर साठी ndots 5 चे मूल्य दिलेले आहे आणि नावात 5 पेक्षा कमी ठिपके आहेत, सिस्टम कॉल क्रमशः त्याचे निराकरण करण्याचा प्रयत्न करेल, प्रथम सर्व स्थानिक शोध डोमेनमधून मार्गक्रमण करेल, आणि, अयशस्वी झाल्यास, शेवटी त्याचे निरपेक्ष नाव म्हणून निराकरण करेल.

मग का ndots:5 याचा अनुप्रयोगाच्या कार्यक्षमतेवर नकारात्मक परिणाम होऊ शकतो?

तुम्ही कल्पना करू शकता की, तुमचा ॲप्लिकेशन खूप जास्त बाह्य रहदारी वापरत असल्यास, स्थापित केलेल्या प्रत्येक TCP कनेक्शनसाठी (किंवा अधिक अचूकपणे, सोडवलेल्या प्रत्येक नावासाठी), ते नावाचे योग्यरितीने निराकरण होण्यापूर्वी 5 DNS क्वेरी जारी करेल, कारण ते प्रथम जाईल. 4 स्थानिक शोध डोमेन, आणि शेवटी एक परिपूर्ण नाव निराकरण विनंती जारी करेल.

खालील तक्त्यामध्ये आमच्या 3 kube-dns मॉड्यूल्सवरील एकूण रहदारी आम्ही आमच्या ऍप्लिकेशनमध्ये कॉन्फिगर केलेली काही होस्टनावे पूर्णपणे पात्रतेवर स्विच करण्यापूर्वी आणि नंतर दाखवली आहे.

खालील आकृती आम्ही आमच्या ऍप्लिकेशनमध्ये कॉन्फिगर केलेली अनेक होस्टनावे पूर्ण नावांवर स्विच करण्यापूर्वी आणि नंतर ऍप्लिकेशन लेटन्सी दर्शविते (उभी निळी रेषा ही उपयोजन आहे):

उपाय #1 - पूर्णपणे पात्र नावे वापरा

जर तुमच्याकडे काही स्टॅटिक एक्सटर्नल नावे असतील (म्हणजे अॅप्लिकेशन कॉन्फिगरेशनमध्ये परिभाषित केलेली) ज्यासाठी तुम्ही मोठ्या संख्येने कनेक्शन तयार करता, तर कदाचित सर्वात सोपा उपाय म्हणजे त्यांना जोडून पूर्ण पात्रांमध्ये स्विच करणे. शेवटी.

हा अंतिम उपाय नाही, परंतु ते त्वरीत, स्वच्छ नसले तरी, परिस्थिती सुधारण्यास मदत करते. आम्ही आमच्या समस्येचे निराकरण करण्यासाठी हा पॅच लागू केला, ज्याचे परिणाम वरील स्क्रीनशॉटमध्ये दर्शविले गेले आहेत.

उपाय #2 - सानुकूलन ndots в dnsConfig

Kubernetes 1.9 मध्ये, कार्यक्षमता अल्फा मोडमध्ये दिसून आली (बीटा आवृत्ती v1.10), जी तुम्हाला पॉड प्रॉपर्टीद्वारे DNS पॅरामीटर्स चांगल्या प्रकारे नियंत्रित करण्यास अनुमती देते dnsConfig. इतर गोष्टींबरोबरच, हे आपल्याला मूल्य कॉन्फिगर करण्याची परवानगी देते ndots विशिष्ट पॉडसाठी, म्हणजे

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

आमच्या ब्लॉगवरील इतर लेख देखील वाचा:

• गोलंगमधील संदर्भ पॅकेज समजून घेणे
• डॉकर प्रतिमा संकुचित करण्यासाठी तीन सोप्या युक्त्या
• Kubernetes मध्ये स्टेटफुल बॅकअप
• मोठ्या संख्येने विषम वेब प्रकल्पांचा बॅकअप
• रेडमाइनसाठी टेलीग्राम बॉट. स्वतःसाठी आणि इतरांसाठी जीवन कसे सोपे करावे

स्त्रोत: www.habr.com