DomClick-ലെ Kubernetes: 1000 മൈക്രോ സർവീസുകളുടെ ഒരു ക്ലസ്റ്റർ കൈകാര്യം ചെയ്യുമ്പോൾ എങ്ങനെ സമാധാനത്തോടെ ഉറങ്ങാം

എന്റെ പേര് വിക്ടർ യാഗോഫറോവ്, ഓപ്‌സ് (ഓപ്പറേഷൻ) ടീമിലെ ഒരു ടെക്‌നിക്കൽ ഡെവലപ്‌മെന്റ് മാനേജരായി ഞാൻ ഡോംക്ലിക്കിലെ കുബർനെറ്റസ് പ്ലാറ്റ്‌ഫോം വികസിപ്പിക്കുകയാണ്. ഞങ്ങളുടെ Dev <-> Ops പ്രോസസുകളുടെ ഘടനയെക്കുറിച്ചും റഷ്യയിലെ ഏറ്റവും വലിയ k8s ക്ലസ്റ്ററുകളിലൊന്ന് പ്രവർത്തിപ്പിക്കുന്നതിന്റെ സവിശേഷതകളെക്കുറിച്ചും ഞങ്ങളുടെ ടീം പ്രയോഗിക്കുന്ന DevOps/SRE പരിശീലനങ്ങളെക്കുറിച്ചും സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

Ops ടീം

ഓപ്‌സ് ടീമിൽ നിലവിൽ 15 പേരാണുള്ളത്. അവരിൽ മൂന്ന് പേർ ഓഫീസിന്റെ ചുമതലയുള്ളവരാണ്, രണ്ട് പേർ വ്യത്യസ്ത സമയ മേഖലയിൽ ജോലി ചെയ്യുന്നു, രാത്രിയിൽ ഉൾപ്പെടെ ലഭ്യമാണ്. അതിനാൽ, Ops-ൽ നിന്നുള്ള ഒരാൾ എപ്പോഴും മോണിറ്ററിലായിരിക്കും, ഏത് സങ്കീർണതയുടെയും സംഭവത്തോട് പ്രതികരിക്കാൻ തയ്യാറാണ്. ഞങ്ങൾക്ക് രാത്രി ഷിഫ്റ്റുകൾ ഇല്ല, അത് നമ്മുടെ മനസ്സിനെ സംരക്ഷിക്കുകയും എല്ലാവർക്കും വേണ്ടത്ര ഉറങ്ങാനും കമ്പ്യൂട്ടറിൽ മാത്രമല്ല ഒഴിവു സമയം ചെലവഴിക്കാനും അവസരം നൽകുന്നു.

എല്ലാവർക്കും വ്യത്യസ്‌തമായ കഴിവുകളുണ്ട്: നെറ്റ്‌വർക്കർമാർ, DBA-കൾ, ELK സ്റ്റാക്ക് സ്പെഷ്യലിസ്റ്റുകൾ, കുബർനെറ്റസ് അഡ്മിൻസ്/ഡെവലപ്പർമാർ, നിരീക്ഷണം, വിർച്ച്വലൈസേഷൻ, ഹാർഡ്‌വെയർ സ്പെഷ്യലിസ്റ്റുകൾ തുടങ്ങിയവ. ഒരു കാര്യം എല്ലാവരേയും ഒന്നിപ്പിക്കുന്നു - എല്ലാവർക്കും നമ്മിൽ ആരെയും ഒരു പരിധിവരെ മാറ്റിസ്ഥാപിക്കാം: ഉദാഹരണത്തിന്, k8s ക്ലസ്റ്ററിലേക്ക് പുതിയ നോഡുകൾ അവതരിപ്പിക്കുക, PostgreSQL അപ്‌ഡേറ്റ് ചെയ്യുക, ഒരു CI/CD + Ansible പൈപ്പ്‌ലൈൻ എഴുതുക, പൈത്തൺ/ബാഷ്/ഗോയിൽ എന്തെങ്കിലും ഓട്ടോമേറ്റ് ചെയ്യുക, ഹാർഡ്‌വെയർ ഇതിലേക്ക് ബന്ധിപ്പിക്കുക ഡാറ്റ കേന്ദ്രം. ഏതെങ്കിലും മേഖലയിലെ ശക്തമായ കഴിവുകൾ നിങ്ങളുടെ പ്രവർത്തനത്തിന്റെ ദിശ മാറ്റുന്നതിൽ നിന്നും മറ്റേതെങ്കിലും മേഖലയിൽ മെച്ചപ്പെടുത്താൻ തുടങ്ങുന്നതിൽ നിന്നും നിങ്ങളെ തടയില്ല. ഉദാഹരണത്തിന്, ഞാൻ ഒരു PostgreSQL സ്പെഷ്യലിസ്റ്റായി ഒരു കമ്പനിയിൽ ചേർന്നു, ഇപ്പോൾ എന്റെ പ്രധാന ഉത്തരവാദിത്ത മേഖല കുബർനെറ്റസ് ക്ലസ്റ്ററുകളാണ്. ടീമിൽ, ഏത് ഉയരവും സ്വാഗതം ചെയ്യുന്നു, ലിവറേജിന്റെ ബോധം വളരെ വികസിച്ചതാണ്.

