എല്ലാവർക്കും ഹായ്! എന്റെ പേര് പാവൽ അഗലെറ്റ്സ്കി. ലമോഡ ഡെലിവറി സിസ്റ്റം വികസിപ്പിക്കുന്ന ഒരു ടീമിൽ ഞാൻ ഒരു ടീം ലീഡായി പ്രവർത്തിക്കുന്നു. 2018-ൽ, ഞാൻ HighLoad++ കോൺഫറൻസിൽ സംസാരിച്ചു, ഇന്ന് എന്റെ റിപ്പോർട്ടിന്റെ ഒരു ട്രാൻസ്ക്രിപ്റ്റ് അവതരിപ്പിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

വ്യത്യസ്ത പരിതസ്ഥിതികളിലേക്ക് സിസ്റ്റങ്ങളും സേവനങ്ങളും വിന്യസിക്കുന്നതിലെ ഞങ്ങളുടെ കമ്പനിയുടെ അനുഭവത്തിനായി എന്റെ വിഷയം സമർപ്പിക്കുന്നു. നമ്മുടെ ചരിത്രാതീത കാലം മുതൽ, ഞങ്ങൾ എല്ലാ സിസ്റ്റങ്ങളെയും സാധാരണ വെർച്വൽ സെർവറുകളിലേക്ക് വിന്യസിച്ചപ്പോൾ, നോമാഡിൽ നിന്ന് കുബെർനെറ്റസിലെ വിന്യാസത്തിലേക്ക് ക്രമാനുഗതമായ പരിവർത്തനത്തോടെ അവസാനിക്കുന്നു. എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഇത് ചെയ്തതെന്നും ഈ പ്രക്രിയയിൽ ഞങ്ങൾക്ക് എന്ത് പ്രശ്‌നങ്ങളുണ്ടെന്നും ഞാൻ നിങ്ങളോട് പറയും.

VM-ലേക്ക് അപേക്ഷകൾ വിന്യസിക്കുന്നു

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

എന്തിനുവേണ്ടിയായിരുന്നു അത്?

ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ പുതിയ റിലീസുകൾ ഞങ്ങൾ വിന്യസിച്ചപ്പോൾ, ഉപയോക്താക്കൾക്ക് ശ്രദ്ധേയമായ പ്രത്യാഘാതങ്ങളില്ലാതെ, തടസ്സങ്ങളില്ലാത്ത റോൾഔട്ട് ഉറപ്പാക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. അൻസിബിൾ ഉപയോഗിച്ചുള്ള അടുത്ത കംപൈൽ ചെയ്ത പതിപ്പ് വാലിലേക്ക് ഉരുട്ടിയതിനാലാണ് ഇത് നേടിയത്. അവിടെ, വിന്യാസത്തിൽ ഏർപ്പെട്ടിരുന്ന ആളുകൾക്ക് എല്ലാം ശരിയാണെന്ന് പരിശോധിച്ച് ഉറപ്പാക്കാൻ കഴിയും: എല്ലാ അളവുകളും വിഭാഗങ്ങളും ആപ്ലിക്കേഷനുകളും പ്രവർത്തിക്കുന്നു; ആവശ്യമായ സ്ക്രിപ്റ്റുകൾ സമാരംഭിച്ചു. എല്ലാം ശരിയാണെന്ന് ബോധ്യപ്പെട്ടതിന് ശേഷമാണ് ഗതാഗതം മാറ്റിയത്. നേരത്തെ വാലായിരുന്ന സെർവറിലേക്ക് അത് പോയിത്തുടങ്ങി. ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ മുൻ പതിപ്പ് ഉള്ളപ്പോൾ തന്നെ, മുമ്പ് തലവനായ ഒരാൾ ഉപയോക്തൃ ട്രാഫിക് ഇല്ലാതെ തുടർന്നു.

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

ഇതിലെല്ലാം എന്തെല്ലാം ഗുണങ്ങളാണ് നാം കണ്ടത്?

1. ഒന്നാമതായി, അത് മതി അത് പ്രവർത്തിക്കുന്നു. അത്തരമൊരു വിന്യാസ പദ്ധതി എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് എല്ലാവർക്കും മനസ്സിലാകും, കാരണം മിക്ക ആളുകളും സാധാരണ വെർച്വൽ സെർവറുകളിലേക്ക് വിന്യസിച്ചിട്ടുണ്ട്.
2. ഇത് മതി വിശ്വസനീയമായി, വിന്യാസ സാങ്കേതികവിദ്യ ലളിതമായതിനാൽ, ആയിരക്കണക്കിന് കമ്പനികൾ പരീക്ഷിച്ചു. ദശലക്ഷക്കണക്കിന് സെർവറുകൾ ഈ രീതിയിൽ വിന്യസിച്ചിരിക്കുന്നു. എന്തെങ്കിലും തകർക്കാൻ പ്രയാസമാണ്.
3. അവസാനം നമുക്ക് കിട്ടും ആറ്റോമിക് വിന്യാസങ്ങൾ. ഉപയോക്താക്കൾക്ക് ഒരേസമയം സംഭവിക്കുന്ന വിന്യാസങ്ങൾ, പഴയ പതിപ്പിനും പുതിയതിനും ഇടയിൽ മാറുന്നതിന്റെ ശ്രദ്ധേയമായ ഘട്ടം കൂടാതെ.

എന്നാൽ ഇതിലെല്ലാം ഞങ്ങൾ നിരവധി പോരായ്മകളും കണ്ടു:

1. ഉൽപ്പാദന അന്തരീക്ഷം കൂടാതെ, വികസന അന്തരീക്ഷം, മറ്റ് പരിസ്ഥിതികൾ ഉണ്ട്. ഉദാഹരണത്തിന്, qa, പ്രീപ്രൊഡക്ഷൻ. അക്കാലത്ത് ഞങ്ങൾക്ക് നിരവധി സെർവറുകളും അറുപതോളം സേവനങ്ങളും ഉണ്ടായിരുന്നു. ഇക്കാരണത്താൽ അത് ആവശ്യമായിരുന്നു ഓരോ സേവനത്തിനും, അതിനായി ഏറ്റവും പുതിയ പതിപ്പ് പരിപാലിക്കുക വെർച്വൽ മെഷീൻ. മാത്രമല്ല, നിങ്ങൾക്ക് ലൈബ്രറികൾ അപ്ഡേറ്റ് ചെയ്യാനോ പുതിയ ഡിപൻഡൻസികൾ ഇൻസ്റ്റാൾ ചെയ്യാനോ താൽപ്പര്യമുണ്ടെങ്കിൽ, നിങ്ങൾ ഇത് എല്ലാ പരിതസ്ഥിതികളിലും ചെയ്യേണ്ടതുണ്ട്. നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ അടുത്ത പുതിയ പതിപ്പ് വിന്യസിക്കാൻ പോകുന്ന സമയവും ആവശ്യമായ പരിസ്ഥിതി ക്രമീകരണങ്ങൾ devops നിർവഹിക്കുന്ന സമയവും നിങ്ങൾ സമന്വയിപ്പിക്കേണ്ടതുണ്ട്. ഈ സാഹചര്യത്തിൽ, എല്ലാ പരിതസ്ഥിതികളിലും ഒരേസമയം നമ്മുടെ പരിസ്ഥിതി കുറച്ച് വ്യത്യസ്തമായ ഒരു സാഹചര്യത്തിലേക്ക് പ്രവേശിക്കുന്നത് എളുപ്പമാണ്. ഉദാഹരണത്തിന്, ഒരു QA പരിതസ്ഥിതിയിൽ ലൈബ്രറികളുടെ ചില പതിപ്പുകൾ ഉണ്ടാകും, കൂടാതെ ഒരു പ്രൊഡക്ഷൻ പരിതസ്ഥിതിയിൽ വ്യത്യസ്തമായവ ഉണ്ടാകും, അത് പ്രശ്നങ്ങളിലേക്ക് നയിക്കും.
2. ഡിപൻഡൻസികൾ അപ്ഡേറ്റ് ചെയ്യാനുള്ള ബുദ്ധിമുട്ട് നിങ്ങളുടെ അപേക്ഷ. ഇത് നിങ്ങളെയല്ല, മറ്റ് ടീമിനെ ആശ്രയിച്ചിരിക്കുന്നു. അതായത്, സെർവറുകൾ പരിപാലിക്കുന്ന devops ടീമിൽ നിന്ന്. നിങ്ങൾ അവർക്ക് ഉചിതമായ ഒരു ജോലിയും നിങ്ങൾ ചെയ്യാൻ ആഗ്രഹിക്കുന്നതിന്റെ വിവരണവും നൽകണം.
3. അക്കാലത്ത്, ഞങ്ങളുടെ പക്കലുണ്ടായിരുന്ന വലിയ വലിയ മോണോലിത്തുകൾ വേറിട്ട ചെറിയ സേവനങ്ങളായി വിഭജിക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു, കാരണം അവ കൂടുതൽ കൂടുതൽ ഉണ്ടാകുമെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി. ആ സമയത്ത്, ഞങ്ങൾക്ക് ഇതിനകം 100-ലധികം എണ്ണം ഉണ്ടായിരുന്നു. ഓരോ പുതിയ സേവനത്തിനും, ഒരു പ്രത്യേക പുതിയ വെർച്വൽ മെഷീൻ സൃഷ്ടിക്കേണ്ടത് ആവശ്യമാണ്, അത് പരിപാലിക്കുകയും വിന്യസിക്കുകയും ചെയ്യേണ്ടതുണ്ട്. കൂടാതെ, നിങ്ങൾക്ക് ഒരു കാറല്ല, കുറഞ്ഞത് രണ്ട് കാറുകളെങ്കിലും ആവശ്യമാണ്. ഇതിനെല്ലാം കൂട്ടിച്ചേർത്തത് QA പരിതസ്ഥിതിയാണ്. ഇത് പ്രശ്‌നങ്ങൾ സൃഷ്ടിക്കുകയും പുതിയ സിസ്റ്റങ്ങൾ നിർമ്മിക്കുകയും പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്നത് നിങ്ങൾക്ക് കൂടുതൽ ബുദ്ധിമുട്ടാക്കും. സങ്കീർണ്ണവും ചെലവേറിയതും നീണ്ടതുമായ പ്രക്രിയ.

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

ഏതാണ് എടുക്കേണ്ടത് എന്ന് ഞങ്ങൾ വളരെ നേരം ആലോചിച്ചു. ആ സമയത്ത് സാധാരണ വെർച്വൽ സെർവറുകളിലെ ഈ വിന്യാസ സ്റ്റാക്ക് കുറച്ച് കാലഹരണപ്പെട്ടതായിരുന്നു എന്നതാണ് വസ്തുത, കാരണം അവയ്ക്ക് ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളുടെ ഏറ്റവും പുതിയ പതിപ്പുകൾ ഇല്ലായിരുന്നു. ചില ഘട്ടങ്ങളിൽ, ഫ്രീബിഎസ്ഡി പോലും ഉണ്ടായിരുന്നു, അത് പിന്തുണയ്ക്കാൻ വളരെ സൗകര്യപ്രദമല്ല. കഴിയുന്നത്ര വേഗത്തിൽ ഡോക്കറിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി. ഞങ്ങളുടെ devops വ്യത്യസ്തമായ പരിഹാരങ്ങൾ ഉപയോഗിച്ച് അവരുടെ നിലവിലുള്ള അനുഭവം നോക്കി Nomad പോലുള്ള ഒരു സിസ്റ്റം തിരഞ്ഞെടുത്തു.

