GitLab.com-നെ കുബർനെറ്റസിലേക്ക് മൈഗ്രേറ്റ് ചെയ്‌ത ഒരു വർഷത്തിൽ നിന്നുള്ള ഞങ്ങളുടെ കണ്ടെത്തലുകൾ

കുറിപ്പ്. വിവർത്തനം.: GitLab-ൽ Kubernetes ദത്തെടുക്കൽ കമ്പനിയുടെ വളർച്ചയ്ക്ക് സംഭാവന നൽകുന്ന രണ്ട് പ്രധാന ഘടകങ്ങളിൽ ഒന്നായി കണക്കാക്കപ്പെടുന്നു. എന്നിരുന്നാലും, അടുത്തിടെ വരെ, GitLab.com ഓൺലൈൻ സേവനത്തിന്റെ ഇൻഫ്രാസ്ട്രക്ചർ വെർച്വൽ മെഷീനുകളിലാണ് നിർമ്മിച്ചിരിക്കുന്നത്, ഏകദേശം ഒരു വർഷം മുമ്പ് മാത്രമാണ് K8-കളിലേക്കുള്ള മൈഗ്രേഷൻ ആരംഭിച്ചത്, അത് ഇപ്പോഴും പൂർത്തിയായിട്ടില്ല. ഇത് എങ്ങനെ സംഭവിക്കുന്നു, പ്രോജക്റ്റിൽ പങ്കെടുക്കുന്ന എഞ്ചിനീയർമാർ എന്ത് നിഗമനങ്ങളിൽ എത്തിച്ചേരുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഒരു GitLab SRE എഞ്ചിനീയറുടെ സമീപകാല ലേഖനത്തിന്റെ വിവർത്തനം അവതരിപ്പിക്കുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട്.

ഏകദേശം ഒരു വർഷമായി, ഞങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ വിഭാഗം GitLab.com-ൽ പ്രവർത്തിക്കുന്ന എല്ലാ സേവനങ്ങളും Kubernetes-ലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുന്നു. ഈ സമയത്ത്, കുബർനെറ്റസിലേക്ക് സേവനങ്ങൾ മാറ്റുന്നതുമായി ബന്ധപ്പെട്ട് മാത്രമല്ല, പരിവർത്തന സമയത്ത് ഹൈബ്രിഡ് വിന്യാസം കൈകാര്യം ചെയ്യുന്നതുമായി ബന്ധപ്പെട്ട വെല്ലുവിളികൾ ഞങ്ങൾ നേരിട്ടു. നാം പഠിച്ച വിലപ്പെട്ട പാഠങ്ങൾ ഈ ലേഖനത്തിൽ ചർച്ചചെയ്യും.

GitLab.com-ന്റെ തുടക്കം മുതൽ, അതിന്റെ സെർവറുകൾ വെർച്വൽ മെഷീനുകളിൽ ക്ലൗഡിൽ പ്രവർത്തിച്ചു. ഈ വെർച്വൽ മെഷീനുകൾ ഷെഫ് നിയന്ത്രിക്കുകയും ഞങ്ങളുടെ ഉപയോഗിച്ച് ഇൻസ്റ്റാൾ ചെയ്യുകയും ചെയ്യുന്നു ഔദ്യോഗിക Linux പാക്കേജ്. വിന്യാസ തന്ത്രം ആപ്ലിക്കേഷൻ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, സിഐ പൈപ്പ്‌ലൈൻ ഉപയോഗിച്ച് ഏകോപിപ്പിച്ചതും ക്രമാനുഗതവുമായ രീതിയിൽ സെർവർ ഫ്ലീറ്റ് അപ്‌ഡേറ്റ് ചെയ്യുന്നത് ഉൾക്കൊള്ളുന്നു. ഈ രീതി - മന്ദഗതിയിലാണെങ്കിലും അൽപ്പം ബോറടിപ്പിക്കുന്ന - GitLab.com ഓഫ്‌ലൈൻ ഉപയോക്താക്കളുടെ അതേ ഇൻസ്റ്റാളേഷനും കോൺഫിഗറേഷൻ രീതികളും ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുന്നു (സ്വയം നിയന്ത്രിത) ഇതിനായി ഞങ്ങളുടെ Linux പാക്കേജുകൾ ഉപയോഗിക്കുന്ന GitLab ഇൻസ്റ്റാളേഷനുകൾ.