വഴിയിൽ, ഞങ്ങൾ വേട്ടയാടുകയാണ്. സ്ഥാനാർത്ഥികൾക്കുള്ള ആവശ്യകതകൾ തികച്ചും സാധാരണമാണ്. വ്യക്തിപരമായി എന്നെ സംബന്ധിച്ചിടത്തോളം, ഒരു വ്യക്തി ടീമുമായി യോജിക്കുന്നതും വൈരുദ്ധ്യമില്ലാത്തതും എന്നാൽ തന്റെ കാഴ്ചപ്പാടിനെ എങ്ങനെ പ്രതിരോധിക്കണമെന്ന് അറിയുന്നതും വികസിപ്പിക്കാൻ ആഗ്രഹിക്കുന്നതും പുതിയ എന്തെങ്കിലും ചെയ്യാൻ ഭയപ്പെടാത്തതും അവന്റെ ആശയങ്ങൾ വാഗ്ദാനം ചെയ്യുന്നതും പ്രധാനമാണ്. കൂടാതെ, സ്ക്രിപ്റ്റിംഗ് ഭാഷകളിലെ പ്രോഗ്രാമിംഗ് കഴിവുകൾ, ലിനക്സിന്റെയും ഇംഗ്ലീഷിന്റെയും അടിസ്ഥാനകാര്യങ്ങളെക്കുറിച്ചുള്ള അറിവ് എന്നിവ ആവശ്യമാണ്. ഇംഗ്ലീഷ് ലളിതമായി ആവശ്യമാണ്, അതിനാൽ ഒരു ഫകാപ്പ് സംഭവിക്കുന്ന ഒരു വ്യക്തിക്ക് 10 മിനിറ്റിനുള്ളിൽ പ്രശ്നത്തിന് ഗൂഗിൾ ചെയ്യാനാകും, അല്ലാതെ 10 മിനിറ്റിനുള്ളിൽ. ലിനക്സിനെക്കുറിച്ച് ആഴത്തിലുള്ള അറിവുള്ള സ്പെഷ്യലിസ്റ്റുകളെ കണ്ടെത്തുന്നത് ഇപ്പോൾ വളരെ ബുദ്ധിമുട്ടാണ്: ഇത് തമാശയാണ്, എന്നാൽ മൂന്ന് സ്ഥാനാർത്ഥികളിൽ രണ്ട് പേർക്കും "ലോഡ് ശരാശരി എന്താണ്? ഇത് എന്താണ് നിർമ്മിച്ചിരിക്കുന്നത്?", കൂടാതെ "ഒരു സി പ്രോഗ്രാമിൽ നിന്ന് ഒരു കോർ ഡംപ് എങ്ങനെ കൂട്ടിച്ചേർക്കാം" എന്ന ചോദ്യം സൂപ്പർമാൻമാരുടെ ലോകത്തിൽ നിന്നുള്ള ഒന്നായി കണക്കാക്കപ്പെടുന്നു ... അല്ലെങ്കിൽ ദിനോസറുകൾ. സാധാരണയായി ആളുകൾ മറ്റ് കഴിവുകൾ വളരെയധികം വികസിപ്പിച്ചതിനാൽ ഞങ്ങൾ ഇത് സഹിക്കണം, പക്ഷേ ഞങ്ങൾ ലിനക്സ് പഠിപ്പിക്കും. “മേഘങ്ങളുടെ ആധുനിക ലോകത്ത് ഒരു DevOps എഞ്ചിനീയർക്ക് ഇതെല്ലാം അറിയേണ്ടത് എന്തുകൊണ്ട്” എന്ന ചോദ്യത്തിനുള്ള ഉത്തരം ലേഖനത്തിന്റെ പരിധിക്ക് പുറത്ത് ഉപേക്ഷിക്കേണ്ടിവരും, പക്ഷേ മൂന്ന് വാക്കുകളിൽ: ഇതെല്ലാം ആവശ്യമാണ്.

ടീം ടൂളുകൾ

ഓട്ടോമേഷനിൽ ടൂൾസ് ടീം ഒരു പ്രധാന പങ്ക് വഹിക്കുന്നു. ഡെവലപ്പർമാർക്ക് സൗകര്യപ്രദമായ ഗ്രാഫിക്കൽ, CLI ടൂളുകൾ സൃഷ്ടിക്കുക എന്നതാണ് അവരുടെ പ്രധാന ദൌത്യം. ഉദാഹരണത്തിന്, ഏതാനും മൗസ് ക്ലിക്കുകളിലൂടെ ഒരു ആപ്ലിക്കേഷൻ അക്ഷരാർത്ഥത്തിൽ Kubernetes-ലേക്ക് റോൾ ചെയ്യാനും അതിന്റെ ഉറവിടങ്ങൾ, നിലവറയിൽ നിന്നുള്ള കീകൾ മുതലായവ ക്രമീകരിക്കാനും ഞങ്ങളുടെ ആന്തരിക വികസന കോൺഫർ നിങ്ങളെ അനുവദിക്കുന്നു. മുമ്പ്, Jenkins + Helm 2 ഉണ്ടായിരുന്നു, എന്നാൽ കോപ്പി-പേസ്റ്റ് ഒഴിവാക്കാനും സോഫ്‌റ്റ്‌വെയർ ലൈഫ് സൈക്കിളിന് ഏകീകൃതത കൊണ്ടുവരാനും എനിക്ക് സ്വന്തമായി ഒരു ടൂൾ വികസിപ്പിക്കേണ്ടി വന്നു.

