Text size
എന്റെ റഡാറിൽ6 മിനിറ്റ് വായന

ഒന്നിലധികം ക്ലസ്റ്ററുകൾ

ടീമുകൾക്ക് എന്തിനാണ് പല ക്ലസ്റ്ററുകളും ഉണ്ടാകുന്നത്, അവയെ എങ്ങനെ വളരെയധികം പ്രശ്നങ്ങളാക്കാതിരിക്കാൻ കഴിയും.

More than one cluster
AI ഉപയോഗിച്ച് സൃഷ്ടിച്ച ചിത്രീകരണം

മിക്കവാറും എല്ലാ കമ്പനികളും ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിലാണ് തുടങ്ങുന്നത്. പിന്നെ രണ്ടാമത്തേത് ആസൂത്രണത്തിനായി. പിന്നെ മറ്റൊരു മേഖലയില് . പിന്നെ ഒരു ടീമിന് സ്വന്തം ടീം വേണം. പിന്നെ എഡ്ജ്, ഡേറ്റാ സയൻസ് ടീം, ഏറ്റെടുക്കൽ... പെട്ടെന്ന് ആരെങ്കിലും ചോദിക്കുന്നു "നമ്മുടെ കൈവശം എത്ര കൂട്ടങ്ങൾ ഉണ്ട്" എന്ന്. കൃത്യമായ ഉത്തരം ആർക്കുമറിയില്ല.

മൾട്ടി-ക്ലസ്റ്റർ എന്നത് മിക്ക ടീമുകളും ഒരു തവണ എടുക്കുന്ന തീരുമാനമല്ല. അത് സംഭവിക്കുന്ന ഒരു കാര്യമാണ്. ചോദ്യം, നീ അത് മനഃപൂർവം ചെയ്യുന്നുണ്ടോ എന്നതാണ്.

ഒരു ക്ലസ്റ്റര് മതിയാകാത്തത് എന്തുകൊണ്ടാണെന്ന്

ഒന്നിലധികം കാരണങ്ങളുണ്ട്.

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

കുറച്ചുകൂടി നല്ല കാരണങ്ങൾഃ ഓരോ ടീമിനും സ്വന്തമായി ഒരു ക്ലസ്റ്റർ ലഭിക്കുന്നത്, കാരണം അത് എളുപ്പത്തിൽ ഒന്നിച്ച് ക്ലിക്ക് ചെയ്യാനാകുമായിരുന്നു.

നിങ്ങൾ ചേര് ക്കുന്ന ഓരോ ക്ലസ്റ്ററും അപ്ഗ്രേഡ് ചെയ്യാനും സുരക്ഷിതമാക്കാനും നിരീക്ഷിക്കാനും പണമടയ്ക്കാനും ഉള്ള മറ്റൊരു കാര്യമാണ്. ഓരോരുത്തരും അവരവരുടെ സ്ഥാനത്ത് നിൽക്കട്ടെ.

ഒരു ഫ്ലോട്ടിന്റെ മാനേജ്മെന്റ്

കുറച്ച് ക്ലസ്റ്ററുകളിലധികം ഉണ്ടെങ്കിൽ കൈകൊണ്ട് കാര്യങ്ങൾ ചെയ്യുന്നത് ഫലപ്രദമാകില്ല. നിങ്ങള് ക്ക് ഒരു ഫ്ലീറ്റ് സമീപനം വേണം.

ഗിറ്റോപ്സ് ആണ് അതിന്റെ അടിസ്ഥാനം. ഗിറ്റിലെ എല്ലാ ക്ലസ്റ്ററുകളിലും ഒരേ അടിസ്ഥാന രേഖയാണ് അര് ഗോ സിഡി അല്ലെങ്കിൽ ഫ്ലക്സ് വിന്യസിക്കുന്നത്: നിരീക്ഷണ ഏജന്റുമാർ, നയങ്ങൾ, പ്രവേശന അല്ലെങ്കിൽ ഗേറ്റ്വേ കൺട്രോളറുകൾ, സെർട്ട് മാനേജർ. അര് ഗോ സിഡി ആപ്ലിക്കേഷൻ സെറ്റുകൾ ക്ലസ്റ്റർ ജനറേറ്റർ ഉപയോഗിച്ച് പ്രത്യേകിച്ചും ഉപയോഗപ്രദമാണ്ഃ ഒരു ആപ്ലിക്കേഷൻ ഒരിക്കൽ നിർവചിക്കുക, അത് ഒരു ലേബലിന് അനുയോജ്യമായ എല്ലാ ക്ലസ്റ്ററുകളിലേക്കും വിന്യസിക്കപ്പെടും.

ക്ലസ്റ്ററിന്റെ ജീവിതചക്രം ക്ലസ്റ്ററുകള് സ്വയം സൃഷ്ടിക്കുകയും നവീകരിക്കുകയും ചെയ്യുക:

  • ക്ലസ്റ്റർ API പല ദാതാക്കളുടെയും Kubernetes റിസോഴ്സുകളുമായി Kubernetes ക്ലസ്റ്ററുകളെ നിയന്ത്രിക്കുന്നു.
  • ടെറാഫോർം അല്ലെങ്കിൽ ഓപ്പൺ ടോഫു മാനേജ്ഡ് സർവീസുകളുമായി (EKS, AKS, GKE) ഏറ്റവും സാധാരണമായ സമീപനമാണ്.
  • റാഞ്ചർ, തുറന്ന ക്ലസ്റ്റർ മാനേജ്മെന്റ് ഗ്ലൌഡ് സ്പെസിഫിക് ഫ്ലീറ്റ് ടൂളുകളും (ജി.ഇ.ഇ. ഫ്ലീറ്റുകൾ പോലുള്ളവ) ഒരു കേന്ദ്ര മാനേജ്മെന്റ് ലെയർ ചേർക്കുന്നു.