GitLab-ന്റെ പകർപ്പുകൾ ഇൻസ്റ്റാൾ ചെയ്യുകയും കോൺഫിഗർ ചെയ്യുകയും ചെയ്യുമ്പോൾ കമ്മ്യൂണിറ്റിയിലെ സാധാരണ അംഗങ്ങൾ അനുഭവിക്കുന്ന എല്ലാ ദുഃഖങ്ങളും സന്തോഷങ്ങളും അനുഭവിക്കേണ്ടത് വളരെ പ്രധാനമായതിനാൽ ഞങ്ങൾ ഈ രീതി ഉപയോഗിക്കുന്നു. ഈ സമീപനം കുറച്ച് സമയത്തേക്ക് നന്നായി പ്രവർത്തിച്ചു, എന്നാൽ GitLab-ലെ പ്രോജക്റ്റുകളുടെ എണ്ണം 10 ദശലക്ഷം കവിഞ്ഞപ്പോൾ, അത് സ്കെയിലിംഗിനും വിന്യാസത്തിനുമുള്ള ഞങ്ങളുടെ ആവശ്യങ്ങൾ നിറവേറ്റുന്നില്ലെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി.

കുബർനെറ്റസിലേക്കും ക്ലൗഡ്-നേറ്റീവ് GitLab-ലേക്കുള്ള ആദ്യ ചുവടുകളും

2017 ലാണ് പദ്ധതി രൂപീകരിച്ചത് GitLab ചാർട്ടുകൾ ക്ലൗഡ് വിന്യാസത്തിനായി GitLab തയ്യാറാക്കുന്നതിനും Kubernetes ക്ലസ്റ്ററുകളിൽ GitLab ഇൻസ്റ്റാൾ ചെയ്യാൻ ഉപയോക്താക്കളെ പ്രാപ്തരാക്കുന്നതിനും. GitLab കുബർനെറ്റസിലേക്ക് മാറ്റുന്നത് SaaS പ്ലാറ്റ്‌ഫോമിന്റെ സ്കേലബിളിറ്റി വർദ്ധിപ്പിക്കുമെന്നും വിന്യാസങ്ങൾ ലളിതമാക്കുമെന്നും കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളുടെ കാര്യക്ഷമത മെച്ചപ്പെടുത്തുമെന്നും ഞങ്ങൾക്കറിയാമായിരുന്നു. അതേ സമയം, ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ പല പ്രവർത്തനങ്ങളും മൌണ്ട് ചെയ്ത NFS പാർട്ടീഷനുകളെ ആശ്രയിച്ചിരിക്കുന്നു, ഇത് വെർച്വൽ മെഷീനുകളിൽ നിന്നുള്ള പരിവർത്തനത്തെ മന്ദഗതിയിലാക്കി.

ക്ലൗഡ് നേറ്റീവ്, കുബർനെറ്റ്സ് എന്നിവയിലേക്കുള്ള പുഷ് ഞങ്ങളുടെ എഞ്ചിനീയർമാരെ ക്രമാനുഗതമായ പരിവർത്തനം ആസൂത്രണം ചെയ്യാൻ അനുവദിച്ചു, ഈ സമയത്ത് പുതിയ സവിശേഷതകൾ വികസിപ്പിക്കുന്നത് തുടരുന്നതിനിടയിൽ ഞങ്ങൾ നെറ്റ്‌വർക്ക് സ്റ്റോറേജിലുള്ള ആപ്ലിക്കേഷന്റെ ചില ഡിപൻഡൻസികൾ ഉപേക്ഷിച്ചു. 2019-ലെ വേനൽക്കാലത്ത് ഞങ്ങൾ മൈഗ്രേഷൻ ആസൂത്രണം ചെയ്യാൻ തുടങ്ങിയതുമുതൽ, ഈ പരിമിതികളിൽ പലതും പരിഹരിച്ചു, കൂടാതെ GitLab.com-നെ Kubernetes-ലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുന്ന പ്രക്രിയ ഇപ്പോൾ നന്നായി നടന്നുകൊണ്ടിരിക്കുകയാണ്!

