കുബെർനെറ്റസിലെ ദീർഘകാല കണക്ഷനുകൾ ലോഡുചെയ്യുക ബാലൻസിങ്, സ്കെയിലിംഗ്

Kubernetes-ൽ ലോഡ് ബാലൻസിംഗ് എങ്ങനെ പ്രവർത്തിക്കുന്നു, ദീർഘകാല കണക്ഷനുകൾ സ്കെയിൽ ചെയ്യുമ്പോൾ എന്ത് സംഭവിക്കും, നിങ്ങൾ HTTP/2, gRPC, RSockets, AMQP അല്ലെങ്കിൽ മറ്റ് ദീർഘകാല പ്രോട്ടോക്കോളുകൾ ഉപയോഗിക്കുകയാണെങ്കിൽ ക്ലയൻ്റ്-സൈഡ് ബാലൻസിംഗ് പരിഗണിക്കുന്നത് എന്തുകൊണ്ട് എന്നിവ മനസ്സിലാക്കാൻ ഈ ലേഖനം നിങ്ങളെ സഹായിക്കും. . 

കുബർനെറ്റസിൽ ട്രാഫിക് എങ്ങനെ പുനർവിതരണം ചെയ്യപ്പെടുന്നു എന്നതിനെക്കുറിച്ച് അൽപ്പം 

ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്നതിന് കുബർനെറ്റസ് രണ്ട് സൗകര്യപ്രദമായ സംഗ്രഹങ്ങൾ നൽകുന്നു: സേവനങ്ങളും വിന്യാസങ്ങളും.

ഏത് സമയത്തും നിങ്ങളുടെ ആപ്ലിക്കേഷൻ്റെ എത്ര, എത്ര പകർപ്പുകൾ പ്രവർത്തിക്കണമെന്ന് വിന്യാസങ്ങൾ വിവരിക്കുന്നു. ഓരോ ആപ്ലിക്കേഷനും ഒരു പോഡ് ആയി വിന്യസിക്കുകയും ഒരു IP വിലാസം നൽകുകയും ചെയ്യുന്നു.

സേവനങ്ങൾ ഒരു ലോഡ് ബാലൻസറിന് സമാനമാണ്. ഒന്നിലധികം പോഡുകളിലുടനീളം ട്രാഫിക് വിതരണം ചെയ്യുന്നതിനാണ് അവ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്.

അത് എങ്ങനെയുണ്ടെന്ന് നോക്കാം.

1. ചുവടെയുള്ള ഡയഗ്രാമിൽ നിങ്ങൾക്ക് ഒരേ ആപ്ലിക്കേഷൻ്റെ മൂന്ന് സംഭവങ്ങളും ഒരു ലോഡ് ബാലൻസറും കാണാൻ കഴിയും:

   

2. ലോഡ് ബാലൻസറിനെ ഒരു സേവനം എന്ന് വിളിക്കുന്നു കൂടാതെ ഒരു IP വിലാസം നൽകുകയും ചെയ്യുന്നു. ഏത് ഇൻകമിംഗ് അഭ്യർത്ഥനയും പോഡുകളിലൊന്നിലേക്ക് റീഡയറക്‌ട് ചെയ്യുന്നു:

   

3. വിന്യാസ സാഹചര്യം ആപ്ലിക്കേഷൻ്റെ സംഭവങ്ങളുടെ എണ്ണം നിർണ്ണയിക്കുന്നു. നിങ്ങൾക്ക് ഒരിക്കലും നേരിട്ട് വിപുലീകരിക്കേണ്ടി വരില്ല:

   

4. ഓരോ പോഡിനും അതിൻ്റേതായ IP വിലാസം നൽകിയിട്ടുണ്ട്:

   

സേവനങ്ങളെ IP വിലാസങ്ങളുടെ ഒരു ശേഖരമായി കണക്കാക്കുന്നത് ഉപയോഗപ്രദമാണ്. ഓരോ തവണയും നിങ്ങൾ സേവനത്തിലേക്ക് പ്രവേശിക്കുമ്പോൾ, ലിസ്റ്റിൽ നിന്ന് ഐപി വിലാസങ്ങളിലൊന്ന് തിരഞ്ഞെടുത്ത് ലക്ഷ്യസ്ഥാന വിലാസമായി ഉപയോഗിക്കുന്നു.

ഇത് ഇതുപോലെ കാണപ്പെടുന്നു.

1. സേവനത്തിലേക്ക് ഒരു ചുരുളൻ 10.96.45.152 അഭ്യർത്ഥന ലഭിച്ചു:

   

2. സേവനം ലക്ഷ്യസ്ഥാനമായി മൂന്ന് പോഡ് വിലാസങ്ങളിൽ ഒന്ന് തിരഞ്ഞെടുക്കുന്നു:

   

3. ട്രാഫിക് ഒരു പ്രത്യേക പോഡിലേക്ക് റീഡയറക്‌ട് ചെയ്‌തു:

   

നിങ്ങളുടെ ആപ്ലിക്കേഷനിൽ ഒരു ഫ്രണ്ട്എൻഡും ബാക്കെൻഡും അടങ്ങിയിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഓരോന്നിനും ഒരു സേവനവും വിന്യാസവും ഉണ്ടായിരിക്കും.

