കുബർനെറ്റസ് ക്ലസ്റ്ററുകൾ രൂപകൽപ്പന ചെയ്യുന്നു: എത്ര എണ്ണം ഉണ്ടായിരിക്കണം?

കുറിപ്പ്. വിവർത്തനം.: ഈ മെറ്റീരിയൽ ഒരു വിദ്യാഭ്യാസ പദ്ധതിയിൽ നിന്നുള്ളതാണ് പഠിക്കുക8s കുബെർനെറ്റസ് അടിസ്ഥാനമാക്കിയുള്ള ഇൻഫ്രാസ്ട്രക്ചർ രൂപകൽപ്പന ചെയ്യുമ്പോൾ ഒരു ജനപ്രിയ ചോദ്യത്തിനുള്ള ഉത്തരമാണ്. ഓരോ ഓപ്ഷന്റെയും ഗുണദോഷങ്ങളെക്കുറിച്ചുള്ള വിശദമായ വിവരണങ്ങൾ നിങ്ങളുടെ പ്രോജക്റ്റിനായി മികച്ച തിരഞ്ഞെടുപ്പ് നടത്താൻ നിങ്ങളെ സഹായിക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

അച്ചു ഡി.ആർ.: ഒരേ കൂട്ടം ജോലിഭാരങ്ങൾ പല വലിയ ക്ലസ്റ്ററുകളിലും (ഓരോ ക്ലസ്റ്ററിനും ധാരാളം വർക്ക്ലോഡുകൾ ഉണ്ടായിരിക്കും) അല്ലെങ്കിൽ നിരവധി ചെറിയവയിൽ (ഓരോ ക്ലസ്റ്ററിലും ചെറിയ എണ്ണം ലോഡുകളോടെ) പ്രവർത്തിപ്പിക്കാം.

ഓരോ സമീപനത്തിന്റെയും ഗുണങ്ങളും ദോഷങ്ങളും വിലയിരുത്തുന്ന ഒരു പട്ടിക ചുവടെയുണ്ട്:

ആപ്ലിക്കേഷനുകൾ പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള ഒരു പ്ലാറ്റ്ഫോമായി Kubernetes ഉപയോഗിക്കുമ്പോൾ, ക്ലസ്റ്ററുകൾ സജ്ജീകരിക്കുന്നതിന്റെ സങ്കീർണതകളെക്കുറിച്ച് പലപ്പോഴും നിരവധി അടിസ്ഥാന ചോദ്യങ്ങൾ ഉയർന്നുവരുന്നു:

• ഞാൻ എത്ര ക്ലസ്റ്ററുകൾ ഉപയോഗിക്കണം?
• ഞാൻ അവയെ എത്ര വലുതാക്കണം?
• ഓരോ ക്ലസ്റ്ററും എന്താണ് ഉൾപ്പെടുത്തേണ്ടത്?

ഈ ലേഖനത്തിൽ, ഓരോ സമീപനത്തിന്റെയും ഗുണദോഷങ്ങൾ വിശകലനം ചെയ്തുകൊണ്ട് ഈ ചോദ്യങ്ങൾക്കെല്ലാം ഉത്തരം നൽകാൻ ഞാൻ ശ്രമിക്കും.

ഒരു ചോദ്യത്തിന്റെ പ്രസ്താവന

ഒരു സോഫ്റ്റ്‌വെയർ ഡെവലപ്പർ എന്ന നിലയിൽ, നിങ്ങൾ ഒരേ സമയം നിരവധി ആപ്ലിക്കേഷനുകൾ വികസിപ്പിക്കുകയും പ്രവർത്തിപ്പിക്കുകയും ചെയ്യാം.

കൂടാതെ, ഈ ആപ്ലിക്കേഷനുകളുടെ പല സന്ദർഭങ്ങളും വ്യത്യസ്ത പരിതസ്ഥിതികളിൽ പ്രവർത്തിക്കാൻ സാധ്യതയുണ്ട് - ഉദാഹരണത്തിന്, ഇവ ആയിരിക്കാം ദേവ്, പരിശോധന и ഉത്പന്നം.

ഫലം ആപ്ലിക്കേഷനുകളുടെയും പരിതസ്ഥിതികളുടെയും ഒരു മുഴുവൻ മാട്രിക്സാണ്:

ആപ്ലിക്കേഷനുകളും പരിസ്ഥിതിയും

മുകളിലുള്ള ഉദാഹരണം 3 ആപ്ലിക്കേഷനുകളെയും 3 പരിതസ്ഥിതികളെയും പ്രതിനിധീകരിക്കുന്നു, അതിന്റെ ഫലമായി ആകെ 9 സാധ്യമായ ഓപ്ഷനുകൾ ലഭിക്കും.

ഓരോ ആപ്ലിക്കേഷൻ സംഭവവും മറ്റുള്ളവരുമായി സ്വതന്ത്രമായി പ്രവർത്തിക്കാൻ കഴിയുന്ന ഒരു സ്വയം ഉൾക്കൊള്ളുന്ന വിന്യാസ യൂണിറ്റാണ്.

അതല്ല ആപ്ലിക്കേഷൻ ഉദാഹരണം പലതും ഉൾപ്പെട്ടേക്കാം ഘടകങ്ങൾ, ഫ്രണ്ട്‌എൻഡ്, ബാക്കെൻഡ്, ഡാറ്റാബേസ് മുതലായവ. ഒരു മൈക്രോസർവീസസ് ആപ്ലിക്കേഷന്റെ കാര്യത്തിൽ, ഉദാഹരണത്തിൽ എല്ലാ മൈക്രോസർവീസുകളും ഉൾപ്പെടും.

തൽഫലമായി, Kubernetes ഉപയോക്താക്കൾക്ക് നിരവധി ചോദ്യങ്ങളുണ്ട്:

