കുബെർനെറ്റസിലെ ഡിഎൻഎസിലെ പ്രശ്നങ്ങൾ. പൊതു പോസ്റ്റ്മോർട്ടം

കുറിപ്പ് വിവർത്തനം: കമ്പനിയുടെ എഞ്ചിനീയറിംഗ് ബ്ലോഗിൽ നിന്നുള്ള ഒരു പൊതു പോസ്റ്റ്‌മോർട്ടത്തിന്റെ വിവർത്തനമാണിത് തയ്യാറാക്കുക. ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിലെ കോൺട്രാക്കിന്റെ പ്രശ്‌നത്തെ ഇത് വിവരിക്കുന്നു, ഇത് ചില ഉൽപ്പാദന സേവനങ്ങളുടെ ഭാഗിക പ്രവർത്തനരഹിതമായ സമയത്തിലേക്ക് നയിച്ചു.

പോസ്റ്റ്‌മോർട്ടങ്ങളെക്കുറിച്ച് കുറച്ചുകൂടി പഠിക്കാനോ ഭാവിയിൽ ഉണ്ടാകാനിടയുള്ള ചില DNS പ്രശ്നങ്ങൾ തടയാനോ ആഗ്രഹിക്കുന്നവർക്ക് ഈ ലേഖനം ഉപയോഗപ്രദമായേക്കാം.

ഇത് DNS അല്ല
ഇത് DNS ആകാൻ കഴിയില്ല
അത് ഡിഎൻഎസ് ആയിരുന്നു

പ്രീപ്ലൈയിലെ പോസ്റ്റ്‌മോർട്ടങ്ങളെയും പ്രക്രിയകളെയും കുറിച്ച് അൽപ്പം

ഒരു പോസ്റ്റ്‌മോർട്ടം ഒരു തകരാറിനെയോ നിർമ്മാണത്തിലെ ചില സംഭവങ്ങളെയോ വിവരിക്കുന്നു. സംഭവങ്ങൾ, ഉപയോക്തൃ സ്വാധീനം, മൂലകാരണം, സ്വീകരിച്ച നടപടികൾ, പഠിച്ച പാഠങ്ങൾ എന്നിവയുടെ ഒരു ടൈംലൈൻ പോസ്റ്റ്‌മോർട്ടത്തിൽ ഉൾപ്പെടുന്നു.

SRE തേടുന്നു

പിസ്സയുമായുള്ള പ്രതിവാര മീറ്റിംഗുകളിൽ, സാങ്കേതിക ടീമിൽ, ഞങ്ങൾ വിവിധ വിവരങ്ങൾ പങ്കിടുന്നു. അത്തരം മീറ്റിംഗുകളുടെ ഏറ്റവും പ്രധാനപ്പെട്ട ഭാഗങ്ങളിലൊന്നാണ് പോസ്റ്റ്‌മോർട്ടം, അവ മിക്കപ്പോഴും സ്ലൈഡുകളുള്ള അവതരണവും സംഭവത്തിന്റെ കൂടുതൽ ആഴത്തിലുള്ള വിശകലനവും ഒപ്പമുണ്ട്. പോസ്റ്റ്‌മോർട്ടത്തിന് ശേഷം കൈയടിക്കുന്നില്ലെങ്കിലും, "കുറ്റമില്ല" എന്ന സംസ്കാരം വളർത്തിയെടുക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു (കുറ്റമറ്റ സംസ്കാരം). പോസ്റ്റ്‌മോർട്ടം എഴുതുകയും അവതരിപ്പിക്കുകയും ചെയ്യുന്നത് ഭാവിയിൽ സമാനമായ സംഭവങ്ങൾ തടയാൻ ഞങ്ങളെ (മറ്റുള്ളവർക്കും) സഹായിക്കുമെന്ന് ഞങ്ങൾ വിശ്വസിക്കുന്നു, അതിനാലാണ് ഞങ്ങൾ അവ പങ്കിടുന്നത്.

ഒരു സംഭവത്തിൽ ഉൾപ്പെട്ട വ്യക്തികൾക്ക് ശിക്ഷയോ പ്രതികാരമോ ഭയപ്പെടാതെ വിശദമായി സംസാരിക്കാൻ കഴിയുമെന്ന് തോന്നണം. കുറ്റപ്പെടുത്തേണ്ടതില്ല! പോസ്റ്റ്‌മോർട്ടം എഴുതുന്നത് ഒരു ശിക്ഷയല്ല, മറിച്ച് മുഴുവൻ കമ്പനിക്കും പഠിക്കാനുള്ള അവസരമാണ്.

CALMS & DevOps സൂക്ഷിക്കുക: എസ് പങ്കിടാനുള്ളതാണ്

കുബർനെറ്റസിലെ ഡിഎൻഎസിലെ പ്രശ്നങ്ങൾ. പോസ്റ്റ്മോർട്ടം

തീയതി: 28.02.2020

രചയിതാക്കൾ: അമേറ്റ് യു., ആൻഡ്രി എസ്., ഇഗോർ കെ., അലക്സി പി.