നൊമാഡിലേക്ക് മാറുക

ഹാഷികോർപ്പിന്റെ ഒരു ഉൽപ്പന്നമാണ് നോമാഡ്. അവ മറ്റ് പരിഹാരങ്ങൾക്കും പേരുകേട്ടതാണ്:

"കൺസൽ" സേവനം കണ്ടെത്തുന്നതിനുള്ള ഒരു ഉപകരണമാണ്.

"ടെറാഫോം" - ഇൻഫ്രാസ്ട്രക്ചർ-എ-കോഡ് എന്ന് വിളിക്കപ്പെടുന്ന കോൺഫിഗറേഷൻ വഴി കോൺഫിഗർ ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്ന സെർവറുകൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഒരു സിസ്റ്റം.

"വാഗ്രന്റ്" പ്രത്യേക കോൺഫിഗറേഷൻ ഫയലുകൾ വഴി പ്രാദേശികമായോ ക്ലൗഡിലോ വെർച്വൽ മെഷീനുകൾ വിന്യസിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

മുഴുവൻ അടിസ്ഥാന സൗകര്യങ്ങളും മാറ്റാതെ വേഗത്തിൽ മാറാൻ കഴിയുന്ന ഒരു ലളിതമായ പരിഹാരമായി അക്കാലത്ത് നോമാഡ് തോന്നി. കൂടാതെ, ഇത് പഠിക്കാൻ വളരെ എളുപ്പമാണ്. അതുകൊണ്ടാണ് ഞങ്ങളുടെ കണ്ടെയ്‌നറിനുള്ള ഫിൽട്ടറേഷൻ സിസ്റ്റമായി ഞങ്ങൾ ഇത് തിരഞ്ഞെടുത്തത്.

നിങ്ങളുടെ സിസ്റ്റം Nomad-ലേക്ക് വിന്യസിക്കാൻ എന്താണ് വേണ്ടത്?

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

നമ്മൾ നൊമാഡിനെ കുറിച്ച് സംസാരിക്കുമ്പോൾ, അത് അതിന്റെ വിവര ഫയൽ ഫോർമാറ്റായി എച്ച്സിഎൽ ഭാഷ ഉപയോഗിക്കുന്നു, അതിനർത്ഥം HashiCorp കോൺഫിഗറേഷൻ ഭാഷ. Nomad പദങ്ങളിൽ നിങ്ങളുടെ സേവനം വിവരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന Yaml-ന്റെ സൂപ്പർസെറ്റാണിത്.

നിങ്ങൾ എത്ര കണ്ടെയ്‌നറുകൾ വിന്യസിക്കണമെന്ന് പറയാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, ഏത് ചിത്രങ്ങളിൽ നിന്നാണ് വിന്യാസ സമയത്ത് അവയ്ക്ക് വിവിധ പാരാമീറ്ററുകൾ കൈമാറേണ്ടത്. അതിനാൽ, നിങ്ങൾ ഈ ഫയൽ നോമാഡിന് നൽകുകയും അത് അനുസരിച്ച് ഉൽപ്പാദനത്തിലേക്ക് കണ്ടെയ്നറുകൾ സമാരംഭിക്കുകയും ചെയ്യുന്നു.

ഞങ്ങളുടെ കാര്യത്തിൽ, ഓരോ സേവനത്തിനും തികച്ചും സമാനമായ HCL ഫയലുകൾ എഴുതുന്നത് വളരെ സൗകര്യപ്രദമല്ലെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി, കാരണം ധാരാളം സേവനങ്ങളുണ്ട്, ചിലപ്പോൾ നിങ്ങൾ അവ അപ്ഡേറ്റ് ചെയ്യാൻ ആഗ്രഹിക്കുന്നു. ഒരു സേവനം വിന്യസിച്ചിരിക്കുന്നത് ഒരു സന്ദർഭത്തിലല്ല, മറിച്ച് വ്യത്യസ്തമായവയിൽ ആണ്. ഉദാഹരണത്തിന്, ഉൽപ്പാദനത്തിൽ നമുക്കുള്ള ഒരു സിസ്റ്റത്തിന് ഉൽപ്പാദനത്തിൽ 100-ലധികം സംഭവങ്ങളുണ്ട്. അവ ഒരേ ചിത്രങ്ങളിൽ നിന്നാണ് പ്രവർത്തിക്കുന്നത്, എന്നാൽ കോൺഫിഗറേഷൻ ക്രമീകരണങ്ങളിലും കോൺഫിഗറേഷൻ ഫയലുകളിലും വ്യത്യാസമുണ്ട്.

അതിനാൽ, വിന്യാസത്തിനായി ഞങ്ങളുടെ എല്ലാ കോൺഫിഗറേഷൻ ഫയലുകളും ഒരു പൊതു ശേഖരത്തിൽ സൂക്ഷിക്കുന്നത് സൗകര്യപ്രദമാണെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു. ഈ രീതിയിൽ അവ ദൃശ്യമായിരുന്നു: അവ പരിപാലിക്കാൻ എളുപ്പമായിരുന്നു, ഞങ്ങൾക്ക് എന്തെല്ലാം സംവിധാനങ്ങളാണുള്ളതെന്ന് ഞങ്ങൾക്ക് കാണാൻ കഴിയും. ആവശ്യമെങ്കിൽ, എന്തെങ്കിലും അപ്ഡേറ്റ് ചെയ്യുന്നതിനോ മാറ്റുന്നതിനോ എളുപ്പമാണ്. ഒരു പുതിയ സിസ്റ്റം ചേർക്കുന്നതും ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല - നിങ്ങൾ പുതിയ ഡയറക്ടറിയിൽ ഒരു കോൺഫിഗറേഷൻ ഫയൽ സൃഷ്ടിക്കേണ്ടതുണ്ട്. അതിനുള്ളിൽ ഇനിപ്പറയുന്ന ഫയലുകൾ ഉണ്ട്: service.hcl, അതിൽ ഞങ്ങളുടെ സേവനത്തിന്റെ വിവരണം അടങ്ങിയിരിക്കുന്നു, കൂടാതെ പ്രൊഡക്ഷനിൽ വിന്യസിക്കുമ്പോൾ ഈ സേവനം കോൺഫിഗർ ചെയ്യാൻ അനുവദിക്കുന്ന ചില env ഫയലുകളും.

