/etc/resolv.conf Kubernetes pods को लागि, ndots:5 विकल्प, यसले कसरी अनुप्रयोगको कार्यसम्पादनमा नकारात्मक प्रभाव पार्न सक्छ

हामीले भर्खरै Kops प्रयोग गरेर AWS मा Kubernetes 1.9 सुरु गर्यौं। हिजो, हाम्रो 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. नाम सर्भर सेवाको आईपी हो 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 जडान स्थापनाको लागि (वा अधिक सटीक रूपमा, प्रत्येक नामको समाधानको लागि), यसले नाम सही रूपमा समाधान हुनु अघि 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

हाम्रो ब्लगमा अन्य लेखहरू पनि पढ्नुहोस्:

• Golang मा सन्दर्भ प्याकेज बुझ्दै
• डकर छविहरू संकुचित गर्न तीन सरल चालहरू
• Kubernetes मा स्टेटफुल ब्याकअप
• विषम वेब परियोजनाहरूको ठूलो संख्याको ब्याकअप
• Redmine को लागी टेलीग्राम बोट। आफ्नो र अरूको लागि जीवन कसरी सरल बनाउने

स्रोत: www.habr.com