ഡാറ്റാബേസ് ക്ലസ്റ്ററുകൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള കുബർനെറ്റസിലെ ഓപ്പറേറ്റർ. വ്ലാഡിസ്ലാവ് ക്ലിമെൻകോ (ആൾട്ടിനിറ്റി, 2019)

കുബർനെറ്റസിൽ ഒരു ഓപ്പറേറ്റർ വികസിപ്പിക്കുന്നതിനും അതിന്റെ വാസ്തുവിദ്യയും അടിസ്ഥാന പ്രവർത്തന തത്വങ്ങളും രൂപകൽപ്പന ചെയ്യുന്നതിനുള്ള പ്രായോഗിക പ്രശ്‌നങ്ങൾക്കായി റിപ്പോർട്ട് സമർപ്പിക്കുന്നു.

റിപ്പോർട്ടിന്റെ ആദ്യ ഭാഗത്ത് ഞങ്ങൾ പരിഗണിക്കും:

• കുബെർനെറ്റസിലെ ഒരു ഓപ്പറേറ്റർ എന്താണ്, എന്തുകൊണ്ട് അത് ആവശ്യമാണ്;
• സങ്കീർണ്ണമായ സിസ്റ്റങ്ങളുടെ മാനേജ്മെന്റ് ഓപ്പറേറ്റർ എങ്ങനെ കൃത്യമായി ലളിതമാക്കുന്നു;
• ഓപ്പറേറ്റർക്ക് ചെയ്യാൻ കഴിയുന്നതും ചെയ്യാൻ കഴിയാത്തതും.

അടുത്തതായി, ഓപ്പറേറ്ററുടെ ആന്തരിക ഘടനയെക്കുറിച്ച് ചർച്ചചെയ്യാം. ഓപ്പറേറ്ററുടെ വാസ്തുവിദ്യയും പ്രവർത്തനവും ഘട്ടം ഘട്ടമായി നോക്കാം. നമുക്ക് അത് വിശദമായി നോക്കാം:

• ഓപ്പറേറ്ററും കുബർനെറ്റസും തമ്മിലുള്ള ഇടപെടൽ;
• ഓപ്പറേറ്റർ ഏതെല്ലാം പ്രവർത്തനങ്ങൾ ഏറ്റെടുക്കുന്നു, അത് കുബെർനെറ്റസിന് എന്ത് പ്രവർത്തനങ്ങൾ നൽകുന്നു.

കുബെർനെറ്റസിൽ ഷാർഡുകളും ഡാറ്റാബേസ് പകർപ്പുകളും നിയന്ത്രിക്കുന്നത് നോക്കാം.
അടുത്തതായി, ഞങ്ങൾ ഡാറ്റ സംഭരണ ​​പ്രശ്നങ്ങൾ ചർച്ച ചെയ്യും:

• ഒരു ഓപ്പറേറ്ററുടെ വീക്ഷണകോണിൽ നിന്ന് പെർസിസ്റ്റന്റ് സ്റ്റോറേജിൽ എങ്ങനെ പ്രവർത്തിക്കാം;
• ലോക്കൽ സ്റ്റോറേജ് ഉപയോഗിക്കുന്നതിന്റെ പോരായ്മകൾ.

റിപ്പോർട്ടിന്റെ അവസാന ഭാഗത്ത്, ആപ്ലിക്കേഷന്റെ പ്രായോഗിക ഉദാഹരണങ്ങൾ ഞങ്ങൾ പരിഗണിക്കും ക്ലിക്ക്ഹൗസ്-ഓപ്പറേറ്റർ Amazon അല്ലെങ്കിൽ Google ക്ലൗഡ് സേവനം ഉപയോഗിച്ച്. ClickHouse-നുള്ള ഒരു ഓപ്പറേറ്ററുടെ വികസനത്തിന്റെയും പ്രവർത്തന പരിചയത്തിന്റെയും ഉദാഹരണത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് റിപ്പോർട്ട്.

വീഡിയോ:

എന്റെ പേര് വ്ലാഡിസ്ലാവ് ക്ലിമെൻകോ. ഒരു ഓപ്പറേറ്റർ വികസിപ്പിക്കുന്നതിലും പ്രവർത്തിപ്പിക്കുന്നതിലുമുള്ള ഞങ്ങളുടെ അനുഭവത്തെക്കുറിച്ച് ഇന്ന് ഞാൻ സംസാരിക്കാൻ ആഗ്രഹിക്കുന്നു, ഇത് ഡാറ്റാബേസ് ക്ലസ്റ്ററുകൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഒരു പ്രത്യേക ഓപ്പറേറ്ററാണ്. ഉദാഹരണത്തിന് ക്ലിക്ക്ഹൗസ്-ഓപ്പറേറ്റർ ClickHouse ക്ലസ്റ്റർ നിയന്ത്രിക്കാൻ.

എന്തുകൊണ്ടാണ് ഞങ്ങൾക്ക് ഓപ്പറേറ്ററെക്കുറിച്ചും ക്ലിക്ക്ഹൗസിനെക്കുറിച്ചും സംസാരിക്കാൻ അവസരം ലഭിക്കുന്നത്?

• ഞങ്ങൾ ClickHouse-നെ പിന്തുണയ്ക്കുകയും വികസിപ്പിക്കുകയും ചെയ്യുന്നു.
• ഇപ്പോൾ, ക്ലിക്ക്ഹൗസിന്റെ വികസനത്തിന് ഞങ്ങളുടെ സംഭാവന സാവധാനം നൽകാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു. ClickHouse-ൽ വരുത്തിയ മാറ്റങ്ങളുടെ കാര്യത്തിൽ Yandex കഴിഞ്ഞാൽ ഞങ്ങൾ രണ്ടാമതാണ്.
• ClickHouse ഇക്കോസിസ്റ്റത്തിനായി കൂടുതൽ പ്രോജക്ടുകൾ സൃഷ്ടിക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു.

ഈ പ്രോജക്ടുകളിലൊന്നിനെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് പറയാൻ ആഗ്രഹിക്കുന്നു. ഇത് Kubernetes-നുള്ള ClickHouse-operator-നെക്കുറിച്ചാണ്.

എന്റെ റിപ്പോർട്ടിൽ ഞാൻ രണ്ട് വിഷയങ്ങളിൽ സ്പർശിക്കാൻ ആഗ്രഹിക്കുന്നു:

• Kubernetes-ൽ ഞങ്ങളുടെ ClickHouse ഡാറ്റാബേസ് മാനേജ്മെന്റ് ഓപ്പറേറ്റർ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതാണ് ആദ്യത്തെ വിഷയം.
• രണ്ടാമത്തെ വിഷയം, ഏതൊരു ഓപ്പറേറ്ററും എങ്ങനെ പ്രവർത്തിക്കുന്നു, അതായത് അത് കുബർനെറ്റുമായി എങ്ങനെ ഇടപഴകുന്നു എന്നതാണ്.

എന്നിരുന്നാലും, ഈ രണ്ട് ചോദ്യങ്ങൾ എന്റെ റിപ്പോർട്ടിൽ ഉടനീളം വിഭജിക്കും.

ഞാൻ പറയാൻ ശ്രമിക്കുന്നത് കേൾക്കാൻ ആർക്കാണ് താൽപ്പര്യം?

• ഓപ്പറേറ്റർമാരെ പ്രവർത്തിപ്പിക്കുന്നവർക്ക് ഇത് ഏറ്റവും താൽപ്പര്യമുള്ളതായിരിക്കും.
• അല്ലെങ്കിൽ അത് ആന്തരികമായി എങ്ങനെ പ്രവർത്തിക്കുന്നു, കുബെർനെറ്റുമായി ഓപ്പറേറ്റർ എങ്ങനെ ഇടപഴകുന്നു, എന്തൊക്കെ അപകടങ്ങൾ പ്രത്യക്ഷപ്പെടാം എന്നിവ മനസിലാക്കാൻ സ്വന്തമായി നിർമ്മിക്കാൻ ആഗ്രഹിക്കുന്നവർക്ക്.

ഇന്ന് നമ്മൾ ചർച്ച ചെയ്യുന്ന കാര്യങ്ങൾ നന്നായി മനസ്സിലാക്കാൻ, കുബെർനെറ്റസ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും ചില അടിസ്ഥാന ക്ലൗഡ് പരിശീലനം നേടുന്നതും നല്ലതാണ്.

എന്താണ് ClickHouse? അനലിറ്റിക്കൽ അന്വേഷണങ്ങളുടെ ഓൺലൈൻ പ്രോസസ്സിംഗിനുള്ള പ്രത്യേക സവിശേഷതകളുള്ള ഒരു കോളം ഡാറ്റാബേസാണിത്. കൂടാതെ ഇത് പൂർണ്ണമായും ഓപ്പൺ സോഴ്‌സ് ആണ്.