എന്നിരുന്നാലും, ഞങ്ങളുടെ ചില സിസ്റ്റങ്ങൾ ഒരു കോപ്പിയിലല്ല, പലതിലും ഒരേസമയം ഉൽപ്പാദനത്തിൽ വിന്യസിച്ചിരിക്കുന്നു. അതിനാൽ, കോൺഫിഗറേഷനുകൾ അവയുടെ ശുദ്ധമായ രൂപത്തിലല്ല, മറിച്ച് അവയുടെ ടെംപ്ലേറ്റഡ് രൂപത്തിൽ സൂക്ഷിക്കുന്നത് ഞങ്ങൾക്ക് സൗകര്യപ്രദമാണെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു. ഞങ്ങൾ തിരഞ്ഞെടുത്തു ജിഞ്ച 2. ഈ ഫോർമാറ്റിൽ, സേവനത്തിന്റെ കോൺഫിഗറേഷനുകളും അതിന് ആവശ്യമായ env ഫയലുകളും ഞങ്ങൾ സംഭരിക്കുന്നു.

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

അതായത്, env ഫയലുകളിൽ നിന്നോ മറ്റ് ഉറവിടങ്ങളിൽ നിന്നോ എടുത്ത വേരിയബിളുകൾ ഉൾപ്പെടുത്തി ഞങ്ങൾ ചില കോൺഫിഗറേഷൻ ലൊക്കേഷൻ വേരിയബിളുകൾ മാറ്റി. കൂടാതെ, എച്ച്സിഎൽ ഫയലുകൾ ഡൈനാമിക്കായി ശേഖരിക്കാനുള്ള അവസരം ഞങ്ങൾക്ക് ലഭിച്ചു, അതായത്, സാധാരണ വേരിയബിൾ ഇൻസെർഷനുകൾ മാത്രമല്ല നമുക്ക് ഉപയോഗിക്കാൻ കഴിയും. ജിഞ്ച ലൂപ്പുകളും വ്യവസ്ഥകളും പിന്തുണയ്ക്കുന്നതിനാൽ, നിങ്ങൾക്ക് അവിടെ കോൺഫിഗറേഷൻ ഫയലുകൾ സൃഷ്ടിക്കാനും കഴിയും, നിങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ കൃത്യമായി എവിടെ വിന്യസിക്കുന്നു എന്നതിനെ ആശ്രയിച്ച് അവ മാറും.

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

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

ആദ്യം, നിങ്ങൾക്ക് പുറത്ത് ഏതെങ്കിലും തരത്തിലുള്ള ബാലൻസർ ആവശ്യമാണ്, അത് എല്ലാ ഉപയോക്തൃ ട്രാഫിക്കും സ്വീകരിക്കും. ഇത് കോൺസലുമായി ചേർന്ന് പ്രവർത്തിക്കുകയും ഒരു പ്രത്യേക ഡൊമെയ്ൻ നാമവുമായി പൊരുത്തപ്പെടുന്ന ഒരു നിർദ്ദിഷ്ട സേവനം എവിടെ, ഏത് നോഡിൽ, ഏത് ഐപി വിലാസത്തിലാണ് സ്ഥിതിചെയ്യുന്നതെന്ന് അതിൽ നിന്ന് കണ്ടെത്തുകയും ചെയ്യും. കോൺസലിലെ സേവനങ്ങൾ നോമാഡിൽ നിന്ന് തന്നെ വരുന്നു. ഇവ ഒരേ കമ്പനിയിൽ നിന്നുള്ള ഉൽപ്പന്നങ്ങളായതിനാൽ, അവ പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നു. Nomad out of the box അതിൽ സമാരംഭിച്ച എല്ലാ സേവനങ്ങളും കോൺസൽ ഉള്ളിൽ രജിസ്റ്റർ ചെയ്യാൻ കഴിയുമെന്ന് നമുക്ക് പറയാം.

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

മാനവ വിഭവശേഷിയുടെ കാര്യത്തിൽ ഈ പരിവർത്തനത്തിന് നമുക്ക് എത്രമാത്രം ചിലവായി?

മുഴുവൻ കമ്പനിയും നോമാഡിലേക്ക് മാറുന്നതിന് ഏകദേശം 5-6 മാസമെടുത്തു. ഞങ്ങൾ സർവീസ് ബൈ-സർവീസ് അടിസ്ഥാനത്തിൽ നീങ്ങി, പക്ഷേ സാമാന്യം വേഗത്തിലാണ്. ഓരോ ടീമും സേവനങ്ങൾക്കായി സ്വന്തം കണ്ടെയ്നറുകൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്.