• എല്ലാ അപേക്ഷാ സന്ദർഭങ്ങളും ഒരു ക്ലസ്റ്ററിൽ സ്ഥാപിക്കണമോ?
• ഓരോ അപേക്ഷാ സന്ദർഭത്തിനും ഒരു പ്രത്യേക ക്ലസ്റ്റർ ഉണ്ടായിരിക്കുന്നത് മൂല്യവത്താണോ?
• അല്ലെങ്കിൽ മുകളിൽ പറഞ്ഞ സമീപനങ്ങളുടെ സംയോജനം ഉപയോഗിക്കേണ്ടതുണ്ടോ?

ഈ ഓപ്ഷനുകളെല്ലാം തികച്ചും പ്രായോഗികമാണ്, കാരണം ഉപയോക്താവിന്റെ കഴിവുകളെ പരിമിതപ്പെടുത്താത്ത ഒരു വഴക്കമുള്ള സംവിധാനമാണ് കുബർനെറ്റസ്.

സാധ്യമായ ചില വഴികൾ ഇതാ:

• ഒരു വലിയ പൊതു ക്ലസ്റ്റർ;
• വളരെ പ്രത്യേകമായ നിരവധി ചെറിയ ക്ലസ്റ്ററുകൾ;
• ഓരോ ആപ്ലിക്കേഷനും ഒരു ക്ലസ്റ്റർ;
• ഒരു പരിസ്ഥിതിക്ക് ഒരു ക്ലസ്റ്റർ.

ചുവടെ കാണിച്ചിരിക്കുന്നതുപോലെ, ആദ്യ രണ്ട് സമീപനങ്ങളും ഓപ്ഷനുകളുടെ സ്കെയിലിന്റെ വിപരീത അറ്റത്താണ്:

കുറച്ച് വലിയ ക്ലസ്റ്ററുകൾ (ഇടത്) മുതൽ നിരവധി ചെറിയവ വരെ (വലത്)

പൊതുവേ, ഒരു ക്ലസ്റ്ററിന് കൂടുതൽ നോഡുകളും പോഡുകളും ഉണ്ടെങ്കിൽ മറ്റൊന്നിനേക്കാൾ "വലുത്" ആയി കണക്കാക്കുന്നു. ഉദാഹരണത്തിന്, 10 നോഡുകളും 100 പോഡുകളുമുള്ള ഒരു ക്ലസ്റ്റർ 1 നോഡും 10 പോഡുകളുമുള്ള ഒരു ക്ലസ്റ്ററിനേക്കാൾ വലുതാണ്.

ശരി, നമുക്ക് ആരംഭിക്കാം!

1. ഒരു വലിയ പൊതു ക്ലസ്റ്റർ

എല്ലാ ജോലിഭാരങ്ങളും ഒരു ക്ലസ്റ്ററിൽ സ്ഥാപിക്കുക എന്നതാണ് ആദ്യ ഓപ്ഷൻ:

ഒരു വലിയ കൂട്ടം

ഈ സമീപനത്തിനുള്ളിൽ, ക്ലസ്റ്റർ ഒരു സാർവത്രികമായി ഉപയോഗിക്കുന്നു ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്ഫോം — നിലവിലുള്ള കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ നിങ്ങൾക്ക് ആവശ്യമുള്ളതെല്ലാം വിന്യസിക്കുക.

നെയിംസ്പേസുകൾ ക്ലസ്റ്ററിന്റെ ഭാഗങ്ങൾ പരസ്പരം ലോജിക്കലായി വേർപെടുത്താൻ Kubernetes അനുവദിക്കുന്നു, അതുവഴി ഓരോ ആപ്ലിക്കേഷനും അതിന്റേതായ നെയിംസ്പേസ് ഉണ്ടായിരിക്കും.

ഈ സമീപനത്തിന്റെ ഗുണങ്ങളും ദോഷങ്ങളും നോക്കാം.

+ വിഭവങ്ങളുടെ കാര്യക്ഷമമായ ഉപയോഗം

ഒരൊറ്റ ക്ലസ്റ്റർ ഉപയോഗിച്ച്, കുബർനെറ്റസ് ക്ലസ്റ്റർ പ്രവർത്തിപ്പിക്കുന്നതിനും നിയന്ത്രിക്കുന്നതിനും ആവശ്യമായ എല്ലാ വിഭവങ്ങളുടെയും ഒരു പകർപ്പ് മാത്രമേ നിങ്ങൾക്ക് ആവശ്യമുള്ളൂ.

ഉദാഹരണത്തിന്, മാസ്റ്റർ നോഡുകൾക്ക് ഇത് ശരിയാണ്. സാധാരണഗതിയിൽ, ഓരോ കുബർനെറ്റസ് ക്ലസ്റ്ററിനും 3 മാസ്റ്റർ നോഡുകൾ ഉണ്ട്, അതിനാൽ ഒരൊറ്റ ക്ലസ്റ്ററിന് അവയുടെ എണ്ണം അതേപടി നിലനിൽക്കും (താരതമ്യത്തിന്, 10 ക്ലസ്റ്ററുകൾക്ക് 30 മാസ്റ്റർ നോഡുകൾ ആവശ്യമാണ്).

ലോഡ് ബാലൻസറുകൾ, ഇൻഗ്രെസ്സ് കൺട്രോളറുകൾ, പ്രാമാണീകരണം, ലോഗിംഗ്, മോണിറ്ററിംഗ് സിസ്റ്റങ്ങൾ എന്നിങ്ങനെ മുഴുവൻ ക്ലസ്റ്ററുകളിലുടനീളം പ്രവർത്തിക്കുന്ന മറ്റ് സേവനങ്ങൾക്കും മുകളിൽ പറഞ്ഞ സൂക്ഷ്മത ബാധകമാണ്.

ഒരൊറ്റ ക്ലസ്റ്ററിൽ, എല്ലാ ജോലിഭാരങ്ങൾക്കും ഈ സേവനങ്ങളെല്ലാം ഒരേസമയം ഉപയോഗിക്കാനാകും (ഒന്നിലധികം ക്ലസ്റ്ററുകളിലെന്നപോലെ അവയുടെ പകർപ്പുകൾ സൃഷ്ടിക്കേണ്ട ആവശ്യമില്ല).