രണ്ട് കാര്യങ്ങൾ മാത്രം അറിയേണ്ടത് പ്രധാനമാണ്. ഇതൊരു ഡാറ്റാബേസാണെന്ന് നിങ്ങൾ അറിയേണ്ടതുണ്ട്, അതിനാൽ ഞാൻ നിങ്ങളോട് പറയുന്നത് മിക്കവാറും എല്ലാ ഡാറ്റാബേസിനും ബാധകമായിരിക്കും. കൂടാതെ ClickHouse DBMS സ്കെയിലുകൾ വളരെ നന്നായി പ്രവർത്തിക്കുന്നു എന്നത് ഏതാണ്ട് ലീനിയർ സ്കേലബിളിറ്റി നൽകുന്നു. അതിനാൽ, ക്ലസ്റ്റർ അവസ്ഥ ക്ലിക്ക്ഹൗസിന്റെ സ്വാഭാവിക അവസ്ഥയാണ്. കുബെർനെറ്റസിലെ ക്ലിക്ക്ഹൗസ് ക്ലസ്റ്റർ എങ്ങനെ സേവിക്കാമെന്ന് ചർച്ചചെയ്യാൻ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ട്.

എന്തുകൊണ്ടാണ് അവനെ അവിടെ ആവശ്യമുള്ളത്? എന്തുകൊണ്ട് നമുക്ക് അത് സ്വയം പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്നില്ല? ഉത്തരങ്ങൾ ഭാഗികമായി സാങ്കേതികവും ഭാഗികമായി സംഘടനാപരവുമാണ്.

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

ഇത് എത്ര എളുപ്പമോ ബുദ്ധിമുട്ടുള്ളതോ ആണ്? ഇത് തീർച്ചയായും കൈകൊണ്ട് ചെയ്യാം. എന്നാൽ ഇത് അത്ര ലളിതമല്ല, കാരണം ഞങ്ങൾക്ക് കുബർനെറ്റസ് കൈകാര്യം ചെയ്യുന്നതിനുള്ള സങ്കീർണ്ണതയുണ്ട്, എന്നാൽ അതേ സമയം ക്ലിക്ക്ഹൗസിന്റെ പ്രത്യേകതകൾ സൂപ്പർഇമ്പോസ് ചെയ്യപ്പെടുന്നു. അത്തരത്തിലുള്ള ഒരു സങ്കലന ഫലവും.

എല്ലാം ഒരുമിച്ച് ഇത് വളരെ വലിയ സാങ്കേതിക വിദ്യകൾ നൽകുന്നു, ഇത് കൈകാര്യം ചെയ്യുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്, കാരണം കുബർനെറ്റസ് അതിന്റേതായ ദൈനംദിന പ്രശ്നങ്ങൾ പ്രവർത്തനത്തിലേക്ക് കൊണ്ടുവരുന്നു, കൂടാതെ ClickHouse അതിന്റെ സ്വന്തം പ്രശ്നങ്ങൾ ദൈനംദിന പ്രവർത്തനത്തിലേക്ക് കൊണ്ടുവരുന്നു. പ്രത്യേകിച്ചും നമുക്ക് നിരവധി ClickHouses ഉണ്ടെങ്കിൽ, അവയുമായി നിരന്തരം എന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ട്.

ഒരു ഡൈനാമിക് കോൺഫിഗറേഷൻ ഉപയോഗിച്ച്, DevOps-ൽ സ്ഥിരമായ ലോഡ് സൃഷ്ടിക്കുന്ന ധാരാളം പ്രശ്നങ്ങൾ ClickHouse-ന് ഉണ്ട്:

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

ഇത് ഞാൻ ഉപയോഗിക്കാൻ എളുപ്പമാക്കാൻ ആഗ്രഹിക്കുന്ന പതിവ് ജോലികളാണ്.

കുബർനെറ്റസ് തന്നെ പ്രവർത്തനത്തിൽ നന്നായി സഹായിക്കുന്നു, പക്ഷേ അടിസ്ഥാന സിസ്റ്റം കാര്യങ്ങളിൽ.

ഇനിപ്പറയുന്നതുപോലുള്ള കാര്യങ്ങൾ സുഗമമാക്കുന്നതിലും യാന്ത്രികമാക്കുന്നതിലും കുബർനെറ്റസ് മികച്ചതാണ്:

• വീണ്ടെടുക്കൽ.
• പുനരാരംഭിക്കുക.
• സ്റ്റോറേജ് സിസ്റ്റം മാനേജ്മെന്റ്.

അത് നല്ലതാണ്, അത് ശരിയായ ദിശയാണ്, പക്ഷേ ഒരു ഡാറ്റാബേസ് ക്ലസ്റ്റർ എങ്ങനെ പ്രവർത്തിപ്പിക്കണമെന്നതിനെക്കുറിച്ച് അയാൾക്ക് പൂർണ്ണമായും വ്യക്തതയില്ല.

ഞങ്ങൾക്ക് കൂടുതൽ വേണം, മുഴുവൻ ഡാറ്റാബേസും കുബർനെറ്റസിൽ പ്രവർത്തിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

നിങ്ങൾ അമർത്തുന്ന ഒരു വലിയ മാജിക് റെഡ് ബട്ടണും പരിഹരിക്കേണ്ട ദൈനംദിന ജോലികളുള്ള ഒരു ക്ലസ്റ്ററും അതിന്റെ മുഴുവൻ ജീവിത ചക്രത്തിലുടനീളം വിന്യസിക്കുകയും പരിപാലിക്കുകയും ചെയ്യുന്നത് പോലെയുള്ള ഒന്ന് ലഭിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. കുബെർനെറ്റസിലെ ക്ലിക്ക്ഹൗസ് ക്ലസ്റ്റർ.

ജോലി എളുപ്പമാക്കാൻ സഹായിക്കുന്ന ഒരു പരിഹാരം ഉണ്ടാക്കാൻ ഞങ്ങൾ ശ്രമിച്ചു. ആൾട്ടിനിറ്റിയിൽ നിന്നുള്ള കുബർനെറ്റസിനായുള്ള ഒരു ക്ലിക്ക്ഹൗസ്-ഓപ്പറേറ്ററാണിത്.

ഒരു ഓപ്പറേറ്റർ എന്നത് മറ്റ് പ്രോഗ്രാമുകൾ കൈകാര്യം ചെയ്യുന്ന ഒരു പ്രോഗ്രാമാണ്, അതായത് അത് ഒരു മാനേജർ ആണ്.

കൂടാതെ അതിൽ പെരുമാറ്റരീതികൾ അടങ്ങിയിരിക്കുന്നു. വിഷയമേഖലയെക്കുറിച്ചുള്ള ക്രോഡീകരിച്ച അറിവിനെ നിങ്ങൾക്ക് വിളിക്കാം.

അവന്റെ പ്രധാന ദൌത്യം DevOps-ന്റെ ജീവിതം എളുപ്പമാക്കുകയും മൈക്രോമാനേജ്മെന്റ് കുറയ്ക്കുകയും ചെയ്യുക എന്നതാണ്, അതുവഴി അവൻ (DevOps) ഇതിനകം ഉയർന്ന തലത്തിൽ ചിന്തിക്കുന്നു, അതായത്, അവൻ (DevOps) മൈക്രോമാനേജ്മെന്റിൽ ഏർപ്പെടില്ല, അങ്ങനെ അവൻ കോൺഫിഗർ ചെയ്യില്ല. എല്ലാ വിശദാംശങ്ങളും സ്വമേധയാ.

മൈക്രോടാസ്കുകൾ കൈകാര്യം ചെയ്യുകയും DevOps-നെ സഹായിക്കുകയും ചെയ്യുന്ന ഒരു റോബോട്ടിക് അസിസ്റ്റന്റാണ് ഓപ്പറേറ്റർ.

എന്തുകൊണ്ടാണ് നിങ്ങൾക്ക് ഒരു ഓപ്പറേറ്റർ വേണ്ടത്? രണ്ട് മേഖലകളിൽ അദ്ദേഹം പ്രത്യേകിച്ച് മികച്ച പ്രകടനം കാഴ്ചവെക്കുന്നു:

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

ഒന്നുകിൽ യാത്ര തുടങ്ങുന്നവർക്കോ, അല്ലെങ്കിൽ വളരെയധികം ഓട്ടോമേഷൻ ചെയ്യേണ്ടവർക്കോ ഇത് ഏറ്റവും ആവശ്യമാണ്.

ഓപ്പറേറ്റർ അടിസ്ഥാനമാക്കിയുള്ള സമീപനം മറ്റ് സിസ്റ്റങ്ങളിൽ നിന്ന് എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു? ഹെൽം ഉണ്ട്. ClickHouse ഇൻസ്റ്റാൾ ചെയ്യാനും ഇത് സഹായിക്കുന്നു; നിങ്ങൾക്ക് ഹെൽം ചാർട്ടുകൾ വരയ്ക്കാം, അത് ഒരു മുഴുവൻ ClickHouse ക്ലസ്റ്ററും ഇൻസ്റ്റാൾ ചെയ്യും. അപ്പോൾ ഓപ്പറേറ്ററും അതുതന്നെയും തമ്മിലുള്ള വ്യത്യാസം എന്താണ്, ഉദാഹരണത്തിന്, ഹെൽം?

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

അതായിരുന്നു ആമുഖ ഭാഗം, നമുക്ക് മുന്നോട്ട് പോകാം.

ഞങ്ങളുടെ ഓപ്പറേറ്ററെ എങ്ങനെ നിർമ്മിക്കാം? ClickHouse ക്ലസ്റ്ററിനെ ഒരൊറ്റ റിസോഴ്സായി കൈകാര്യം ചെയ്യുന്നതിനുള്ള പ്രശ്നത്തെ സമീപിക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു.