കുബർനെറ്റസിലെ GitLab.com-ന്റെ സവിശേഷതകൾ

GitLab.com-നായി, എല്ലാ ആപ്ലിക്കേഷൻ ട്രാഫിക്കും കൈകാര്യം ചെയ്യുന്ന ഒരൊറ്റ പ്രാദേശിക GKE ക്ലസ്റ്റർ ഞങ്ങൾ ഉപയോഗിക്കുന്നു. (ഇതിനകം തന്ത്രപ്രധാനമായ) മൈഗ്രേഷന്റെ സങ്കീർണ്ണത കുറയ്ക്കുന്നതിന്, പ്രാദേശിക സംഭരണത്തെയോ NFS-നെയോ ആശ്രയിക്കാത്ത സേവനങ്ങളിൽ ഞങ്ങൾ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു. GitLab.com പ്രധാനമായും മോണോലിത്തിക്ക് റെയിൽസ് കോഡ്ബേസ് ഉപയോഗിക്കുന്നു, കൂടാതെ വർക്ക് ലോഡ് സ്വഭാവസവിശേഷതകളെ അടിസ്ഥാനമാക്കി ഞങ്ങൾ ട്രാഫിക്കിനെ അവരുടെ സ്വന്തം നോഡ് പൂളുകളിലേക്ക് വേർതിരിച്ചിരിക്കുന്ന വ്യത്യസ്ത എൻഡ് പോയിന്റുകളിലേക്ക് നയിക്കും.

മുൻഭാഗത്തിന്റെ കാര്യത്തിൽ, ഈ തരങ്ങളെ വെബ്, API, Git SSH/HTTPS, രജിസ്ട്രി എന്നിവയിലേക്കുള്ള അഭ്യർത്ഥനകളായി തിരിച്ചിരിക്കുന്നു. ബാക്കെൻഡിന്റെ കാര്യത്തിൽ, വിവിധ സ്വഭാവസവിശേഷതകൾ അനുസരിച്ച് ഞങ്ങൾ ക്യൂവിലെ ജോലികൾ വിഭജിക്കുന്നു മുൻകൂട്ടി നിശ്ചയിച്ച വിഭവ അതിരുകൾ, വിവിധ ജോലിഭാരങ്ങൾക്കായി സേവന-തല ലക്ഷ്യങ്ങൾ (SLOs) സജ്ജമാക്കാൻ ഇത് ഞങ്ങളെ അനുവദിക്കുന്നു.

ഈ GitLab.com സേവനങ്ങളെല്ലാം പരിഷ്‌ക്കരിക്കാത്ത GitLab ഹെൽം ചാർട്ട് ഉപയോഗിച്ചാണ് ക്രമീകരിച്ചിരിക്കുന്നത്. കോൺഫിഗറേഷൻ സബ്‌ചാർട്ടുകളിലാണ് നടപ്പിലാക്കുന്നത്, ഞങ്ങൾ സേവനങ്ങൾ ക്ലസ്റ്ററിലേക്ക് ക്രമേണ മൈഗ്രേറ്റ് ചെയ്യുമ്പോൾ തിരഞ്ഞെടുത്ത് പ്രവർത്തനക്ഷമമാക്കാം. Redis, Postgres, GitLab പേജുകൾ, Gitaly എന്നിവ പോലെയുള്ള ഞങ്ങളുടെ ചില സ്റ്റേറ്റ്ഫുൾ സേവനങ്ങൾ മൈഗ്രേഷനിൽ ഉൾപ്പെടുത്തേണ്ടെന്ന് ഞങ്ങൾ തീരുമാനിച്ചെങ്കിലും, Kubernetes ഉപയോഗിക്കുന്നത് ഷെഫ് നിലവിൽ കൈകാര്യം ചെയ്യുന്ന VM-കളുടെ എണ്ണം സമൂലമായി കുറയ്ക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു.

