/etc/resolv.conf Kubernetes pods-ի համար, ndots:5 տարբերակ, ինչպես դա կարող է բացասաբար ազդել հավելվածի աշխատանքի վրա

Մենք վերջերս գործարկեցինք Kubernetes 1.9-ը AWS-ի վրա՝ օգտագործելով Kops: Երեկ, երբ սահուն կերպով նոր տրաֆիկ տարածում էի դեպի մեր ամենամեծ Kubernetes կլաստերները, ես սկսեցի նկատել մեր հավելվածի կողմից գրանցված DNS անվան լուծման անսովոր սխալներ:

Այս մասին բավականին շատ բան կա GitHub-ում խոսեց, ուստի ես էլ որոշեցի դա պարզել։ Ի վերջո, ես հասկացա, որ մեր դեպքում դա պայմանավորված է ծանրաբեռնվածության ավելացմամբ kube-dns и dnsmasq. Ինձ համար ամենահետաքրքիրն ու նորը հենց DNS հարցումների տրաֆիկի զգալի աճի պատճառն էր։ Իմ գրառումը այս մասին է և ինչ անել դրա հետ կապված:

DNS լուծումը կոնտեյների ներսում, ինչպես ցանկացած Linux համակարգում, որոշվում է կազմաձևման ֆայլով /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 կապի համար (կամ ավելի ճիշտ՝ յուրաքանչյուր լուծված անվան համար), այն կթողարկի 5 DNS հարցումներ՝ նախքան անունը ճիշտ լուծվելը, քանի որ այն նախ կանցնի: 4 տեղական որոնման տիրույթ, և վերջում կհրապարակվի անվան լուծման բացարձակ հարցում:

Հետևյալ գծապատկերը ցույց է տալիս մեր 3 kube-dns մոդուլների ընդհանուր երթևեկությունը՝ նախքան և այն բանից հետո, երբ մենք փոխեցինք մեր հավելվածում կազմաձևված մի քանի հոսթների անունները լիովին որակավորվածների:

Հետևյալ դիագրամը ցույց է տալիս հավելվածի հետաձգումը նախքան և այն բանից հետո, երբ մենք մեր հավելվածում կազմաձևված մի քանի հյուրընկալող անունները փոխեցինք լրիվ անունների (ուղղահայաց կապույտ գիծը տեղակայումն է).

Լուծում #1 - Օգտագործեք լիովին որակավորված անուններ

Եթե ​​դուք ունեք մի քանի ստատիկ արտաքին անուններ (այսինքն՝ սահմանված են հավելվածի կազմաձևում), որոնց դուք ստեղծում եք մեծ թվով կապեր, թերևս ամենապարզ լուծումը դրանք լիովին որակյալների փոխարկելն է՝ պարզապես դրանք կցելով: վերջում.

Սա վերջնական լուծում չէ, բայց օգնում է արագ, թեկուզ ոչ մաքուր, բարելավել իրավիճակը։ Մենք կիրառեցինք այս կարկատումը մեր խնդիրը լուծելու համար, որի արդյունքները ցուցադրվեցին վերևի սքրինշոթներում:

Լուծում #2 - հարմարեցում ndots в dnsConfig

Kubernetes 1.9-ում ֆունկցիոնալությունը հայտնվեց ալֆա ռեժիմում (բետա տարբերակ v1.10), որը թույլ է տալիս ավելի լավ վերահսկել DNS-ի պարամետրերը pod հատկության միջոցով: 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 ծառայությունների և pods-ի համար

Կարդացեք նաև մեր բլոգի այլ հոդվածներ.

• Հասկանալով համատեքստային փաթեթը Golang-ում
• Երեք պարզ հնարք՝ Docker պատկերները փոքրացնելու համար
• Պետական ​​պահուստավորումներ Kubernetes-ում
• Մեծ թվով տարասեռ վեբ նախագծերի կրկնօրինակում
• Telegram բոտ Redmine-ի համար։ Ինչպես պարզեցնել կյանքը ձեր և ուրիշների համար

Source: www.habr.com