Ops ടീം ഡവലപ്പർമാർക്കായി പൈപ്പ് ലൈനുകൾ എഴുതുന്നില്ല, എന്നാൽ അവരുടെ രചനയിൽ എന്തെങ്കിലും പ്രശ്നങ്ങളെക്കുറിച്ച് ഉപദേശിക്കാൻ കഴിയും (ചില ആളുകൾക്ക് ഇപ്പോഴും ഹെൽം 3 ഉണ്ട്).

DevOps

DevOps-നെ സംബന്ധിച്ചിടത്തോളം, ഞങ്ങൾ ഇത് ഇതുപോലെ കാണുന്നു:

ദേവ് ടീമുകൾ കോഡ് എഴുതുന്നു, അത് കോൺഫർ ടു dev -> qa/stage -> prod-ലേക്ക് റോൾ ചെയ്യുന്നു. കോഡ് വേഗത കുറയുന്നില്ലെന്നും പിശകുകൾ അടങ്ങിയിട്ടില്ലെന്നും ഉറപ്പാക്കുന്നതിനുള്ള ഉത്തരവാദിത്തം Dev, Ops ടീമുകൾക്കാണ്. പകൽസമയത്ത്, ഓപ്‌സ് ടീമിൽ നിന്ന് ഡ്യൂട്ടിയിലുള്ള വ്യക്തി ആദ്യം തന്റെ അപേക്ഷയോടൊപ്പം ഒരു സംഭവത്തോട് പ്രതികരിക്കണം, വൈകുന്നേരവും രാത്രിയും, ഡ്യൂട്ടിയിലുള്ള അഡ്മിനിസ്ട്രേറ്റർ (ഓപ്‌സ്) ഡവലപ്പറെ ഡ്യൂട്ടിയിൽ ഉണർത്തണം. അടിസ്ഥാന സൗകര്യങ്ങളിലല്ല പ്രശ്നം എന്ന് ഉറപ്പാണ്. മോണിറ്ററിംഗിലെ എല്ലാ മെട്രിക്കുകളും അലേർട്ടുകളും സ്വയമേവയോ അർദ്ധ സ്വയമേവയോ ദൃശ്യമാകും.

ആപ്ലിക്കേഷൻ ഉൽപ്പാദിപ്പിക്കപ്പെടുന്ന നിമിഷം മുതൽ Ops-ന്റെ ഉത്തരവാദിത്ത മേഖല ആരംഭിക്കുന്നു, പക്ഷേ ദേവിന്റെ ഉത്തരവാദിത്തം അവിടെ അവസാനിക്കുന്നില്ല - ഞങ്ങൾ ഒരേ കാര്യം ചെയ്യുന്നു, ഒരേ ബോട്ടിലാണ്.

ഒരു അഡ്‌മിൻ മൈക്രോസർവീസ് (ഉദാഹരണത്തിന്, Go backend + HTML5) എഴുതാൻ സഹായം ആവശ്യമുണ്ടെങ്കിൽ ഡെവലപ്പർമാർ അഡ്‌മിനുകളെ ഉപദേശിക്കുന്നു, കൂടാതെ ഏതെങ്കിലും ഇൻഫ്രാസ്ട്രക്ചർ പ്രശ്‌നങ്ങളിലോ k8s മായി ബന്ധപ്പെട്ട പ്രശ്‌നങ്ങളിലോ അഡ്‌മിനുകൾ ഡെവലപ്പർമാരെ ഉപദേശിക്കുന്നു.

വഴിയിൽ, ഞങ്ങൾക്ക് ഒരു മോണോലിത്ത് ഇല്ല, മൈക്രോസർവീസുകൾ മാത്രം. അവരുടെ എണ്ണം ഇതുവരെ 900 നും 1000 നും ഇടയിൽ prod k8s ക്ലസ്റ്ററിൽ ചാഞ്ചാടുന്നു, സംഖ്യകൊണ്ട് അളക്കുകയാണെങ്കിൽ വിന്യാസങ്ങൾ. കായ്കളുടെ എണ്ണം 1700 നും 2000 നും ഇടയിലാണ്.

അനാവശ്യമായ മൈക്രോസർവീസുകൾ ഞങ്ങൾ നിരീക്ഷിക്കുകയും അവ സെമി-ഓട്ടോമാറ്റിക്കായി മുറിക്കുകയും ചെയ്യുന്നതിനാൽ എനിക്ക് കൃത്യമായ നമ്പറുകൾ നൽകാൻ കഴിയില്ല. K8s അനാവശ്യമായ എന്റിറ്റികളുടെ ട്രാക്ക് സൂക്ഷിക്കാൻ ഞങ്ങളെ സഹായിക്കുന്നു ഉപയോഗശൂന്യമായ-ഓപ്പറേറ്റർ, ഇത് ധാരാളം വിഭവങ്ങളും പണവും ലാഭിക്കുന്നു.

