ഇന്റർനെറ്റിൽ ഒരു കൂട്ടം ലേഖനങ്ങൾ о സേവന മെഷ് (സർവീസ് മെഷ്), ഇതാ മറ്റൊന്ന്. ഹൂറേ! പക്ഷെ എന്തുകൊണ്ട്? പിന്നെ, ഡോക്കർ, കുബർനെറ്റസ് തുടങ്ങിയ കണ്ടെയ്‌നർ പ്ലാറ്റ്‌ഫോമുകൾ വരുന്നതിന് മുമ്പ്, 10 വർഷം മുമ്പ് സർവീസ് മെഷുകൾ പ്രത്യക്ഷപ്പെട്ടാൽ നന്നായിരുന്നു എന്ന എന്റെ അഭിപ്രായം പ്രകടിപ്പിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. എന്റെ കാഴ്ചപ്പാട് മറ്റുള്ളവരേക്കാൾ മികച്ചതോ മോശമായതോ ആണെന്ന് ഞാൻ പറയുന്നില്ല, എന്നാൽ സേവന മെഷുകൾ തികച്ചും സങ്കീർണ്ണമായ മൃഗങ്ങളായതിനാൽ, ഒന്നിലധികം കാഴ്ചപ്പാടുകൾ അവയെ നന്നായി മനസ്സിലാക്കാൻ സഹായിക്കും.

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

ഡോട്ട്ക്ലൗഡിന്റെ ചരിത്രം

ഡോട്ട്‌ക്ലൗഡിന്റെ ചരിത്രത്തെക്കുറിച്ചും ഈ പ്ലാറ്റ്‌ഫോമിനായുള്ള ആർക്കിടെക്ചർ ചോയ്‌സുകളെക്കുറിച്ചും ഞാൻ എഴുതിയിട്ടുണ്ട്, പക്ഷേ നെറ്റ്‌വർക്ക് ലെയറിനെക്കുറിച്ച് ഞാൻ കൂടുതൽ സംസാരിച്ചിട്ടില്ല. നിങ്ങൾക്ക് വായനയിൽ മുഴുകാൻ താൽപ്പര്യമില്ലെങ്കിൽ അവസാന ലേഖനം ഡോട്ട്‌ക്ലൗഡിനെക്കുറിച്ച് ചുരുക്കത്തിൽ ചുരുക്കം: ഇത് ഒരു PaaS പ്ലാറ്റ്‌ഫോം-എ-സേവനമാണ്, അത് ഉപഭോക്താക്കളെ വിപുലമായ ശ്രേണിയിലുള്ള ആപ്ലിക്കേഷനുകൾ (Java, PHP, Python...) പ്രവർത്തിപ്പിക്കാൻ അനുവദിക്കുന്നു. സേവനങ്ങളും (MongoDB, MySQL, Redis...) Heroku പോലുള്ള ഒരു വർക്ക്ഫ്ലോയും: നിങ്ങൾ പ്ലാറ്റ്‌ഫോമിലേക്ക് നിങ്ങളുടെ കോഡ് അപ്‌ലോഡ് ചെയ്യുന്നു, അത് കണ്ടെയ്‌നർ ഇമേജുകൾ നിർമ്മിക്കുകയും അവയെ വിന്യസിക്കുകയും ചെയ്യുന്നു.

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

ഹോസ്റ്റ് ചെയ്ത ആപ്ലിക്കേഷനുകൾക്കുള്ള ട്രാഫിക് റൂട്ടിംഗ്

ഡോട്ട്ക്ലൗഡിലെ ആപ്ലിക്കേഷനുകൾക്ക് എച്ച്ടിടിപി, ടിസിപി എൻഡ് പോയിന്റുകൾ വെളിപ്പെടുത്താനാകും.

HTTP അവസാന പോയിന്റുകൾ ലോഡ് ബാലൻസർ ക്ലസ്റ്റർ കോൺഫിഗറേഷനിലേക്ക് ചലനാത്മകമായി ചേർത്തു ഹിപ്പാച്ചെ. ഇത് ഇന്ന് വിഭവങ്ങൾ ചെയ്യുന്നതിന് സമാനമാണ് തുടരുക കുബെർനെറ്റസിൽ ഒരു ലോഡ് ബാലൻസറും ട്രാഫിക്.