+ വിലകുറഞ്ഞത്

മേൽപ്പറഞ്ഞവയുടെ അനന്തരഫലമായി, ഓവർഹെഡ് ചെലവുകൾ ഇല്ലാത്തതിനാൽ കുറച്ച് ക്ലസ്റ്ററുകൾ സാധാരണയായി വിലകുറഞ്ഞതാണ്.

മാസ്റ്റർ നോഡുകൾക്ക് ഇത് പ്രത്യേകിച്ചും സത്യമാണ്, അവ എങ്ങനെ ഹോസ്റ്റ് ചെയ്‌തിരിക്കുന്നു എന്നത് പരിഗണിക്കാതെ തന്നെ ഗണ്യമായ തുക ചിലവാകും (ഓൺ-പ്രിമൈസിലോ ക്ലൗഡിലോ).

ചിലർ കുബെർനെറ്റസ് സേവനങ്ങൾ നിയന്ത്രിച്ചു Google Kubernetes എഞ്ചിൻ (GKE) അഥവാ അസുർ കുബേർനെറ്റ്സ് സേവനം (എകെഎസ്), നിയന്ത്രണ പാളി സൗജന്യമായി നൽകുക. ഈ സാഹചര്യത്തിൽ, ചെലവ് പ്രശ്നം കുറവാണ്.

ഓരോ കുബർനെറ്റസ് ക്ലസ്റ്ററിന്റെ പ്രവർത്തനത്തിനും ഒരു നിശ്ചിത ഫീസ് ഈടാക്കുന്ന നിയന്ത്രിത സേവനങ്ങളുമുണ്ട് (ഉദാഹരണത്തിന്, ആമസോൺ ഇലാസ്റ്റിക് കുബർനെറ്റസ് സേവനം, ഇ.കെ.എസ്).

+ കാര്യക്ഷമമായ ഭരണം

ഒരു ക്ലസ്റ്റർ കൈകാര്യം ചെയ്യുന്നത് പലതും കൈകാര്യം ചെയ്യുന്നതിനേക്കാൾ എളുപ്പമാണ്.

അഡ്മിനിസ്ട്രേഷനിൽ ഇനിപ്പറയുന്ന ജോലികൾ ഉൾപ്പെട്ടേക്കാം:

• കുബർനെറ്റസ് പതിപ്പ് അപ്ഡേറ്റ്;
• ഒരു CI/CD പൈപ്പ്ലൈൻ സ്ഥാപിക്കൽ;
• CNI പ്ലഗിൻ ഇൻസ്റ്റാൾ ചെയ്യുന്നു;
• ഒരു ഉപയോക്തൃ പ്രാമാണീകരണ സംവിധാനം സജ്ജീകരിക്കുക;
• ഒരു ആക്സസ് കൺട്രോളറിന്റെ ഇൻസ്റ്റാളേഷൻ;

കൂടാതെ മറ്റു പലതും…

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

പല ക്ലസ്റ്ററുകൾക്കും, പ്രവർത്തനങ്ങൾ പല പ്രാവശ്യം ആവർത്തിക്കേണ്ടി വരും, ഈ പ്രക്രിയയിൽ സ്ഥിരതയും സ്ഥിരതയും ഉറപ്പാക്കാൻ പ്രോസസുകളുടെയും ടൂളുകളുടെയും ചില ഓട്ടോമേഷൻ ആവശ്യമായി വരും.

ഇപ്പോൾ ദോഷങ്ങളെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ.

- പരാജയത്തിന്റെ ഒറ്റ പോയിന്റ്

വിസമ്മതിച്ചാൽ ഒരേയൊരു ക്ലസ്റ്റർ ഉടൻ പ്രവർത്തിക്കുന്നത് നിർത്തും എല്ലാം ജോലിഭാരം!

കാര്യങ്ങൾ തെറ്റാകാൻ നിരവധി മാർഗങ്ങളുണ്ട്:

• Kubernetes അപ്‌ഡേറ്റ് ചെയ്യുന്നത് അപ്രതീക്ഷിത പാർശ്വഫലങ്ങളിലേക്ക് നയിക്കുന്നു;
• ഒരു ക്ലസ്റ്റർ-വൈഡ് ഘടകം (ഉദാഹരണത്തിന്, ഒരു CNI പ്ലഗിൻ) പ്രതീക്ഷിച്ചതുപോലെ പ്രവർത്തിക്കാൻ തുടങ്ങുന്നു;
• ക്ലസ്റ്റർ ഘടകങ്ങളിൽ ഒന്ന് ശരിയായി ക്രമീകരിച്ചിട്ടില്ല;
• അടിസ്ഥാന സൗകര്യങ്ങളുടെ പരാജയം.

പങ്കിട്ട ക്ലസ്റ്ററിൽ ഹോസ്റ്റ് ചെയ്‌തിരിക്കുന്ന എല്ലാ ജോലിഭാരങ്ങൾക്കും അത്തരം ഒരു സംഭവം ഗുരുതരമായ നാശമുണ്ടാക്കും.

− കർശനമായ ഇൻസുലേഷൻ ഇല്ല

ഒരു പങ്കിട്ട ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുക എന്നതിനർത്ഥം ക്ലസ്റ്റർ നോഡുകളിൽ ആപ്ലിക്കേഷനുകൾ ഹാർഡ്‌വെയർ, നെറ്റ്‌വർക്കിംഗ് കഴിവുകൾ, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം എന്നിവ പങ്കിടുന്നു എന്നാണ്.

ഒരർത്ഥത്തിൽ, ഒരേ നോഡിൽ പ്രവർത്തിക്കുന്ന രണ്ട് വ്യത്യസ്ത ആപ്ലിക്കേഷനുകളുള്ള രണ്ട് കണ്ടെയ്‌നറുകൾ ഒരേ OS കേർണൽ പ്രവർത്തിക്കുന്ന ഒരേ മെഷീനിൽ പ്രവർത്തിക്കുന്ന രണ്ട് പ്രക്രിയകൾ പോലെയാണ്.