ഇവിടെ നമുക്ക് ചിത്രത്തിന്റെ ഇടതുവശത്ത് ഇൻപുട്ട് ഡാറ്റയുണ്ട്. ഇത് ഒരു ക്ലസ്റ്റർ സ്പെസിഫിക്കേഷനോടുകൂടിയ YAML ആണ്, ഇത് kubectl വഴി ക്ലാസിക് രീതിയിൽ Kubernetes-ലേക്ക് കൈമാറുന്നു. അവിടെ ഞങ്ങളുടെ ഓപ്പറേറ്റർ അത് എടുത്ത് അവന്റെ മാജിക് ചെയ്യുന്നു. ഔട്ട്പുട്ടിൽ നമുക്ക് ഇനിപ്പറയുന്ന സ്കീം ലഭിക്കും. ഇത് Kubernetes-ലെ ClickHouse-ന്റെ ഒരു നിർവ്വഹണമാണ്.

ഓപ്പറേറ്റർ കൃത്യമായി എങ്ങനെ പ്രവർത്തിക്കുന്നു, എന്ത് സാധാരണ ജോലികൾ പരിഹരിക്കാൻ കഴിയുമെന്ന് ഞങ്ങൾ പതുക്കെ നോക്കും. പരിമിതമായ സമയമുള്ളതിനാൽ ഞങ്ങൾ സാധാരണ ജോലികൾ മാത്രമേ പരിഗണിക്കൂ. ഓപ്പറേറ്റർക്ക് തീരുമാനിക്കാൻ കഴിയുന്ന എല്ലാ കാര്യങ്ങളും ചർച്ച ചെയ്യില്ല.

നമുക്ക് പരിശീലനത്തിൽ നിന്ന് ആരംഭിക്കാം. ഞങ്ങളുടെ പ്രോജക്റ്റ് പൂർണ്ണമായും ഓപ്പൺ സോഴ്‌സ് ആണ്, അതിനാൽ ഇത് GitHub-ൽ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. നിങ്ങൾക്ക് ഇത് സമാരംഭിക്കണമെങ്കിൽ, ദ്രുത ആരംഭ ഗൈഡ് ഉപയോഗിച്ച് ആരംഭിക്കാം എന്ന പരിഗണനകളിൽ നിന്ന് നിങ്ങൾക്ക് മുന്നോട്ട് പോകാം.

നിങ്ങൾക്ക് വിശദമായി മനസ്സിലാക്കണമെങ്കിൽ, ഡോക്യുമെന്റേഷൻ കൂടുതലോ കുറവോ മാന്യമായ രൂപത്തിൽ നിലനിർത്താൻ ഞങ്ങൾ ശ്രമിക്കുന്നു.

നമുക്ക് ഒരു പ്രായോഗിക പ്രശ്നത്തിൽ നിന്ന് ആരംഭിക്കാം. നാമെല്ലാവരും ആരംഭിക്കാൻ ആഗ്രഹിക്കുന്ന ആദ്യത്തെ ടാസ്ക്, എങ്ങനെയെങ്കിലും ആദ്യ ഉദാഹരണം പ്രവർത്തിപ്പിക്കുക എന്നതാണ്. എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് എനിക്കറിയില്ലെങ്കിലും, ഓപ്പറേറ്റർ ഉപയോഗിച്ച് എനിക്ക് എങ്ങനെ ക്ലിക്ക്ഹൗസ് സമാരംഭിക്കാം? ഞങ്ങൾ ഒരു പ്രകടനപത്രിക എഴുതുകയാണ്, കാരണം... കെ8കളുമായുള്ള എല്ലാ ആശയവിനിമയങ്ങളും മാനിഫെസ്റ്റുകളിലൂടെയുള്ള ആശയവിനിമയമാണ്.

ഇത് വളരെ സങ്കീർണ്ണമായ ഒരു പ്രകടനപത്രികയാണ്. നമ്മൾ ചുവപ്പ് നിറത്തിൽ ഹൈലൈറ്റ് ചെയ്തിരിക്കുന്നത് നമ്മൾ ശ്രദ്ധ കേന്ദ്രീകരിക്കേണ്ട കാര്യമാണ്. ഡെമോ എന്ന പേരിൽ ഒരു ക്ലസ്റ്റർ സൃഷ്ടിക്കാൻ ഞങ്ങൾ ഓപ്പറേറ്ററോട് ആവശ്യപ്പെടുന്നു.

ഇവ ഇപ്പോൾ അടിസ്ഥാന ഉദാഹരണങ്ങളാണ്. സ്റ്റോറേജ് ഇതുവരെ വിവരിച്ചിട്ടില്ല, എന്നാൽ കുറച്ച് കഴിഞ്ഞ് ഞങ്ങൾ സ്റ്റോറേജിലേക്ക് മടങ്ങും. ഇപ്പോൾ, ക്ലസ്റ്ററിന്റെ വികസനത്തിന്റെ ചലനാത്മകത ഞങ്ങൾ നിരീക്ഷിക്കും.

ഞങ്ങൾ ഈ പ്രകടനപത്രിക സൃഷ്ടിച്ചു. ഞങ്ങൾ അത് ഞങ്ങളുടെ ഓപ്പറേറ്റർക്ക് നൽകുന്നു. അവൻ പ്രവർത്തിച്ചു, മാന്ത്രികത ഉണ്ടാക്കി.

ഞങ്ങൾ കൺസോളിലേക്ക് നോക്കുന്നു. മൂന്ന് ഘടകങ്ങൾ താൽപ്പര്യമുള്ളവയാണ്: ഒരു പോഡ്, രണ്ട് സേവനങ്ങൾ, ഒരു സ്റ്റേറ്റ്ഫുൾസെറ്റ്.

ഓപ്പറേറ്റർ പ്രവർത്തിച്ചു, അവൻ കൃത്യമായി എന്താണ് സൃഷ്ടിച്ചതെന്ന് നമുക്ക് കാണാൻ കഴിയും.

അവൻ ഇതുപോലെ എന്തെങ്കിലും സൃഷ്ടിക്കുന്നു. ഓരോ പകർപ്പിനും ഞങ്ങൾക്ക് സ്റ്റേറ്റ്ഫുൾസെറ്റ്, പോഡ്, കോൺഫിഗ്മാപ്പ്, മുഴുവൻ ക്ലസ്റ്ററിനും കോൺഫിഗ്മാപ്പ് എന്നിവയുണ്ട്. ക്ലസ്റ്ററിലേക്കുള്ള പ്രവേശന പോയിന്റുകളായി സേവനങ്ങൾ ആവശ്യമാണ്.

സേവനങ്ങൾ സെൻട്രൽ ലോഡ് ബാലൻസർ സേവനമാണ്, ഓരോ പകർപ്പിനും ഓരോ ഷാർഡിനും ഇത് ഉപയോഗിക്കാം.

ഞങ്ങളുടെ അടിസ്ഥാന ക്ലസ്റ്റർ ഇതുപോലെയാണ് കാണപ്പെടുന്നത്. ഇത് ഒരൊറ്റ നോഡിൽ നിന്നാണ്.

നമുക്ക് കൂടുതൽ മുന്നോട്ട് പോയി കാര്യങ്ങൾ സങ്കീർണ്ണമാക്കാം. നമുക്ക് ക്ലസ്റ്റർ വിഭജിക്കേണ്ടതുണ്ട്.

ഞങ്ങളുടെ ചുമതലകൾ വളരുകയാണ്, ചലനാത്മകത ആരംഭിക്കുന്നു. ഞങ്ങൾ ഒരു ഷാർഡ് ചേർക്കാൻ ആഗ്രഹിക്കുന്നു. ഞങ്ങൾ വികസനം പിന്തുടരുന്നു. ഞങ്ങൾ ഞങ്ങളുടെ സ്പെസിഫിക്കേഷൻ മാറ്റുകയാണ്. ഞങ്ങൾക്ക് രണ്ട് കഷണങ്ങൾ വേണമെന്ന് ഞങ്ങൾ സൂചിപ്പിക്കുന്നു.

സിസ്റ്റത്തിന്റെ വളർച്ചയ്‌ക്കൊപ്പം ചലനാത്മകമായി വികസിക്കുന്ന അതേ ഫയലാണിത്. സ്റ്റോറേജ് നമ്പർ, സംഭരണം കൂടുതൽ ചർച്ച ചെയ്യും, ഇതൊരു പ്രത്യേക വിഷയമാണ്.

ഞങ്ങൾ YAML ഓപ്പറേറ്റർക്ക് ഭക്ഷണം നൽകുകയും എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണുക.

ഓപ്പറേറ്റർ ചിന്തിച്ച് ഇനിപ്പറയുന്ന എന്റിറ്റികൾ ഉണ്ടാക്കി. ഞങ്ങൾക്ക് ഇതിനകം രണ്ട് പോഡുകളും മൂന്ന് സേവനങ്ങളും പെട്ടെന്ന് 2 സ്റ്റേറ്റ്ഫുൾ സെറ്റുകളും ഉണ്ട്. എന്തുകൊണ്ട് 2 സ്റ്റേറ്റ്ഫുൾ സെറ്റുകൾ?

ഡയഗ്രാമിൽ ഇത് ഇപ്രകാരമായിരുന്നു - ഞങ്ങൾക്ക് ഒരു പോഡ് ഉള്ളപ്പോൾ ഇതാണ് ഞങ്ങളുടെ പ്രാരംഭ അവസ്ഥ.