ഫ്രണ്ട്എൻഡ് ബാക്കെൻഡിലേക്ക് ഒരു അഭ്യർത്ഥന നടത്തുമ്പോൾ, ബാക്കെൻഡ് എത്ര പോഡുകൾ നൽകുന്നു എന്ന് കൃത്യമായി അറിയേണ്ടതില്ല: ഒന്നോ പത്തോ നൂറോ ആകാം.

കൂടാതെ, ബാക്ക്എൻഡിന് നൽകുന്ന പോഡുകളുടെ വിലാസങ്ങളെക്കുറിച്ച് ഫ്രണ്ട്എൻഡിന് ഒന്നും അറിയില്ല.

ഫ്രണ്ട്എൻഡ് ബാക്കെൻഡിലേക്ക് ഒരു അഭ്യർത്ഥന നടത്തുമ്പോൾ, അത് ബാക്കെൻഡ് സേവനത്തിൻ്റെ IP വിലാസം ഉപയോഗിക്കുന്നു, അത് മാറില്ല.

ഇങ്ങനെയാണ് കാണുന്നത്.

1. 1-ന് കീഴിൽ ആന്തരിക ബാക്കെൻഡ് ഘടകം അഭ്യർത്ഥിക്കുന്നു. ബാക്കെൻഡിനായി ഒരു നിർദ്ദിഷ്ട ഒന്ന് തിരഞ്ഞെടുക്കുന്നതിനുപകരം, ഇത് സേവനത്തിലേക്ക് ഒരു അഭ്യർത്ഥന നടത്തുന്നു:

   

2. ലക്ഷ്യസ്ഥാന വിലാസമായി സേവനം ബാക്കെൻഡ് പോഡുകളിലൊന്ന് തിരഞ്ഞെടുക്കുന്നു:

   

3. സേവനം തിരഞ്ഞെടുത്ത പോഡ് 1 മുതൽ പോഡ് 5 വരെ ട്രാഫിക് പോകുന്നു:

   

4. 1 വയസ്സിന് താഴെയുള്ളവർക്ക്, 5 വയസ്സിന് താഴെയുള്ള എത്ര പോഡുകൾ സേവനത്തിന് പിന്നിൽ മറഞ്ഞിരിക്കുന്നുവെന്ന് കൃത്യമായി അറിയില്ല:

   

എന്നാൽ സേവനം കൃത്യമായി എങ്ങനെയാണ് അഭ്യർത്ഥനകൾ വിതരണം ചെയ്യുന്നത്? റൗണ്ട് റോബിൻ ബാലൻസിങ് ഉപയോഗിച്ചതായി തോന്നുന്നു? നമുക്ക് അത് കണ്ടുപിടിക്കാം. 

കുബർനെറ്റസ് സേവനങ്ങളിൽ ബാലൻസിങ്

Kubernetes സേവനങ്ങൾ നിലവിലില്ല. ഒരു IP വിലാസവും പോർട്ടും നൽകിയിട്ടുള്ള സേവനത്തിന് ഒരു പ്രക്രിയയും ഇല്ല.

ക്ലസ്റ്ററിലെ ഏത് നോഡിലേക്കും പ്രവേശിച്ച് netstat -ntlp കമാൻഡ് പ്രവർത്തിപ്പിച്ച് നിങ്ങൾക്ക് ഇത് സ്ഥിരീകരിക്കാൻ കഴിയും.

സേവനത്തിനായി അനുവദിച്ച IP വിലാസം പോലും നിങ്ങൾക്ക് കണ്ടെത്താൻ കഴിയില്ല.

സേവനത്തിൻ്റെ IP വിലാസം കൺട്രോൾ ലെയറിലും കൺട്രോളറിലും, ഡാറ്റാബേസിൽ രേഖപ്പെടുത്തിയിട്ടുണ്ട് - etcd. അതേ വിലാസം മറ്റൊരു ഘടകം ഉപയോഗിക്കുന്നു - kube-proxy.
Kube-proxy എല്ലാ സേവനങ്ങൾക്കുമുള്ള IP വിലാസങ്ങളുടെ ഒരു ലിസ്റ്റ് സ്വീകരിക്കുകയും ക്ലസ്റ്ററിലെ ഓരോ നോഡിലും ഒരു കൂട്ടം iptables നിയമങ്ങൾ സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.

ഈ നിയമങ്ങൾ പറയുന്നു: "ഞങ്ങൾ സേവനത്തിൻ്റെ IP വിലാസം കാണുകയാണെങ്കിൽ, അഭ്യർത്ഥനയുടെ ലക്ഷ്യസ്ഥാന വിലാസം ഞങ്ങൾ പരിഷ്ക്കരിച്ച് പോഡുകളിലൊന്നിലേക്ക് അയയ്ക്കേണ്ടതുണ്ട്."

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

നമുക്ക് ഇത് നോക്കാം. 

1. മൂന്ന് നോഡുകളുടെ ഒരു ക്ലസ്റ്റർ പരിഗണിക്കുക. ഓരോ നോഡിനും പോഡുകൾ ഉണ്ട്:

   