Linux കണ്ടെയ്‌നറുകൾ ഏതെങ്കിലും തരത്തിലുള്ള ഐസൊലേഷൻ നൽകുന്നു, എന്നാൽ ഇത് വെർച്വൽ മെഷീനുകൾ നൽകുന്നതിനേക്കാൾ ശക്തമല്ല. സാരാംശത്തിൽ, ഒരു കണ്ടെയ്‌നറിലെ ഒരു പ്രോസസ്സ് ഹോസ്റ്റ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ പ്രവർത്തിക്കുന്ന അതേ പ്രക്രിയയാണ്.

ഇതൊരു സുരക്ഷാ പ്രശ്‌നമാകാം: ഈ ക്രമീകരണം സൈദ്ധാന്തികമായി ബന്ധമില്ലാത്ത ആപ്ലിക്കേഷനുകളെ പരസ്പരം ആശയവിനിമയം നടത്താൻ അനുവദിക്കുന്നു (മനപ്പൂർവ്വമോ ആകസ്മികമോ).

കൂടാതെ, ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിലെ എല്ലാ ജോലിഭാരങ്ങളും ചില ക്ലസ്റ്റർ-വൈഡ് സേവനങ്ങൾ പങ്കിടുന്നു ഡിഎൻഎസ് - ക്ലസ്റ്ററിലെ മറ്റ് ആപ്ലിക്കേഷനുകളുടെ സേവനങ്ങൾ കണ്ടെത്താൻ ഇത് അപ്ലിക്കേഷനുകളെ അനുവദിക്കുന്നു.

ആപ്ലിക്കേഷൻ സുരക്ഷാ ആവശ്യകതകളെ ആശ്രയിച്ച് മുകളിലുള്ള എല്ലാ പോയിന്റുകൾക്കും വ്യത്യസ്ത അർത്ഥങ്ങൾ ഉണ്ടായിരിക്കാം.

പോലുള്ള സുരക്ഷാ പ്രശ്നങ്ങൾ തടയാൻ Kubernetes വിവിധ ടൂളുകൾ നൽകുന്നു PodSecurityPolicies и നെറ്റ്‌വർക്ക് നയങ്ങൾ. എന്നിരുന്നാലും, അവ ശരിയായി സജ്ജീകരിക്കുന്നതിന് കുറച്ച് അനുഭവം ആവശ്യമാണ്; കൂടാതെ, അവർക്ക് എല്ലാ സുരക്ഷാ ദ്വാരങ്ങളും അടയ്ക്കാൻ കഴിയില്ല.

കുബെർനെറ്റസ് യഥാർത്ഥത്തിൽ രൂപകൽപ്പന ചെയ്‌തതാണെന്ന് എപ്പോഴും ഓർക്കേണ്ടത് പ്രധാനമാണ് പങ്കുവയ്ക്കുന്നു, വേണ്ടിയല്ല ഒറ്റപ്പെടലും സുരക്ഷിതത്വവും.

− കർശനമായ മൾട്ടി ടെനൻസിയുടെ അഭാവം

ഒരു കുബെർനെറ്റസ് ക്ലസ്റ്ററിലെ പങ്കിട്ട വിഭവങ്ങളുടെ സമൃദ്ധി കണക്കിലെടുക്കുമ്പോൾ, വ്യത്യസ്ത ആപ്ലിക്കേഷനുകൾക്ക് പരസ്പരം കാലിൽ പിടിക്കാൻ കഴിയുന്ന നിരവധി മാർഗങ്ങളുണ്ട്.

ഉദാഹരണത്തിന്, ഒരു ആപ്ലിക്കേഷൻ പങ്കിട്ട റിസോഴ്സ് (സിപിയു അല്ലെങ്കിൽ മെമ്മറി പോലുള്ളവ) കുത്തകയാക്കുകയും അതേ നോഡിൽ പ്രവർത്തിക്കുന്ന മറ്റ് ആപ്ലിക്കേഷനുകൾ അതിലേക്കുള്ള ആക്സസ് നിരസിക്കുകയും ചെയ്തേക്കാം.

ഈ സ്വഭാവം നിയന്ത്രിക്കാൻ കുബെർനെറ്റസ് വിവിധ സംവിധാനങ്ങൾ നൽകുന്നു വിഭവ അഭ്യർത്ഥനകളും പരിധികളും (ലേഖനവും കാണുക" കുബർനെറ്റസിലെ സിപിയു പരിധികളും ആക്രമണാത്മക ത്രോട്ടിലിംഗും " - ഏകദേശം. വിവർത്തനം.), റിസോഴ്സ് ക്വാട്ടകൾ и പരിധി ശ്രേണികൾ. എന്നിരുന്നാലും, സുരക്ഷയുടെ കാര്യത്തിലെന്നപോലെ, അവയുടെ കോൺഫിഗറേഷൻ വളരെ നിസ്സാരമാണ്, മാത്രമല്ല അപ്രതീക്ഷിതമായ എല്ലാ പാർശ്വഫലങ്ങളും തടയാൻ അവർക്ക് കഴിയില്ല.

− ധാരാളം ഉപയോക്താക്കൾ

ഒരൊറ്റ ക്ലസ്റ്ററിന്റെ കാര്യത്തിൽ, നിങ്ങൾ അതിലേക്ക് നിരവധി ആളുകൾക്ക് പ്രവേശനം തുറക്കേണ്ടതുണ്ട്. അവരുടെ എണ്ണം കൂടുന്തോറും അവർ എന്തെങ്കിലും "തകർക്കാൻ" സാധ്യത കൂടുതലാണ്.