അത് ഇങ്ങനെ ആയി. ഇതുവരെ എല്ലാം ലളിതമാണ്, അത് തനിപ്പകർപ്പാണ്.

എന്തുകൊണ്ടാണ് രണ്ട് സ്റ്റേറ്റ്ഫുൾ സെറ്റുകൾ ഉണ്ടായത്? കുബെർനെറ്റസിൽ പോഡ്‌സ് എങ്ങനെ കൈകാര്യം ചെയ്യപ്പെടുന്നു എന്ന ചോദ്യം ഇവിടെ നമ്മൾ വ്യതിചലിക്കുകയും ചർച്ച ചെയ്യുകയും വേണം.

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

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

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

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

നമുക്ക് പ്രായോഗിക പ്രശ്നങ്ങളിലേക്ക് മടങ്ങാം. ഞങ്ങളുടെ ക്ലസ്റ്ററിൽ നമുക്ക് ഉപയോക്താക്കളെ കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്, അതായത്. നിങ്ങൾ Kubernetes-ൽ ClickHouse-ന്റെ ചില കോൺഫിഗറേഷൻ ചെയ്യേണ്ടതുണ്ട്. ഇതിനുള്ള എല്ലാ സാധ്യതകളും ഓപ്പറേറ്റർ നൽകുന്നു.

YAML-ൽ നമുക്ക് ആവശ്യമുള്ളത് നേരിട്ട് എഴുതാം. എല്ലാ കോൺഫിഗറേഷൻ ഓപ്ഷനുകളും ഈ YAML-ൽ നിന്ന് നേരിട്ട് ക്ലിക്ക്ഹൗസ് കോൺഫിഗറുകളിലേക്ക് മാപ്പ് ചെയ്യുന്നു, അവ ക്ലസ്റ്ററിലുടനീളം വിതരണം ചെയ്യുന്നു.

നിങ്ങൾക്ക് ഇതുപോലെ എഴുതാം. ഇത് ഉദാഹരണമാണ്. പാസ്‌വേഡ് എൻക്രിപ്റ്റ് ചെയ്യാം. തീർച്ചയായും എല്ലാ ClickHouse കോൺഫിഗറേഷൻ ഓപ്ഷനുകളും പിന്തുണയ്ക്കുന്നു. ഇവിടെ ഒരു ഉദാഹരണം മാത്രം.

ക്ലസ്റ്റർ കോൺഫിഗറേഷൻ ഒരു കോൺഫിഗ്മാപ്പ് ആയി വിതരണം ചെയ്യുന്നു. പ്രായോഗികമായി, കോൺഫിഗ്മാപ്പ് അപ്‌ഡേറ്റ് തൽക്ഷണം സംഭവിക്കുന്നില്ല, അതിനാൽ ക്ലസ്റ്റർ വലുതാണെങ്കിൽ, കോൺഫിഗറേഷൻ പുഷ് ചെയ്യുന്ന പ്രക്രിയയ്ക്ക് കുറച്ച് സമയമെടുക്കും. എന്നാൽ ഇതെല്ലാം ഉപയോഗിക്കാൻ വളരെ സൗകര്യപ്രദമാണ്.

നമുക്ക് ചുമതല സങ്കീർണ്ണമാക്കാം. ക്ലസ്റ്റർ വികസിച്ചുകൊണ്ടിരിക്കുന്നു. ഡാറ്റ പകർത്താൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. അതായത്, ഞങ്ങൾക്ക് ഇതിനകം രണ്ട് ഷാർഡുകൾ ഉണ്ട്, ഓരോ പകർപ്പ് വീതം, ഉപയോക്താക്കൾ കോൺഫിഗർ ചെയ്തിട്ടുണ്ട്. ഞങ്ങൾ വളരുകയാണ്, പകർപ്പെടുക്കാൻ ആഗ്രഹിക്കുന്നു.

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

ഞങ്ങൾക്ക് ZooKeeper ആവശ്യമാണ്. ClickHouse-ൽ, ZooKeeper ഉപയോഗിച്ചാണ് പകർപ്പ് നിർമ്മിച്ചിരിക്കുന്നത്. ZooKeeper ആവശ്യമാണ്, അതിനാൽ ഏത് ClickHouse-ൽ ഏത് ഡാറ്റ ബ്ലോക്കുകളാണ് ഉള്ളത് എന്നതിനെ കുറിച്ച് വ്യത്യസ്ത ClickHouse പകർപ്പുകൾക്ക് സമവായമുണ്ടാകും.

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

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

k8s-ൽ ഡാറ്റ വിജയകരമായി പകർത്താൻ ക്ലിക്ക്ഹൗസിന് ഇതെല്ലാം ആവശ്യമാണ്.

ഇപ്പോൾ ടാസ്‌ക് തന്നെ നോക്കാം, തനിപ്പകർപ്പിനുള്ള മാനിഫെസ്റ്റ് എങ്ങനെയായിരിക്കുമെന്ന്.

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

ഇത് ഇങ്ങനെയായിരുന്നു.

ഇത് ഇതുപോലെ മാറുന്നു. പകർപ്പുകൾ ചേർത്തിരിക്കുന്നു. നാലാമത്തേത് അനുയോജ്യമല്ല, അവയിൽ പലതും അവിടെ ഉണ്ടാകാമെന്ന് ഞങ്ങൾ വിശ്വസിക്കുന്നു. ഒപ്പം ZooKeeper വശത്തേക്ക് ചേർത്തിരിക്കുന്നു. പദ്ധതികൾ കൂടുതൽ സങ്കീർണ്ണമാവുകയാണ്.

അടുത്ത ടാസ്‌ക് ചേർക്കാനുള്ള സമയമാണിത്. ഞങ്ങൾ പെർസിസ്റ്റന്റ് സ്റ്റോറേജ് ചേർക്കും.

സ്ഥിരമായ സംഭരണത്തിനായി ഞങ്ങൾക്ക് വിവിധ ഓപ്ഷനുകൾ ഉണ്ട്.

ഞങ്ങൾ ഒരു ക്ലൗഡ് ദാതാവിലാണ് പ്രവർത്തിക്കുന്നതെങ്കിൽ, ഉദാഹരണത്തിന്, ആമസോൺ, ഗൂഗിൾ എന്നിവ ഉപയോഗിച്ച്, ക്ലൗഡ് സ്റ്റോറേജ് ഉപയോഗിക്കാനുള്ള ഒരു വലിയ പ്രലോഭനമുണ്ട്. ഇത് വളരെ സൗകര്യപ്രദമാണ്, നല്ലത്.

കൂടാതെ രണ്ടാമത്തെ ഓപ്ഷനുമുണ്ട്. ഓരോ നോഡിലും ലോക്കൽ ഡിസ്കുകൾ ഉള്ളപ്പോൾ ഇത് ലോക്കൽ സ്റ്റോറേജിനുള്ളതാണ്. ഈ ഓപ്ഷൻ നടപ്പിലാക്കാൻ വളരെ ബുദ്ധിമുട്ടാണ്, എന്നാൽ അതേ സമയം അത് കൂടുതൽ ഉൽപ്പാദനക്ഷമതയുള്ളതാണ്.

നമുക്ക് ക്ലൗഡ് സ്റ്റോറേജ് സംബന്ധിച്ച് എന്താണ് ഉള്ളതെന്ന് നോക്കാം.

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

കൂടാതെ ഒരു പോരായ്മയുണ്ട്. ചിലരെ സംബന്ധിച്ചിടത്തോളം ഇത് നിർണായകമല്ലാത്ത ഒരു പോരായ്മയാണ്. തീർച്ചയായും, ചില പ്രകടന പ്രശ്നങ്ങൾ ഉണ്ടാകും. ഇത് ഉപയോഗിക്കാൻ വളരെ സൗകര്യപ്രദവും വിശ്വസനീയവുമാണ്, എന്നാൽ ചില സാധ്യതയുള്ള പ്രകടന പോരായ്മകളുണ്ട്.

കാരണം ClickHouse ഉൽപ്പാദനക്ഷമതയിൽ പ്രത്യേകം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു, അത് സാധ്യമായതെല്ലാം ചൂഷണം ചെയ്യുന്നുവെന്ന് ഒരാൾ പോലും പറഞ്ഞേക്കാം, അതിനാലാണ് പല ക്ലയന്റുകളും പരമാവധി ഉൽപ്പാദനക്ഷമത ചൂഷണം ചെയ്യാൻ ശ്രമിക്കുന്നത്.

അത് പരമാവധി പ്രയോജനപ്പെടുത്തുന്നതിന്, ഞങ്ങൾക്ക് പ്രാദേശിക സംഭരണം ആവശ്യമാണ്.

Kubernetes-ൽ പ്രാദേശിക സംഭരണം ഉപയോഗിക്കുന്നതിന് Kubernetes മൂന്ന് സംഗ്രഹങ്ങൾ നൽകുന്നു. ഈ:

• EmptyDir
• ഹോസ്റ്റ്പാത്ത്.
• പ്രാദേശിക

അവ എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നുവെന്നും അവ എങ്ങനെ സമാനമാണെന്നും നോക്കാം.