Kubernetes കോൺഫിഗറേഷൻ ദൃശ്യപരതയും മാനേജ്മെന്റും

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

Kubernetes ക്ലസ്റ്ററിനായുള്ള ഞങ്ങളുടെ പൈപ്പ്‌ലൈനുകൾ ഒരു പ്രത്യേക GitLab ഇൻസ്റ്റാളേഷനിൽ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും, ഇനിപ്പറയുന്ന വിലാസങ്ങളിൽ പൊതുവായി ലഭ്യമായ കോഡ് ശേഖരണങ്ങളുടെ മിററുകൾ ഉണ്ട്:

• k8s-workloads/gitlab-com - GitLab ഹെൽം ചാർട്ടിനായുള്ള GitLab.com കോൺഫിഗറേഷൻ ഫ്രെയിംവർക്ക്;
• k8s-workloads/gitlab-helmfiles - GitLab ആപ്ലിക്കേഷനുമായി നേരിട്ട് ബന്ധമില്ലാത്ത സേവനങ്ങൾക്കായുള്ള കോൺഫിഗറേഷനുകൾ അടങ്ങിയിരിക്കുന്നു. ലോഗിംഗിനും ക്ലസ്റ്റർ നിരീക്ഷണത്തിനുമുള്ള കോൺഫിഗറേഷനുകളും PlantUML പോലുള്ള സംയോജിത ഉപകരണങ്ങളും ഇതിൽ ഉൾപ്പെടുന്നു;
• Gitlab-com-infrastructure - കുബർനെറ്റസിനും ലെഗസി വിഎം ഇൻഫ്രാസ്ട്രക്ചറിനും ടെറാഫോം കോൺഫിഗറേഷൻ. ക്ലസ്റ്റർ, നോഡ് പൂളുകൾ, സർവീസ് അക്കൌണ്ടുകൾ, ഐപി അഡ്രസ് റിസർവേഷനുകൾ എന്നിവയുൾപ്പെടെ ക്ലസ്റ്റർ പ്രവർത്തിപ്പിക്കുന്നതിന് ആവശ്യമായ എല്ലാ ഉറവിടങ്ങളും ഇവിടെ നിങ്ങൾ കോൺഫിഗർ ചെയ്യുന്നു.

മാറ്റങ്ങൾ വരുത്തുമ്പോൾ പൊതു കാഴ്ച കാണിക്കുന്നു. ഹ്രസ്വ സംഗ്രഹം ക്ലസ്റ്ററിൽ മാറ്റങ്ങൾ വരുത്തുന്നതിന് മുമ്പ് SRE വിശകലനം ചെയ്യുന്ന വിശദമായ വ്യത്യാസത്തിലേക്കുള്ള ലിങ്ക് സഹിതം.

