Kubernetes പോഡുകൾക്കുള്ള /etc/resolv.conf, ndots:5 ഓപ്ഷൻ, ഇത് ആപ്ലിക്കേഷൻ പ്രകടനത്തെ എങ്ങനെ പ്രതികൂലമായി ബാധിക്കും

ഞങ്ങൾ അടുത്തിടെ കോപ്‌സ് ഉപയോഗിച്ച് AWS-ൽ Kubernetes 1.9 സമാരംഭിച്ചു. ഇന്നലെ, ഞങ്ങളുടെ ഏറ്റവും വലിയ കുബർനെറ്റസ് ക്ലസ്റ്ററുകളിലേക്ക് പുതിയ ട്രാഫിക് സുഗമമായി അവതരിപ്പിക്കുന്നതിനിടയിൽ, ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ ലോഗ് ചെയ്ത അസാധാരണമായ DNS നെയിം റെസലൂഷൻ പിശകുകൾ ഞാൻ ശ്രദ്ധിക്കാൻ തുടങ്ങി.

GitHub-ൽ ഇതിനെക്കുറിച്ച് ധാരാളം ഉണ്ട് സംസാരിച്ചു, അങ്ങനെ ഞാനും അത് കണ്ടുപിടിക്കാൻ തീരുമാനിച്ചു. അവസാനം, ഞങ്ങളുടെ കാര്യത്തിൽ ഇത് വർദ്ധിച്ച ലോഡ് കൊണ്ടാണ് സംഭവിക്കുന്നതെന്ന് ഞാൻ മനസ്സിലാക്കി kube-dns и dnsmasq. എന്നെ സംബന്ധിച്ചിടത്തോളം ഏറ്റവും രസകരവും പുതിയതുമായ കാര്യം DNS അഭ്യർത്ഥന ട്രാഫിക്കിൽ ഗണ്യമായ വർദ്ധനവിന് കാരണമായിരുന്നു. എന്റെ പോസ്റ്റ് ഇതിനെക്കുറിച്ച്, എന്താണ് ചെയ്യേണ്ടത്.

കണ്ടെയ്നറിനുള്ളിലെ ഡിഎൻഎസ് റെസല്യൂഷൻ - ഏതൊരു ലിനക്സ് സിസ്റ്റത്തിലേയും പോലെ - കോൺഫിഗറേഷൻ ഫയലാണ് നിർണ്ണയിക്കുന്നത് /etc/resolv.conf. ഡിഫോൾട്ട് കുബർനെറ്റസ് dnsPolicy അത് ClusterFirst, ഏത് ഡിഎൻഎസ് അഭ്യർത്ഥനയും ഫോർവേഡ് ചെയ്യപ്പെടും എന്നാണ് 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 നെയിം യോഗ്യത
• കുബർനെറ്റസ്: സേവനങ്ങൾക്കും പോഡുകൾക്കുമുള്ള ഡിഎൻഎസ്

ഞങ്ങളുടെ ബ്ലോഗിലെ മറ്റ് ലേഖനങ്ങളും വായിക്കുക:

• ഗോലാങ്ങിലെ സന്ദർഭ പാക്കേജ് മനസ്സിലാക്കുന്നു
• ഡോക്കർ ഇമേജുകൾ ചുരുക്കുന്നതിനുള്ള മൂന്ന് ലളിതമായ തന്ത്രങ്ങൾ
• കുബെർനെറ്റസിലെ സ്റ്റേറ്റ്ഫുൾ ബാക്കപ്പുകൾ
• ധാരാളം വൈവിധ്യമാർന്ന വെബ് പ്രോജക്റ്റുകളുടെ ബാക്കപ്പ്
• Redmine-നുള്ള ടെലിഗ്രാം ബോട്ട്. നിങ്ങൾക്കും മറ്റുള്ളവർക്കുമായി ജീവിതം എങ്ങനെ ലളിതമാക്കാം

അവലംബം: www.habr.com