K8S മൾട്ടിക്ലസ്റ്റർ യാത്ര

ഹേ ഹബർ!

ഞങ്ങൾ Exness പ്ലാറ്റ്ഫോം ടീമിനെ പ്രതിനിധീകരിക്കുന്നു. മുമ്പ്, ഞങ്ങളുടെ സഹപ്രവർത്തകർ ഇതിനകം ഒരു ലേഖനം എഴുതിയിട്ടുണ്ട് k8s-നുള്ള പ്രൊഡക്ഷൻ-റെഡി ഇമേജുകൾ. കുബർനെറ്റസിലേക്ക് മൈഗ്രേറ്റ് ചെയ്ത സേവനങ്ങളുടെ അനുഭവം ഇന്ന് ഞങ്ങൾ പങ്കിടാൻ ആഗ്രഹിക്കുന്നു.

ആരംഭിക്കുന്നതിന്, എന്താണ് ചർച്ച ചെയ്യപ്പെടുക എന്നതിനെക്കുറിച്ച് കൂടുതൽ നന്നായി മനസ്സിലാക്കാൻ ഞങ്ങൾ നിങ്ങൾക്ക് ചില നമ്പറുകൾ വാഗ്ദാനം ചെയ്യുന്നു:

• ഞങ്ങളുടെ ഡെവലപ്‌മെന്റ് ഡിപ്പാർട്ട്‌മെന്റിൽ 100-ലധികം ആളുകൾ ഉൾപ്പെടുന്നു, അതിൽ സ്വയം പര്യാപ്തമായ QA, DevOps, സ്‌ക്രം പ്രോസസ്സുകൾ എന്നിവയുള്ള 10-ലധികം വ്യത്യസ്ത ടീമുകൾ ഉൾപ്പെടുന്നു. ഡെവലപ്‌മെന്റ് സ്റ്റാക്ക് - പൈത്തൺ, PHP, C++, Java, Golang. 
• ടെസ്റ്റ്, പ്രൊഡക്ഷൻ പരിതസ്ഥിതികളുടെ വലിപ്പം ഏകദേശം 2000 കണ്ടെയ്നറുകൾ വീതമാണ്. അവർ സ്വന്തം വെർച്വലൈസേഷനിലും വിഎംവെയറിനു കീഴിലും Rancher v1.6 പ്രവർത്തിപ്പിക്കുന്നു. 

പ്രചോദനം

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

പ്രൊപ്രൈറ്ററി വെർച്വലൈസേഷൻ ഡാറ്റ സംഭരണത്തിലും അതിന്റെ സുരക്ഷയിലും കൂടുതൽ നിയന്ത്രണം നൽകിയെങ്കിലും, കമ്പനിയുടെ നിരന്തരമായ വളർച്ചയും പ്രോജക്റ്റുകളുടെ എണ്ണവും അവയ്ക്കുള്ള ആവശ്യകതകളും കണക്കിലെടുത്ത് അംഗീകരിക്കാൻ പ്രയാസമുള്ള പ്രവർത്തനച്ചെലവ് അത് ചുമത്തി.

IaC മാനദണ്ഡങ്ങൾ പാലിക്കാനും ആവശ്യമെങ്കിൽ, ഏത് ഭൂമിശാസ്ത്രപരമായ സ്ഥലത്തും വെണ്ടർ ലോക്ക് ഇല്ലാതെയും വേഗത്തിൽ ശേഷി നേടാനും അത് വേഗത്തിൽ ഉപേക്ഷിക്കാനും ഞങ്ങൾ ആഗ്രഹിച്ചു.

ആദ്യ ചുവടുകൾ

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

ക്ലസ്റ്ററുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു ഉപകരണം തിരഞ്ഞെടുക്കുന്നതിനുള്ള ചോദ്യം അടുത്തതായി വന്നു. ഞങ്ങൾ ഏറ്റവും ജനപ്രിയമായ പരിഹാരങ്ങൾ താരതമ്യം ചെയ്തു: kops, kubespray, kubeadm.

ആരംഭിക്കുന്നതിന്, kubeadm ഒരു "സൈക്കിളിന്റെ" കണ്ടുപിടുത്തക്കാരനെപ്പോലെ വളരെ സങ്കീർണ്ണമായ ഒരു പാതയാണെന്ന് ഞങ്ങൾക്ക് തോന്നി, കൂടാതെ കോപ്സിന് വേണ്ടത്ര വഴക്കമില്ലായിരുന്നു.

കൂടാതെ വിജയി ഇതായിരുന്നു:

ഞങ്ങൾ ഞങ്ങളുടെ സ്വന്തം വെർച്വലൈസേഷനും AWS-ഉം ഉപയോഗിച്ച് പരീക്ഷിക്കാൻ തുടങ്ങി, ഞങ്ങളുടെ മുമ്പത്തെ റിസോഴ്‌സ് മാനേജ്‌മെന്റ് പാറ്റേണിന് സമാനമായ ഒന്ന് പുനഃസൃഷ്ടിക്കാൻ ശ്രമിക്കുന്നു, അവിടെ എല്ലാവരും ഒരേ "ക്ലസ്റ്റർ" പങ്കിട്ടു. ഇപ്പോൾ ഞങ്ങളുടെ ആദ്യത്തെ 10 ചെറിയ വെർച്വൽ മെഷീനുകൾ ഉണ്ട്, അവയിൽ രണ്ടെണ്ണം AWS-ൽ സ്ഥിതിചെയ്യുന്നു. ഞങ്ങൾ അവിടെ ടീമുകളെ മൈഗ്രേറ്റ് ചെയ്യാൻ ശ്രമിച്ചു തുടങ്ങി, എല്ലാം "നല്ലത്" ആണെന്ന് തോന്നി, കഥ പൂർത്തിയാക്കാം, പക്ഷേ...

ആദ്യ പ്രശ്നങ്ങൾ

അൻസിബിൾ ആണ് kubespray നിർമ്മിച്ചിരിക്കുന്നത്, IaC പിന്തുടരാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു ഉപകരണമല്ല ഇത്: നോഡുകൾ കമ്മീഷൻ ചെയ്യുമ്പോൾ/ഡീകമ്മീഷൻ ചെയ്യുമ്പോൾ, നിരന്തരം എന്തെങ്കിലും തെറ്റ് സംഭവിക്കുകയും ചില ഇടപെടൽ ആവശ്യമായി വരികയും, വ്യത്യസ്ത OS-കൾ ഉപയോഗിക്കുമ്പോൾ, പ്ലേബുക്ക് വ്യത്യസ്തമായി പെരുമാറുകയും ചെയ്തു. . ക്ലസ്റ്ററിലെ ടീമുകളുടെയും നോഡുകളുടെയും എണ്ണം വർദ്ധിക്കുന്നതിനനുസരിച്ച്, പ്ലേബുക്ക് പൂർത്തിയാക്കാൻ കൂടുതൽ സമയമെടുക്കുന്നതായി ഞങ്ങൾ ശ്രദ്ധിക്കാൻ തുടങ്ങി, അതിന്റെ ഫലമായി ഞങ്ങളുടെ റെക്കോർഡ് 3,5 മണിക്കൂറായിരുന്നു, നിങ്ങളുടെ കാര്യമോ? 🙂

കുബെസ്പ്രേ വെറും അൻസിബിൾ ആണെന്ന് തോന്നുന്നു, ഒറ്റനോട്ടത്തിൽ എല്ലാം വ്യക്തമാണ്, പക്ഷേ:

യാത്രയുടെ തുടക്കത്തിൽ, AWS-ലും വെർച്വലൈസേഷനിലും മാത്രം ശേഷി സമാരംഭിക്കുക എന്നതായിരുന്നു ചുമതല, എന്നാൽ പലപ്പോഴും സംഭവിക്കുന്നത് പോലെ, ആവശ്യകതകൾ മാറി.
 


ഇതിന്റെ വെളിച്ചത്തിൽ, ഒരു ഓർക്കസ്ട്രേഷൻ സിസ്റ്റത്തിലേക്ക് വിഭവങ്ങൾ സംയോജിപ്പിക്കുന്ന ഞങ്ങളുടെ പഴയ രീതി അനുയോജ്യമല്ലെന്ന് വ്യക്തമായി - ക്ലസ്റ്ററുകൾ വളരെ വിദൂരവും വ്യത്യസ്ത ദാതാക്കൾ കൈകാര്യം ചെയ്യുന്നതുമായ സാഹചര്യത്തിൽ 

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

ജീവനക്കാർക്കുള്ള അവകാശങ്ങൾ നൽകുന്നതാണ് ഒരു പ്രത്യേക കഥ: ഓരോ ടീമും ക്ലസ്റ്ററിന്റെ "തലയിൽ" ആയിരിക്കാനും അത് പൂർണ്ണമായും നിയന്ത്രിക്കാനും ആഗ്രഹിച്ചു, ഇത് പൂർണ്ണമായ തകർച്ചയ്ക്ക് കാരണമാകും, കാരണം ടീമുകൾ അടിസ്ഥാനപരമായി പരസ്പരം സ്വതന്ത്രമാണ്.