SRE-യ്‌ക്കായി, ലിങ്ക് GitLab ഇൻസ്റ്റാളേഷനിൽ വിശദമായ വ്യത്യാസത്തിലേക്ക് നയിക്കുന്നു, ഇത് ഉൽപ്പാദനത്തിനും പരിമിതമായ ആക്‌സസ്സിനും ഉപയോഗിക്കുന്നു. ഓപ്പറേഷണൽ പ്രോജക്‌റ്റിലേക്ക് ആക്‌സസ് ഇല്ലാതെ ജീവനക്കാർക്കും കമ്മ്യൂണിറ്റിക്കും ഇത് അനുവദിക്കുന്നു (ഇത് SRE-കൾക്ക് മാത്രം തുറന്നിരിക്കുന്നു), നിർദ്ദിഷ്ട കോൺഫിഗറേഷൻ മാറ്റങ്ങൾ കാണുന്നതിന്. CI പൈപ്പ്‌ലൈനുകൾക്കുള്ള ഒരു സ്വകാര്യ ഉദാഹരണവുമായി കോഡിനായി ഒരു പൊതു GitLab ഉദാഹരണം സംയോജിപ്പിക്കുന്നതിലൂടെ, കോൺഫിഗറേഷൻ അപ്‌ഡേറ്റുകൾക്കായി GitLab.com-ൽ നിന്നുള്ള സ്വാതന്ത്ര്യം ഉറപ്പാക്കുമ്പോൾ ഞങ്ങൾ ഒരൊറ്റ വർക്ക്ഫ്ലോ നിലനിർത്തുന്നു.

കുടിയേറ്റത്തിനിടയിൽ ഞങ്ങൾ കണ്ടെത്തിയത്

കുബെർനെറ്റസിലെ പുതിയ കുടിയേറ്റങ്ങൾക്കും വിന്യാസങ്ങൾക്കും ഞങ്ങൾ ബാധകമാകുന്ന അനുഭവം ഈ നീക്കത്തിനിടയിൽ ലഭിച്ചു.

1. ലഭ്യത മേഖലകൾക്കിടയിലുള്ള ട്രാഫിക് കാരണം വർദ്ധിച്ച ചെലവ്

GitLab.com-ലെ Git റിപ്പോസിറ്ററി ഫ്ലീറ്റിനായുള്ള പ്രതിദിന എക്ഗ്രസ് സ്ഥിതിവിവരക്കണക്കുകൾ (പ്രതിദിനം ബൈറ്റുകൾ)

ഗൂഗിൾ അതിന്റെ നെറ്റ്‌വർക്കിനെ പ്രദേശങ്ങളായി വിഭജിക്കുന്നു. അവ, പ്രവേശനക്ഷമത സോണുകളായി (AZ) തിരിച്ചിരിക്കുന്നു. Git ഹോസ്റ്റിംഗ് വലിയ അളവിലുള്ള ഡാറ്റയുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, അതിനാൽ നെറ്റ്‌വർക്ക് എഗ്രസ് നിയന്ത്രിക്കേണ്ടത് ഞങ്ങൾക്ക് പ്രധാനമാണ്. ആന്തരിക ട്രാഫിക്കിന്, ഒരേ ലഭ്യത സോണിൽ തന്നെ തുടരുകയാണെങ്കിൽ മാത്രമേ എക്‌സ് സൗജന്യമാകൂ. ഇത് എഴുതുമ്പോൾ, ഞങ്ങൾ ഒരു സാധാരണ പ്രവൃത്തിദിനത്തിൽ ഏകദേശം 100 TB ഡാറ്റ നൽകുന്നു (അത് Git റിപ്പോസിറ്ററികൾക്ക് മാത്രമുള്ളതാണ്). ഞങ്ങളുടെ പഴയ VM-അധിഷ്‌ഠിത ടോപ്പോളജിയിലെ അതേ വെർച്വൽ മെഷീനുകളിൽ താമസിച്ചിരുന്ന സേവനങ്ങൾ ഇപ്പോൾ വ്യത്യസ്ത കുബർനെറ്റസ് പോഡുകളിൽ പ്രവർത്തിക്കുന്നു. ഇതിനർത്ഥം VM-ന് മുമ്പ് പ്രാദേശികമായിരുന്ന ചില ട്രാഫിക്ക് ലഭ്യത മേഖലകൾക്ക് പുറത്ത് സഞ്ചരിക്കാൻ സാധ്യതയുണ്ട് എന്നാണ്.