2. ബീജ് ചായം പൂശിയ ടൈഡ് പോഡുകൾ സേവനത്തിൻ്റെ ഭാഗമാണ്. സേവനം ഒരു പ്രക്രിയയായി നിലവിലില്ലാത്തതിനാൽ, അത് ചാരനിറത്തിൽ കാണിച്ചിരിക്കുന്നു:

   

3. ആദ്യത്തെ പോഡ് ഒരു സേവനം അഭ്യർത്ഥിക്കുന്നു കൂടാതെ അനുബന്ധ പോഡുകളിലൊന്നിലേക്ക് പോകണം:

   

4. എന്നാൽ സേവനം നിലവിലില്ല, പ്രക്രിയ നിലവിലില്ല. അതെങ്ങനെയാണ് പ്രവര്ത്തിക്കുന്നത്?

   

5. അഭ്യർത്ഥന നോഡിൽ നിന്ന് പുറപ്പെടുന്നതിന് മുമ്പ്, അത് iptables നിയമങ്ങളിലൂടെ കടന്നുപോകുന്നു:

   

6. ഈ സേവനം നിലവിലില്ലെന്ന് iptables നിയമങ്ങൾക്കറിയാം, കൂടാതെ ആ സേവനവുമായി ബന്ധപ്പെട്ട പോഡുകളുടെ IP വിലാസങ്ങളിലൊന്ന് ഉപയോഗിച്ച് അതിൻ്റെ IP വിലാസം മാറ്റിസ്ഥാപിക്കുക:

   

7. അഭ്യർത്ഥന ലക്ഷ്യസ്ഥാന വിലാസമായി സാധുവായ ഒരു IP വിലാസം സ്വീകരിക്കുകയും സാധാരണയായി പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു:

   

8. നെറ്റ്‌വർക്ക് ടോപ്പോളജി അനുസരിച്ച്, അഭ്യർത്ഥന ഒടുവിൽ പോഡിൽ എത്തുന്നു:

   

iptables-ന് ബാലൻസ് ലോഡ് ചെയ്യാൻ കഴിയുമോ?

ഇല്ല, iptables ഫിൽട്ടറിംഗിനായി ഉപയോഗിക്കുന്നു, അവ ബാലൻസിംഗിനായി രൂപകൽപ്പന ചെയ്തിട്ടില്ല.

എന്നിരുന്നാലും, ഇതുപോലെ പ്രവർത്തിക്കുന്ന ഒരു കൂട്ടം നിയമങ്ങൾ എഴുതാൻ കഴിയും കപട ബാലൻസർ.

ഇത് തന്നെയാണ് കുബർനെറ്റസിൽ നടപ്പിലാക്കിയിരിക്കുന്നത്.

നിങ്ങൾക്ക് മൂന്ന് പോഡുകൾ ഉണ്ടെങ്കിൽ, kube-proxy ഇനിപ്പറയുന്ന നിയമങ്ങൾ എഴുതും:

1. 33% സാധ്യതയുള്ള ആദ്യ ഉപവിഭാഗം തിരഞ്ഞെടുക്കുക, അല്ലാത്തപക്ഷം അടുത്ത നിയമത്തിലേക്ക് പോകുക.
2. 50% സാധ്യതയുള്ള രണ്ടാമത്തേത് തിരഞ്ഞെടുക്കുക, അല്ലാത്തപക്ഷം അടുത്ത നിയമത്തിലേക്ക് പോകുക.
3. ചുവടെയുള്ള മൂന്നാമത്തേത് തിരഞ്ഞെടുക്കുക.

ഈ സംവിധാനം 33% സംഭാവ്യതയോടെ ഓരോ പോഡും തിരഞ്ഞെടുക്കുന്നു.

പോഡ് 2-ന് ശേഷം പോഡ് 1 തിരഞ്ഞെടുക്കപ്പെടുമെന്ന് യാതൊരു ഉറപ്പുമില്ല.

അഭിപായപ്പെടുക: iptables ക്രമരഹിതമായ വിതരണത്തോടുകൂടിയ ഒരു സ്റ്റാറ്റിസ്റ്റിക്കൽ മൊഡ്യൂൾ ഉപയോഗിക്കുന്നു. അങ്ങനെ, ബാലൻസിങ് അൽഗോരിതം ക്രമരഹിതമായ തിരഞ്ഞെടുപ്പിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്.

സേവനങ്ങൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഇപ്പോൾ നിങ്ങൾ മനസ്സിലാക്കുന്നു, കൂടുതൽ രസകരമായ സേവന സാഹചര്യങ്ങൾ നോക്കാം.

കുബർനെറ്റസിലെ ദീർഘകാല കണക്ഷനുകൾ ഡിഫോൾട്ടായി സ്കെയിൽ ചെയ്യുന്നില്ല

ഫ്രണ്ട്എൻഡിൽ നിന്ന് ബാക്കെൻഡിലേക്കുള്ള ഓരോ HTTP അഭ്യർത്ഥനയും ഒരു പ്രത്യേക TCP കണക്ഷനാണ് നൽകുന്നത്, അത് തുറക്കുകയും അടയ്ക്കുകയും ചെയ്യുന്നു.