ഒന്നാമതായി, മൂന്ന് സമീപനങ്ങളിലും നമുക്ക് സംഭരണമുണ്ട് - ഇവ ഒരേ ഫിസിക്കൽ k8s നോഡിൽ സ്ഥിതിചെയ്യുന്ന ലോക്കൽ ഡിസ്കുകളാണ്. എന്നാൽ അവർക്ക് ചില വ്യത്യാസങ്ങളുണ്ട്.

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

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

പ്രകടനത്തിന്റെ അടിസ്ഥാനത്തിൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കും? ഇത് ലോക്കൽ ഡിസ്ക് വേഗതയിൽ പ്രവർത്തിക്കും, അതായത്. ഇത് നിങ്ങളുടെ സ്ക്രൂയിലേക്കുള്ള പൂർണ്ണ ആക്സസ് ആണ്.

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

ഈ സമീപനം ടെസ്റ്റുകൾക്ക് നല്ലതാണ്, കാരണം ഇത് ഇതിനകം സാധാരണ വേഗത കാണിക്കുന്നു, എന്നാൽ ഗുരുതരമായ എന്തെങ്കിലും ഈ ഓപ്ഷൻ അനുയോജ്യമല്ല.

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

ഈ രീതിക്ക് ഗുണങ്ങളുണ്ട്. ഇത് ഇതിനകം തന്നെ ഒരു യഥാർത്ഥ പെർസിസ്റ്റന്റാണ്, അതിലെ ഒരു ക്ലാസിക്. ഡിസ്കിൽ ചില വിലാസങ്ങളിൽ ഞങ്ങൾക്ക് ഡാറ്റ റെക്കോർഡ് ചെയ്യപ്പെടും.

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

പ്രത്യേകിച്ചും ഈ ആവശ്യങ്ങൾക്കായി, ഈ സങ്കീർണ്ണതയെല്ലാം മറയ്ക്കാൻ ഞങ്ങളുടെ ഓപ്പറേറ്ററിൽ ഞങ്ങൾ ടെംപ്ലേറ്റുകൾ ഉണ്ടാക്കി. നിങ്ങൾക്ക് ലളിതമായി ഇങ്ങനെ പറയാം: "ഓരോ ഫിസിക്കൽ നോഡിനും അത്തരം ഒരു പാതയിലും ക്ലിക്ക്ഹൗസിന്റെ ഒരു ഉദാഹരണം വേണമെന്ന് ഞാൻ ആഗ്രഹിക്കുന്നു."

എന്നാൽ ഞങ്ങൾക്ക് മാത്രമല്ല ഈ ആവശ്യം ആവശ്യമുള്ളത്, അതിനാൽ ആളുകൾക്ക് ഫിസിക്കൽ ഡിസ്കുകളിലേക്ക് പ്രവേശനം ലഭിക്കണമെന്ന് കുബെർനെറ്റസിൽ നിന്നുള്ള മാന്യന്മാരും മനസ്സിലാക്കുന്നു, അതിനാൽ അവർ മൂന്നാമത്തെ പാളി നൽകുന്നു.

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

നമുക്ക് നമ്മുടെ പ്രായോഗിക പ്രശ്നത്തിലേക്ക് മടങ്ങാം. നമുക്ക് YAML ടെംപ്ലേറ്റിലേക്ക് മടങ്ങാം. ഇവിടെ നമുക്ക് യഥാർത്ഥ സംഭരണമുണ്ട്. ഞങ്ങൾ അതിലേക്ക് മടങ്ങി. k8s-ൽ ഉള്ളതുപോലെ ഞങ്ങൾ ക്ലാസിക് VolumeClaim ടെംപ്ലേറ്റ് സജ്ജമാക്കി. ഏത് തരത്തിലുള്ള സംഭരണമാണ് നമുക്ക് വേണ്ടതെന്ന് ഞങ്ങൾ വിവരിക്കുന്നു.

ഇതിനുശേഷം, k8s സംഭരണം അഭ്യർത്ഥിക്കും. സ്റ്റേറ്റ്ഫുൾ സെറ്റിൽ അത് ഞങ്ങൾക്ക് അനുവദിക്കും. അവസാനം അത് ക്ലിക്ക്ഹൗസിന്റെ പക്കലായിരിക്കും.

ഞങ്ങൾക്ക് ഈ സ്കീം ഉണ്ടായിരുന്നു. ഞങ്ങളുടെ പെർസിസ്റ്റന്റ് സ്‌റ്റോറേജ് ചുവപ്പായിരുന്നു, അത് ചെയ്യേണ്ടതുണ്ടെന്ന് സൂചന നൽകി.

അത് പച്ചയായി മാറുന്നു. ഇപ്പോൾ k8s ക്ലസ്റ്റർ സ്കീമിലെ ClickHouse പൂർണ്ണമായി പൂർത്തിയായി. ഞങ്ങൾക്ക് ചില്ലുകളും പകർപ്പുകളും സൂ കീപ്പറും ഉണ്ട്, ഞങ്ങൾക്ക് ഒരു യഥാർത്ഥ പെർസിസ്റ്റന്റ് ഉണ്ട്, അത് ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊന്നിൽ നടപ്പിലാക്കുന്നു. സ്കീം ഇതിനകം പൂർണ്ണമായും പ്രവർത്തനക്ഷമമാണ്.

ഞങ്ങൾ തുടർന്നും ജീവിക്കുന്നു. ഞങ്ങളുടെ ക്ലസ്റ്റർ വികസിച്ചുകൊണ്ടിരിക്കുന്നു. കൂടാതെ Alexey ശ്രമിക്കുകയും ക്ലിക്ക്ഹൗസിന്റെ ഒരു പുതിയ പതിപ്പ് പുറത്തിറക്കുകയും ചെയ്യുന്നു.

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

ഇതിനെക്കുറിച്ച് നമുക്ക് എന്ത് പറയാൻ കഴിയും?

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

നമുക്ക് കുറച്ചുകൂടി ഉള്ളിലേക്ക് പോകാം. ഇതിനുമുമ്പ്, ClickHouse-ന്റെ പ്രത്യേകതകളുമായി ബന്ധപ്പെട്ട് ClickHouse-operator എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഞങ്ങൾ സംസാരിച്ചു.

ഏത് ഓപ്പറേറ്ററും പൊതുവായി എങ്ങനെ പ്രവർത്തിക്കുന്നു, അതുപോലെ തന്നെ അത് K8 കളുമായി എങ്ങനെ ഇടപഴകുന്നു എന്നതിനെക്കുറിച്ചും ഇപ്പോൾ കുറച്ച് വാക്കുകൾ പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

നമുക്ക് ആദ്യം K8 കളുമായി സംവദിക്കുന്നത് നോക്കാം. നമ്മൾ kubectl പ്രയോഗിക്കുമ്പോൾ എന്ത് സംഭവിക്കും? ഞങ്ങളുടെ ഒബ്‌ജക്‌റ്റുകൾ API വഴി etcd-ൽ ദൃശ്യമാകുന്നു.

ഉദാഹരണത്തിന്, അടിസ്ഥാന കുബർനെറ്റസ് ഒബ്‌ജക്റ്റുകൾ: പോഡ്, സ്റ്റേറ്റ്ഫുൾസെറ്റ്, സേവനം, അങ്ങനെ ലിസ്റ്റിൽ താഴെ.

അതേ സമയം, ഇതുവരെ ശാരീരികമായി ഒന്നും സംഭവിക്കുന്നില്ല. ഈ വസ്‌തുക്കൾ ക്ലസ്റ്ററിൽ ദ്രവ്യമാക്കണം.

ഈ ആവശ്യത്തിനായി, ഒരു കൺട്രോളർ പ്രത്യക്ഷപ്പെടുന്നു. ഈ വിവരണങ്ങൾ പ്രാവർത്തികമാക്കാൻ കഴിയുന്ന ഒരു പ്രത്യേക k8s ഘടകമാണ് കൺട്രോളർ. ശാരീരികമായി എങ്ങനെ, എന്ത് ചെയ്യണമെന്ന് അവനറിയാം. കണ്ടെയ്നറുകൾ എങ്ങനെ പ്രവർത്തിപ്പിക്കണമെന്ന് അവനറിയാം, സെർവർ പ്രവർത്തിക്കുന്നതിന് അവിടെ എന്താണ് കോൺഫിഗർ ചെയ്യേണ്ടത്.

അത് K8s-ൽ നമ്മുടെ ഒബ്ജക്റ്റുകളെ വസ്തുനിഷ്ഠമാക്കുന്നു.

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

എന്നാൽ K8s-ന് ഇനിപ്പറയുന്ന നല്ല കാര്യമുണ്ട്. പോഡുകളിൽ നിന്നും സ്റ്റേറ്റ്‌ഫുൾസെറ്റിൽ നിന്നും ഞങ്ങളുടെ ക്ലസ്റ്റർ കൂട്ടിച്ചേർക്കപ്പെടുന്ന ഈ സങ്കീർണ്ണമായ എന്റിറ്റി പോലെ എവിടെയെങ്കിലും ഞങ്ങൾക്ക് ഉണ്ടാകണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

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

ഞങ്ങൾ അത് kubectl apply വഴിയും അയയ്‌ക്കുന്നു. കുബർനെറ്റസ് അത് സന്തോഷത്തോടെ ഏറ്റെടുത്തു.