എങ്ങനെ?

മുകളിൽ പറഞ്ഞ കാര്യങ്ങളും കൂടുതൽ സ്വതന്ത്രരാകാനുള്ള ടീമുകളുടെ ആഗ്രഹങ്ങളും കണക്കിലെടുത്ത് ഞങ്ങൾ ഒരു ലളിതമായ നിഗമനത്തിലെത്തി: ഒരു ടീം - ഒരു ക്ലസ്റ്റർ. 

അതിനാൽ ഞങ്ങൾക്ക് രണ്ടാമത്തേത് ലഭിച്ചു:

പിന്നെ മൂന്നാമത്തെ ക്ലസ്റ്റർ: 

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

മുഴുവൻ കുബർനെറ്റുകളും വരും! ഇത് ഒരുതരം MultiKubernetes ആണ്, അത് മാറുന്നു. 

അതേ സമയം, നമുക്കെല്ലാവർക്കും ഈ ക്ലസ്റ്ററുകളെല്ലാം എങ്ങനെയെങ്കിലും പരിപാലിക്കേണ്ടതുണ്ട്, അവയിലേക്കുള്ള ആക്‌സസ് എളുപ്പത്തിൽ കൈകാര്യം ചെയ്യാൻ കഴിയും, അതുപോലെ തന്നെ പുതിയവ സൃഷ്‌ടിക്കുകയും സ്വമേധയാലുള്ള ഇടപെടലില്ലാതെ പഴയവ ഡീകമ്മീഷൻ ചെയ്യുകയും വേണം.

കുബെർനെറ്റസ് ലോകത്തേക്കുള്ള ഞങ്ങളുടെ യാത്രയുടെ തുടക്കം മുതൽ കുറച്ച് സമയം കടന്നുപോയി, ലഭ്യമായ പരിഹാരങ്ങൾ വീണ്ടും പരിശോധിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ഇത് ഇതിനകം വിപണിയിൽ നിലവിലുണ്ടെന്ന് മനസ്സിലായി - റാഞ്ചർ 2.2.

ഞങ്ങളുടെ ഗവേഷണത്തിന്റെ ആദ്യ ഘട്ടത്തിൽ, റാഞ്ചർ ലാബ്‌സ് പതിപ്പ് 2 ന്റെ ആദ്യ പതിപ്പ് ഇതിനകം തന്നെ നടത്തിയിരുന്നു, എന്നാൽ രണ്ട് പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് ബാഹ്യ ഡിപൻഡൻസികളില്ലാതെ ഒരു കണ്ടെയ്‌നർ ലോഞ്ച് ചെയ്‌തോ അല്ലെങ്കിൽ ഔദ്യോഗിക HELM ചാർട്ട് ഉപയോഗിച്ചോ ഇത് വളരെ വേഗത്തിൽ ഉയർത്താനാകുമെങ്കിലും, അത് അസംസ്‌കൃതമാണെന്ന് തോന്നി. ഞങ്ങൾക്ക്, ഈ തീരുമാനം വികസിപ്പിക്കപ്പെടുമോ അതോ പെട്ടെന്ന് ഉപേക്ഷിക്കപ്പെടുമോ എന്ന് ഞങ്ങൾക്ക് ആശ്രയിക്കാനാകുമോ എന്ന് ഞങ്ങൾക്ക് അറിയില്ലായിരുന്നു. UI-ലെ ക്ലസ്റ്റർ = ക്ലിക്കുകളുടെ മാതൃകയും ഞങ്ങൾക്ക് അനുയോജ്യമല്ല, മാത്രമല്ല RKE-യുമായി ബന്ധിപ്പിക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചില്ല, കാരണം ഇത് വളരെ ഇടുങ്ങിയ കേന്ദ്രീകൃത ഉപകരണമാണ്. 

റാഞ്ചർ 2.2 പതിപ്പിന് ഇതിനകം തന്നെ കൂടുതൽ പ്രവർത്തനക്ഷമമായ രൂപമുണ്ടായിരുന്നു, മുമ്പത്തേതിനൊപ്പം, നിരവധി ബാഹ്യ ദാതാക്കളുമായുള്ള സംയോജനം, അവകാശങ്ങളുടെയും kubeconfig ഫയലുകളുടെയും ഒരൊറ്റ പോയിന്റ് വിതരണം, ഒരു kubectl സമാരംഭിക്കൽ എന്നിങ്ങനെയുള്ള രസകരമായ ഒരു കൂട്ടം സവിശേഷതകൾ ഉണ്ടായിരുന്നു. യുഐയിലെ നിങ്ങളുടെ അവകാശങ്ങളുള്ള ചിത്രം, നെസ്റ്റഡ് നെയിംസ്‌പെയ്‌സ് അല്ലെങ്കിൽ പ്രോജക്‌റ്റുകൾ. 