ക്ലയന്റുകൾ ഉചിതമായ ഡൊമെയ്‌നുകൾ വഴി HTTP എൻഡ്‌പോയിന്റുകളിലേക്ക് കണക്‌റ്റ് ചെയ്യുന്നു, ഡൊമെയ്‌ൻ നാമം ഡോട്ട്‌ക്ലൗഡ് ലോഡ് ബാലൻസറുകളിലേക്ക് പോയിന്റ് ചെയ്യുന്നുവെങ്കിൽ. പ്രത്യേകിച്ചൊന്നുമില്ല.

TCP അവസാന പോയിന്റുകൾ ഒരു പോർട്ട് നമ്പറുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, അത് പരിസ്ഥിതി വേരിയബിളുകൾ വഴി ആ സ്റ്റാക്കിലെ എല്ലാ കണ്ടെയ്‌നറുകളിലേക്കും കൈമാറുന്നു.

ക്ലയന്റുകൾക്ക് ഉചിതമായ ഹോസ്റ്റ്നാമവും (ഗേറ്റ്‌വേ-X.dotcloud.com പോലെയുള്ളത്) പോർട്ട് നമ്പറും ഉപയോഗിച്ച് TCP എൻഡ്‌പോയിന്റുകളിലേക്ക് കണക്റ്റുചെയ്യാനാകും.

ഈ ഹോസ്റ്റ്നാമം "nats" സെർവർ ക്ലസ്റ്ററിലേക്ക് പരിഹരിക്കുന്നു (ഇതുമായി ബന്ധപ്പെട്ടതല്ല നാറ്റ്സ്), ഇത് ഇൻകമിംഗ് TCP കണക്ഷനുകളെ ശരിയായ കണ്ടെയ്‌നറിലേക്ക് നയിക്കും (അല്ലെങ്കിൽ, ലോഡ്-ബാലൻസ്ഡ് സേവനങ്ങളുടെ കാര്യത്തിൽ, ശരിയായ കണ്ടെയ്‌നറുകളിലേക്ക്).

നിങ്ങൾക്ക് Kubernetes-നെ പരിചയമുണ്ടെങ്കിൽ, ഇത് ഒരുപക്ഷേ നിങ്ങളെ സേവനങ്ങളെക്കുറിച്ച് ഓർമ്മപ്പെടുത്തും നോഡ്പോർട്ട്.

dotCloud പ്ലാറ്റ്‌ഫോമിൽ തത്തുല്യമായ സേവനങ്ങളൊന്നും ഉണ്ടായിരുന്നില്ല ClusterIP: ലാളിത്യത്തിനായി, പ്ലാറ്റ്‌ഫോമിന് അകത്തും പുറത്തും നിന്ന് സേവനങ്ങൾ ഒരേ രീതിയിൽ ആക്‌സസ് ചെയ്‌തു.

എല്ലാം വളരെ ലളിതമായി ക്രമീകരിച്ചിരിക്കുന്നു: HTTP, TCP റൂട്ടിംഗ് നെറ്റ്‌വർക്കുകളുടെ പ്രാരംഭ നിർവ്വഹണം പൈത്തണിന്റെ ഏതാനും നൂറ് വരികൾ മാത്രമായിരിക്കാം. പ്ലാറ്റ്‌ഫോം വളരുകയും അധിക ആവശ്യകതകൾ പ്രത്യക്ഷപ്പെടുകയും ചെയ്യുന്നതിനനുസരിച്ച് പരിഷ്‌ക്കരിച്ച ലളിതമായ (നിഷ്‌കളങ്കമെന്ന് ഞാൻ പറയും) അൽഗോരിതങ്ങൾ.