ഓരോ ടീമും അവരുടെ സിസ്റ്റങ്ങളുടെ ഡോക്കർ ഇമേജുകൾക്ക് സ്വതന്ത്രമായി ഉത്തരവാദികളാകുന്ന ഒരു സമീപനമാണ് ഞങ്ങൾ സ്വീകരിച്ചിരിക്കുന്നത്. DevOps വിന്യാസത്തിന് ആവശ്യമായ പൊതുവായ ഇൻഫ്രാസ്ട്രക്ചർ നൽകുന്നു, അതായത്, ക്ലസ്റ്ററിനുള്ള പിന്തുണ, CI സിസ്റ്റത്തിനുള്ള പിന്തുണ മുതലായവ. ആ സമയത്ത്, ഞങ്ങൾക്ക് 60 ലധികം സിസ്റ്റങ്ങൾ നോമാഡിലേക്ക് മാറ്റി, അത് ഏകദേശം 2 ആയിരം കണ്ടെയ്നറുകൾ ആയിരുന്നു.

വിന്യാസം, സെർവറുകൾ എന്നിവയുമായി ബന്ധപ്പെട്ട എല്ലാറ്റിന്റെയും പൊതുവായ അടിസ്ഥാന സൗകര്യങ്ങളുടെ ഉത്തരവാദിത്തം Devops ആണ്. ഓരോ ഡെവലപ്‌മെന്റ് ടീമും അതിന്റെ നിർദ്ദിഷ്ട സിസ്റ്റത്തിനായി കണ്ടെയ്‌നറുകൾ നടപ്പിലാക്കുന്നതിന് ഉത്തരവാദികളാണ്, കാരണം ഒരു പ്രത്യേക കണ്ടെയ്‌നറിൽ പൊതുവായി എന്താണ് ആവശ്യമെന്ന് അറിയുന്ന ടീമാണിത്.

നാടോടിയെ ഉപേക്ഷിക്കാനുള്ള കാരണങ്ങൾ

നോമാഡും ഡോക്കറും ഉപയോഗിച്ചുള്ള വിന്യാസത്തിലേക്ക് മാറിയതിനാൽ ഞങ്ങൾക്ക് എന്ത് നേട്ടങ്ങൾ ലഭിച്ചു?

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

എന്നാൽ ഞങ്ങൾ നിരവധി ദോഷങ്ങൾ നേരിട്ടു:

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

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

അതിനാൽ അടുത്തതായി എവിടേക്കാണ് പോകേണ്ടതെന്ന് ചിന്തിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ആ സമയത്ത്, ഞങ്ങൾ എന്താണ് നേടാൻ ആഗ്രഹിക്കുന്നതെന്ന് ഞങ്ങൾ കൂടുതൽ ബോധവാന്മാരായി. അതായത്: ഞങ്ങൾക്ക് വിശ്വാസ്യതയും, നോമാഡ് നൽകുന്നതിനേക്കാൾ അൽപ്പം കൂടുതൽ ഫംഗ്‌ഷനുകളും, കൂടുതൽ പക്വതയുള്ള, കൂടുതൽ സ്ഥിരതയുള്ള സംവിധാനവും വേണം.

ഇക്കാര്യത്തിൽ, ക്ലസ്റ്ററുകൾ സമാരംഭിക്കുന്നതിനുള്ള ഏറ്റവും ജനപ്രിയമായ പ്ലാറ്റ്ഫോം എന്ന നിലയിൽ ഞങ്ങളുടെ തിരഞ്ഞെടുപ്പ് കുബെർനെറ്റസിൽ പതിച്ചു. ഞങ്ങളുടെ കണ്ടെയ്‌നറുകളുടെ വലുപ്പവും എണ്ണവും ആവശ്യത്തിന് വലുതായതിനാൽ പ്രത്യേകിച്ചും. അത്തരം ആവശ്യങ്ങൾക്ക്, നമുക്ക് നോക്കാൻ കഴിയുന്ന ഏറ്റവും അനുയോജ്യമായ സംവിധാനം കുബർനെറ്റസ് ആണെന്ന് തോന്നി.

കുബർനെറ്റസിലേക്കുള്ള മാറ്റം

കുബെർനെറ്റസിന്റെ അടിസ്ഥാന ആശയങ്ങളെക്കുറിച്ചും അവ നോമാഡിൽ നിന്ന് എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു എന്നതിനെക്കുറിച്ചും ഞാൻ നിങ്ങളോട് കുറച്ച് പറയും.

ഒന്നാമതായി, കുബർനെറ്റസിലെ ഏറ്റവും അടിസ്ഥാന ആശയം പോഡ് എന്ന ആശയമാണ്. പോഡ് എപ്പോഴും ഒരുമിച്ച് പ്രവർത്തിക്കുന്ന ഒന്നോ അതിലധികമോ കണ്ടെയ്‌നറുകളുടെ ഒരു ഗ്രൂപ്പാണ്. അവ എല്ലായ്പ്പോഴും ഒരു വെർച്വൽ മെഷീനിൽ കർശനമായി പ്രവർത്തിക്കുന്നു. വ്യത്യസ്ത പോർട്ടുകളിൽ IP 127.0.0.1 വഴി അവ പരസ്പരം ആക്സസ് ചെയ്യാവുന്നതാണ്.

നിങ്ങൾക്ക് nginx, php-fpm - ക്ലാസിക് സ്കീം എന്നിവ അടങ്ങുന്ന ഒരു PHP ആപ്ലിക്കേഷൻ ഉണ്ടെന്ന് കരുതുക. മിക്കവാറും, നിങ്ങൾ nginx, php-fpm കണ്ടെയ്‌നറുകൾ എല്ലായ്‌പ്പോഴും ഒരുമിച്ച് സൂക്ഷിക്കാൻ ആഗ്രഹിക്കുന്നു. ഒരു പൊതു പോഡ് എന്ന് വിവരിച്ചുകൊണ്ട് ഇത് നേടാൻ കുബെർനെറ്റസ് നിങ്ങളെ അനുവദിക്കുന്നു. നോമാഡിനോടൊപ്പം ഞങ്ങൾക്ക് ലഭിക്കാത്തത് ഇതാണ്.