റിസോഴ്സ് മാനേജ്മെന്റ്

നിരീക്ഷിക്കുന്നു

നല്ല ഘടനാപരമായതും വിജ്ഞാനപ്രദവുമായ നിരീക്ഷണം ഒരു വലിയ ക്ലസ്റ്ററിന്റെ പ്രവർത്തനത്തിലെ മൂലക്കല്ലായി മാറുന്നു. എല്ലാ നിരീക്ഷണ ആവശ്യങ്ങളുടെയും 100% ഉൾക്കൊള്ളുന്ന ഒരു സാർവത്രിക പരിഹാരം ഞങ്ങൾ ഇതുവരെ കണ്ടെത്തിയിട്ടില്ല, അതിനാൽ ഈ പരിതസ്ഥിതിയിൽ ഞങ്ങൾ ഇടയ്ക്കിടെ വ്യത്യസ്ത ഇഷ്‌ടാനുസൃത പരിഹാരങ്ങൾ സൃഷ്ടിക്കുന്നു.

• സബ്ബിക്സ്. അടിസ്ഥാന സൗകര്യങ്ങളുടെ മൊത്തത്തിലുള്ള അവസ്ഥ ട്രാക്ക് ചെയ്യാൻ പ്രാഥമികമായി ഉദ്ദേശിച്ചിട്ടുള്ള നല്ല പഴയ നിരീക്ഷണം. പ്രോസസ്സിംഗ്, മെമ്മറി, ഡിസ്കുകൾ, നെറ്റ്‌വർക്ക് മുതലായവയിൽ ഒരു നോഡ് മരിക്കുമ്പോൾ അത് നമ്മോട് പറയുന്നു. അമാനുഷികമായി ഒന്നുമില്ല, പക്ഷേ ഞങ്ങൾക്ക് ഒരു പ്രത്യേക ഡെമോൺസെറ്റ് ഏജന്റുകളുണ്ട്, അതിന്റെ സഹായത്തോടെ, ഉദാഹരണത്തിന്, ക്ലസ്റ്ററിലെ ഡിഎൻഎസിന്റെ അവസ്ഥ ഞങ്ങൾ നിരീക്ഷിക്കുന്നു: ഞങ്ങൾ മണ്ടൻ കോറെഡ്‌സ് പോഡുകൾക്കായി തിരയുന്നു, ബാഹ്യ ഹോസ്റ്റുകളുടെ ലഭ്യത ഞങ്ങൾ പരിശോധിക്കുന്നു. എന്തുകൊണ്ടാണ് ഇത് വിഷമിപ്പിക്കുന്നതെന്ന് തോന്നുന്നു, പക്ഷേ വലിയ ട്രാഫിക്കിൽ ഈ ഘടകം ഗുരുതരമായ പരാജയമാണ്. ഇതിനകം ഞാൻ വിവരിച്ചു, ഒരു ക്ലസ്റ്ററിലെ DNS പ്രകടനവുമായി ഞാൻ എങ്ങനെ ബുദ്ധിമുട്ടി.
• പ്രൊമിത്യൂസ് ഓപ്പറേറ്റർ. വിവിധ കയറ്റുമതിക്കാരുടെ ഒരു കൂട്ടം ക്ലസ്റ്ററിന്റെ എല്ലാ ഘടകങ്ങളുടെയും ഒരു വലിയ അവലോകനം നൽകുന്നു. അടുത്തതായി, ഗ്രാഫാനയിലെ വലിയ ഡാഷ്‌ബോർഡുകളിൽ ഞങ്ങൾ ഇതെല്ലാം ദൃശ്യവൽക്കരിക്കുകയും അലേർട്ടുകൾക്കായി അലർട്ട്മാനേജർ ഉപയോഗിക്കുകയും ചെയ്യുന്നു.