നിലവിലുള്ള കോഡിന്റെ വിപുലമായ റീഫാക്‌ടറിംഗ് ആവശ്യമില്ല. പ്രത്യേകിച്ച്, 12 ഫാക്ടർ ആപ്പുകൾ പരിസ്ഥിതി വേരിയബിളുകൾ വഴി ലഭിച്ച വിലാസം നേരിട്ട് ഉപയോഗിക്കാം.

ഒരു ആധുനിക സേവന മെഷിൽ നിന്ന് ഇത് എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു?

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

പ്രവർത്തനപരമായ വീക്ഷണകോണിൽ നിന്ന് മാത്രമല്ല (പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ സഹായിക്കുന്നതിന്) മാത്രമല്ല, പുതിയ ഫീച്ചറുകൾ പുറത്തിറക്കുമ്പോഴും ദൃശ്യപരത പ്രധാനമാണ്. ഇത് സുരക്ഷിതമായ കാര്യമാണ് നീല-പച്ച വിന്യാസം и കാനറി വിന്യാസം.

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

അത്തരം പ്രശ്നങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിൽ ആധുനിക സേവന മെഷുകൾ മികച്ചതാണ്. ഒന്നാമതായി, കണക്ഷനുകൾ റൂട്ട് ചെയ്തിട്ടുണ്ടോ എന്ന് അവർ പരിശോധിക്കുന്നു ഉറവിടത്തിൽ. ലോജിക്കൽ ഒഴുക്ക് ഒന്നുതന്നെയാണ്: клиент → меш → сервис, എന്നാൽ ഇപ്പോൾ മെഷ് പ്രാദേശികമായി പ്രവർത്തിക്കുന്നു, റിമോട്ട് നോഡുകളിലല്ല, അതിനാൽ കണക്ഷൻ клиент → меш പ്രാദേശികവും വളരെ വേഗതയുള്ളതുമാണ് (മില്ലിസെക്കന്റിന് പകരം മൈക്രോസെക്കൻഡ്).

ആധുനിക സേവന മെഷുകളും മികച്ച ലോഡ് ബാലൻസിംഗ് അൽഗോരിതങ്ങൾ നടപ്പിലാക്കുന്നു. ബാക്കെൻഡുകളുടെ ആരോഗ്യം നിരീക്ഷിക്കുന്നതിലൂടെ, അവർക്ക് വേഗത്തിലുള്ള ബാക്കെൻഡുകളിലേക്ക് കൂടുതൽ ട്രാഫിക് അയയ്‌ക്കാൻ കഴിയും, അതിന്റെ ഫലമായി മൊത്തത്തിലുള്ള പ്രകടനം മെച്ചപ്പെടും.

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

പ്ലാറ്റ്ഫോം സേവനങ്ങൾക്കായി ട്രാഫിക് റൂട്ടിംഗ്

ശരി, ആപ്ലിക്കേഷനുകൾക്കിടയിലുള്ള ട്രാഫിക്കിനെക്കുറിച്ച് ഞങ്ങൾ ചർച്ച ചെയ്തു, എന്നാൽ ഡോട്ട്ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമിന്റെ കാര്യമോ?

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

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

കുറച്ച് കീ നോഡുകളിൽ നേരിട്ട് കണ്ടെയ്‌നറുകൾ പ്രവർത്തിപ്പിച്ചാണ് ഈ താഴ്ന്ന നിലയിലുള്ള, മിഷൻ-ക്രിട്ടിക്കൽ സേവനങ്ങൾ വിന്യസിച്ചത്. ഈ സാഹചര്യത്തിൽ, സ്റ്റാൻഡേർഡ് പ്ലാറ്റ്ഫോം സേവനങ്ങൾ ഉപയോഗിച്ചിട്ടില്ല: ലിങ്കർ, ഷെഡ്യൂളർ, റണ്ണർ. നിങ്ങൾക്ക് ആധുനിക കണ്ടെയ്‌നർ പ്ലാറ്റ്‌ഫോമുകളുമായി താരതമ്യം ചെയ്യണമെങ്കിൽ, അത് ഒരു നിയന്ത്രണ വിമാനം പ്രവർത്തിപ്പിക്കുന്നതുപോലെയാണ് docker run കുബർനെറ്റസിന് ചുമതല ഏൽപ്പിക്കുന്നതിന് പകരം നേരിട്ട് നോഡുകളിൽ. ആശയത്തിൽ ഇത് വളരെ സാമ്യമുള്ളതാണ് സ്റ്റാറ്റിക് മൊഡ്യൂളുകൾ (പോഡുകൾ), അത് ഉപയോഗിക്കുന്നത് kubeadm അഥവാ bootkube ഒരു ഒറ്റപ്പെട്ട ക്ലസ്റ്റർ ബൂട്ട് ചെയ്യുമ്പോൾ.