റിഡൻഡൻസിക്കായി ഒന്നിലധികം ലഭ്യത സോണുകൾ വ്യാപിപ്പിക്കാൻ റീജിയണൽ GKE ക്ലസ്റ്ററുകൾ നിങ്ങളെ അനുവദിക്കുന്നു. ഞങ്ങൾ സാധ്യത പരിഗണിക്കുന്നു പ്രാദേശിക GKE ക്ലസ്റ്ററിനെ സിംഗിൾ സോൺ ക്ലസ്റ്ററുകളായി വിഭജിക്കുക വലിയ അളവിൽ ട്രാഫിക് സൃഷ്ടിക്കുന്ന സേവനങ്ങൾക്ക്. ഇത് ക്ലസ്റ്റർ ലെവൽ റിഡൻഡൻസി നിലനിർത്തിക്കൊണ്ടുതന്നെ എഗ്രസ് ചെലവ് കുറയ്ക്കും.

2. പരിധികൾ, വിഭവ അഭ്യർത്ഥനകൾ, സ്കെയിലിംഗ്

registry.gitlab.com-ൽ പ്രൊഡക്ഷൻ ട്രാഫിക് പ്രോസസ്സ് ചെയ്യുന്ന പകർപ്പുകളുടെ എണ്ണം. ~15:00 UTC-ന് ട്രാഫിക് പീക്ക്.

ഞങ്ങളുടെ മൈഗ്രേഷൻ സ്റ്റോറി ആരംഭിച്ചത് 2019 ഓഗസ്റ്റിൽ, ഞങ്ങളുടെ ആദ്യ സേവനമായ GitLab കണ്ടെയ്‌നർ രജിസ്‌ട്രി, Kubernetes-ലേക്ക് മൈഗ്രേറ്റ് ചെയ്‌തതോടെയാണ്. ഈ ദൗത്യ-നിർണ്ണായകവും ഉയർന്ന ട്രാഫിക്കുള്ളതുമായ സേവനം ആദ്യത്തെ മൈഗ്രേഷനുള്ള ഒരു നല്ല തിരഞ്ഞെടുപ്പായിരുന്നു, കാരണം ഇത് കുറച്ച് ബാഹ്യ ആശ്രയത്വങ്ങളുള്ള ഒരു സ്‌റ്റേറ്റ്‌ലെസ് ആപ്ലിക്കേഷനാണ്. നോഡുകളിൽ മെമ്മറി കുറവായതിനാൽ പുറത്താക്കപ്പെട്ട ധാരാളം പോഡുകളാണ് ഞങ്ങൾ നേരിട്ട ആദ്യത്തെ പ്രശ്നം. ഇക്കാരണത്താൽ, ഞങ്ങൾക്ക് അഭ്യർത്ഥനകളും പരിധികളും മാറ്റേണ്ടി വന്നു.

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

3. മെട്രിക്സും ലോഗുകളും

ഇൻഫ്രാസ്ട്രക്ചർ ഡിവിഷൻ ലേറ്റൻസി, പിശക് നിരക്കുകൾ, ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള സാച്ചുറേഷൻ എന്നിവയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു സേവന നില ലക്ഷ്യങ്ങൾ (SLO) എന്നതിലേക്ക് ബന്ധിപ്പിച്ചിരിക്കുന്നു ഞങ്ങളുടെ സിസ്റ്റത്തിന്റെ പൊതുവായ ലഭ്യത.

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

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