ഞങ്ങൾക്ക് ഉപയോഗപ്രദമായ മറ്റൊരു ഉപകരണം ലിസ്റ്റ്-പ്രവേശനം. ഒരു ടീം മറ്റൊരു ടീമിന്റെ ഇൻഗ്രെസ്സ് പാതകൾ ഓവർലാപ്പ് ചെയ്യുന്ന ഒരു സാഹചര്യം നേരിടേണ്ടി വന്നതിന് ശേഷം ഞങ്ങൾ ഇത് എഴുതി, അതിന്റെ ഫലമായി 50x പിശകുകൾ. ഇപ്പോൾ പ്രൊഡക്ഷനിലേക്ക് വിന്യസിക്കുന്നതിന് മുമ്പ്, ഡവലപ്പർമാർ ആരെയും ബാധിക്കില്ലെന്ന് പരിശോധിക്കുന്നു, എന്റെ ടീമിനെ സംബന്ധിച്ചിടത്തോളം ഇത് ഇൻഗ്രെസുകളിലെ പ്രശ്‌നങ്ങളുടെ പ്രാഥമിക രോഗനിർണയത്തിനുള്ള നല്ലൊരു ഉപകരണമാണ്. ആദ്യം ഇത് അഡ്മിൻമാർക്ക് വേണ്ടി എഴുതിയതാണ് എന്നത് തമാശയാണ്, പക്ഷേ അത് "വിചിത്രമായി" കാണപ്പെട്ടു, എന്നാൽ ദേവ് ടീമുകൾ ഈ ടൂളുമായി പ്രണയത്തിലായതിനുശേഷം, അത് വളരെയധികം മാറി, "ഒരു അഡ്മിൻ അഡ്മിൻമാർക്കായി ഒരു വെബ് മുഖം ഉണ്ടാക്കി" എന്ന് തോന്നാൻ തുടങ്ങി. ” താമസിയാതെ ഞങ്ങൾ ഈ ഉപകരണം ഉപേക്ഷിക്കും, പൈപ്പ് ലൈൻ പുറത്തുവരുന്നതിന് മുമ്പുതന്നെ അത്തരം സാഹചര്യങ്ങൾ സാധൂകരിക്കപ്പെടും.

ക്യൂബിലെ ടീം വിഭവങ്ങൾ

ഉദാഹരണങ്ങളിലേക്ക് കടക്കുന്നതിന് മുമ്പ്, ഞങ്ങൾ എങ്ങനെയാണ് വിഭവങ്ങൾ വിനിയോഗിക്കുന്നത് എന്ന് വിശദീകരിക്കുന്നത് മൂല്യവത്താണ് മൈക്രോസർവീസുകൾ.

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

ഒരു ടീമിന് വിഭവങ്ങൾ അനുവദിക്കുന്നതിനുള്ള ഒരു ഉദാഹരണം:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

അഭ്യർത്ഥനകളും പരിധികളും

ക്യൂബ്ഡ്" അപേക്ഷ ഗ്യാരണ്ടീഡ് റിസർവ്ഡ് റിസോഴ്സുകളുടെ എണ്ണമാണ് പാകമായ (ഒന്നോ അതിലധികമോ ഡോക്കർ കണ്ടെയ്‌നറുകൾ) ഒരു ക്ലസ്റ്ററിൽ. പരിധി ഉറപ്പില്ലാത്ത പരമാവധി ആണ്. ചില ടീം അതിന്റെ എല്ലാ ആപ്ലിക്കേഷനുകൾക്കും നിരവധി അഭ്യർത്ഥനകൾ സജ്ജമാക്കിയിരിക്കുന്നത് എങ്ങനെയെന്ന് നിങ്ങൾക്ക് പലപ്പോഴും ഗ്രാഫുകളിൽ കാണാൻ കഴിയും, കൂടാതെ "ക്യൂബിലേക്ക്" ആപ്ലിക്കേഷൻ വിന്യസിക്കാൻ കഴിയില്ല, കാരണം അവരുടെ നെയിംസ്പേസിന് കീഴിലുള്ള എല്ലാ അഭ്യർത്ഥനകളും ഇതിനകം തന്നെ "ചെലവഴിച്ചു".

ഈ അവസ്ഥയിൽ നിന്നുള്ള ശരിയായ മാർഗം യഥാർത്ഥ വിഭവ ഉപഭോഗം നോക്കുകയും അഭ്യർത്ഥിച്ച തുകയുമായി താരതമ്യം ചെയ്യുകയുമാണ് (അഭ്യർത്ഥന).

മുകളിലുള്ള സ്ക്രീൻഷോട്ടുകളിൽ, "അഭ്യർത്ഥിച്ച" CPU-കൾ യഥാർത്ഥ ത്രെഡുകളുമായി പൊരുത്തപ്പെടുന്നതായി നിങ്ങൾക്ക് കാണാൻ കഴിയും, കൂടാതെ പരിധികൾ യഥാർത്ഥ CPU ത്രെഡുകളുടെ എണ്ണം കവിയുന്നു =)

ഇപ്പോൾ നമുക്ക് കുറച്ച് നെയിംസ്‌പേസ് വിശദമായി നോക്കാം (ഞാൻ നെയിംസ്‌പേസ് ക്യൂബ്-സിസ്റ്റം തിരഞ്ഞെടുത്തു - “ക്യൂബിന്റെ” ഘടകങ്ങൾക്കുള്ള സിസ്റ്റം നെയിംസ്‌പെയ്‌സ്) കൂടാതെ യഥാർത്ഥത്തിൽ ഉപയോഗിച്ച പ്രോസസ്സർ സമയത്തിന്റെയും മെമ്മറിയുടെയും അനുപാതം അഭ്യർത്ഥിച്ചതിന് നോക്കാം:

യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്നതിനേക്കാൾ കൂടുതൽ മെമ്മറിയും സിപിയുവും സിസ്റ്റം സേവനങ്ങൾക്കായി നീക്കിവച്ചിട്ടുണ്ടെന്ന് വ്യക്തമാണ്. ക്യൂബ്-സിസ്റ്റത്തിന്റെ കാര്യത്തിൽ, ഇത് ന്യായീകരിക്കപ്പെടുന്നു: nginx ഇൻഗ്രെസ്സ് കൺട്രോളർ അല്ലെങ്കിൽ nodelocaldns അവരുടെ ഉച്ചസ്ഥായിയിൽ CPU- യിൽ തട്ടി ധാരാളം റാം ഉപയോഗിച്ചു, അതിനാൽ ഇവിടെ അത്തരമൊരു കരുതൽ ന്യായീകരിക്കപ്പെടുന്നു. കൂടാതെ, കഴിഞ്ഞ 3 മണിക്കൂർ ചാർട്ടുകളെ ആശ്രയിക്കാൻ കഴിയില്ല: ഒരു വലിയ കാലയളവിൽ ചരിത്രപരമായ അളവുകൾ കാണുന്നത് അഭികാമ്യമാണ്.

"ശുപാർശകളുടെ" ഒരു സംവിധാനം വികസിപ്പിച്ചെടുത്തു. ഉദാഹരണത്തിന്, "പരിധികൾ" (മുകളിൽ അനുവദനീയമായ ബാർ) ഉയർത്തുന്നത് ഏതൊക്കെ റിസോഴ്സുകളാണ് നല്ലതെന്ന് ഇവിടെ നിങ്ങൾക്ക് കാണാൻ കഴിയും, അങ്ങനെ "ത്രോട്ടിലിംഗ്" ഉണ്ടാകില്ല: ഒരു റിസോഴ്സ് ഇതിനകം അനുവദിച്ച സമയ സ്ലൈസിൽ CPU അല്ലെങ്കിൽ മെമ്മറി ചെലവഴിച്ച നിമിഷം കൂടാതെ അത് "അൺഫ്രോസൺ" ആകുന്നതുവരെ കാത്തിരിക്കുന്നു:

അവരുടെ വിശപ്പ് നിയന്ത്രിക്കേണ്ട കായ്കൾ ഇതാ:

ഓൺ ത്രോട്ടിലിംഗ് + റിസോഴ്സ് മോണിറ്ററിംഗ്, നിങ്ങൾക്ക് ഒന്നിൽ കൂടുതൽ ലേഖനങ്ങൾ എഴുതാൻ കഴിയും, അതിനാൽ അഭിപ്രായങ്ങളിൽ ചോദ്യങ്ങൾ ചോദിക്കുക. കുറച്ച് വാക്കുകളിൽ, അത്തരം അളവുകൾ ഓട്ടോമേറ്റ് ചെയ്യുക എന്നത് വളരെ ബുദ്ധിമുട്ടുള്ള കാര്യമാണെന്ന് എനിക്ക് പറയാൻ കഴിയും, കൂടാതെ "വിൻഡോ" ഫംഗ്ഷനുകളും "സിടിഇ" പ്രൊമിത്യൂസ് / വിക്ടോറിയമെട്രിക്സും (ഏതാണ്ട് ഉള്ളതിനാൽ ഈ നിബന്ധനകൾ ഉദ്ധരണികളിലാണ്. PromQL-ൽ ഇതുപോലെ ഒന്നുമില്ല, കൂടാതെ നിങ്ങൾ ഭയപ്പെടുത്തുന്ന ചോദ്യങ്ങളെ ടെക്‌സ്‌റ്റിന്റെ നിരവധി സ്‌ക്രീനുകളായി വിഭജിക്കുകയും അവ ഒപ്റ്റിമൈസ് ചെയ്യുകയും വേണം).

തൽഫലമായി, ഡവലപ്പർമാർക്ക് ക്യൂബിൽ അവരുടെ നെയിംസ്‌പെയ്‌സുകൾ നിരീക്ഷിക്കുന്നതിനുള്ള ടൂളുകൾ ഉണ്ട്, കൂടാതെ ഏത് ആപ്ലിക്കേഷനുകൾക്ക് അവരുടെ ഉറവിടങ്ങൾ "കട്ട്" ചെയ്യാമെന്നും ഏത് സെർവറുകൾക്ക് രാത്രി മുഴുവൻ സിപിയു നൽകാമെന്നും അവർക്ക് സ്വയം തിരഞ്ഞെടുക്കാനും കഴിയും.

രീതിശാസ്ത്രങ്ങൾ

ഇപ്പോഴത്തെ പോലെ കമ്പനിയിൽ ഫാഷനബിൾ, ഞങ്ങൾ DevOps- കൂടാതെ SRE-പരിശീലകൻ ഒരു കമ്പനിക്ക് 1000 മൈക്രോസർവീസുകളും 350 ഓളം ഡെവലപ്പർമാരും മുഴുവൻ ഇൻഫ്രാസ്ട്രക്ചറിനായി 15 അഡ്മിൻമാരും ഉള്ളപ്പോൾ, നിങ്ങൾ “ഫാഷനബിൾ” ആയിരിക്കണം: ഈ “ബേസ്‌വേർഡുകൾ”ക്ക് പിന്നിൽ എല്ലാവരെയും എല്ലാവരെയും ഓട്ടോമേറ്റ് ചെയ്യേണ്ടത് അടിയന്തിര ആവശ്യമാണ്, മാത്രമല്ല അഡ്മിൻമാർ ഒരു തടസ്സമാകരുത്. പ്രക്രിയകളിൽ.