ക്ലസ്‌റ്ററിനുള്ളിൽ ആർക്കൊക്കെ എന്തു ചെയ്യാമെന്നത് നിങ്ങൾക്ക് നിയന്ത്രിക്കാനാകും റോൾ-ബേസ്ഡ് ആക്സസ് കൺട്രോൾ (RBAC) (ലേഖനം കാണുക" Kubernetes-ലെ ഉപയോക്താക്കളും അധികാരപ്പെടുത്തൽ RBAC " - ഏകദേശം. വിവർത്തനം.). എന്നിരുന്നാലും, ഉപയോക്താക്കളെ അവരുടെ ഉത്തരവാദിത്ത മേഖലയുടെ പരിധിക്കുള്ളിൽ എന്തെങ്കിലും "തകർക്കുന്നതിൽ" നിന്ന് ഇത് തടയില്ല.

- ക്ലസ്റ്ററുകൾ അനിശ്ചിതമായി വളരാൻ കഴിയില്ല

എല്ലാ ജോലിഭാരങ്ങൾക്കും ഉപയോഗിക്കുന്ന ക്ലസ്റ്റർ വളരെ വലുതായിരിക്കും (നോഡുകളുടെയും പോഡുകളുടെയും എണ്ണത്തിൽ).

എന്നാൽ ഇവിടെ മറ്റൊരു പ്രശ്നം ഉയർന്നുവരുന്നു: കുബർനെറ്റസിലെ ക്ലസ്റ്ററുകൾ അനിശ്ചിതമായി വളരാൻ കഴിയില്ല.

ക്ലസ്റ്റർ വലുപ്പത്തിന് സൈദ്ധാന്തിക പരിധിയുണ്ട്. കുബർനെറ്റസിൽ ഇത് ഏകദേശം ആണ് 5000 നോഡുകൾ, 150 ആയിരം പോഡുകൾ, 300 ആയിരം കണ്ടെയ്നറുകൾ.

എന്നിരുന്നാലും, യഥാർത്ഥ ജീവിതത്തിൽ, പ്രശ്നങ്ങൾ വളരെ നേരത്തെ ആരംഭിക്കാം - ഉദാഹരണത്തിന്, കൂടെ 500 നോട്ടുകൾ.

വലിയ ക്ലസ്റ്ററുകൾ കുബർനെറ്റസ് കൺട്രോൾ ലെയറിൽ ഉയർന്ന ലോഡ് സ്ഥാപിക്കുന്നു എന്നതാണ് വസ്തുത. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ക്ലസ്റ്റർ ഉയർത്തിപ്പിടിക്കാനും കാര്യക്ഷമമായി പ്രവർത്തിക്കാനും ശ്രദ്ധാപൂർവമായ ട്യൂണിംഗ് ആവശ്യമാണ്.

"" എന്ന യഥാർത്ഥ ബ്ലോഗിലെ അനുബന്ധ ലേഖനത്തിൽ ഈ പ്രശ്നം പര്യവേക്ഷണം ചെയ്തിട്ടുണ്ട്.കുബർനെറ്റസ് ക്ലസ്റ്ററുകൾ ആർക്കിടെക്റ്റിംഗ് - ഒരു വർക്കർ നോഡ് വലുപ്പം തിരഞ്ഞെടുക്കൽ".

എന്നാൽ നമുക്ക് വിപരീത സമീപനം പരിഗണിക്കാം: നിരവധി ചെറിയ ക്ലസ്റ്ററുകൾ.

2. നിരവധി ചെറിയ, പ്രത്യേക ക്ലസ്റ്ററുകൾ

ഈ സമീപനത്തിലൂടെ, നിങ്ങൾ വിന്യസിക്കുന്ന ഓരോ ഘടകത്തിനും നിങ്ങൾ ഒരു പ്രത്യേക ക്ലസ്റ്റർ ഉപയോഗിക്കുന്നു:

ധാരാളം ചെറിയ കൂട്ടങ്ങൾ

ഈ ലേഖനത്തിന്റെ ഉദ്ദേശ്യങ്ങൾക്കായി, താഴെ വിന്യസിക്കാവുന്ന ഘടകം ഒരു ആപ്ലിക്കേഷന്റെ ഒരു ഉദാഹരണത്തെ സൂചിപ്പിക്കുന്നു - ഉദാഹരണത്തിന്, ഒരു പ്രത്യേക ആപ്ലിക്കേഷന്റെ dev പതിപ്പ്.

ഈ തന്ത്രം കുബർനെറ്റസിനെ ഒരു സ്പെഷ്യലൈസ്ഡ് ആയി ഉപയോഗിക്കുന്നു റൺടൈം വ്യക്തിഗത അപേക്ഷാ സന്ദർഭങ്ങൾക്കായി.

ഈ സമീപനത്തിന്റെ ഗുണങ്ങളും ദോഷങ്ങളും നോക്കാം.

+ പരിമിതമായ "സ്ഫോടന ആരം"

ഒരു ക്ലസ്റ്റർ പരാജയപ്പെടുമ്പോൾ, പ്രതികൂല ഫലങ്ങൾ ആ ക്ലസ്റ്ററിൽ വിന്യസിച്ചിരിക്കുന്ന ജോലിഭാരങ്ങളിൽ മാത്രമായി പരിമിതപ്പെടുത്തിയിരിക്കുന്നു. മറ്റെല്ലാ ജോലിഭാരങ്ങളും സ്പർശിക്കാതെ തുടരുന്നു.

+ ഇൻസുലേഷൻ

വ്യക്തിഗത ക്ലസ്റ്ററുകളിൽ ഹോസ്റ്റുചെയ്തിരിക്കുന്ന ജോലിഭാരങ്ങൾ പ്രോസസ്സർ, മെമ്മറി, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം, നെറ്റ്‌വർക്ക് അല്ലെങ്കിൽ മറ്റ് സേവനങ്ങൾ എന്നിവ പോലുള്ള ഉറവിടങ്ങൾ പങ്കിടുന്നില്ല.

ബന്ധമില്ലാത്ത ആപ്ലിക്കേഷനുകൾക്കിടയിൽ കർശനമായ ഒറ്റപ്പെടലാണ് ഫലം, അത് അവയുടെ സുരക്ഷയ്ക്ക് ഗുണം ചെയ്യും.

+ ചെറിയ എണ്ണം ഉപയോക്താക്കൾ