ഫ്രണ്ട്എൻഡ് ബാക്കെൻഡിലേക്ക് സെക്കൻഡിൽ 100 ​​അഭ്യർത്ഥനകൾ അയയ്ക്കുകയാണെങ്കിൽ, 100 വ്യത്യസ്ത TCP കണക്ഷനുകൾ തുറക്കുകയും അടയ്ക്കുകയും ചെയ്യുന്നു.

ഒരു TCP കണക്ഷൻ തുറന്ന് തുടർന്നുള്ള എല്ലാ HTTP അഭ്യർത്ഥനകൾക്കും അത് ഉപയോഗിക്കുന്നതിലൂടെ നിങ്ങൾക്ക് അഭ്യർത്ഥന പ്രോസസ്സിംഗ് സമയവും ലോഡും കുറയ്ക്കാനാകും.

HTTP പ്രോട്ടോക്കോളിന് HTTP Keep-alive അല്ലെങ്കിൽ കണക്ഷൻ പുനരുപയോഗം എന്നൊരു സവിശേഷതയുണ്ട്. ഈ സാഹചര്യത്തിൽ, ഒന്നിലധികം HTTP അഭ്യർത്ഥനകളും പ്രതികരണങ്ങളും അയയ്ക്കാനും സ്വീകരിക്കാനും ഒരൊറ്റ TCP കണക്ഷൻ ഉപയോഗിക്കുന്നു:

ഈ സവിശേഷത സ്ഥിരസ്ഥിതിയായി പ്രവർത്തനക്ഷമമാക്കിയിട്ടില്ല: സെർവറും ക്ലയൻ്റും അതിനനുസരിച്ച് കോൺഫിഗർ ചെയ്തിരിക്കണം.

സജ്ജീകരണം തന്നെ ലളിതവും മിക്ക പ്രോഗ്രാമിംഗ് ഭാഷകൾക്കും പരിതസ്ഥിതികൾക്കും ആക്സസ് ചെയ്യാവുന്നതുമാണ്.

വ്യത്യസ്ത ഭാഷകളിലുള്ള ഉദാഹരണങ്ങളിലേക്കുള്ള ചില ലിങ്കുകൾ ഇതാ:

• Node.js-ൽ Keep-alive
• സ്പ്രിംഗ് ബൂട്ടിൽ ജീവൻ നിലനിർത്തുക
• പൈത്തണിൽ ജീവൻ നിലനിർത്തുക
• .NET-ൽ നിലനിർത്തുക

ഒരു കുബർനെറ്റസ് സേവനത്തിൽ നമ്മൾ Keep-alive ഉപയോഗിച്ചാൽ എന്ത് സംഭവിക്കും?
ഫ്രണ്ട്എൻഡും ബാക്ക്എൻഡും സജീവമായി നിലനിർത്തുന്നതിനെ പിന്തുണയ്ക്കുന്നുവെന്ന് നമുക്ക് അനുമാനിക്കാം.

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

ഒരു പ്രതികരണം ലഭിച്ചതിന് ശേഷം TCP കണക്ഷൻ ക്ലോസ് ചെയ്യുന്ന സാധാരണ സാഹചര്യത്തിൽ നിന്ന് വ്യത്യസ്തമായി, കൂടുതൽ HTTP അഭ്യർത്ഥനകൾക്കായി ഇത് ഇപ്പോൾ തുറന്നിരിക്കുന്നു.

മുൻഭാഗം ബാക്കെൻഡിലേക്ക് കൂടുതൽ അഭ്യർത്ഥനകൾ അയച്ചാൽ എന്ത് സംഭവിക്കും?

ഈ അഭ്യർത്ഥനകൾ കൈമാറാൻ, ഒരു തുറന്ന TCP കണക്ഷൻ ഉപയോഗിക്കും, എല്ലാ അഭ്യർത്ഥനകളും ആദ്യ അഭ്യർത്ഥന പോയ അതേ ബാക്കെൻഡിലേക്ക് പോകും.

iptables ട്രാഫിക് പുനർവിതരണം ചെയ്യേണ്ടതല്ലേ?

ഈ സാഹചര്യത്തിൽ അല്ല.

ഒരു TCP കണക്ഷൻ സൃഷ്‌ടിക്കുമ്പോൾ, അത് iptables നിയമങ്ങളിലൂടെ കടന്നുപോകുന്നു, അത് ട്രാഫിക്ക് പോകുന്ന ഒരു പ്രത്യേക ബാക്കെൻഡ് തിരഞ്ഞെടുക്കുന്നു.

തുടർന്നുള്ള എല്ലാ അഭ്യർത്ഥനകളും ഇതിനകം തുറന്ന TCP കണക്ഷനിലുള്ളതിനാൽ, iptables നിയമങ്ങൾ ഇനി വിളിക്കില്ല.

അത് എങ്ങനെയുണ്ടെന്ന് നോക്കാം.

1. ആദ്യ പോഡ് സേവനത്തിലേക്ക് ഒരു അഭ്യർത്ഥന അയയ്ക്കുന്നു:

   