ഈ സേവനങ്ങൾ ലളിതവും അപരിഷ്‌കൃതവുമായ രീതിയിൽ തുറന്നുകാട്ടപ്പെട്ടു: ഒരു YAML ഫയൽ അവരുടെ പേരും വിലാസങ്ങളും പട്ടികപ്പെടുത്തി; വിന്യാസത്തിനായി ഓരോ ക്ലയന്റും ഈ YAML ഫയലിന്റെ ഒരു പകർപ്പ് എടുക്കേണ്ടതുണ്ട്.

ഒരു വശത്ത്, ഇത് വളരെ വിശ്വസനീയമാണ്, കാരണം ഇതിന് സൂക്കീപ്പർ പോലുള്ള ഒരു ബാഹ്യ കീ/മൂല്യ സ്റ്റോറിന്റെ പിന്തുണ ആവശ്യമില്ല (ഓർക്കുക, etcd അല്ലെങ്കിൽ കോൺസൽ അക്കാലത്ത് നിലവിലില്ല). മറുവശത്ത്, ഇത് സർവീസുകൾ നീക്കുന്നത് ബുദ്ധിമുട്ടാക്കി. ഓരോ തവണയും ഒരു നീക്കം നടത്തുമ്പോൾ, എല്ലാ ക്ലയന്റുകൾക്കും ഒരു അപ്‌ഡേറ്റ് ചെയ്ത YAML ഫയൽ ലഭിക്കും (കൂടാതെ റീബൂട്ട് ചെയ്യാൻ സാധ്യതയുണ്ട്). വളരെ സുഖകരമല്ല!

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

(TLS കണക്ഷനുകളിലെ ട്രാഫിക്ക് എൻക്യാപ്‌സുലേറ്റ് ചെയ്യാനും സ്വീകരിക്കുന്ന ഭാഗത്ത് മറ്റൊരു പ്രോക്‌സി സെർവർ സ്ഥാപിക്കാനും കൂടാതെ സ്വീകരിക്കുന്ന സേവനത്തിന്റെ പങ്കാളിത്തമില്ലാതെ TLS സർട്ടിഫിക്കറ്റുകൾ പരിശോധിക്കാനും പദ്ധതിയിട്ടിരുന്നു, ഇത് കണക്ഷനുകൾ സ്വീകരിക്കുന്നതിന് മാത്രം കോൺഫിഗർ ചെയ്‌തിരിക്കുന്നു. localhost. ഇതിനെക്കുറിച്ച് കൂടുതൽ പിന്നീട്).

ഇത് വളരെ സാമ്യമുള്ളതാണ് സ്മാർട്ട് സ്റ്റാക്ക് Airbnb-ൽ നിന്ന്, എന്നാൽ പ്രധാന വ്യത്യാസം SmartStack നടപ്പിലാക്കുകയും ഉൽപ്പാദനത്തിലേക്ക് വിന്യസിക്കുകയും ചെയ്യുന്നു എന്നതാണ്, അതേസമയം dotCloud ഡോക്കറായി മാറിയപ്പോൾ dotCloud-ന്റെ ആന്തരിക റൂട്ടിംഗ് സിസ്റ്റം ഉപേക്ഷിച്ചു.

Istio, Linkerd, Consul Connect പോലുള്ള സിസ്റ്റങ്ങളുടെ മുൻഗാമികളിൽ ഒന്നായി SmartStack ഞാൻ വ്യക്തിപരമായി കരുതുന്നു, കാരണം അവയെല്ലാം ഒരേ പാറ്റേൺ പിന്തുടരുന്നു:

• ഓരോ നോഡിലും ഒരു പ്രോക്സി പ്രവർത്തിപ്പിക്കുക.
• ക്ലയന്റുകൾ പ്രോക്സിയിലേക്ക് കണക്ട് ചെയ്യുന്നു.
• ബാക്കെൻഡുകൾ മാറുമ്പോൾ കൺട്രോൾ പ്ലെയിൻ പ്രോക്സി കോൺഫിഗറേഷൻ അപ്ഡേറ്റ് ചെയ്യുന്നു.
• ... ലാഭം!

ഒരു സേവന മെഷിന്റെ ആധുനിക നിർവ്വഹണം

ഇന്ന് സമാനമായ ഒരു ഗ്രിഡ് നടപ്പിലാക്കണമെങ്കിൽ, സമാനമായ തത്ത്വങ്ങൾ നമുക്ക് ഉപയോഗിക്കാം. ഉദാഹരണത്തിന്, സ്‌പെയ്‌സിലെ വിലാസങ്ങളിലേക്ക് സേവന നാമങ്ങൾ മാപ്പ് ചെയ്‌ത് ഒരു ആന്തരിക DNS സോൺ കോൺഫിഗർ ചെയ്യുക 127.0.0.0/8. തുടർന്ന് ക്ലസ്റ്ററിലെ ഓരോ നോഡിലും HAProxy പ്രവർത്തിപ്പിക്കുക, ഓരോ സേവന വിലാസത്തിലും കണക്ഷനുകൾ സ്വീകരിക്കുക (ആ സബ്‌നെറ്റിൽ 127.0.0.0/8) കൂടാതെ അനുയോജ്യമായ ബാക്കെൻഡുകളിലേക്ക് ലോഡ് റീഡയറക്‌ട് ചെയ്യുന്നു/ബാലൻസ് ചെയ്യുന്നു. HAProxy കോൺഫിഗറേഷൻ നിയന്ത്രിക്കാനാകും confd, etcd അല്ലെങ്കിൽ കോൺസലിൽ ബാക്കെൻഡ് വിവരങ്ങൾ സംഭരിക്കാനും ആവശ്യമുള്ളപ്പോൾ അപ്‌ഡേറ്റ് ചെയ്ത കോൺഫിഗറേഷൻ HAProxy-ലേക്ക് സ്വയമേവ പുഷ് ചെയ്യാനും നിങ്ങളെ അനുവദിക്കുന്നു.

ഇസ്തിയോ പ്രവർത്തിക്കുന്നത് ഇങ്ങനെയാണ്! എന്നാൽ ചില വ്യത്യാസങ്ങളോടെ:

• ഉപയോഗിക്കുന്നു ദൂതൻ പ്രോക്സി പകരം HAProxy.
• etcd അല്ലെങ്കിൽ കോൺസൽ എന്നതിന് പകരം Kubernetes API വഴി ബാക്കെൻഡ് കോൺഫിഗറേഷൻ സംഭരിക്കുന്നു.
• സേവനങ്ങൾക്ക് 127.0.0.0/8 എന്നതിനുപകരം ആന്തരിക സബ്‌നെറ്റിൽ (കുബർനെറ്റസ് ക്ലസ്റ്റർഐപി വിലാസങ്ങൾ) വിലാസങ്ങൾ അനുവദിച്ചിരിക്കുന്നു.
• ക്ലയന്റിനും സെർവറുകൾക്കുമിടയിൽ മ്യൂച്വൽ TLS പ്രാമാണീകരണം ചേർക്കുന്നതിന് ഒരു അധിക ഘടകം (സിറ്റാഡൽ) ഉണ്ട്.
• സർക്യൂട്ട് ബ്രേക്കിംഗ്, ഡിസ്ട്രിബ്യൂട്ടഡ് ട്രെയ്‌സിംഗ്, കാനറി വിന്യാസം തുടങ്ങിയ പുതിയ സവിശേഷതകളെ പിന്തുണയ്ക്കുന്നു.