ഓപ്‌സ് എന്ന നിലയിൽ, സേവന പ്രതികരണ നിരക്കുകളുമായും പിശകുകളുമായും ബന്ധപ്പെട്ട ഡെവലപ്പർമാർക്കായി ഞങ്ങൾ വിവിധ അളവുകളും ഡാഷ്‌ബോർഡുകളും നൽകുന്നു.

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

ഒരു മാസമായി ഞാൻ ഗ്രാഫ് വരച്ചിട്ടില്ല. ഇത് ഒരുപക്ഷേ ഒരു നല്ല അടയാളമാണ്: ഇതിനർത്ഥം "ആഗ്രഹങ്ങൾ" മിക്കതും ഇതിനകം സാക്ഷാത്കരിച്ചിട്ടുണ്ട് എന്നാണ്. ആഴ്ചയിൽ ഞാൻ ദിവസത്തിൽ ഒരിക്കലെങ്കിലും പുതിയ ഗ്രാഫ് വരയ്ക്കുന്നത് സംഭവിച്ചു.

തത്ഫലമായുണ്ടാകുന്ന ഫലം വിലപ്പെട്ടതാണ്, കാരണം ഇപ്പോൾ ഡെവലപ്പർമാർ വളരെ അപൂർവ്വമായി "എവിടെ ചില മെട്രിക്സ് നോക്കണം" എന്ന ചോദ്യങ്ങളുമായി അഡ്മിനുകളിലേക്ക് പോകാറുണ്ട്.

നടപ്പിലാക്കൽ സേവന മെഷ് ഇത് വളരെ അടുത്താണ്, എല്ലാവർക്കും ജീവിതം വളരെ എളുപ്പമാക്കണം, ടൂളുകളിൽ നിന്നുള്ള സഹപ്രവർത്തകർ ഇതിനകം തന്നെ "ആരോഗ്യമുള്ള വ്യക്തിയുടെ ഇസ്തിയോ" എന്ന സംഗ്രഹം നടപ്പിലാക്കാൻ അടുത്തിരിക്കുന്നു: ഓരോ HTTP(കൾ) അഭ്യർത്ഥനയുടെയും ജീവിത ചക്രം നിരീക്ഷണത്തിൽ ദൃശ്യമാകും. ഇന്റർ-സർവീസ് (മാത്രമല്ല) ഇടപഴകുമ്പോൾ "ഏത് ഘട്ടത്തിലാണ് എല്ലാം തകർന്നത്" എന്ന് മനസ്സിലാക്കാൻ എപ്പോഴും സാധിക്കും. DomClick ഹബിൽ നിന്നുള്ള വാർത്തകൾ സബ്‌സ്‌ക്രൈബ് ചെയ്യുക. =)

കുബർനെറ്റസ് ഇൻഫ്രാസ്ട്രക്ചർ പിന്തുണ

ചരിത്രപരമായി, ഞങ്ങൾ പാച്ച് ചെയ്ത പതിപ്പ് ഉപയോഗിക്കുന്നു കുബേസ്പ്രേ - കുബർനെറ്റുകളെ വിന്യസിക്കുന്നതിനും വിപുലീകരിക്കുന്നതിനും അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനുമുള്ള പ്രധാന പങ്ക്. ചില ഘട്ടങ്ങളിൽ, നോൺ-കുബീഡ്ം ഇൻസ്റ്റാളേഷനുകൾക്കുള്ള പിന്തുണ പ്രധാന ബ്രാഞ്ചിൽ നിന്ന് വെട്ടിക്കുറച്ചു, കൂടാതെ kubeadm-ലേക്ക് മാറുന്ന പ്രക്രിയ നിർദ്ദേശിക്കപ്പെട്ടില്ല. തൽഫലമായി, സൗത്ത്ബ്രിഡ്ജ് കമ്പനി സ്വന്തം ഫോർക്ക് ഉണ്ടാക്കി (kubeadm പിന്തുണയോടെയും ഗുരുതരമായ പ്രശ്നങ്ങൾക്ക് പെട്ടെന്നുള്ള പരിഹാരവും).

എല്ലാ k8s ക്ലസ്റ്ററുകളും അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനുള്ള പ്രക്രിയ ഇതുപോലെ കാണപ്പെടുന്നു:

• എടുക്കുക കുബേസ്പ്രേ സൗത്ത്ബ്രിഡ്ജിൽ നിന്ന്, ഞങ്ങളുടെ ത്രെഡ്, മെർജിം പരിശോധിക്കുക.
• ഞങ്ങൾ അപ്ഡേറ്റ് പുറത്തിറക്കുന്നു സമ്മര്ദ്ദം- "ക്യൂബ്".
• ഞങ്ങൾ ഒരു സമയം ഒരു നോഡ് അപ്‌ഡേറ്റ് ചെയ്യുന്നു (അൻസിബിളിൽ ഇത് “സീരിയൽ: 1” ആണ്) ദേവ്- "ക്യൂബ്".
• ഞങ്ങൾ അപ്ഡേറ്റ് ചെയ്യുന്നു പ്രൊഡ ശനിയാഴ്ച വൈകുന്നേരം ഒരു സമയം ഒരു നോഡ്.