പഴയ VM ഇൻഫ്രാസ്ട്രക്ചറിലും പുതിയ കുബർനെറ്റസ് അധിഷ്ഠിത ഇൻഫ്രാസ്ട്രക്ചറിനും സമാന്തരമായി ഒരേ അഭ്യർത്ഥനകൾ നൽകുന്നത് ഒരു സവിശേഷമായ വെല്ലുവിളിയാണ്. ലിഫ്റ്റ് ആൻഡ് ഷിഫ്റ്റ് മൈഗ്രേഷൻ പോലെയല്ല (ഒരു പുതിയ ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് "ആയിരിക്കുന്നതുപോലെ" ആപ്ലിക്കേഷനുകളുടെ ദ്രുത കൈമാറ്റം; കൂടുതൽ വിശദാംശങ്ങൾ വായിക്കാം, ഉദാഹരണത്തിന്, ഇവിടെ - ഏകദേശം. പരിഭാഷ.), "പഴയ" VM-കളിലും Kubernetes-ലും സമാന്തരമായി പ്രവർത്തിക്കുന്നതിന്, നിരീക്ഷണ ഉപകരണങ്ങൾ രണ്ട് പരിതസ്ഥിതികളുമായും പൊരുത്തപ്പെടുന്നതും മെട്രിക്‌സ് ഒരു കാഴ്ചയിലേക്ക് സംയോജിപ്പിക്കാൻ കഴിയുന്നതും ആവശ്യമാണ്. പരിവർത്തന കാലയളവിൽ സ്ഥിരമായ നിരീക്ഷണക്ഷമത കൈവരിക്കുന്നതിന് ഞങ്ങൾ ഒരേ ഡാഷ്‌ബോർഡുകളും ലോഗ് അന്വേഷണങ്ങളും ഉപയോഗിക്കുന്നത് പ്രധാനമാണ്.

4. ഒരു പുതിയ ക്ലസ്റ്ററിലേക്ക് ട്രാഫിക് മാറ്റുന്നു

GitLab.com-ന്, സെർവറുകളുടെ ഒരു ഭാഗം സമർപ്പിക്കപ്പെട്ടിരിക്കുന്നു കാനറി ഘട്ടം. കാനറി പാർക്ക് ഞങ്ങളുടെ ആന്തരിക പ്രോജക്റ്റുകൾക്ക് സേവനം നൽകുന്നു ഉപയോക്താക്കൾ പ്രാപ്തമാക്കിയത്. എന്നാൽ അടിസ്ഥാന സൗകര്യങ്ങളിലും ആപ്ലിക്കേഷനിലും വരുത്തിയ മാറ്റങ്ങൾ പരിശോധിക്കുന്നതിനാണ് ഇത് പ്രാഥമികമായി രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. പരിമിതമായ അളവിലുള്ള ഇന്റേണൽ ട്രാഫിക് സ്വീകരിച്ചുകൊണ്ട് ആദ്യത്തെ മൈഗ്രേറ്റഡ് സേവനം ആരംഭിച്ചു, ക്ലസ്റ്ററിലേക്ക് എല്ലാ ട്രാഫിക്കും അയയ്‌ക്കുന്നതിന് മുമ്പ് SLO-കൾ പാലിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ഈ രീതി ഉപയോഗിക്കുന്നത് തുടരുന്നു.

മൈഗ്രേഷന്റെ കാര്യത്തിൽ, ആന്തരിക പ്രോജക്ടുകളിലേക്കുള്ള അഭ്യർത്ഥനകൾ ആദ്യം കുബെർനെറ്റസിലേക്ക് അയയ്‌ക്കുന്നു എന്നാണ് ഇതിനർത്ഥം, തുടർന്ന് HAProxy വഴി ബാക്കെൻഡിന്റെ ഭാരം മാറ്റിക്കൊണ്ട് ഞങ്ങൾ ബാക്കിയുള്ള ട്രാഫിക്ക് ക്ലസ്റ്ററിലേക്ക് മാറ്റുന്നു. VM-ൽ നിന്ന് Kubernetes-ലേക്കുള്ള മൈഗ്രേഷൻ സമയത്ത്, പഴയതും പുതിയതുമായ ഇൻഫ്രാസ്ട്രക്ചറുകൾക്കിടയിൽ ട്രാഫിക് റീഡയറക്‌ട് ചെയ്യുന്നതിനുള്ള എളുപ്പവഴി വളരെ പ്രയോജനകരമാണെന്ന് വ്യക്തമായി, അതനുസരിച്ച്, മൈഗ്രേഷനുശേഷം ആദ്യ കുറച്ച് ദിവസങ്ങളിൽ പഴയ ഇൻഫ്രാസ്ട്രക്ചർ റോൾബാക്കിനായി തയ്യാറാക്കി വയ്ക്കുക.