പദവി: തീർന്നു

ചുരുക്കത്തിൽ: Kubernetes ക്ലസ്റ്ററിലെ ചില സേവനങ്ങൾക്ക് ഭാഗിക DNS ലഭ്യമല്ല (26 മിനിറ്റ്).

സ്വാധീനം: എ, ബി, സി സേവനങ്ങൾക്കായി 15000 ഇവന്റുകൾ നഷ്ടപ്പെട്ടു

മൂലകാരണം: Contrack ടേബിളിൽ നിന്ന് ഒരു പഴയ എൻട്രി ശരിയായി നീക്കം ചെയ്യാൻ Kube-proxy-ന് കഴിഞ്ഞില്ല, അതിനാൽ ചില സേവനങ്ങൾ ഇപ്പോഴും നിലവിലില്ലാത്ത പോഡുകളിലേക്ക് കണക്റ്റ് ചെയ്യാൻ ശ്രമിച്ചുകൊണ്ടിരുന്നു

E0228 20:13:53.795782       1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...

ട്രിഗർ: കുബർനെറ്റസ് ക്ലസ്റ്ററിനുള്ളിൽ ലോഡ് കുറവായതിനാൽ, CoreDNS-autoscaler വിന്യാസത്തിലെ പോഡുകളുടെ എണ്ണം മൂന്നിൽ നിന്ന് രണ്ടായി കുറച്ചു.

പരിഹാരം: ആപ്ലിക്കേഷന്റെ അടുത്ത വിന്യാസം പുതിയ നോഡുകളുടെ നിർമ്മാണത്തിന് തുടക്കമിട്ടു, CoreDNS-autoscaler ക്ലസ്റ്ററിനെ സേവിക്കാൻ കൂടുതൽ പോഡുകൾ ചേർത്തു, ഇത് കോൺട്രാക്ക് ടേബിളിന്റെ തിരുത്തിയെഴുതാൻ കാരണമായി.

കണ്ടെത്തൽ: എ, ബി, സി സേവനങ്ങൾക്കായി പ്രോമിത്യൂസ് മോണിറ്ററിംഗ് 5xx പിശകുകൾ കണ്ടെത്തുകയും ഓൺ-ഡ്യൂട്ടി എഞ്ചിനീയർമാരെ വിളിക്കുകയും ചെയ്തു.

കിബാനയിൽ 5xx പിശകുകൾ

പ്രവൃത്തികൾ

ഫലം
ടൈപ്പ് ചെയ്യുക
ഉത്തരവാദിയായ
ലക്ഷ്യം

CoreDNS-നായി ഓട്ടോസ്കെയിലർ പ്രവർത്തനരഹിതമാക്കുക
തടഞ്ഞു
അമേത് യു.
DEVOPS-695

ഒരു കാഷിംഗ് DNS സെർവർ സജ്ജീകരിക്കുക
കുറയുന്നു
മാക്സ് വി.
DEVOPS-665

കോൺട്രാക്ക് മോണിറ്ററിംഗ് സജ്ജീകരിക്കുക
തടഞ്ഞു
അമേത് യു.
DEVOPS-674

പഠിച്ച പാഠങ്ങൾ

എന്താണ് നന്നായി നടന്നത്:

• നിരീക്ഷണം നന്നായി പ്രവർത്തിച്ചു. പ്രതികരണം വേഗത്തിലും സംഘടിതവുമായിരുന്നു
• നോഡുകളിൽ ഞങ്ങൾ പരിധികളൊന്നും അടിച്ചിട്ടില്ല

എന്താണ് തെറ്റ്:

• സമാനമായ യഥാർത്ഥ മൂലകാരണം ഇപ്പോഴും അജ്ഞാതമാണ് നിർദ്ദിഷ്ട ബഗ് കോൺട്രാക്കിൽ
• എല്ലാ പ്രവർത്തനങ്ങളും പരിണതഫലങ്ങൾ മാത്രമേ ശരിയാക്കൂ, മൂലകാരണമല്ല (ബഗ്)
• താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് ഞങ്ങൾക്ക് DNS-ൽ പ്രശ്‌നങ്ങളുണ്ടാകാമെന്ന് ഞങ്ങൾക്കറിയാമായിരുന്നു, പക്ഷേ ഞങ്ങൾ ടാസ്‌ക്കുകൾക്ക് മുൻഗണന നൽകിയില്ല

എവിടെയാണ് നമുക്ക് ഭാഗ്യമുണ്ടായത്:

• Contrack ടേബിളിനെ തിരുത്തിയെഴുതിയ CoreDNS-autoscaler ആണ് അടുത്ത വിന്യാസം ആരംഭിച്ചത്.
• ഈ ബഗ് ചില സേവനങ്ങളെ മാത്രം ബാധിച്ചു

ടൈംലൈൻ (EET)

സമയം
ഫലം

22:13
CoreDNS-autoscaler പോഡുകളുടെ എണ്ണം മൂന്നിൽ നിന്ന് രണ്ടായി കുറച്ചു