ഓരോ ക്ലസ്റ്ററിലും പരിമിതമായ ജോലിഭാരം മാത്രമേ ഉള്ളൂ എന്നതിനാൽ, അതിലേക്കുള്ള ആക്‌സസ് ഉള്ള ഉപയോക്താക്കളുടെ എണ്ണം കുറയുന്നു.

കുറച്ച് ആളുകൾക്ക് ക്ലസ്റ്ററിലേക്ക് ആക്സസ് ഉണ്ട്, എന്തെങ്കിലും "തകരും" എന്ന അപകടസാധ്യത കുറവാണ്.

പോരായ്മകൾ നോക്കാം.

− വിഭവങ്ങളുടെ കാര്യക്ഷമമല്ലാത്ത ഉപയോഗം

നേരത്തെ സൂചിപ്പിച്ചതുപോലെ, ഓരോ കുബർനെറ്റസ് ക്ലസ്റ്ററിനും ഒരു പ്രത്യേക മാനേജ്മെന്റ് ഉറവിടങ്ങൾ ആവശ്യമാണ്: മാസ്റ്റർ നോഡുകൾ, നിയന്ത്രണ പാളി ഘടകങ്ങൾ, നിരീക്ഷണവും ലോഗിംഗ് പരിഹാരങ്ങളും.

ധാരാളം ചെറിയ ക്ലസ്റ്ററുകളുടെ കാര്യത്തിൽ, വിഭവങ്ങളുടെ വലിയൊരു പങ്ക് മാനേജ്മെന്റിന് അനുവദിക്കണം.

- ചെലവേറിയത്

വിഭവങ്ങളുടെ കാര്യക്ഷമമല്ലാത്ത ഉപയോഗം യാന്ത്രികമായി ഉയർന്ന ചിലവുകൾ ഉണ്ടാക്കുന്നു.

ഉദാഹരണത്തിന്, ഒരേ കംപ്യൂട്ടിംഗ് ശക്തിയിൽ മൂന്നിന് പകരം 30 മാസ്റ്റർ നോഡുകൾ പരിപാലിക്കുന്നത് ചെലവിനെ ബാധിക്കും.

- ഭരണത്തിലെ ബുദ്ധിമുട്ടുകൾ

ഒന്നിലധികം കുബർനെറ്റസ് ക്ലസ്റ്ററുകൾ കൈകാര്യം ചെയ്യുന്നത് ഒരെണ്ണം മാത്രം കൈകാര്യം ചെയ്യുന്നതിനേക്കാൾ വളരെ ബുദ്ധിമുട്ടാണ്.

ഉദാഹരണത്തിന്, ഓരോ ക്ലസ്റ്ററിനും നിങ്ങൾ പ്രാമാണീകരണവും അംഗീകാരവും കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്. കുബർനെറ്റസ് പതിപ്പും നിരവധി തവണ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടിവരും.

ഈ ജോലികളെല്ലാം കൂടുതൽ കാര്യക്ഷമമാക്കാൻ നിങ്ങൾ ഓട്ടോമേഷൻ ഉപയോഗിക്കേണ്ടി വരും.

ഇപ്പോൾ നമുക്ക് കുറച്ച് തീവ്രമായ സാഹചര്യങ്ങൾ നോക്കാം.

3. ഓരോ ആപ്ലിക്കേഷനും ഒരു ക്ലസ്റ്റർ

ഈ സമീപനത്തിൽ, ഒരു പ്രത്യേക ആപ്ലിക്കേഷന്റെ എല്ലാ സന്ദർഭങ്ങൾക്കുമായി നിങ്ങൾ ഒരു പ്രത്യേക ക്ലസ്റ്റർ സൃഷ്ടിക്കുന്നു:

ഓരോ ആപ്ലിക്കേഷനും ക്ലസ്റ്റർ

ഈ പാത തത്വത്തിന്റെ പൊതുവൽക്കരണമായി കണക്കാക്കാം "ഓരോ ടീമിനും പ്രത്യേക ക്ലസ്റ്റർ”, കാരണം സാധാരണയായി എഞ്ചിനീയർമാരുടെ ഒരു സംഘം ഒന്നോ അതിലധികമോ ആപ്ലിക്കേഷനുകൾ വികസിപ്പിക്കുന്നു.

ഈ സമീപനത്തിന്റെ ഗുണങ്ങളും ദോഷങ്ങളും നോക്കാം.

+ ആപ്ലിക്കേഷനുമായി ക്ലസ്റ്റർ ക്രമീകരിക്കാൻ കഴിയും

ഒരു ആപ്ലിക്കേഷന് പ്രത്യേക ആവശ്യങ്ങളുണ്ടെങ്കിൽ, അവ മറ്റ് ക്ലസ്റ്ററുകളെ ബാധിക്കാതെ ഒരു ക്ലസ്റ്ററിൽ നടപ്പിലാക്കാം.

അത്തരം ആവശ്യങ്ങളിൽ GPU തൊഴിലാളികൾ, ചില CNI പ്ലഗിനുകൾ, ഒരു സേവന മെഷ് അല്ലെങ്കിൽ മറ്റേതെങ്കിലും സേവനം എന്നിവ ഉൾപ്പെട്ടേക്കാം.

ഓരോ ക്ലസ്റ്ററും അതിൽ പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷന് അനുസൃതമായി ക്രമീകരിക്കാൻ കഴിയും, അങ്ങനെ അതിൽ ആവശ്യമുള്ളത് മാത്രം അടങ്ങിയിരിക്കുന്നു.

− ഒരു ക്ലസ്റ്ററിൽ വ്യത്യസ്ത പരിതസ്ഥിതികൾ

ഈ സമീപനത്തിന്റെ പോരായ്മ, വ്യത്യസ്ത പരിതസ്ഥിതികളിൽ നിന്നുള്ള പ്രയോഗ സംഭവങ്ങൾ ഒരേ ക്ലസ്റ്ററിൽ ഒന്നിച്ച് നിലകൊള്ളുന്നു എന്നതാണ്.