ചില വ്യത്യാസങ്ങൾ നമുക്ക് പെട്ടെന്ന് നോക്കാം.

ദൂതൻ പ്രോക്സി

എൻവോയ് പ്രോക്സി എഴുതിയത് ലിഫ്റ്റ് ആണ് [ടാക്സി മാർക്കറ്റിലെ യൂബറിന്റെ എതിരാളി - ഏകദേശം. പാത]. ഇത് മറ്റ് പ്രോക്സികളോട് (ഉദാ. HAProxy, Nginx, Traefik...) പല തരത്തിൽ സമാനമാണ്, എന്നാൽ മറ്റ് പ്രോക്സികൾക്ക് ഇല്ലാത്ത ഫീച്ചറുകൾ ആവശ്യമായതിനാൽ ലിഫ്റ്റ് അവരുടേത് എഴുതി, നിലവിലുള്ളത് വിപുലീകരിക്കുന്നതിന് പകരം പുതിയത് നിർമ്മിക്കുന്നത് മികച്ചതായി തോന്നി.

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

എന്നാൽ എൻവോയ് ആയി പ്രവർത്തിക്കാനും കഴിവുണ്ട് ഡാറ്റാ വിമാനം (ഡാറ്റ പ്ലെയിൻ) സേവന മെഷിന്. ഈ സേവന മെഷിനായി എൻവോയ് ഇപ്പോൾ കോൺഫിഗർ ചെയ്‌തിരിക്കുന്നു എന്നാണ് ഇതിനർത്ഥം നിയന്ത്രണ തലം (നിയന്ത്രണ തലം).

നിയന്ത്രണ വിമാനം

കൺട്രോൾ പ്ലെയിനിനായി, ഇസ്റ്റിയോ കുബർനെറ്റസ് എപിഐയെ ആശ്രയിക്കുന്നു. ഇത് confd ഉപയോഗിക്കുന്നതിൽ നിന്ന് വളരെ വ്യത്യസ്തമല്ല, ഡാറ്റ സ്റ്റോറിലെ കീകളുടെ സെറ്റ് കാണുന്നതിന് etcd അല്ലെങ്കിൽ കോൺസലിനെ ആശ്രയിക്കുന്നു. ഒരു കൂട്ടം കുബർനെറ്റസ് ഉറവിടങ്ങൾ കാണുന്നതിന് ഇസ്റ്റിയോ കുബർനെറ്റസ് API ഉപയോഗിക്കുന്നു.

ഇതിനും അതിനുശേഷവും: വ്യക്തിപരമായി ഇത് ഉപയോഗപ്രദമാണെന്ന് ഞാൻ കണ്ടെത്തി Kubernetes API വിവരണംഅത് വായിക്കുന്നു:

API ഉറവിടങ്ങൾക്കായി സംഭരണം, പതിപ്പിംഗ്, മൂല്യനിർണ്ണയം, അപ്‌ഡേറ്റ് ചെയ്യൽ, സെമാന്റിക്‌സ് എന്നിവ വാഗ്ദാനം ചെയ്യുന്ന ഒരു "മൂക സെർവർ" ആണ് Kubernetes API സെർവർ.

കുബർനെറ്റസുമായി ചേർന്ന് പ്രവർത്തിക്കാൻ ഇസ്തിയോ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു; നിങ്ങൾക്ക് ഇത് കുബർനെറ്റസിന് പുറത്ത് ഉപയോഗിക്കാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ, നിങ്ങൾ Kubernetes API സെർവറിന്റെ (കൂടാതെ etcd സഹായ സേവനത്തിന്റെ) ഒരു ഉദാഹരണം പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്.

സേവന വിലാസങ്ങൾ

കുബെർനെറ്റ്സ് അനുവദിക്കുന്ന ക്ലസ്റ്റർഐപി വിലാസങ്ങളെയാണ് ഇസ്തിയോ ആശ്രയിക്കുന്നത്, അതിനാൽ ഇസ്റ്റിയോ സേവനങ്ങൾക്ക് ഒരു ആന്തരിക വിലാസം ലഭിക്കും (പരിധിയിലല്ല 127.0.0.0/8).