2. അടുത്തതായി എന്ത് സംഭവിക്കുമെന്ന് നിങ്ങൾക്ക് ഇതിനകം അറിയാം. സേവനം നിലവിലില്ല, എന്നാൽ അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുന്ന iptables നിയമങ്ങളുണ്ട്:

   

3. ലക്ഷ്യസ്ഥാന വിലാസമായി ബാക്കെൻഡ് പോഡുകളിലൊന്ന് തിരഞ്ഞെടുക്കും:

   

4. അഭ്യർത്ഥന പോഡിൽ എത്തുന്നു. ഈ സമയത്ത്, രണ്ട് പോഡുകൾക്കിടയിൽ ഒരു സ്ഥിരമായ TCP കണക്ഷൻ സ്ഥാപിക്കപ്പെടും:

   

5. ആദ്യ പോഡിൽ നിന്നുള്ള ഏതൊരു തുടർന്നുള്ള അഭ്യർത്ഥനയും ഇതിനകം സ്ഥാപിച്ച കണക്ഷനിലൂടെ കടന്നുപോകും:

   

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

നിങ്ങൾക്ക് ബാക്കെൻഡിൽ രണ്ട് പോഡുകൾ ഉണ്ടെങ്കിൽപ്പോലും, സ്ഥിരമായ കണക്ഷൻ ഉപയോഗിച്ച്, ട്രാഫിക്ക് എപ്പോഴും അവയിലൊന്നിലേക്ക് പോകും.

ഇത് പരിഹരിക്കാൻ കഴിയുമോ?

സ്ഥിരമായ കണക്ഷനുകൾ എങ്ങനെ സന്തുലിതമാക്കണമെന്ന് കുബെർനെറ്റസിന് അറിയാത്തതിനാൽ, ഈ ടാസ്‌ക് നിങ്ങളുടേതാണ്.

സേവനങ്ങൾ IP വിലാസങ്ങളുടെയും എൻഡ് പോയിൻ്റുകൾ എന്ന് വിളിക്കപ്പെടുന്ന പോർട്ടുകളുടെയും ഒരു ശേഖരമാണ്.

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

അല്ലെങ്കിൽ കൂടുതൽ പ്രയോഗിക്കുക സങ്കീർണ്ണമായ ബാലൻസിങ് അൽഗോരിതങ്ങൾ.

ബാലൻസിംഗിന് ഉത്തരവാദിയായ ക്ലയൻ്റ് സൈഡ് കോഡ് ഈ ലോജിക് പിന്തുടരേണ്ടതാണ്:

1. സേവനത്തിൽ നിന്ന് അവസാന പോയിൻ്റുകളുടെ ഒരു ലിസ്റ്റ് നേടുക.
2. ഓരോ എൻഡ് പോയിൻ്റിനും ഒരു സ്ഥിരമായ കണക്ഷൻ തുറക്കുക.
3. ഒരു അഭ്യർത്ഥന നടത്തേണ്ടിവരുമ്പോൾ, തുറന്ന കണക്ഷനുകളിലൊന്ന് ഉപയോഗിക്കുക.
4. എൻഡ് പോയിൻ്റുകളുടെ ലിസ്റ്റ് പതിവായി അപ്‌ഡേറ്റ് ചെയ്യുക, പുതിയവ സൃഷ്‌ടിക്കുക അല്ലെങ്കിൽ ലിസ്റ്റ് മാറുകയാണെങ്കിൽ പഴയ സ്ഥിരമായ കണക്ഷനുകൾ അടയ്ക്കുക.

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

1. സേവനത്തിലേക്ക് അഭ്യർത്ഥന അയയ്‌ക്കുന്ന ആദ്യ പോഡ് പകരം, നിങ്ങൾക്ക് ക്ലയൻ്റ് വശത്തുള്ള അഭ്യർത്ഥനകൾ ബാലൻസ് ചെയ്യാൻ കഴിയും:

   

2. ഏതൊക്കെ പോഡുകൾ സേവനത്തിൻ്റെ ഭാഗമാണെന്ന് ചോദിക്കുന്ന കോഡ് നിങ്ങൾ എഴുതേണ്ടതുണ്ട്:

   

3. നിങ്ങൾക്ക് ലിസ്റ്റ് ലഭിച്ചുകഴിഞ്ഞാൽ, അത് ക്ലയൻ്റ് വശത്ത് സംരക്ഷിച്ച് പോഡുകളിലേക്ക് കണക്റ്റുചെയ്യാൻ ഉപയോഗിക്കുക:

   

4. ലോഡ് ബാലൻസിംഗ് അൽഗോരിതത്തിന് നിങ്ങൾ ഉത്തരവാദിയാണ്:

   

ഇപ്പോൾ ചോദ്യം ഉയർന്നുവരുന്നു: ഈ പ്രശ്നം HTTP-ജീപ്-ലൈവിനു മാത്രമേ ബാധകമാകൂ?

ക്ലയൻ്റ്-സൈഡ് ലോഡ് ബാലൻസിങ്