ഉദാഹരണത്തിന്, ആപ്ലിക്കേഷന്റെ പ്രോഡ് പതിപ്പ് dev പതിപ്പിന്റെ അതേ ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്നു. ആപ്ലിക്കേഷന്റെ പ്രൊഡക്ഷൻ പതിപ്പ് പ്രവർത്തിക്കുന്ന അതേ ക്ലസ്റ്ററിലാണ് ഡവലപ്പർമാർ പ്രവർത്തിക്കുന്നത് എന്നും ഇതിനർത്ഥം.

ഡെവലപ്പർമാരുടെ പ്രവർത്തനങ്ങൾ അല്ലെങ്കിൽ dev പതിപ്പിലെ തകരാറുകൾ കാരണം, ക്ലസ്റ്ററിൽ ഒരു പരാജയം സംഭവിക്കുകയാണെങ്കിൽ, പ്രോഡ് പതിപ്പും ബാധിക്കാനിടയുണ്ട് - ഈ സമീപനത്തിന്റെ ഒരു വലിയ പോരായ്മ.

അവസാനമായി, ഞങ്ങളുടെ ലിസ്റ്റിലെ അവസാന രംഗം.

4. ഓരോ പരിസ്ഥിതിക്കും ഒരു ക്ലസ്റ്റർ

ഓരോ പരിതസ്ഥിതിക്കും ഒരു പ്രത്യേക ക്ലസ്റ്റർ അനുവദിക്കുന്നത് ഈ സാഹചര്യത്തിൽ ഉൾപ്പെടുന്നു:

ഓരോ പരിസ്ഥിതിക്കും ഒരു ക്ലസ്റ്റർ

ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ക്ലസ്റ്ററുകൾ ഉണ്ടായിരിക്കാം ദേവ്, പരിശോധന и ഉത്പന്നം, ഒരു പ്രത്യേക പരിതസ്ഥിതിയിൽ സമർപ്പിച്ചിരിക്കുന്ന ആപ്ലിക്കേഷന്റെ എല്ലാ സന്ദർഭങ്ങളും നിങ്ങൾ പ്രവർത്തിപ്പിക്കും.

ഈ സമീപനത്തിന്റെ ഗുണങ്ങളും ദോഷങ്ങളും ഇവിടെയുണ്ട്.

+ പ്രോഡ് പരിസ്ഥിതിയുടെ ഒറ്റപ്പെടൽ

ഈ സമീപനത്തിനുള്ളിൽ, എല്ലാ പരിതസ്ഥിതികളും പരസ്പരം ഒറ്റപ്പെട്ടതാണ്. എന്നിരുന്നാലും, പ്രായോഗികമായി ഇത് ഒരു പ്രോഡ് പരിതസ്ഥിതിയിൽ പ്രത്യേകിച്ചും പ്രധാനമാണ്.

ആപ്ലിക്കേഷന്റെ പ്രൊഡക്ഷൻ പതിപ്പുകൾ ഇപ്പോൾ മറ്റ് ക്ലസ്റ്ററുകളിലും പരിതസ്ഥിതികളിലും സംഭവിക്കുന്നതിൽ നിന്ന് സ്വതന്ത്രമാണ്.

ഈ രീതിയിൽ, dev ക്ലസ്റ്ററിൽ പെട്ടെന്ന് ഒരു പ്രശ്നം ഉണ്ടായാൽ, ആപ്ലിക്കേഷനുകളുടെ പ്രോഡ് പതിപ്പുകൾ ഒന്നും സംഭവിക്കാത്തത് പോലെ പ്രവർത്തിക്കുന്നത് തുടരും.

+ ക്ലസ്റ്റർ പരിസ്ഥിതിയുമായി ക്രമീകരിക്കാൻ കഴിയും

ഓരോ ക്ലസ്റ്ററും അതിന്റെ പരിതസ്ഥിതിയിൽ ക്രമീകരിക്കാൻ കഴിയും. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് കഴിയും:

• dev ക്ലസ്റ്ററിൽ വികസനത്തിനും ഡീബഗ്ഗിംഗിനുമുള്ള ഉപകരണങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുക;
• ക്ലസ്റ്ററിൽ ടെസ്റ്റ് ഫ്രെയിംവർക്കുകളും ടൂളുകളും ഇൻസ്റ്റാൾ ചെയ്യുക പരിശോധന;
• ക്ലസ്റ്ററിൽ കൂടുതൽ ശക്തമായ ഹാർഡ്‌വെയറും നെറ്റ്‌വർക്ക് ചാനലുകളും ഉപയോഗിക്കുക ഉത്പന്നം.

ആപ്ലിക്കേഷൻ വികസനത്തിന്റെയും പ്രവർത്തനത്തിന്റെയും കാര്യക്ഷമത വർദ്ധിപ്പിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

+ പ്രൊഡക്ഷൻ ക്ലസ്റ്ററിലേക്കുള്ള പ്രവേശനം നിയന്ത്രിക്കുന്നു

ഒരു പ്രോഡ് ക്ലസ്റ്ററുമായി നേരിട്ട് പ്രവർത്തിക്കേണ്ടതിന്റെ ആവശ്യകത വളരെ അപൂർവമായി മാത്രമേ ഉണ്ടാകൂ, അതിനാൽ അതിലേക്ക് ആക്സസ് ഉള്ള ആളുകളുടെ സർക്കിളിനെ നിങ്ങൾക്ക് ഗണ്യമായി പരിമിതപ്പെടുത്താൻ കഴിയും.

നിങ്ങൾക്ക് കൂടുതൽ മുന്നോട്ട് പോയി ഈ ക്ലസ്റ്ററിലേക്കുള്ള ആക്സസ് പൂർണ്ണമായും നിരസിക്കാം, കൂടാതെ ഒരു ഓട്ടോമേറ്റഡ് CI/CD ടൂൾ ഉപയോഗിച്ച് എല്ലാ വിന്യാസങ്ങളും നടത്താം. അത്തരം ഒരു സമീപനം മനുഷ്യ പിശകുകളുടെ അപകടസാധ്യത കുറയ്ക്കും, അത് ഏറ്റവും പ്രസക്തമായിടത്ത്.