സ്റ്റാൻഡേർഡൈസേഷനാണ് അതിനെ സ്കെയിലാക്കുന്നത്. ക്ലസ്റ്ററുകൾ കന്നുകാലികളായിരിക്കണം, വളർത്തുമൃഗങ്ങളല്ല. ഒരേ ടെംപ്ലേറ്റുകളിൽ നിന്നും ഒരേ അടിസ്ഥാന രേഖകളിലൂടെയും സൃഷ്ടിച്ചതാണ്. അതിനാൽ ഏത് എൻജിനീയർക്കും ഏത് ക്ലസ്റ്ററിലും പ്രവർത്തിക്കാം.

കണക്ട് ചെയ്യുന്ന ക്ലസ്റ്ററുകൾ

ചിലപ്പോള് വ്യത്യസ്ത ക്ലസ്റ്ററുകളിലെ സേവനങ്ങള് പരസ്പരം സംസാരിക്കേണ്ടതുണ്ട്. ഓപ്ഷനുകൾ:

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

എന്റെ ഉപദേശം: കഴിയുമ്പോഴെല്ലാം ക്രോസ്-ക്ലസ്റ്റർ ആശ്രിതത്വം ഒഴിവാക്കുക. സിസ്റ്റത്തിന്റെ ഒരു പൂർണ്ണ ഭാഗം (ഉദാഹരണത്തിന് ഒരു പ്രദേശം) സേവിക്കുന്ന ഓരോ ക്ലസ്റ്ററും ക്ലസ്റ്ററുകളിലുടനീളം നിരന്തരം വിളിക്കുന്ന സേവനങ്ങളേക്കാൾ വളരെ ലളിതമാണ്.

എവിടെയും ഐഡന്റിറ്റിയും രഹസ്യങ്ങളും

പല ക്ലസ്റ്ററുകളിലും, പ്രവേശന നിയന്ത്രണം സങ്കീർണ്ണമാകുന്നു:

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

കപ്പലിലെ നിരീക്ഷണ ശേഷി

ഓരോ ക്ലസ്റ്ററും മെട്രിക്സ്, ലോഗ്, ട്രെയ്സ് എന്നിവ ഒരു കേന്ദ്ര സ്ഥലത്തേക്ക് അയയ്ക്കുന്നതാണ് പ്രധാനം. എല്ലാം ക്ലസ്റ്ററിന്റെ പേരും മേഖലയും ഉപയോഗിച്ച് അടയാളപ്പെടുത്തുക. എല്ലാ ക്ലസ്റ്ററുകളും വശങ്ങളിലായി കാണിക്കുന്ന ഒരു ഡാഷ്ബോർഡ്, പതിപ്പുകളും ആരോഗ്യവും ഉപയോഗിച്ച്, പെട്ടെന്ന് ഉത്തരം നൽകുന്നു "ഇത് ഈ ക്ലസ്റ്റർ മാത്രമാണോ, അതോ അവയെല്ലാം തന്നെയാണോ?"

ട്രാക്കും പതിപ്പുകൾ: ഓരോ ക്ലസ്റ്ററും ഏത് Kubernetes പതിപ്പും ഏത് ആഡ്-ഓൺ പതിപ്പുകളും പ്രവർത്തിപ്പിക്കുന്നു. ഒരു കപ്പലിലൂടെയുള്ള പതിപ്പ് നീക്കം "അത് A ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്നു, പക്ഷേ B അല്ല" എന്നതിന്റെ ഒരു ക്ലാസിക് ഉറവിടമാണ്.

എത്ര ഗ്രൂപ്പുകൾ വേണം?

നിങ്ങളുടെ ആവശ്യങ്ങൾ അനുവദിക്കുന്നത്രയും, നിങ്ങളുടെ ഒറ്റപ്പെടൽ, മേഖല, പാലിക്കൽ ആവശ്യങ്ങൾ ആവശ്യപ്പെടുന്നത്രയും. എണ്ണമെന്തായാലും, ഒന്നാം ദിവസം മുതൽ ഒരു ഫ്ലീറ്റായി അവയെ കൈകാര്യം ചെയ്യുക: എല്ലാത്തിനും ഗിറ്റ്ഓപ്പുകൾ, എല്ലായിടത്തും ഒരേ അടിസ്ഥാനം, കേന്ദ്ര നിരീക്ഷണക്ഷമത.

എന്റെ അഭിപ്രായം: എല്ലാ ക്ലസ്റ്ററുകളും ഒരേപോലെ കാണുമ്പോൾ മൾട്ടി ക്ലസ്റ്റർ കൈകാര്യം ചെയ്യാവുന്നതാണ്. അവരിൽ ഒരാൾ പ്രത്യേകതയുള്ള ദിവസം മുതൽ പ്രശ്നങ്ങൾ തുടങ്ങുന്നു.

ഡെസ്ലി