ഇപ്പോൾ ഞങ്ങളുടെ സ്റ്റോറേജിൽ, etcd-ലെ ഒബ്‌ജക്റ്റിന് ClickHouseInstallation എന്ന ഇഷ്‌ടാനുസൃത ഉറവിടം റെക്കോർഡുചെയ്യാനുള്ള അവസരമുണ്ട്.

എന്നാൽ ഇപ്പോൾ മറ്റൊന്നും സംഭവിക്കില്ല. അതായത്, നമ്മൾ ഇപ്പോൾ YAML ഫയൽ സൃഷ്‌ടിച്ച് ഷാർഡുകളും പകർപ്പുകളും വിവരിച്ച് “kubectl പ്രയോഗിക്കുക” എന്ന് പറഞ്ഞാൽ, കുബെർനെറ്റസ് അത് സ്വീകരിക്കുകയും etcd-ൽ ഇട്ട് ഇങ്ങനെ പറയുകയും ചെയ്യും: “കൊള്ളാം, പക്ഷേ എന്തുചെയ്യണമെന്ന് എനിക്കറിയില്ല. അതിന്റെ കൂടെ. ClickHouseInstallation എങ്ങനെ പരിപാലിക്കണമെന്ന് എനിക്കറിയില്ല.

അതനുസരിച്ച്, പുതിയ ഡാറ്റാ തരം സെർവ് ചെയ്യാൻ കുബർനെറ്റസിനെ സഹായിക്കാൻ ഞങ്ങൾക്ക് ഒരാളെ ആവശ്യമുണ്ട്. ഇടതുവശത്ത് നേറ്റീവ് ഡാറ്റാ തരങ്ങളുമായി പ്രവർത്തിക്കുന്ന ഒരു നേറ്റീവ് കുബർനെറ്റ്സ് കൺട്രോളർ ഞങ്ങൾക്കുണ്ട്. വലതുവശത്ത് ഇഷ്‌ടാനുസൃത ഡാറ്റ തരങ്ങളുമായി പ്രവർത്തിക്കാൻ കഴിയുന്ന ഒരു ഇഷ്‌ടാനുസൃത കൺട്രോളർ നമുക്കുണ്ടായിരിക്കണം.

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

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

ഓപ്പറേറ്റർ എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്? അവൻ അത് എങ്ങനെ ചെയ്യുന്നുവെന്ന് കാണാൻ വലതുവശത്ത് നോക്കാം. ഓപ്പറേറ്റർ ഇതെല്ലാം എങ്ങനെ യാഥാർത്ഥ്യമാക്കുന്നുവെന്നും കെ 8 കളുമായി കൂടുതൽ ഇടപെടൽ എങ്ങനെ സംഭവിക്കുന്നുവെന്നും നമുക്ക് കണ്ടെത്താം.

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

ഓപ്പറേറ്റർ ഇവന്റുകൾ സബ്‌സ്‌ക്രൈബുചെയ്യുകയും ഏതെങ്കിലും തരത്തിലുള്ള പ്രതികരണം നടത്തുകയും വേണം. ഉയർന്നുവരുന്ന സംഭവങ്ങളോട് പ്രതികരിക്കുക എന്നതാണ് അതിന്റെ ചുമതല.

ചില അപ്ഡേറ്റുകൾ വഴിയാണ് ഇവന്റുകൾ സൃഷ്ടിക്കുന്നത്. ClickHouseInstallation-ന്റെ വിവരണമുള്ള ഞങ്ങളുടെ YAML ഫയൽ എത്തുന്നു. kubectl apply വഴിയാണ് അദ്ദേഹം etcd ലേക്ക് പോയത്. അവിടെ ഒരു ഇവന്റ് ട്രിഗർ ചെയ്യപ്പെട്ടു, അതിന്റെ ഫലമായി ഈ ഇവന്റ് ClickHouse-operator-ലേക്ക് വന്നു. ഓപ്പറേറ്റർക്ക് ഈ വിവരണം ലഭിച്ചു. പിന്നെ അവൻ എന്തെങ്കിലും ചെയ്യണം. ClickHouseInstallation ഒബ്‌ജക്റ്റിനായി ഒരു അപ്‌ഡേറ്റ് വന്നിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾ ക്ലസ്റ്റർ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതുണ്ട്. ക്ലസ്റ്റർ അപ്‌ഡേറ്റ് ചെയ്യുക എന്നതാണ് ഓപ്പറേറ്ററുടെ ചുമതല.

അവൻ എന്താണ് ചെയ്യുന്നത്? ആദ്യം, ഈ അപ്‌ഡേറ്റ് ഉപയോഗിച്ച് ഞങ്ങൾ എന്തുചെയ്യും എന്നതിനുള്ള ഒരു പ്രവർത്തന പദ്ധതി തയ്യാറാക്കേണ്ടതുണ്ട്. അപ്ഡേറ്റുകൾ വളരെ ചെറുതായിരിക്കാം, അതായത്. YAML എക്സിക്യൂഷനിൽ ചെറുതാണ്, എന്നാൽ ക്ലസ്റ്ററിൽ വളരെ വലിയ മാറ്റങ്ങൾ വരുത്താം. അതിനാൽ, ഓപ്പറേറ്റർ ഒരു പ്ലാൻ സൃഷ്ടിക്കുന്നു, തുടർന്ന് അവൻ അതിൽ ഉറച്ചുനിൽക്കുന്നു.

ഈ പ്ലാൻ അനുസരിച്ച്, കായ്കൾ, സേവനങ്ങൾ, അതായത്, ഭൗതികമാക്കുന്നതിനായി അവൻ ഈ ഘടന ഉള്ളിൽ പാചകം ചെയ്യാൻ തുടങ്ങുന്നു. അവന്റെ പ്രധാന ദൗത്യം ചെയ്യുക. Kubernetes-ൽ ഒരു ClickHouse ക്ലസ്റ്റർ നിർമ്മിക്കുന്നത് ഇങ്ങനെയാണ്.

ഇപ്പോൾ നമുക്ക് അത്തരമൊരു രസകരമായ കാര്യം സ്പർശിക്കാം. ഇത് കുബർനെറ്റസും ഓപ്പറേറ്ററും തമ്മിലുള്ള ഉത്തരവാദിത്ത വിഭജനമാണ്, അതായത്. കുബർനെറ്റസ് എന്താണ് ചെയ്യുന്നത്, ഓപ്പറേറ്റർ എന്താണ് ചെയ്യുന്നത്, അവർ എങ്ങനെ പരസ്പരം ഇടപഴകുന്നു.

സിസ്റ്റം കാര്യങ്ങൾക്ക് കുബെർനെറ്റസ് ഉത്തരവാദിയാണ്, അതായത്. സിസ്റ്റം-സ്കോപ്പ് ആയി വ്യാഖ്യാനിക്കാവുന്ന ഒരു അടിസ്ഥാന വസ്തുക്കളുടെ ഒരു കൂട്ടം. പോഡുകൾ എങ്ങനെ സമാരംഭിക്കണം, കണ്ടെയ്നറുകൾ എങ്ങനെ പുനരാരംഭിക്കണം, വോള്യങ്ങൾ എങ്ങനെ മൌണ്ട് ചെയ്യാം, കോൺഫിഗ്മാപ്പിൽ എങ്ങനെ പ്രവർത്തിക്കാം, അതായത്, കുബർനെറ്റസിന് അറിയാം. സിസ്റ്റം എന്ന് വിളിക്കാവുന്ന എല്ലാം.

ഡൊമെയ്‌നുകളിൽ ഓപ്പറേറ്റർമാർ പ്രവർത്തിക്കുന്നു. ഓരോ ഓപ്പറേറ്ററും അവരുടേതായ വിഷയ മേഖലയ്ക്ക് വേണ്ടിയാണ് നിർമ്മിച്ചിരിക്കുന്നത്. ഞങ്ങൾ അത് ക്ലിക്ക്ഹൗസിനായി ചെയ്തു.

ഒരു പകർപ്പ് ചേർക്കൽ, ഒരു ഡയഗ്രം നിർമ്മിക്കൽ, നിരീക്ഷണം സജ്ജീകരിക്കൽ തുടങ്ങിയ വിഷയ മേഖലയുടെ അടിസ്ഥാനത്തിൽ ഓപ്പറേറ്റർ കൃത്യമായി ഇടപെടുന്നു. ഇത് ഒരു വിഭജനത്തിന് കാരണമാകുന്നു.

ആഡ് റെപ്ലിക്ക ആക്ഷൻ ചെയ്യുമ്പോൾ ഈ ഉത്തരവാദിത്ത വിഭജനം എങ്ങനെ സംഭവിക്കുന്നു എന്നതിന്റെ പ്രായോഗിക ഉദാഹരണം നോക്കാം.

ഓപ്പറേറ്റർക്ക് ഒരു ടാസ്ക് ലഭിക്കുന്നു - ഒരു പകർപ്പ് ചേർക്കാൻ. ഓപ്പറേറ്റർ എന്താണ് ചെയ്യുന്നത്? ഒരു പുതിയ സ്റ്റേറ്റ്ഫുൾസെറ്റ് സൃഷ്ടിക്കേണ്ടതുണ്ടെന്ന് ഓപ്പറേറ്റർ കണക്കാക്കും, അതിൽ അത്തരം ടെംപ്ലേറ്റുകൾ, വോളിയം ക്ലെയിം എന്നിവ വിവരിക്കണം.