സ്ഥിരമായ TCP കണക്ഷനുകൾ ഉപയോഗിക്കാനാകുന്ന ഒരേയൊരു പ്രോട്ടോക്കോൾ HTTP അല്ല.

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

പകരം, ഡാറ്റാബേസിലേക്കുള്ള സ്ഥിരമായ TCP കണക്ഷൻ തുറന്ന് ഉപയോഗിക്കപ്പെടുന്നു.

നിങ്ങളുടെ ഡാറ്റാബേസ് Kubernetes-ൽ വിന്യസിക്കുകയും ആക്സസ് ഒരു സേവനമായി നൽകുകയും ചെയ്താൽ, മുമ്പത്തെ വിഭാഗത്തിൽ വിവരിച്ച അതേ പ്രശ്നങ്ങൾ നിങ്ങൾക്ക് നേരിടേണ്ടിവരും.

ഒരു ഡാറ്റാബേസ് പകർപ്പ് മറ്റുള്ളവയേക്കാൾ കൂടുതൽ ലോഡ് ചെയ്യും. Kube-proxy ഉം Kubernetes ഉം കണക്ഷനുകൾ ബാലൻസ് ചെയ്യാൻ സഹായിക്കില്ല. നിങ്ങളുടെ ഡാറ്റാബേസിലേക്ക് ചോദ്യങ്ങൾ ബാലൻസ് ചെയ്യാൻ നിങ്ങൾ ശ്രദ്ധിക്കണം.

ഡാറ്റാബേസിലേക്ക് കണക്റ്റുചെയ്യാൻ നിങ്ങൾ ഉപയോഗിക്കുന്ന ലൈബ്രറിയെ ആശ്രയിച്ച്, ഈ പ്രശ്നം പരിഹരിക്കുന്നതിന് നിങ്ങൾക്ക് വ്യത്യസ്ത ഓപ്ഷനുകൾ ഉണ്ടായേക്കാം.

Node.js-ൽ നിന്ന് MySQL ഡാറ്റാബേസ് ക്ലസ്റ്റർ ആക്‌സസ് ചെയ്യുന്നതിനുള്ള ഒരു ഉദാഹരണം ചുവടെയുണ്ട്:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

സ്ഥിരമായ TCP കണക്ഷനുകൾ ഉപയോഗിക്കുന്ന മറ്റ് നിരവധി പ്രോട്ടോക്കോളുകൾ ഉണ്ട്:

• വെബ്‌സോക്കറ്റുകളും സുരക്ഷിത വെബ്‌സോക്കറ്റുകളും
• HTTP / 2
• gRPC
• RSockets
• എഎംക്യുപി

ഈ പ്രോട്ടോക്കോളുകളിൽ ഭൂരിഭാഗവും നിങ്ങൾക്ക് ഇതിനകം പരിചിതമായിരിക്കണം.

എന്നാൽ ഈ പ്രോട്ടോക്കോളുകൾ വളരെ ജനപ്രിയമാണെങ്കിൽ, എന്തുകൊണ്ട് ഒരു സ്റ്റാൻഡേർഡ് ബാലൻസിങ് സൊല്യൂഷൻ ഇല്ല? എന്തുകൊണ്ടാണ് ക്ലയൻ്റ് ലോജിക്ക് മാറേണ്ടത്? ഒരു നേറ്റീവ് കുബർനെറ്റസ് പരിഹാരം ഉണ്ടോ?

Kube-proxy, iptables എന്നിവ Kubernetes-ലേക്ക് വിന്യസിക്കുമ്പോൾ ഏറ്റവും സാധാരണമായ ഉപയോഗ കേസുകൾ ഉൾക്കൊള്ളുന്ന തരത്തിലാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഇത് സൗകര്യാർത്ഥമാണ്.

നിങ്ങൾ ഒരു REST API തുറന്നുകാട്ടുന്ന ഒരു വെബ് സേവനമാണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, നിങ്ങൾ ഭാഗ്യവാനാണ് - ഈ സാഹചര്യത്തിൽ, സ്ഥിരമായ TCP കണക്ഷനുകൾ ഉപയോഗിക്കില്ല, നിങ്ങൾക്ക് ഏത് Kubernetes സേവനവും ഉപയോഗിക്കാം.

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

എന്നിരുന്നാലും, തീർച്ചയായും സഹായിക്കുന്ന ഓപ്ഷനുകൾ ഉണ്ട്.

കുബർനെറ്റസിലെ ദീർഘകാല കണക്ഷനുകൾ സന്തുലിതമാക്കുന്നു

കുബർനെറ്റസിൽ നാല് തരം സേവനങ്ങളുണ്ട്:

1. ClusterIP
2. നോഡ്പോർട്ട്
3. ലോഡ്ബാലൻസർ
4. തലയില്ലാത്ത

ആദ്യത്തെ മൂന്ന് സേവനങ്ങളും ഒരു വെർച്വൽ ഐപി വിലാസത്തെ അടിസ്ഥാനമാക്കിയാണ് പ്രവർത്തിക്കുന്നത്, ഇത് iptables നിയമങ്ങൾ നിർമ്മിക്കാൻ kube-proxy ഉപയോഗിക്കുന്നു. എന്നാൽ എല്ലാ സേവനങ്ങളുടെയും അടിസ്ഥാന അടിസ്ഥാനം തലയില്ലാത്ത സേവനമാണ്.