രണ്ടാമത്തെ ആശയം വിന്യാസം. പോഡ് തന്നെ ഒരു ക്ഷണികമായ കാര്യമാണ് എന്നതാണ് വസ്തുത; അത് ആരംഭിക്കുകയും അപ്രത്യക്ഷമാവുകയും ചെയ്യുന്നു. നിങ്ങളുടെ മുമ്പത്തെ എല്ലാ കണ്ടെയ്‌നറുകളും ആദ്യം ഇല്ലാതാക്കണോ, തുടർന്ന് പുതിയ പതിപ്പുകൾ ഒറ്റയടിക്ക് സമാരംഭിക്കണോ അതോ ക്രമേണ അവ പുറത്തിറക്കണോ? വിന്യാസം എന്ന ആശയം ഉത്തരവാദിയായിരിക്കുന്ന പ്രക്രിയയാണിത്. നിങ്ങളുടെ പോഡുകൾ എങ്ങനെ വിന്യസിക്കുന്നു, ഏത് അളവിൽ, അവ എങ്ങനെ അപ്‌ഡേറ്റ് ചെയ്യാം എന്നിവ ഇത് വിവരിക്കുന്നു.

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

നാലാമത്തെ അടിസ്ഥാന ആശയം തുടരുക. ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്ന ഒരു സേവനമാണിത്. എല്ലാ അഭ്യർത്ഥനകളും ഏറ്റെടുക്കുന്ന ഒരു ബാഹ്യ ലോഡ് ബാലൻസറായി ഇത് പ്രവർത്തിക്കുന്നു. Kubernetes API ഉപയോഗിച്ച്, ഈ അഭ്യർത്ഥനകൾ എവിടേക്കാണ് അയയ്‌ക്കേണ്ടതെന്ന് ഇൻഗ്രസിന് നിർണ്ണയിക്കാനാകും. മാത്രമല്ല, അവൻ ഇത് വളരെ വഴക്കത്തോടെ ചെയ്യുന്നു. ഈ ഹോസ്റ്റിലേക്കുള്ള എല്ലാ അഭ്യർത്ഥനകളും അത്തരം URL-കളും ഈ സേവനത്തിലേക്ക് അയച്ചതായി നിങ്ങൾക്ക് പറയാം. ഈ ഹോസ്റ്റിലേക്കും മറ്റൊരു URL ലേക്ക് വരുന്ന ഈ അഭ്യർത്ഥനകൾ മറ്റൊരു സേവനത്തിലേക്ക് അയയ്ക്കുന്നു.

ഒരു ആപ്ലിക്കേഷൻ വികസിപ്പിച്ചെടുക്കുന്ന ഒരാളുടെ വീക്ഷണകോണിൽ നിന്നുള്ള ഏറ്റവും മികച്ച കാര്യം, നിങ്ങൾക്ക് എല്ലാം സ്വയം കൈകാര്യം ചെയ്യാൻ കഴിയും എന്നതാണ്. ഇൻഗ്രെസ്സ് കോൺഫിഗറേഷൻ സജ്ജീകരിക്കുന്നതിലൂടെ, അത്തരം ഒരു എപിഐയിലേക്ക് വരുന്ന എല്ലാ ട്രാഫിക്കും നിങ്ങൾക്ക് പ്രത്യേകം കണ്ടെയ്‌നറുകളിലേക്ക് അയയ്‌ക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, Go-ൽ. എന്നാൽ ഈ ട്രാഫിക്, ഒരേ ഡൊമെയ്‌നിലേക്ക് വരുന്നു, പക്ഷേ മറ്റൊരു URL-ലേക്ക്, PHP-യിൽ എഴുതിയിരിക്കുന്ന കണ്ടെയ്‌നറുകളിലേക്ക് അയയ്‌ക്കണം, അവിടെ ധാരാളം ലോജിക് ഉണ്ട്, പക്ഷേ അവ വളരെ വേഗതയുള്ളതല്ല.

ഈ സങ്കൽപ്പങ്ങളെല്ലാം നോമാഡുമായി താരതമ്യം ചെയ്താൽ, ആദ്യത്തെ മൂന്ന് ആശയങ്ങളും ഒരുമിച്ച് സേവനമാണെന്ന് നമുക്ക് പറയാം. അവസാനത്തെ ആശയം നൊമാഡിൽ തന്നെ ഇല്ല. ഞങ്ങൾ ഒരു ബാഹ്യ ബാലൻസർ ഉപയോഗിച്ചു: അത് ഹാപ്രോക്സി, nginx, nginx+ മുതലായവ ആകാം. ഒരു ക്യൂബിന്റെ കാര്യത്തിൽ, നിങ്ങൾ ഈ അധിക ആശയം പ്രത്യേകം അവതരിപ്പിക്കേണ്ടതില്ല. എന്നിരുന്നാലും, നിങ്ങൾ ഇൻഗ്രെസ് ആന്തരികമായി നോക്കുകയാണെങ്കിൽ, അത് ഒന്നുകിൽ nginx, haproxy, അല്ലെങ്കിൽ traefik, എന്നാൽ കുബെർനെറ്റസിൽ നിർമ്മിച്ചതാണ്.

ഞാൻ വിവരിച്ച എല്ലാ ആശയങ്ങളും, വാസ്തവത്തിൽ, ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിനുള്ളിൽ നിലനിൽക്കുന്ന ഉറവിടങ്ങളാണ്. അവയെ ക്യൂബിൽ വിവരിക്കുന്നതിന്, നോമാഡിന്റെ കാര്യത്തിൽ HCL ഫയലുകളേക്കാൾ കൂടുതൽ വായിക്കാവുന്നതും പരിചിതവുമായ ഒരു yaml ഫോർമാറ്റ് ഉപയോഗിക്കുന്നു. എന്നാൽ ഘടനാപരമായി അവർ അതേ കാര്യം വിവരിക്കുന്നു, ഉദാഹരണത്തിന്, പോഡ്. അവർ പറയുന്നു - അത്തരത്തിലുള്ള അത്തരം പോഡുകൾ അവിടെ വിന്യസിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു, അത്തരം ചിത്രങ്ങളോടൊപ്പം, അത്തരം അളവുകളിൽ.