അവൻ അതെല്ലാം തയ്യാറാക്കി K8 കൾക്ക് കൈമാറുന്നു. ConfigMap, StatefulSet, Volume എന്നിവ ആവശ്യമാണെന്ന് അദ്ദേഹം പറയുന്നു. കുബർനെറ്റസ് പ്രവർത്തിക്കുന്നു. താൻ പ്രവർത്തിക്കുന്ന അടിസ്ഥാന യൂണിറ്റുകൾ അവൻ ഭൗതികമാക്കുന്നു.

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

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

ഒരു പകർപ്പ് ചേർക്കുമ്പോൾ നിർവ്വഹണത്തിന്റെയും ഉത്തരവാദിത്ത വിഭജനത്തിന്റെയും ഒരു ശൃംഖല വളരെ ദൈർഘ്യമേറിയതാണെന്ന് ഇത് മാറുന്നു.

ഞങ്ങൾ ഞങ്ങളുടെ പ്രായോഗിക ജോലികൾ തുടരുന്നു. നിങ്ങൾക്ക് ഇതിനകം ഒരു ക്ലസ്റ്റർ ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് കോൺഫിഗറേഷൻ മൈഗ്രേറ്റ് ചെയ്യാം.

ക്ലിക്ക്ഹൗസ് മനസ്സിലാക്കുന്ന നിലവിലുള്ള xml-ലേക്ക് നിങ്ങൾക്ക് ഒട്ടിക്കാൻ കഴിയുന്ന തരത്തിലാണ് ഞങ്ങൾ ഇത് നിർമ്മിച്ചിരിക്കുന്നത്.

നിങ്ങൾക്ക് ClickHouse നന്നായി ട്യൂൺ ചെയ്യാം. ഹോസ്റ്റ്പാത്ത്, ലോക്കൽ സ്റ്റോറേജ് എന്നിവ വിശദീകരിക്കുമ്പോൾ ഞാൻ സംസാരിച്ചത് ജസ്റ്റ് സോൺഡ് വിന്യാസത്തെക്കുറിച്ചാണ്. ഇങ്ങനെയാണ് സോൺ ചെയ്ത വിന്യാസം ശരിയായി ചെയ്യേണ്ടത്.

അടുത്ത പ്രായോഗിക ജോലി നിരീക്ഷണമാണ്.

ഞങ്ങളുടെ ക്ലസ്റ്റർ മാറുകയാണെങ്കിൽ, ഞങ്ങൾ ആനുകാലികമായി നിരീക്ഷണം ക്രമീകരിക്കേണ്ടതുണ്ട്.

നമുക്ക് ഡയഗ്രം നോക്കാം. ഞങ്ങൾ ഇതിനകം ഇവിടെ പച്ച അമ്പുകൾ നോക്കി. ഇനി നമുക്ക് ചുവന്ന അമ്പുകൾ നോക്കാം. ഇങ്ങനെയാണ് ഞങ്ങളുടെ ക്ലസ്റ്റർ നിരീക്ഷിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നത്. ClickHouse ക്ലസ്റ്ററിൽ നിന്നുള്ള മെട്രിക്കുകൾ എങ്ങനെയാണ് പ്രോമിത്യൂസിലേക്കും തുടർന്ന് ഗ്രാഫാനയിലേക്കും എത്തുന്നത്.

നിരീക്ഷണത്തിൽ എന്താണ് ബുദ്ധിമുട്ട്? എന്തുകൊണ്ടാണ് ഇത് ഒരുതരം നേട്ടമായി അവതരിപ്പിക്കുന്നത്? ബുദ്ധിമുട്ട് ചലനാത്മകതയിലാണ്. ഞങ്ങൾക്ക് ഒരു ക്ലസ്റ്റർ ഉള്ളപ്പോൾ അത് സ്ഥിരമായിരിക്കുമ്പോൾ, നമുക്ക് ഒരു തവണ നിരീക്ഷണം സജ്ജീകരിക്കാം, ഇനി വിഷമിക്കേണ്ടതില്ല.

എന്നാൽ നമുക്ക് ധാരാളം ക്ലസ്റ്ററുകൾ ഉണ്ടെങ്കിൽ, അല്ലെങ്കിൽ എന്തെങ്കിലും നിരന്തരം മാറിക്കൊണ്ടിരിക്കുകയാണെങ്കിൽ, പ്രക്രിയ ചലനാത്മകമാണ്. മോണിറ്ററിംഗ് നിരന്തരം പുനഃക്രമീകരിക്കുന്നത് വിഭവങ്ങളുടെയും സമയത്തിന്റെയും പാഴാക്കലാണ്, അതായത്. വെറും അലസത പോലും. ഇത് യാന്ത്രികമാക്കേണ്ടതുണ്ട്. പ്രക്രിയയുടെ ചലനാത്മകതയിലാണ് ബുദ്ധിമുട്ട്. ഓപ്പറേറ്റർ ഇത് നന്നായി ഓട്ടോമേറ്റ് ചെയ്യുന്നു.

ഞങ്ങളുടെ ക്ലസ്റ്റർ എങ്ങനെ വികസിച്ചു? തുടക്കത്തിൽ അവൻ അങ്ങനെയായിരുന്നു.

അപ്പോൾ അവൻ ഇങ്ങനെയായിരുന്നു.

അവസാനം അവൻ ഇങ്ങനെ ആയി.

കൂടാതെ ഓപ്പറേറ്റർ സ്വയമേവ നിരീക്ഷണം നടത്തുന്നു. പ്രവേശനത്തിന്റെ ഒരൊറ്റ പോയിന്റ്.

പുറത്തുകടക്കുമ്പോൾ, ഞങ്ങളുടെ ക്ലസ്റ്ററിന്റെ ജീവിതം എങ്ങനെ തിളച്ചുമറിയുന്നുവെന്ന് കാണാൻ ഞങ്ങൾ ഗ്രാഫാന ഡാഷ്‌ബോർഡിലേക്ക് നോക്കുന്നു.

വഴിയിൽ, ഗ്രാഫാന ഡാഷ്‌ബോർഡും ഞങ്ങളുടെ ഓപ്പറേറ്ററുമായി നേരിട്ട് സോഴ്‌സ് കോഡിൽ വിതരണം ചെയ്യുന്നു. നിങ്ങൾക്ക് ബന്ധിപ്പിക്കാനും ഉപയോഗിക്കാനും കഴിയും. ഞങ്ങളുടെ DevOps എനിക്ക് ഈ സ്ക്രീൻഷോട്ട് നൽകി.

അടുത്തതായി എവിടെ പോകാനാണ് ഞങ്ങൾ ആഗ്രഹിക്കുന്നത്? ഈ:

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

നമുക്ക് ചില ഇന്റർമീഡിയറ്റ് ഫലങ്ങൾ എടുക്കാം.

അതിന്റെ ഫലമായി നമുക്ക് എന്ത് ലഭിക്കും? അത് ചെയ്യുന്നത് മൂല്യവത്താണോ അല്ലയോ? ഡാറ്റാബേസ് കുബെർനെറ്റസിലേക്ക് വലിച്ചിടാനും ഓപ്പറേറ്ററെ പൊതുവായും അലിറ്റ്നിറ്റി ഓപ്പറേറ്റർ പ്രത്യേകിച്ചും ഉപയോഗിക്കാനും ശ്രമിക്കേണ്ടതുണ്ടോ?

ഔട്ട്പുട്ടിൽ നമുക്ക് ലഭിക്കുന്നത്:

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

അവസാനമായി ഒരു ചോദ്യം മാത്രം ബാക്കി. വിർച്ച്വലൈസേഷനായ കുബർനെറ്റസിൽ ഞങ്ങൾക്ക് ഇതിനകം ഒരു ഡാറ്റാബേസ് ഉണ്ട്. പ്രകടനത്തിനായി ക്ലിക്ക്ഹൗസ് ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കുന്നതിനാൽ, അത്തരമൊരു പരിഹാരത്തിന്റെ പ്രകടനത്തെക്കുറിച്ച്?

എല്ലാം ശരിയാണ് എന്നതാണ് ഉത്തരം! ഞാൻ വിശദാംശങ്ങളിലേക്ക് പോകുന്നില്ല; ഇത് ഒരു പ്രത്യേക റിപ്പോർട്ടിന്റെ വിഷയമാണ്.

എന്നാൽ ടിഎസ്ബിഎസ് പോലെയുള്ള ഒരു പദ്ധതിയുണ്ട്. അതിന്റെ പ്രധാന ദൗത്യം എന്താണ്? ഇതൊരു ഡാറ്റാബേസ് പ്രകടന പരിശോധനയാണ്. ഊഷ്മളമായ ചൂടും മൃദുത്വവും മൃദുവും തമ്മിൽ താരതമ്യം ചെയ്യാനുള്ള ശ്രമമാണിത്.