ഹെഡ്‌ലെസ് സേവനത്തിന് ഇതുമായി ബന്ധപ്പെട്ട IP വിലാസങ്ങളൊന്നുമില്ല, മാത്രമല്ല IP വിലാസങ്ങളുടെയും അതുമായി ബന്ധപ്പെട്ട പോഡുകളുടെ (എൻഡ്‌പോയിൻ്റുകൾ) പോർട്ടുകളുടെയും ഒരു ലിസ്റ്റ് വീണ്ടെടുക്കുന്നതിനുള്ള ഒരു സംവിധാനം മാത്രമാണ് നൽകുന്നത്.

എല്ലാ സേവനങ്ങളും തലയില്ലാത്ത സേവനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്.

ClusterIP സേവനം ചില കൂട്ടിച്ചേർക്കലുകളുള്ള ഒരു തലയില്ലാത്ത സേവനമാണ്: 

1. മാനേജ്മെൻ്റ് ലെയർ അതിന് ഒരു IP വിലാസം നൽകുന്നു.
2. Kube-proxy ആവശ്യമായ iptables നിയമങ്ങൾ സൃഷ്ടിക്കുന്നു.

ഇതുവഴി നിങ്ങൾക്ക് kube-proxy അവഗണിക്കാനും നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ബാലൻസ് ലോഡുചെയ്യുന്നതിന് ഹെഡ്‌ലെസ് സേവനത്തിൽ നിന്ന് ലഭിച്ച എൻഡ് പോയിൻ്റുകളുടെ ലിസ്റ്റ് നേരിട്ട് ഉപയോഗിക്കാനും കഴിയും.

എന്നാൽ ക്ലസ്റ്ററിൽ വിന്യസിച്ചിരിക്കുന്ന എല്ലാ ആപ്ലിക്കേഷനുകൾക്കും സമാനമായ ലോജിക് എങ്ങനെ ചേർക്കാം?

നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ഇതിനകം വിന്യസിച്ചിട്ടുണ്ടെങ്കിൽ, ഈ ടാസ്ക് അസാധ്യമാണെന്ന് തോന്നിയേക്കാം. എന്നിരുന്നാലും, ഒരു ബദൽ ഓപ്ഷൻ ഉണ്ട്.

സേവന മെഷ് നിങ്ങളെ സഹായിക്കും

ക്ലയൻ്റ്-സൈഡ് ലോഡ് ബാലൻസിങ് തന്ത്രം തികച്ചും സ്റ്റാൻഡേർഡ് ആണെന്ന് നിങ്ങൾ ഇതിനകം ശ്രദ്ധിച്ചിരിക്കാം.

ആപ്ലിക്കേഷൻ ആരംഭിക്കുമ്പോൾ, അത്:

1. സേവനത്തിൽ നിന്ന് IP വിലാസങ്ങളുടെ ഒരു ലിസ്റ്റ് ലഭിക്കുന്നു.
2. ഒരു കണക്ഷൻ പൂൾ തുറക്കുകയും പരിപാലിക്കുകയും ചെയ്യുന്നു.
3. എൻഡ് പോയിൻ്റുകൾ ചേർത്തോ നീക്കം ചെയ്തോ പൂൾ കാലാകാലങ്ങളിൽ അപ്ഡേറ്റ് ചെയ്യുന്നു.

ഒരിക്കൽ അപേക്ഷ ഒരു അഭ്യർത്ഥന നടത്താൻ ആഗ്രഹിക്കുന്നു, അത്:

1. ചില ലോജിക് ഉപയോഗിച്ച് ലഭ്യമായ ഒരു കണക്ഷൻ തിരഞ്ഞെടുക്കുന്നു (ഉദാ. റൗണ്ട്-റോബിൻ).
2. അഭ്യർത്ഥന നടപ്പിലാക്കുന്നു.

WebSockets, gRPC, AMQP കണക്ഷനുകൾ എന്നിവയ്‌ക്കായി ഈ ഘട്ടങ്ങൾ പ്രവർത്തിക്കുന്നു.

നിങ്ങൾക്ക് ഈ യുക്തിയെ ഒരു പ്രത്യേക ലൈബ്രറിയായി വേർതിരിക്കാനും നിങ്ങളുടെ ആപ്ലിക്കേഷനുകളിൽ ഇത് ഉപയോഗിക്കാനും കഴിയും.

എന്നിരുന്നാലും, നിങ്ങൾക്ക് പകരം Istio അല്ലെങ്കിൽ Linkerd പോലുള്ള സേവന മെഷുകൾ ഉപയോഗിക്കാം.

സർവീസ് മെഷ് നിങ്ങളുടെ അപേക്ഷയെ ഒരു പ്രോസസ് ഉപയോഗിച്ച് വർദ്ധിപ്പിക്കുന്നു:

1. സേവന ഐപി വിലാസങ്ങൾക്കായി സ്വയമേവ തിരയുന്നു.
2. WebSockets, gRPC തുടങ്ങിയ കണക്ഷനുകൾ പരിശോധിക്കുന്നു.
3. ശരിയായ പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് അഭ്യർത്ഥനകൾ ബാലൻസ് ചെയ്യുന്നു.

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

ബാലൻസിങ് പ്രശ്നങ്ങൾ നിങ്ങൾ അവഗണിക്കുകയാണെങ്കിൽ എന്ത് സംഭവിക്കും?

നിങ്ങൾക്ക് ലോഡ് ബാലൻസിങ് ഉപയോഗിക്കരുതെന്നും അപ്പോഴും മാറ്റങ്ങളൊന്നും ശ്രദ്ധിക്കാതിരിക്കാനും തിരഞ്ഞെടുക്കാം. കുറച്ച് ജോലി സാഹചര്യങ്ങൾ നോക്കാം.

നിങ്ങൾക്ക് സെർവറുകളേക്കാൾ കൂടുതൽ ക്ലയൻ്റുകൾ ഉണ്ടെങ്കിൽ, ഇത് അത്ര വലിയ പ്രശ്നമല്ല.

രണ്ട് സെർവറുകളുമായി ബന്ധിപ്പിക്കുന്ന അഞ്ച് ക്ലയൻ്റുകൾ ഉണ്ടെന്ന് നമുക്ക് പറയാം. ബാലൻസിംഗ് ഇല്ലെങ്കിൽപ്പോലും, രണ്ട് സെർവറുകളും ഉപയോഗിക്കും:

കണക്ഷനുകൾ തുല്യമായി വിതരണം ചെയ്യപ്പെടണമെന്നില്ല: ഒരുപക്ഷേ ഒരേ സെർവറിലേക്ക് നാല് ക്ലയൻ്റുകളെ ബന്ധിപ്പിച്ചിട്ടുണ്ടാകാം, എന്നാൽ രണ്ട് സെർവറുകളും ഉപയോഗിക്കാനുള്ള നല്ല അവസരമുണ്ട്.

വിപരീത സാഹചര്യമാണ് കൂടുതൽ പ്രശ്‌നമുണ്ടാക്കുന്നത്.

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

രണ്ട് ക്ലയൻ്റുകളും അഞ്ച് സെർവറുകളും ഉണ്ടെന്ന് പറയാം. മികച്ച സാഹചര്യത്തിൽ, അഞ്ചിൽ രണ്ട് സെർവറുകളിലേക്ക് രണ്ട് സ്ഥിരമായ കണക്ഷനുകൾ ഉണ്ടാകും.

ശേഷിക്കുന്ന സെർവറുകൾ നിഷ്‌ക്രിയമായിരിക്കും:

ഈ രണ്ട് സെർവറുകൾക്കും ക്ലയൻ്റ് അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യാൻ കഴിയുന്നില്ലെങ്കിൽ, തിരശ്ചീന സ്കെയിലിംഗ് സഹായിക്കില്ല.

തീരുമാനം

മിക്ക സ്റ്റാൻഡേർഡ് വെബ് ആപ്ലിക്കേഷൻ സാഹചര്യങ്ങളിലും പ്രവർത്തിക്കാനാണ് കുബർനെറ്റസ് സേവനങ്ങൾ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്.

എന്നിരുന്നാലും, ഡാറ്റാബേസുകൾ, gRPC അല്ലെങ്കിൽ WebSockets പോലുള്ള സ്ഥിരമായ TCP കണക്ഷനുകൾ ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷൻ പ്രോട്ടോക്കോളുകളിൽ നിങ്ങൾ പ്രവർത്തിക്കാൻ തുടങ്ങിയാൽ, സേവനങ്ങൾ ഇനി അനുയോജ്യമല്ല. സ്ഥിരമായ TCP കണക്ഷനുകൾ സന്തുലിതമാക്കുന്നതിനുള്ള ആന്തരിക സംവിധാനങ്ങൾ Kubernetes നൽകുന്നില്ല.

ക്ലയൻ്റ്-സൈഡ് ബാലൻസിംഗ് മനസ്സിൽ വെച്ചുകൊണ്ട് നിങ്ങൾ ആപ്ലിക്കേഷനുകൾ എഴുതണം എന്നാണ് ഇതിനർത്ഥം.

സംഘം തയ്യാറാക്കിയ പരിഭാഷ Mail.ru-ൽ നിന്ന് Kubernetes aaS.

വിഷയത്തിൽ മറ്റെന്താണ് വായിക്കേണ്ടത്:

1. കുബർനെറ്റസിലെ ഓട്ടോസ്‌കേലിംഗിന്റെ മൂന്ന് തലങ്ങളും അവ എങ്ങനെ ഫലപ്രദമായി ഉപയോഗിക്കാമെന്നും. 
2. നടപ്പാക്കൽ ടെംപ്ലേറ്റിനൊപ്പം പൈറസിയുടെ ആവേശത്തിൽ കുബർനെറ്റസ്.
3. ഡിജിറ്റൽ പരിവർത്തനത്തെക്കുറിച്ചുള്ള ഞങ്ങളുടെ ടെലിഗ്രാം ചാനൽ.

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