Istio ഇല്ലാതെ Kubernetes ക്ലസ്റ്ററിലെ ഒരു നിർദ്ദിഷ്ട സേവനത്തിനായുള്ള ClusterIP വിലാസത്തിലേക്കുള്ള ട്രാഫിക് kube-proxy തടസ്സപ്പെടുത്തുകയും ആ പ്രോക്സിയുടെ ബാക്കെൻഡിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു. നിങ്ങൾക്ക് സാങ്കേതിക വിശദാംശങ്ങളിൽ താൽപ്പര്യമുണ്ടെങ്കിൽ, ClusterIP വിലാസത്തിലേക്ക് പോകുന്ന കണക്ഷനുകളുടെ ലക്ഷ്യസ്ഥാന ഐപി വിലാസങ്ങൾ മാറ്റിയെഴുതാൻ kube-proxy iptables നിയമങ്ങൾ (അല്ലെങ്കിൽ IPVS ലോഡ് ബാലൻസറുകൾ, അത് എങ്ങനെ കോൺഫിഗർ ചെയ്‌തിരിക്കുന്നു എന്നതിനെ ആശ്രയിച്ച്) സജ്ജമാക്കുന്നു.

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

Kubernetes DNS-മായി സംയോജിപ്പിക്കുമ്പോൾ, ഞങ്ങളുടെ കോഡിന് സേവന നാമത്തിലൂടെയും എല്ലാം "പ്രവർത്തിക്കുന്നു" എന്നതിലൂടെയും ബന്ധിപ്പിക്കാൻ കഴിയുമെന്നാണ് ഇതിനർത്ഥം. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഞങ്ങളുടെ കോഡ് ഇതുപോലുള്ള ചോദ്യങ്ങൾ നൽകുന്നു http://api/v1/users/4242തുടർന്ന് api എന്നതിനായുള്ള അഭ്യർത്ഥന പരിഹരിക്കുക 10.97.105.48, iptables നിയമങ്ങൾ 10.97.105.48 മുതലുള്ള കണക്ഷനുകളെ തടസ്സപ്പെടുത്തുകയും പ്രാദേശിക എൻവോയ് പ്രോക്സിക്ക് കൈമാറുകയും ചെയ്യും, കൂടാതെ പ്രാദേശിക പ്രോക്സി യഥാർത്ഥ ബാക്കെൻഡ് API ലേക്ക് അഭ്യർത്ഥന കൈമാറും. ഛെ!

അധിക അലങ്കാരങ്ങൾ

എംടിഎൽഎസ് (മ്യൂച്വൽ ടിഎൽഎസ്) വഴി എൻഡ്-ടു-എൻഡ് എൻക്രിപ്ഷനും പ്രാമാണീകരണവും ഇസ്റ്റിയോ നൽകുന്നു. എന്ന ഒരു ഘടകം കോട്ട.

ഒരു ഘടകവുമുണ്ട് മിക്സര്, ഏത് ദൂതന് അഭ്യർത്ഥിക്കാം ഓരോന്നും തലക്കെട്ടുകൾ, ബാക്കെൻഡ് ലോഡ് മുതലായവ പോലുള്ള വിവിധ ഘടകങ്ങളെ ആശ്രയിച്ച് ആ അഭ്യർത്ഥനയെക്കുറിച്ച് ഒരു പ്രത്യേക തീരുമാനം എടുക്കാൻ അഭ്യർത്ഥിക്കുക... (വിഷമിക്കേണ്ട: മിക്സർ പ്രവർത്തിപ്പിക്കാൻ നിരവധി മാർഗങ്ങളുണ്ട്, അത് തകരാറിലായാലും, എൻവോയ് തുടർന്നും പ്രവർത്തിക്കും ഒരു പ്രോക്സി ആയി കൊള്ളാം) .

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

വികസിപ്പിക്കുക അല്ലെങ്കിൽ വാങ്ങുക

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

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