കൂടാതെ, ഓരോ വ്യക്തിഗത ഉറവിടവും കൈകൊണ്ട് സൃഷ്ടിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ലെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി: വിന്യാസം, സേവനങ്ങൾ, പ്രവേശനം മുതലായവ. പകരം, വിന്യാസ സമയത്ത് ഞങ്ങളുടെ ഓരോ സിസ്റ്റത്തെയും കുബർനെറ്റുകളുടെ അടിസ്ഥാനത്തിൽ വിവരിക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു, അതിനാൽ ആവശ്യമായ എല്ലാ റിസോഴ്‌സ് ഡിപൻഡൻസികളും ശരിയായ ക്രമത്തിൽ സ്വമേധയാ പുനഃസൃഷ്ടിക്കേണ്ടതില്ല. ഇത് ചെയ്യാൻ ഞങ്ങളെ അനുവദിച്ച സംവിധാനമായി ഹെൽമിനെ തിരഞ്ഞെടുത്തു.

ഹെൽമിലെ അടിസ്ഥാന ആശയങ്ങൾ

ഹെൽം ആണ് പാക്കേജ് മാനേജർ കുബെർനെറ്റസിന്. പ്രോഗ്രാമിംഗ് ഭാഷകളിലെ പാക്കേജ് മാനേജർമാർ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിന് സമാനമാണ് ഇത്. ഉദാഹരണത്തിന്, വിന്യാസം nginx, വിന്യാസം php-fpm, ഇൻഗ്രസിനായുള്ള കോൺഫിഗറേഷൻ, കോൺഫിഗ്മാപ്പുകൾ (ഇത് നിങ്ങളുടെ സിസ്റ്റത്തിനായി എൻവിയും മറ്റ് പാരാമീറ്ററുകളും സജ്ജീകരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു എന്റിറ്റിയാണ്) ഉൾപ്പെടുന്ന ഒരു സേവനം സംഭരിക്കാൻ അവ നിങ്ങളെ അനുവദിക്കുന്നു- ചാർട്ടുകൾ എന്ന് വിളിക്കുന്നു. അതേ സമയം ഹെൽം കുബർനെറ്റസിന്റെ മുകളിൽ ഓടുന്നു. അതായത്, ഇത് ഒരുതരം സംവിധാനമല്ല, മറിച്ച് ക്യൂബിനുള്ളിൽ ആരംഭിച്ച മറ്റൊരു സേവനം മാത്രമാണ്. ഒരു കൺസോൾ കമാൻഡ് വഴി അതിന്റെ API വഴി നിങ്ങൾ സംവദിക്കുന്നു. അതിന്റെ സൌകര്യവും സൌന്ദര്യവും എന്തെന്നാൽ, ഹെം പൊട്ടിപ്പോയാലും അല്ലെങ്കിൽ ക്ലസ്റ്ററിൽ നിന്ന് നീക്കം ചെയ്താലും, നിങ്ങളുടെ സേവനങ്ങൾ അപ്രത്യക്ഷമാകില്ല, കാരണം ഹെം പ്രധാനമായും സിസ്റ്റം ആരംഭിക്കാൻ മാത്രമേ സഹായിക്കൂ. സേവനങ്ങളുടെ പ്രകടനത്തിനും അവസ്ഥയ്ക്കും കുബർനെറ്റസ് തന്നെ ഉത്തരവാദിയാണ്.

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

ഹെൽം ഞങ്ങൾക്കായി കുറച്ച് ആശയങ്ങൾ കൂടി ചേർക്കുന്നു.

ചാർട്ട് - ഇത് നിങ്ങളുടെ സേവനത്തിന്റെ വിവരണമാണ്. മറ്റ് പാക്കേജ് മാനേജർമാരിൽ ഇതിനെ ഒരു പാക്കേജ്, ബണ്ടിൽ അല്ലെങ്കിൽ സമാനമായ എന്തെങ്കിലും എന്ന് വിളിക്കും. ഇവിടെ അതിനെ ചാർട്ട് എന്ന് വിളിക്കുന്നു.

മൂല്യങ്ങൾ ടെംപ്ലേറ്റുകളിൽ നിന്ന് നിങ്ങളുടെ കോൺഫിഗറുകൾ നിർമ്മിക്കാൻ നിങ്ങൾ ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുന്ന വേരിയബിളുകളാണ്.

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

നമ്മൾ ഹെൽം ഉപയോഗിക്കുമ്പോൾ, കുബർനെറ്റസിനായുള്ള റെഗുലർ കോൺഫിഗറുകളും ടെംപ്ലേറ്റുകളായി മാറുന്നു, അതിൽ വേരിയബിളുകൾ, ഫംഗ്ഷനുകൾ, സോപാധിക പ്രസ്താവനകൾ എന്നിവ ഉപയോഗിക്കാനാകും. ഇതുവഴി നിങ്ങൾക്ക് പരിസ്ഥിതിയെ ആശ്രയിച്ച് നിങ്ങളുടെ സേവന കോൺഫിഗറേഷൻ ശേഖരിക്കാനാകും.