5. കായ്കളുടെ കരുതൽ ശേഷിയും അവയുടെ ഉപയോഗവും

ഉടൻ തന്നെ ഇനിപ്പറയുന്ന പ്രശ്നം തിരിച്ചറിഞ്ഞു: രജിസ്ട്രി സേവനത്തിനായുള്ള പോഡുകൾ വേഗത്തിൽ ആരംഭിച്ചു, പക്ഷേ Sidekiq-നുള്ള പോഡുകൾ സമാരംഭിക്കുന്നത് രണ്ട് മിനിറ്റ്. ജോലികൾ വേഗത്തിൽ പ്രോസസ്സ് ചെയ്യുകയും വേഗത്തിൽ സ്കെയിൽ ചെയ്യുകയും ചെയ്യേണ്ട തൊഴിലാളികൾക്കായി ഞങ്ങൾ വർക്ക്ലോഡുകൾ കുബർനെറ്റിലേക്ക് മാറ്റാൻ തുടങ്ങിയപ്പോൾ Sidekiq പോഡുകളുടെ നീണ്ട പ്രവർത്തന സമയം ഒരു പ്രശ്നമായി.

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

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

തീരുമാനം

ഓരോ സേവനവും മൈഗ്രേറ്റ് ചെയ്‌തതിന് ശേഷം, ഉൽപ്പാദനത്തിൽ Kubernetes ഉപയോഗിക്കുന്നതിന്റെ നേട്ടങ്ങളിൽ ഞങ്ങൾ സന്തോഷിച്ചു: വേഗതയേറിയതും സുരക്ഷിതവുമായ ആപ്ലിക്കേഷൻ വിന്യാസം, സ്കെയിലിംഗ്, കൂടുതൽ കാര്യക്ഷമമായ വിഭവ വിഹിതം. മാത്രമല്ല, മൈഗ്രേഷന്റെ ഗുണങ്ങൾ GitLab.com സേവനത്തിനപ്പുറമാണ്. ഔദ്യോഗിക ഹെൽം ചാർട്ടിലെ എല്ലാ മെച്ചപ്പെടുത്തലുകളും അതിന്റെ ഉപയോക്താക്കൾക്ക് പ്രയോജനകരമാണ്.

ഞങ്ങളുടെ കുബർനെറ്റസ് മൈഗ്രേഷൻ സാഹസങ്ങളുടെ കഥ നിങ്ങൾ ആസ്വദിച്ചുവെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. ഞങ്ങൾ ക്ലസ്റ്ററിലേക്ക് എല്ലാ പുതിയ സേവനങ്ങളും മൈഗ്രേറ്റ് ചെയ്യുന്നത് തുടരുന്നു. കൂടുതൽ വിവരങ്ങൾ ഇനിപ്പറയുന്ന പ്രസിദ്ധീകരണങ്ങളിൽ കാണാം:

• «എന്തുകൊണ്ടാണ് ഞങ്ങൾ കുബർനെറ്റസിലേക്ക് കുടിയേറുന്നത്?";
• «Kubernetes-ൽ GitLab.com";
• കുബർനെറ്റസിലേക്ക് GitLab.com മൈഗ്രേറ്റ് ചെയ്യുന്നതിന്റെ ഇതിഹാസം.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «നിർമ്മാണത്തിൽ കുബർനെറ്റിനൊപ്പം 3 വർഷം: ഞങ്ങൾ മനസ്സിലാക്കുന്നത് ഇതാ";
• «Kubernetes ഉപയോഗിക്കുമ്പോൾ 10 സാധാരണ തെറ്റുകൾ";
• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 3: GitHub";
• «കുബർനെറ്റസിലേക്കുള്ള ടിൻഡർ പരിവർത്തനം".

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