ഭാവിയിൽ ഇത് മാറ്റിസ്ഥാപിക്കാൻ പദ്ധതിയുണ്ട് കുബേസ്പ്രേ എന്തെങ്കിലും വേഗത്തിലാക്കി പോകുക kubeadm.

മൊത്തത്തിൽ ഞങ്ങൾക്ക് മൂന്ന് "ക്യൂബുകൾ" ഉണ്ട്: സമ്മർദ്ദം, ദേവ്, പ്രോഡ്. ഞങ്ങൾ മറ്റൊന്ന് സമാരംഭിക്കാൻ പദ്ധതിയിടുന്നു (ചൂടുള്ള സ്റ്റാൻഡ്ബൈ) രണ്ടാമത്തെ ഡാറ്റാ സെന്ററിൽ പ്രോഡ്-“ക്യൂബ്”. സമ്മര്ദ്ദം и ദേവ് "വെർച്വൽ മെഷീനുകളിൽ" ജീവിക്കുക (സമ്മർദ്ദത്തിനായുള്ള oVirt, ദേവിനുള്ള VMWare ക്ലൗഡ്). പ്രൊഡ- "ക്യൂബ്" "ബെയർ ​​മെറ്റലിൽ" ജീവിക്കുന്നു: ഇവ 32 സിപിയു ത്രെഡുകൾ, 64-128 ജിബി മെമ്മറി, 300 ജിബി എസ്എസ്ഡി റെയ്ഡ് 10 എന്നിവയുള്ള സമാന നോഡുകളാണ് - അവയിൽ ആകെ 50 എണ്ണം ഉണ്ട്. മൂന്ന് "നേർത്ത" നോഡുകൾ "മാസ്റ്റേഴ്സിന്" സമർപ്പിച്ചിരിക്കുന്നു പ്രൊഡ- "ക്യൂബ": 16 GB മെമ്മറി, 12 CPU ത്രെഡുകൾ.

വിൽപ്പനയ്ക്കായി, "ബെയർ ​​മെറ്റൽ" ഉപയോഗിക്കാനും അനാവശ്യമായ പാളികൾ ഒഴിവാക്കാനും ഞങ്ങൾ ഇഷ്ടപ്പെടുന്നു ഓപ്പൺസ്റ്റാക്ക്: ഞങ്ങൾക്ക് "ശബ്ദമുള്ള അയൽക്കാർ", CPU എന്നിവ ആവശ്യമില്ല സമയം മോഷ്ടിക്കുക. ഇൻ-ഹൗസ് ഓപ്പൺസ്റ്റാക്കിന്റെ കാര്യത്തിൽ അഡ്മിനിസ്ട്രേഷന്റെ സങ്കീർണ്ണത ഏകദേശം ഇരട്ടിയാകുന്നു.

CI/CD “ക്യൂബിക്”, മറ്റ് ഇൻഫ്രാസ്ട്രക്ചർ ഘടകങ്ങൾ എന്നിവയ്‌ക്കായി ഞങ്ങൾ ഒരു പ്രത്യേക GIT സെർവർ ഉപയോഗിക്കുന്നു, Helm 3 (ഇത് ഹെൽം 2-ൽ നിന്ന് വളരെ വേദനാജനകമായ ഒരു പരിവർത്തനമായിരുന്നു, എന്നാൽ ഓപ്ഷനുകളിൽ ഞങ്ങൾ വളരെ സന്തുഷ്ടരാണ്. ആറ്റോമിക), ജെങ്കിൻസ്, അൻസിബിൾ, ഡോക്കർ. ഫീച്ചർ ബ്രാഞ്ചുകളും ഒരു ശേഖരത്തിൽ നിന്ന് വ്യത്യസ്ത പരിതസ്ഥിതികളിലേക്കുള്ള വിന്യാസവും ഞങ്ങൾ ഇഷ്ടപ്പെടുന്നു.

തീരുമാനം

ഇത് പൊതുവായി പറഞ്ഞാൽ, ഒരു ഓപ്പറേഷൻസ് എഞ്ചിനീയറുടെ വീക്ഷണകോണിൽ നിന്ന് DomClick-ൽ DevOps പ്രോസസ്സ് എങ്ങനെയിരിക്കും. ലേഖനം ഞാൻ പ്രതീക്ഷിച്ചതിലും കുറഞ്ഞ സാങ്കേതികതയുള്ളതായി മാറി: അതിനാൽ, ഹബ്രെയിലെ DomClick വാർത്തകൾ പിന്തുടരുക: Kubernetes നെ കുറിച്ചും മറ്റും കൂടുതൽ "ഹാർഡ്‌കോർ" ലേഖനങ്ങൾ ഉണ്ടാകും.

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