22:18
ഡ്യൂട്ടിയിലുള്ള എഞ്ചിനീയർമാർക്ക് മോണിറ്ററിംഗ് സിസ്റ്റത്തിൽ നിന്ന് കോളുകൾ ലഭിച്ചു തുടങ്ങി

22:21
ഡ്യൂട്ടിയിലുണ്ടായിരുന്ന എഞ്ചിനീയർമാർ പിശകുകളുടെ കാരണം കണ്ടെത്താൻ തുടങ്ങി.

22:39
ഡ്യൂട്ടിയിലുള്ള എഞ്ചിനീയർമാർ ഏറ്റവും പുതിയ സേവനങ്ങളിലൊന്ന് മുമ്പത്തെ പതിപ്പിലേക്ക് തിരികെ കൊണ്ടുവരാൻ തുടങ്ങി

22:40
5xx പിശകുകൾ ദൃശ്യമാകുന്നത് നിർത്തി, സ്ഥിതി സുസ്ഥിരമായി

• കണ്ടെത്താനുള്ള സമയം: 20 മിനിറ്റ്
• പ്രവർത്തനത്തിന് മുമ്പുള്ള സമയം: 20 മിനിറ്റ്
• പരിഹരിക്കാനുള്ള സമയം: 20 മിനിറ്റ്

കൂടുതൽ വിവരങ്ങൾ

• CoreDNS ലോഗുകൾ:

  I0228 20:13:53.507780       1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2

• കിബാന (കട്ട്), ഗ്രാഫാന (കട്ട്) എന്നിവയിലേക്കുള്ള ലിങ്കുകൾ
• Linux contrack നിങ്ങളുടെ സുഹൃത്തല്ലാത്തിടത്ത്
• kube-proxy സൂക്ഷ്മതകൾ: ഡീബഗ്ഗിംഗ് ഒരു ഇടവിട്ടുള്ള കണക്ഷൻ റീസെറ്റ്
• റേസി കോൺട്രാക്ക്, ഡിഎൻഎസ് ലുക്കപ്പ് ടൈംഔട്ടുകൾ

സിപിയു ഉപയോഗം കുറയ്ക്കുന്നതിന്, ലിനക്സ് കേർണൽ കോൺട്രാക്ക് എന്ന് വിളിക്കുന്ന ഒന്ന് ഉപയോഗിക്കുന്നു. ചുരുക്കത്തിൽ, ഒരു പ്രത്യേക പട്ടികയിൽ സൂക്ഷിച്ചിരിക്കുന്ന NAT റെക്കോർഡുകളുടെ ഒരു ലിസ്റ്റ് അടങ്ങുന്ന ഒരു യൂട്ടിലിറ്റിയാണിത്. അടുത്ത പാക്കറ്റ് അതേ പോഡിൽ നിന്ന് മുമ്പത്തെ പോഡിലേക്ക് വരുമ്പോൾ, അന്തിമ ഐപി വിലാസം വീണ്ടും കണക്കാക്കില്ല, പക്ഷേ കോൺട്രാക്ക് പട്ടികയിൽ നിന്ന് എടുക്കും.

കോൺട്രാക്ക് എങ്ങനെ പ്രവർത്തിക്കുന്നു

ഫലങ്ങൾ

ഉപയോഗപ്രദമായ ചില ലിങ്കുകളുള്ള ഞങ്ങളുടെ പോസ്റ്റ്‌മോർട്ടത്തിന്റെ ഒരു ഉദാഹരണമായിരുന്നു ഇത്. പ്രത്യേകിച്ച് ഈ ലേഖനത്തിൽ, മറ്റ് കമ്പനികൾക്ക് ഉപയോഗപ്രദമായേക്കാവുന്ന വിവരങ്ങൾ ഞങ്ങൾ പങ്കിടുന്നു. അതുകൊണ്ടാണ് തെറ്റുകൾ വരുത്താൻ ഞങ്ങൾ ഭയപ്പെടാത്തത്, അതുകൊണ്ടാണ് ഞങ്ങളുടെ ഒരു പോസ്റ്റ്‌മോർട്ടം ഞങ്ങൾ പരസ്യമാക്കുന്നത്. കൂടുതൽ രസകരമായ പൊതു പോസ്റ്റ്‌മോർട്ടങ്ങൾ ഇതാ:

• GitLab: ജനുവരി 31-ന് ഡാറ്റാബേസ് തകരാറിന്റെ പോസ്റ്റ്‌മോർട്ടം
• ഡ്രോപ്പ്ബോക്സ്: പോസ്റ്റ്‌മോർട്ടം മുടങ്ങിയത്
• നീനുവിനും: DNS-മായി Spotify-യുടെ സ്നേഹം/വിദ്വേഷ ബന്ധം
• മറ്റ് പലരിൽ നിന്നും ഈ സാരം ശേഖരണവും കുബർനെറ്റസ് പരാജയ കഥകൾ
• എതിരെ ഉദാഹരണം എസ്ആർഇ ബുക്ക് ഉപയോഗിച്ച് പൊതു പോസ്റ്റ്മോർട്ടം

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