അവൻ എങ്ങനെ പ്രവർത്തിക്കുന്നു? ഒരു ഡാറ്റ സെറ്റ് ജനറേറ്റ് ചെയ്തു. തുടർന്ന് ഈ ഡാറ്റ സെറ്റ് ഒരേ ടെസ്റ്റുകൾ ഉപയോഗിച്ച് വ്യത്യസ്ത ഡാറ്റാബേസുകളിൽ പ്രവർത്തിക്കുന്നു. ഓരോ ഡാറ്റാബേസും ഒരു പ്രശ്നം എങ്ങനെയെന്ന് അറിയുന്ന രീതിയിൽ പരിഹരിക്കുന്നു. തുടർന്ന് നിങ്ങൾക്ക് ഫലങ്ങൾ താരതമ്യം ചെയ്യാം.

ഇത് ഇതിനകം ഒരു വലിയ കൂട്ടം ഡാറ്റാബേസുകളെ പിന്തുണയ്ക്കുന്നു. ഞാൻ പ്രധാനമായും മൂന്നെണ്ണം തിരിച്ചറിഞ്ഞു. ഈ:

• ടൈംസ്കെയിൽDB.
• InfluxDB.
• ക്ലിക്ക്ഹൗസ്.

സമാനമായ മറ്റൊരു പരിഹാരവുമായി ഒരു താരതമ്യവും നടത്തി. റെഡ് ഷിഫ്റ്റുമായുള്ള താരതമ്യം. ആമസോണിൽ താരതമ്യം ചെയ്തു. ക്ലിക്ക്ഹൗസും ഇക്കാര്യത്തിൽ എല്ലാവരേക്കാളും ഏറെ മുന്നിലാണ്.

ഞാൻ പറഞ്ഞതിൽ നിന്ന് എന്ത് നിഗമനങ്ങളിൽ എത്തിച്ചേരാനാകും?

• കുബർനെറ്റസിലെ ഡിബി സാധ്യമാണ്. ഒരുപക്ഷേ എന്തെങ്കിലും സാധ്യമാണ്, പക്ഷേ മൊത്തത്തിൽ ഇത് സാധ്യമാണെന്ന് തോന്നുന്നു. ഞങ്ങളുടെ ഓപ്പറേറ്ററുടെ സഹായത്തോടെ Kubernetes-ലെ ClickHouse തീർച്ചയായും സാധ്യമാണ്.
• പ്രക്രിയകൾ ഓട്ടോമേറ്റ് ചെയ്യാനും ജീവിതം എളുപ്പമാക്കാനും ഓപ്പറേറ്റർ സഹായിക്കുന്നു.
• പ്രകടനം സാധാരണമാണ്.
• ഇത് ഉപയോഗിക്കാനും ഉപയോഗിക്കാനും കഴിയുമെന്ന് ഞങ്ങൾക്ക് തോന്നുന്നു.

ഓപ്പൺ സോഴ്സ് - ഞങ്ങളോടൊപ്പം ചേരൂ!

ഞാൻ ഇതിനകം പറഞ്ഞതുപോലെ, ഓപ്പറേറ്റർ പൂർണ്ണമായും ഓപ്പൺ സോഴ്‌സ് ഉൽപ്പന്നമാണ്, അതിനാൽ പരമാവധി ആളുകൾ ഇത് ഉപയോഗിച്ചാൽ അത് വളരെ നല്ലതാണ്. ഞങ്ങൾക്കൊപ്പം ചേരുക! ഞങ്ങൾ നിങ്ങൾക്കായി കാത്തിരിക്കുന്നു!

എല്ലാവർക്കുംനന്ദി!

ചോദ്യങ്ങൾ

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

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

ഹലോ! റിപ്പോർട്ടിന് നന്ദി! പെർസിസ്റ്റന്റ് വോള്യങ്ങളുമായി ബന്ധപ്പെട്ട ഒരു സാധാരണ ചോദ്യമുണ്ട്. ഈ ഓപ്പറേറ്ററുമായി ഞങ്ങൾ ഒരു കോൺഫിഗറേഷൻ സൃഷ്ടിക്കുമ്പോൾ, ഏത് നോഡിലാണ് നമുക്ക് ഒരു പ്രത്യേക ഡിസ്കോ ഫോൾഡറോ ഘടിപ്പിച്ചിരിക്കുന്നതെന്ന് ഓപ്പറേറ്റർ എങ്ങനെ നിർണ്ണയിക്കും? ഡിസ്കുള്ള ഈ നോഡുകളിൽ ഞങ്ങളുടെ ക്ലിക്ക്ഹൗസ് സ്ഥാപിക്കണമെന്ന് ഞങ്ങൾ ആദ്യം അദ്ദേഹത്തോട് വിശദീകരിക്കണം?

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

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

ഇത് കുറച്ച് എളുപ്പമാക്കാൻ സഹായിക്കുന്ന മൂന്നാമത്തെ ഓപ്ഷനാണ്, പ്രാദേശികം. ഞാൻ ഇതിനകം ഊന്നിപ്പറഞ്ഞതുപോലെ, ഇത് ട്യൂണിംഗിലെ കഠിനമായ ജോലിയാണ്, ഇത് ആത്യന്തികമായി പരമാവധി പ്രകടനം നേടാൻ സഹായിക്കുന്നു.

ഇതുമായി ബന്ധപ്പെട്ട് എനിക്ക് രണ്ടാമത്തെ ചോദ്യമുണ്ട്. നമുക്ക് ഒരു നോഡ് നഷ്‌ടപ്പെടുമോ ഇല്ലയോ എന്നത് പ്രശ്‌നമല്ലാത്ത വിധത്തിലാണ് കുബർനെറ്റസ് രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നത്. നമ്മുടെ ശരണം തൂങ്ങിക്കിടക്കുന്ന നോഡ് നഷ്ടപ്പെട്ടാൽ ഈ സാഹചര്യത്തിൽ നമ്മൾ എന്തുചെയ്യണം?

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

ഇപ്പോൾ ഒരു പ്രായോഗിക ചോദ്യത്തിനായി. ഡിസ്ക് ഉണ്ടായിരുന്ന നോഡ് നഷ്ടപ്പെട്ടാൽ എന്തുചെയ്യും? ഇവിടെ പ്രശ്നം ഉയർന്ന തലത്തിൽ പരിഹരിക്കപ്പെടുന്നു. ClickHouse-ന്റെ കാര്യത്തിൽ, ഞങ്ങൾക്ക് ഉയർന്ന തലത്തിൽ പ്രവർത്തിക്കുന്ന പകർപ്പുകൾ ഉണ്ട്, അതായത്. ClickHouse തലത്തിൽ.

ഫലമായുണ്ടാകുന്ന സ്വഭാവം എന്താണ്? ഡാറ്റ നഷ്‌ടപ്പെടുന്നില്ലെന്ന് ഉറപ്പാക്കുന്നതിന് DevOps ഉത്തരവാദിയാണ്. അവൻ റെപ്ലിക്കേഷൻ ശരിയായി സജ്ജീകരിക്കുകയും റെപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുകയും വേണം. ClickHouse ലെവലിലുള്ള പകർപ്പിന് ഡ്യൂപ്ലിക്കേറ്റഡ് ഡാറ്റ ഉണ്ടായിരിക്കണം. ഇത് ഓപ്പറേറ്റർ പരിഹരിക്കുന്ന ചുമതലയല്ല. അല്ലാതെ കുബർനെറ്റസ് തന്നെ പരിഹരിക്കുന്ന പ്രശ്നമല്ല. ഇത് ClickHouse തലത്തിലാണ്.

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

റിപ്പോർട്ടിന് നന്ദി! എല്ലാത്തരം മോശമായ കാര്യങ്ങളും സംഭവിക്കുമ്പോൾ, ഓപ്പറേറ്റർ തകരുകയും പുനരാരംഭിക്കുകയും ചെയ്യുന്നു, ആ നിമിഷത്തിൽ ഇവന്റുകൾ എത്തുന്നു, നിങ്ങൾ ഇത് എങ്ങനെയെങ്കിലും കൈകാര്യം ചെയ്യുമോ?

ഓപ്പറേറ്റർ ക്രാഷ് ചെയ്ത് റീസ്റ്റാർട്ട് ചെയ്താൽ എന്ത് സംഭവിക്കും, അല്ലേ?

അതെ. ആ നിമിഷം സംഭവങ്ങൾ എത്തി.

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

ഹലോ! റിപ്പോർട്ടിന് നന്ദി! ദിമിത്രി Zavyalov, കമ്പനി സ്മെഡോവ. ഹാപ്രോക്സി ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്യാനുള്ള കഴിവ് ഓപ്പറേറ്ററിലേക്ക് ചേർക്കാൻ പദ്ധതിയുണ്ടോ? സ്റ്റാൻഡേർഡ് ഒന്നുകൂടാതെ മറ്റ് ചില ബാലൻസറുകളിൽ എനിക്ക് താൽപ്പര്യമുണ്ട്, അതുവഴി അത് മികച്ചതും ClickHouse ശരിക്കും അവിടെ ഉണ്ടെന്ന് മനസ്സിലാക്കുന്നതുമാണ്.

നിങ്ങൾ ഇൻഗ്രെസിനെക്കുറിച്ചാണോ സംസാരിക്കുന്നത്?

അതെ, Haproxy ഉപയോഗിച്ച് Ingress മാറ്റിസ്ഥാപിക്കുക. ഹാപ്രോക്സിയിൽ, ക്ലസ്റ്ററിന് പകർപ്പുകളുള്ള ടോപ്പോളജി വ്യക്തമാക്കാൻ കഴിയും.

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

ഇതിനകം.

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

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