എന്നാൽ ഞങ്ങൾക്ക് വിപുലമായ ആവശ്യകതകളുണ്ടെങ്കിൽ, ഒരു സേവന മെഷ് "വാങ്ങുന്നത്" വളരെ മികച്ച ഓപ്ഷനാണെന്ന് തോന്നുന്നു. (ഇസ്തിയോ ഓപ്പൺ സോഴ്‌സ് ആയതിനാൽ ഇത് എല്ലായ്‌പ്പോഴും "വാങ്ങൽ" അല്ല, പക്ഷേ അത് മനസിലാക്കാനും വിന്യസിക്കാനും നിയന്ത്രിക്കാനും ഞങ്ങൾക്ക് എഞ്ചിനീയറിംഗ് സമയം നിക്ഷേപിക്കേണ്ടതുണ്ട്.)

ഞാൻ Istio, Linkerd അല്ലെങ്കിൽ Consul Connect തിരഞ്ഞെടുക്കണോ?

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

എന്ത് തിരഞ്ഞെടുക്കും?

സത്യം പറഞ്ഞാൽ എനിക്കറിയില്ല. ഈ ചോദ്യത്തിന് ഉത്തരം നൽകാൻ തക്ക യോഗ്യതയുള്ളതായി ഇപ്പോൾ ഞാൻ കരുതുന്നില്ല. കുറച്ച് ഉണ്ട് രസകരമായ ലേഖനങ്ങൾ ഈ ഉപകരണങ്ങളുടെ താരതമ്യത്തോടൊപ്പം പോലും മാനദണ്ഡങ്ങൾ.

ഒരു വാഗ്ദാനമായ സമീപനം പോലെയുള്ള ഒരു ഉപകരണം ഉപയോഗിക്കുക എന്നതാണ് സൂപ്പർഗ്ലൂ. സേവന മെഷുകൾ വെളിപ്പെടുത്തുന്ന API-കൾ ലളിതമാക്കുന്നതിനും ഏകീകരിക്കുന്നതിനും ഇത് ഒരു അബ്‌സ്‌ട്രാക്ഷൻ ലെയർ നടപ്പിലാക്കുന്നു. വ്യത്യസ്ത സേവന മെഷുകളുടെ നിർദ്ദിഷ്ട (എന്റെ അഭിപ്രായത്തിൽ, താരതമ്യേന സങ്കീർണ്ണമായ) API-കൾ പഠിക്കുന്നതിനുപകരം, നമുക്ക് SuperGloo- ന്റെ ലളിതമായ നിർമ്മിതികൾ ഉപയോഗിക്കാം - HTTP ഇന്റർഫേസുകളും ബാക്കെൻഡുകളും വിവരിക്കുന്ന ഒരു ഇന്റർമീഡിയറ്റ് കോൺഫിഗറേഷൻ ഫോർമാറ്റ് ഉള്ളതുപോലെ എളുപ്പത്തിൽ ഒന്നിൽ നിന്ന് മറ്റൊന്നിലേക്ക് മാറാം. Nginx, HAProxy, Traefik, Apache... എന്നിവയ്‌ക്കായുള്ള യഥാർത്ഥ കോൺഫിഗറേഷൻ ജനറേറ്റുചെയ്യുന്നു...

ഞാൻ Istio, SuperGloo എന്നിവയുമായി അൽപ്പം ഇടപഴകിയിട്ടുണ്ട്, അടുത്ത ലേഖനത്തിൽ SuperGloo ഉപയോഗിച്ച് നിലവിലുള്ള ഒരു ക്ലസ്റ്ററിലേക്ക് Istio അല്ലെങ്കിൽ Linkerd എങ്ങനെ ചേർക്കാമെന്നും രണ്ടാമത്തേത് എങ്ങനെ ജോലി ചെയ്യുന്നുവെന്നും കാണിക്കാൻ ആഗ്രഹിക്കുന്നു, അതായത്, അതിൽ നിന്ന് മാറാൻ നിങ്ങളെ അനുവദിക്കുന്നു കോൺഫിഗറേഷനുകൾ പുനരാലേഖനം ചെയ്യാതെ ഒരു സേവന മെഷ് മറ്റൊന്നിലേക്ക്.

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