Rancher 2 ന് ചുറ്റും ഇതിനകം തന്നെ ഒരു കമ്മ്യൂണിറ്റി രൂപീകരിച്ചിരുന്നു, അത് കൈകാര്യം ചെയ്യുന്നതിനായി HashiCorp Terraform എന്നൊരു ദാതാവ് സൃഷ്ടിക്കപ്പെട്ടു, ഇത് എല്ലാം ഒരുമിച്ച് ചേർക്കാൻ ഞങ്ങളെ സഹായിച്ചു.

എന്ത് സംഭവിച്ചു

തൽഫലമായി, റാഞ്ചർ പ്രവർത്തിപ്പിക്കുന്ന ഒരു ചെറിയ ക്ലസ്റ്ററിൽ ഞങ്ങൾ അവസാനിച്ചു, മറ്റെല്ലാ ക്ലസ്റ്ററുകൾക്കും അതുമായി ബന്ധിപ്പിച്ചിരിക്കുന്ന നിരവധി ക്ലസ്റ്ററുകൾക്കും ആക്‌സസ് ചെയ്യാനാകും, അവയിലേതെങ്കിലും ആക്‌സസ്സ് ldap ഡയറക്‌ടറിയിലേക്ക് ഒരു ഉപയോക്താവിനെ ചേർക്കുന്നത് പോലെ തന്നെ അനുവദിക്കാം. അത് എവിടെയാണ് സ്ഥിതിചെയ്യുന്നത്, ഏത് ദാതാവിന്റെ ഉറവിടങ്ങളാണ് അത് ഉപയോഗിക്കുന്നത്.

gitlab-ci, Terraform എന്നിവ ഉപയോഗിച്ച്, ക്ലൗഡ് ദാതാക്കളിലോ ഞങ്ങളുടെ സ്വന്തം ഇൻഫ്രാസ്ട്രക്ചറിലോ ഏതെങ്കിലും കോൺഫിഗറേഷന്റെ ഒരു ക്ലസ്റ്റർ സൃഷ്ടിക്കാനും അവയെ റാഞ്ചറുമായി ബന്ധിപ്പിക്കാനും നിങ്ങളെ അനുവദിക്കുന്ന ഒരു സിസ്റ്റം സൃഷ്ടിച്ചു. ഇതെല്ലാം IaC ശൈലിയിലാണ് ചെയ്യുന്നത്, അവിടെ ഓരോ ക്ലസ്റ്ററും ഒരു ശേഖരം വിവരിക്കുകയും അതിന്റെ അവസ്ഥ പതിപ്പിക്കുകയും ചെയ്യുന്നു. അതേ സമയം, മിക്ക മൊഡ്യൂളുകളും ബാഹ്യ ശേഖരണങ്ങളിൽ നിന്ന് ബന്ധിപ്പിച്ചിരിക്കുന്നു, അതിനാൽ അവശേഷിക്കുന്നത് വേരിയബിളുകൾ കൈമാറുകയോ അല്ലെങ്കിൽ നിങ്ങളുടെ ഇഷ്‌ടാനുസൃത കോൺഫിഗറേഷൻ വിവരിക്കുകയോ ആണ്, ഇത് കോഡ് ആവർത്തനത്തിന്റെ ശതമാനം കുറയ്ക്കാൻ സഹായിക്കുന്നു.

തീർച്ചയായും, ഞങ്ങളുടെ യാത്ര അവസാനിച്ചിട്ടില്ല, ഏതെങ്കിലും ക്ലസ്റ്ററുകളുടെ ലോഗുകളും മെട്രിക്‌സും ഉള്ള ഒരൊറ്റ പോയിന്റ് വർക്ക്, സർവീസ് മെഷ്, മൾട്ടിക്ലസ്റ്ററിലെ ലോഡുകൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള ജിടോപ്പുകൾ എന്നിവയും അതിലേറെയും പോലുള്ള രസകരമായ നിരവധി ജോലികൾ ഇനിയും മുന്നിലുണ്ട്. ഞങ്ങളുടെ അനുഭവം നിങ്ങൾക്ക് രസകരമാണെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു! 

എ. ആന്റിപോവ്, എ. ഗനുഷ്, പ്ലാറ്റ്ഫോം എഞ്ചിനീയർമാരാണ് ലേഖനം എഴുതിയത്. 

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