ഇപ്പോൾ ദോഷങ്ങളെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ.

− ആപ്ലിക്കേഷനുകൾക്കിടയിൽ ഒറ്റപ്പെടലില്ല

ഹാർഡ്‌വെയറിന്റെ അഭാവവും ആപ്ലിക്കേഷനുകൾക്കിടയിൽ റിസോഴ്‌സ് ഒറ്റപ്പെടലും ആണ് സമീപനത്തിന്റെ പ്രധാന പോരായ്മ.

ബന്ധമില്ലാത്ത ആപ്ലിക്കേഷനുകൾ ക്ലസ്റ്റർ ഉറവിടങ്ങൾ പങ്കിടുന്നു: സിസ്റ്റം കോർ, പ്രോസസർ, മെമ്മറി, മറ്റ് ചില സേവനങ്ങൾ.

സൂചിപ്പിച്ചതുപോലെ, ഇത് അപകടകരമായേക്കാം.

− ആപ്ലിക്കേഷൻ ഡിപൻഡൻസികൾ ലോക്കലൈസ് ചെയ്യാനുള്ള കഴിവില്ലായ്മ

ഒരു ആപ്ലിക്കേഷന് പ്രത്യേക ആവശ്യകതകളുണ്ടെങ്കിൽ, എല്ലാ ക്ലസ്റ്ററുകളിലും അവ തൃപ്തിപ്പെട്ടിരിക്കണം.

ഉദാഹരണത്തിന്, ഒരു ആപ്ലിക്കേഷന് ഒരു ജിപിയു ആവശ്യമാണെങ്കിൽ, ഓരോ ക്ലസ്റ്ററിലും കുറഞ്ഞത് ഒരു ജിപിയു ഉള്ള ഒരു തൊഴിലാളിയെങ്കിലും ഉണ്ടായിരിക്കണം (അത് ആ ആപ്ലിക്കേഷൻ മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂവെങ്കിലും).

തൽഫലമായി, ഉയർന്ന ചെലവുകളും വിഭവങ്ങളുടെ കാര്യക്ഷമമല്ലാത്ത ഉപയോഗവും ഞങ്ങൾ അപകടപ്പെടുത്തുന്നു.

തീരുമാനം

നിങ്ങൾക്ക് ഒരു പ്രത്യേക സെറ്റ് ആപ്ലിക്കേഷനുകൾ ഉണ്ടെങ്കിൽ, അവ നിരവധി വലിയ ക്ലസ്റ്ററുകളിലോ ചെറിയവയിലോ സ്ഥാപിക്കാവുന്നതാണ്.

ഒരു ഗ്ലോബൽ ക്ലസ്റ്റർ മുതൽ ചെറുതും വളരെ സ്പെഷ്യലൈസ് ചെയ്തതുമായ നിരവധി സമീപനങ്ങൾ വരെയുള്ള വിവിധ സമീപനങ്ങളുടെ ഗുണദോഷങ്ങൾ ലേഖനം ചർച്ചചെയ്യുന്നു:

• ഒരു വലിയ പൊതു ക്ലസ്റ്റർ;
• വളരെ പ്രത്യേകമായ നിരവധി ചെറിയ ക്ലസ്റ്ററുകൾ;
• ഓരോ ആപ്ലിക്കേഷനും ഒരു ക്ലസ്റ്റർ;
• ഒരു പരിസ്ഥിതിക്ക് ഒരു ക്ലസ്റ്റർ.

അപ്പോൾ നിങ്ങൾ ഏത് സമീപനമാണ് സ്വീകരിക്കേണ്ടത്?

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

എന്നിരുന്നാലും, തിരഞ്ഞെടുക്കൽ മുകളിലുള്ള ഉദാഹരണങ്ങളിൽ മാത്രം പരിമിതപ്പെടുത്തിയിട്ടില്ല - നിങ്ങൾക്ക് അവയുടെ ഏത് കോമ്പിനേഷനും ഉപയോഗിക്കാം!

ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ഓരോ ടീമിനും രണ്ട് ക്ലസ്റ്ററുകൾ സംഘടിപ്പിക്കാൻ കഴിയും: ഒരു വികസന ക്ലസ്റ്റർ (അതിൽ പരിതസ്ഥിതികൾ ഉണ്ടാകും ദേവ് и പരിശോധന) എന്നതിനായുള്ള ക്ലസ്റ്ററും ഉത്പാദനം (ഉൽപാദന അന്തരീക്ഷം എവിടെയാണ് സ്ഥിതി ചെയ്യുന്നത്).

ഈ ലേഖനത്തിലെ വിവരങ്ങളെ അടിസ്ഥാനമാക്കി, ഒരു പ്രത്യേക സാഹചര്യത്തിനനുസരിച്ച് നിങ്ങൾക്ക് ഗുണങ്ങളും ദോഷങ്ങളും ഒപ്റ്റിമൈസ് ചെയ്യാൻ കഴിയും. നല്ലതുവരട്ടെ!

പി.എസ്

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

• «കുബെർനെറ്റസ് ട്രബിൾഷൂട്ടിംഗിനുള്ള ഒരു വിഷ്വൽ ഗൈഡ്";
• «ഇന്ന് കുബർനെറ്റസിലെ ലോഗുകൾ (മാത്രമല്ല): പ്രതീക്ഷകളും യാഥാർത്ഥ്യവും";
• «സർവീസ് മെഷ്: ഏറ്റവും ചൂടേറിയ സാങ്കേതികവിദ്യയെക്കുറിച്ച് ഓരോ സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറും അറിഞ്ഞിരിക്കേണ്ട കാര്യങ്ങൾ";
• «കുബർനെറ്റസിലെ എബിസി ഓഫ് സെക്യൂരിറ്റി: ആധികാരികത, അംഗീകാരം, ഓഡിറ്റിംഗ്".

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