പ്രായോഗികമായി, ഞങ്ങൾ നൊമാഡിനേക്കാൾ അല്പം വ്യത്യസ്തമായി കാര്യങ്ങൾ ചെയ്യാൻ തീരുമാനിച്ചു. Nomad-ൽ ഞങ്ങളുടെ സേവനം വിന്യസിക്കാൻ ആവശ്യമായ വിന്യാസ കോൺഫിഗുകളും n-വേരിയബിളുകളും ഒരു ശേഖരത്തിൽ സംഭരിച്ചിട്ടുണ്ടെങ്കിൽ, ഇവിടെ അവയെ രണ്ട് വ്യത്യസ്ത ശേഖരങ്ങളായി വിഭജിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. "ഡിപ്ലോയ്" റിപ്പോസിറ്ററി വിന്യാസത്തിന് ആവശ്യമായ n-വേരിയബിളുകൾ മാത്രമേ സംഭരിക്കുന്നുള്ളൂ, കൂടാതെ "ഹെൽം" റിപ്പോസിറ്ററി കോൺഫിഗറുകളോ ചാർട്ടുകളോ സംഭരിക്കുന്നു.

ഇത് ഞങ്ങൾക്ക് എന്താണ് നൽകിയത്?

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

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

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

ഞങ്ങൾ ഒരു വിന്യാസ സ്‌ക്രിപ്റ്റ് ഉപേക്ഷിച്ചു - deploy.sh, അത് ഹെൽം ഉപയോഗിച്ച് വിന്യാസത്തിനായി ലോഞ്ച് ലളിതമാക്കുകയും സ്റ്റാൻഡേർഡ് ചെയ്യുകയും ചെയ്യുന്നു. അതിനാൽ, വിന്യസിക്കാൻ ആഗ്രഹിക്കുന്ന ആർക്കും, വിന്യാസ ഇന്റർഫേസ് നോമാഡിലൂടെ വിന്യസിക്കുമ്പോൾ അത് പോലെ തന്നെ കാണപ്പെടുന്നു. അതേ deploy.sh, നിങ്ങളുടെ സേവനത്തിന്റെ പേര്, നിങ്ങൾ അത് എവിടെ വിന്യസിക്കാൻ ആഗ്രഹിക്കുന്നു. ഇത് ഹെൽം ആന്തരികമായി ആരംഭിക്കുന്നതിന് കാരണമാകുന്നു. ഇത് ടെംപ്ലേറ്റുകളിൽ നിന്ന് കോൺഫിഗറേഷനുകൾ ശേഖരിക്കുകയും അവയിൽ ആവശ്യമായ മൂല്യങ്ങളുടെ ഫയലുകൾ തിരുകുകയും തുടർന്ന് അവയെ വിന്യസിക്കുകയും കുബർനെറ്റുകളിലേക്ക് സമാരംഭിക്കുകയും ചെയ്യുന്നു.

കണ്ടെത്തലുകൾ

കുബർനെറ്റസ് സേവനം നോമാഡിനേക്കാൾ സങ്കീർണ്ണമാണെന്ന് തോന്നുന്നു.

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

ഞങ്ങൾ പരിവർത്തനം നടത്തുമ്പോൾ, ഞങ്ങൾ മുമ്പ് ഉപയോഗിച്ചിരുന്ന നോമാഡിന്റെ എല്ലാ കഴിവുകളും കുബർനെറ്റസിനുണ്ടെന്ന് ഞങ്ങൾ കണ്ടു, കൂടാതെ ധാരാളം പുതിയ കാര്യങ്ങൾ ചേർത്തു. പ്ലഗിനുകൾ വഴിയും യഥാർത്ഥത്തിൽ ഇഷ്‌ടാനുസൃത റിസോഴ്‌സ് തരങ്ങൾ വഴിയും ഇത് വിപുലീകരിക്കാൻ കഴിയും. അതായത്, ബോക്‌സിന് പുറത്ത് കുബർനെറ്റിനൊപ്പം വരുന്ന എന്തെങ്കിലും ഉപയോഗിക്കാൻ മാത്രമല്ല, നിങ്ങളുടെ റിസോഴ്‌സ് വായിക്കുന്ന നിങ്ങളുടെ സ്വന്തം റിസോഴ്‌സും സേവനവും സൃഷ്ടിക്കാനുള്ള അവസരമുണ്ട്. Kubernetes വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യാതെയും പരിഷ്കാരങ്ങൾ ആവശ്യമില്ലാതെയും നിങ്ങളുടെ സിസ്റ്റം വിപുലീകരിക്കുന്നതിന് ഇത് നിങ്ങൾക്ക് അധിക ഓപ്ഷനുകൾ നൽകുന്നു.

ഞങ്ങളുടെ കുബർനെറ്റസ് ക്ലസ്റ്ററിനുള്ളിൽ പ്രവർത്തിക്കുന്ന പ്രോമിത്യൂസ് ആണ് അത്തരം ഉപയോഗത്തിന്റെ ഒരു ഉദാഹരണം. ഒരു പ്രത്യേക സേവനത്തിൽ നിന്ന് മെട്രിക്‌സ് ശേഖരിക്കുന്നത് ആരംഭിക്കുന്നതിന്, സേവന വിവരണത്തിലേക്ക് ഞങ്ങൾ ഒരു അധിക തരം റിസോഴ്‌സ്, സേവന മോണിറ്റർ എന്ന് വിളിക്കപ്പെടുന്നവ ചേർക്കേണ്ടതുണ്ട്. Prometheus, Kubernetes-ൽ സമാരംഭിക്കുമ്പോൾ ഒരു ഇഷ്‌ടാനുസൃത ഉറവിട തരം വായിക്കാൻ കഴിയുമെന്നതിനാൽ, പുതിയ സിസ്റ്റത്തിൽ നിന്ന് മെട്രിക്‌സ് സ്വയമേവ ശേഖരിക്കാൻ തുടങ്ങുന്നു. ഇത് തികച്ചും സൗകര്യപ്രദമാണ്.

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

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