🥇કુબરનેટ્સમાં લાંબા સમયથી ચાલતા કનેક્શનને બેલેન્સિંગ અને સ્કેલિંગ લોડ કરો

આ લેખ તમને એ સમજવામાં મદદ કરશે કે કુબરનેટ્સમાં લોડ બેલેન્સિંગ કેવી રીતે કામ કરે છે, લાંબા ગાળાના કનેક્શનને સ્કેલિંગ કરતી વખતે શું થાય છે અને જો તમે HTTP/2, gRPC, RSockets, AMQP અથવા અન્ય લાંબા ગાળાના પ્રોટોકોલનો ઉપયોગ કરો છો તો તમારે ક્લાયંટ-સાઇડ બેલેન્સિંગ શા માટે ધ્યાનમાં લેવું જોઈએ. .

કુબરનેટ્સમાં ટ્રાફિક કેવી રીતે પુનઃવિતરિત થાય છે તે વિશે થોડું

કુબરનેટ્સ એપ્લીકેશન જમાવટ કરવા માટે બે અનુકૂળ એબ્સ્ટ્રેક્શન પ્રદાન કરે છે: સેવાઓ અને જમાવટ.

ડિપ્લોયમેન્ટ્સ કોઈપણ સમયે તમારી અરજીની કેવી અને કેટલી નકલો ચાલવી જોઈએ તેનું વર્ણન કરે છે. દરેક એપ્લિકેશન પોડ તરીકે જમાવવામાં આવે છે અને તેને IP સરનામું સોંપવામાં આવે છે.

સેવાઓ લોડ બેલેન્સર જેવી જ કાર્ય કરે છે. તેઓ બહુવિધ પોડ પર ટ્રાફિકનું વિતરણ કરવા માટે રચાયેલ છે.

ચાલો જોઈએ કે તે કેવો દેખાય છે.

નીચેની આકૃતિમાં તમે સમાન એપ્લિકેશન અને લોડ બેલેન્સરના ત્રણ ઉદાહરણો જોઈ શકો છો:
લોડ બેલેન્સરને સેવા કહેવામાં આવે છે અને તેને IP સરનામું સોંપવામાં આવે છે. કોઈપણ ઇનકમિંગ વિનંતી પોડમાંથી એક પર રીડાયરેક્ટ કરવામાં આવે છે:
જમાવટનું દૃશ્ય એપ્લિકેશનના ઉદાહરણોની સંખ્યા નક્કી કરે છે. તમારે લગભગ ક્યારેય સીધા નીચે વિસ્તરણ કરવું પડશે નહીં:
દરેક પોડને તેનું પોતાનું IP સરનામું સોંપવામાં આવે છે:

સેવાઓને IP સરનામાઓના સંગ્રહ તરીકે વિચારવું ઉપયોગી છે. દર વખતે જ્યારે તમે સેવાનો ઉપયોગ કરો છો, ત્યારે સૂચિમાંથી એક IP સરનામું પસંદ કરવામાં આવે છે અને તેનો ઉપયોગ ગંતવ્ય સરનામા તરીકે થાય છે.

તે આના જેવું લાગે છે.

સેવાને કર્લ 10.96.45.152 વિનંતી પ્રાપ્ત થઈ છે:
સેવા ગંતવ્ય તરીકે ત્રણ પોડ સરનામાંઓમાંથી એક પસંદ કરે છે:
ટ્રાફિકને ચોક્કસ પોડ પર રીડાયરેક્ટ કરવામાં આવે છે:

જો તમારી એપ્લિકેશનમાં ફ્રન્ટ એન્ડ અને બેકએન્ડ હોય, તો તમારી પાસે દરેક માટે સેવા અને જમાવટ બંને હશે.

જ્યારે ફ્રન્ટએન્ડ બેકએન્ડને વિનંતી કરે છે, ત્યારે તેને બરાબર જાણવાની જરૂર નથી કે બેકએન્ડ કેટલા પોડ્સ આપે છે: ત્યાં એક, દસ અથવા સો હોઈ શકે છે.

ઉપરાંત, ફ્રન્ટએન્ડ બેકએન્ડને સેવા આપતા શીંગોના સરનામાં વિશે કંઈપણ જાણતું નથી.

જ્યારે ફ્રન્ટએન્ડ બેકએન્ડને વિનંતી કરે છે, ત્યારે તે બેકએન્ડ સેવાના IP સરનામાંનો ઉપયોગ કરે છે, જે બદલાતું નથી.

આ તે જેવો દેખાય છે.

1 હેઠળ આંતરિક બેકએન્ડ ઘટકની વિનંતી કરે છે. બેકએન્ડ માટે ચોક્કસ પસંદ કરવાને બદલે, તે સેવાને વિનંતી કરે છે:
સેવા ગંતવ્ય સરનામાં તરીકે બેકએન્ડ પોડમાંથી એક પસંદ કરે છે:
ટ્રાફિક પોડ 1 થી પોડ 5 સુધી જાય છે, સેવા દ્વારા પસંદ કરવામાં આવે છે:
1 હેઠળની સેવાની પાછળ 5 હેઠળના જેવા કેટલા પોડ્સ છુપાયેલા છે તે બરાબર જાણતું નથી:

પરંતુ સેવા વિનંતીઓનું વિતરણ કેવી રીતે કરે છે? એવું લાગે છે કે રાઉન્ડ-રોબિન બેલેન્સિંગનો ઉપયોગ થાય છે? ચાલો તેને આકૃતિ કરીએ.

કુબરનેટ્સ સેવાઓમાં સંતુલન

Kubernetes સેવાઓ અસ્તિત્વમાં નથી. IP સરનામું અને પોર્ટ સોંપેલ સેવા માટે કોઈ પ્રક્રિયા નથી.

તમે ક્લસ્ટરમાં કોઈપણ નોડમાં લૉગ ઇન કરીને અને netstat -ntlp આદેશ ચલાવીને આને ચકાસી શકો છો.

તમે સેવા માટે ફાળવેલ IP સરનામું પણ શોધી શકશો નહીં.

સેવાનું IP સરનામું નિયંત્રણ સ્તરમાં, નિયંત્રકમાં સ્થિત છે, અને ડેટાબેઝમાં રેકોર્ડ થયેલ છે - વગેરે. સમાન સરનામું અન્ય ઘટક દ્વારા ઉપયોગમાં લેવાય છે - kube-proxy.
કુબે-પ્રોક્સી બધી સેવાઓ માટે IP સરનામાઓની સૂચિ મેળવે છે અને ક્લસ્ટરમાં દરેક નોડ પર iptables નિયમોનો સમૂહ બનાવે છે.

આ નિયમો કહે છે: "જો અમને સેવાનું IP સરનામું દેખાય છે, તો અમારે વિનંતીના ગંતવ્ય સરનામાંને સંશોધિત કરવાની જરૂર છે અને તેને એક પોડ પર મોકલવાની જરૂર છે."

સર્વિસ IP એડ્રેસનો ઉપયોગ ફક્ત એન્ટ્રી પોઈન્ટ તરીકે જ થાય છે અને તે IP એડ્રેસ અને પોર્ટ સાંભળવાની કોઈપણ પ્રક્રિયા દ્વારા સેવા આપવામાં આવતી નથી.

ચાલો આ જોઈએ.

ત્રણ ગાંઠોના ક્લસ્ટરને ધ્યાનમાં લો. દરેક નોડમાં શીંગો હોય છે:
બાંધેલી શીંગો પેઇન્ટેડ ન રંગેલું ઊની કાપડ સેવાનો એક ભાગ છે. કારણ કે સેવા પ્રક્રિયા તરીકે અસ્તિત્વમાં નથી, તે ગ્રે રંગમાં બતાવવામાં આવી છે:
પ્રથમ પોડ સેવાની વિનંતી કરે છે અને તેને સંબંધિત પોડમાંથી એક પર જવું આવશ્યક છે:
પરંતુ સેવા અસ્તિત્વમાં નથી, પ્રક્રિયા અસ્તિત્વમાં નથી. તે કેવી રીતે કામ કરે છે?
વિનંતી નોડ છોડે તે પહેલાં, તે iptables નિયમોમાંથી પસાર થાય છે:
iptables નિયમો જાણે છે કે સેવા અસ્તિત્વમાં નથી અને તેના IP સરનામાને તે સેવા સાથે સંકળાયેલા પોડ્સના IP સરનામાઓમાંથી એક સાથે બદલો:
વિનંતીને ગંતવ્ય સરનામાં તરીકે માન્ય IP સરનામું પ્રાપ્ત થાય છે અને સામાન્ય રીતે પ્રક્રિયા કરવામાં આવે છે:
નેટવર્ક ટોપોલોજીના આધારે, વિનંતી આખરે પોડ સુધી પહોંચે છે:

શું iptables બેલેન્સ લોડ કરી શકે છે?

ના, iptables નો ઉપયોગ ફિલ્ટરિંગ માટે થાય છે અને તે સંતુલિત કરવા માટે રચાયેલ નથી.

જો કે, નિયમોનો સમૂહ લખવાનું શક્ય છે જે કામ કરે છે સ્યુડો-બેલેન્સર.

અને કુબરનેટ્સમાં આ બરાબર લાગુ કરવામાં આવ્યું છે.

જો તમારી પાસે ત્રણ પોડ હોય, તો કુબે-પ્રોક્સી નીચેના નિયમો લખશે:

33% ની સંભાવના સાથે પ્રથમ પેટા પસંદ કરો, અન્યથા આગલા નિયમ પર જાઓ.
50% ની સંભાવના સાથે બીજો પસંદ કરો, અન્યથા આગલા નિયમ પર જાઓ.
હેઠળ ત્રીજો પસંદ કરો.

આ સિસ્ટમના પરિણામે દરેક પોડ 33% ની સંભાવના સાથે પસંદ કરવામાં આવે છે.

અને ત્યાં કોઈ ગેરેંટી નથી કે Pod 2 પછી Pod 1 પસંદ કરવામાં આવશે.

નોંધણી: iptables રેન્ડમ વિતરણ સાથે આંકડાકીય મોડ્યુલનો ઉપયોગ કરે છે. આમ, સંતુલન અલ્ગોરિધમ રેન્ડમ પસંદગી પર આધારિત છે.

હવે તમે સમજો છો કે સેવાઓ કેવી રીતે કાર્ય કરે છે, ચાલો વધુ રસપ્રદ સેવા દૃશ્યો જોઈએ.

કુબરનેટ્સમાં લાંબા ગાળાના જોડાણો મૂળભૂત રીતે માપવામાં આવતા નથી

ફ્રન્ટએન્ડથી બેકએન્ડ સુધીની દરેક HTTP વિનંતી એક અલગ TCP કનેક્શન દ્વારા આપવામાં આવે છે, જે ખોલવામાં આવે છે અને બંધ થાય છે.

જો ફ્રન્ટએન્ડ બેકએન્ડને પ્રતિ સેકન્ડે 100 વિનંતીઓ મોકલે છે, તો પછી 100 અલગ-અલગ TCP જોડાણો ખોલવામાં અને બંધ કરવામાં આવે છે.

તમે એક TCP કનેક્શન ખોલીને અને અનુગામી બધી HTTP વિનંતીઓ માટે તેનો ઉપયોગ કરીને વિનંતી પ્રક્રિયા સમય અને લોડ ઘટાડી શકો છો.

HTTP પ્રોટોકોલમાં HTTP કીપ-લાઇવ અથવા કનેક્શન પુનઃઉપયોગ નામની સુવિધા છે. આ કિસ્સામાં, એક TCP કનેક્શનનો ઉપયોગ બહુવિધ HTTP વિનંતીઓ અને પ્રતિસાદો મોકલવા અને પ્રાપ્ત કરવા માટે થાય છે:

આ સુવિધા ડિફૉલ્ટ રૂપે સક્ષમ નથી: સર્વર અને ક્લાયંટ બંને તે મુજબ ગોઠવેલા હોવા જોઈએ.

મોટાભાગની પ્રોગ્રામિંગ ભાષાઓ અને વાતાવરણ માટે સેટઅપ પોતે જ સરળ અને સુલભ છે.

અહીં વિવિધ ભાષાઓમાં ઉદાહરણોની કેટલીક લિંક્સ છે:

જો આપણે કુબરનેટ્સ સેવામાં કીપ-લાઇવનો ઉપયોગ કરીએ તો શું થાય?
ચાલો ધારીએ કે ફ્રન્ટ એન્ડ અને બેકએન્ડ બંને સપોર્ટ જીવંત રાખે છે.

અમારી પાસે ફ્રન્ટએન્ડની એક નકલ અને બેકએન્ડની ત્રણ નકલો છે. ફ્રન્ટએન્ડ પ્રથમ વિનંતી કરે છે અને બેકએન્ડ પર TCP કનેક્શન ખોલે છે. વિનંતી સેવા સુધી પહોંચે છે, બેકએન્ડ પોડમાંથી એકને ગંતવ્ય સરનામા તરીકે પસંદ કરવામાં આવે છે. બેકએન્ડ પ્રતિસાદ મોકલે છે, અને અગ્રભાગ તેને પ્રાપ્ત કરે છે.

સામાન્ય પરિસ્થિતિથી વિપરીત જ્યાં પ્રતિસાદ પ્રાપ્ત કર્યા પછી TCP કનેક્શન બંધ કરવામાં આવે છે, તે હવે વધુ HTTP વિનંતીઓ માટે ખુલ્લું રાખવામાં આવ્યું છે.

જો ફ્રન્ટએન્ડ બેકએન્ડને વધુ વિનંતીઓ મોકલે તો શું થાય?

આ વિનંતીઓને ફોરવર્ડ કરવા માટે, ઓપન TCP કનેક્શનનો ઉપયોગ કરવામાં આવશે, બધી વિનંતીઓ એ જ બેકએન્ડ પર જશે જ્યાં પ્રથમ વિનંતી કરવામાં આવી હતી.

શું iptables ટ્રાફિકનું પુનઃવિતરણ ન કરવું જોઈએ?

આ કિસ્સામાં નહીં.

જ્યારે TCP કનેક્શન બનાવવામાં આવે છે, ત્યારે તે iptables નિયમોમાંથી પસાર થાય છે, જે ચોક્કસ બેકએન્ડ પસંદ કરે છે જ્યાં ટ્રાફિક જશે.

ત્યારથી બધી અનુગામી વિનંતીઓ પહેલેથી જ ખુલ્લા TCP કનેક્શન પર છે, iptables નિયમો હવે કહેવાતા નથી.

ચાલો જોઈએ કે તે કેવો દેખાય છે.

પ્રથમ પોડ સેવાને વિનંતી મોકલે છે:
તમે પહેલાથી જ જાણો છો કે આગળ શું થશે. સેવા અસ્તિત્વમાં નથી, પરંતુ ત્યાં iptables નિયમો છે જે વિનંતી પર પ્રક્રિયા કરશે:
બેકએન્ડ પોડ્સમાંથી એકને ગંતવ્ય સરનામું તરીકે પસંદ કરવામાં આવશે:
વિનંતી પોડ સુધી પહોંચે છે. આ બિંદુએ, બે શીંગો વચ્ચે સતત TCP જોડાણ સ્થાપિત થશે:
પ્રથમ પોડની કોઈપણ અનુગામી વિનંતી પહેલાથી સ્થાપિત કનેક્શનમાંથી પસાર થશે:

પરિણામ ઝડપી પ્રતિસાદ સમય અને ઉચ્ચ થ્રુપુટ છે, પરંતુ તમે બેકએન્ડને માપવાની ક્ષમતા ગુમાવો છો.

જો તમારી પાસે બેકએન્ડમાં બે પોડ્સ હોય, તો પણ સતત જોડાણ સાથે, ટ્રાફિક હંમેશા તેમાંથી એક પર જશે.

શું આને ઠીક કરી શકાય?

કુબરનેટ્સ સતત કનેક્શનને કેવી રીતે સંતુલિત કરવું તે જાણતું નથી, તેથી આ કાર્ય તમારા પર આવે છે.

સેવાઓ એ IP એડ્રેસ અને પોર્ટનો સંગ્રહ છે જેને એન્ડપોઇન્ટ કહેવાય છે.

તમારી એપ્લિકેશન સેવામાંથી અંતિમ બિંદુઓની સૂચિ મેળવી શકે છે અને તેમની વચ્ચે વિનંતીઓ કેવી રીતે વિતરિત કરવી તે નક્કી કરી શકે છે. તમે દરેક પોડ માટે સતત કનેક્શન ખોલી શકો છો અને રાઉન્ડ-રોબિનનો ઉપયોગ કરીને આ જોડાણો વચ્ચે સંતુલન વિનંતીઓ કરી શકો છો.

અથવા વધુ અરજી કરો જટિલ સંતુલન ગાણિતીક નિયમો.

ક્લાયંટ-સાઇડ કોડ કે જે સંતુલન માટે જવાબદાર છે તે આ તર્કને અનુસરે છે:

સેવામાંથી અંતિમ બિંદુઓની સૂચિ મેળવો.
દરેક અંતિમ બિંદુ માટે સતત કનેક્શન ખોલો.
જ્યારે વિનંતી કરવાની જરૂર હોય, ત્યારે ખુલ્લા જોડાણોમાંથી એકનો ઉપયોગ કરો.
એન્ડપોઇન્ટ્સની સૂચિને નિયમિતપણે અપડેટ કરો, નવા બનાવો અથવા જો સૂચિ બદલાય તો જૂના સતત જોડાણો બંધ કરો.

આ તે જેવો દેખાશે.

પ્રથમ પોડ સેવાને વિનંતી મોકલવાને બદલે, તમે ક્લાયન્ટ બાજુ પર વિનંતીઓને સંતુલિત કરી શકો છો:
તમારે કોડ લખવાની જરૂર છે જે પૂછે છે કે કયા પોડ્સ સેવાનો ભાગ છે:
એકવાર તમારી પાસે સૂચિ હોય તે પછી, તેને ક્લાયંટ બાજુ પર સાચવો અને પોડ્સ સાથે કનેક્ટ કરવા માટે તેનો ઉપયોગ કરો:
તમે લોડ બેલેન્સિંગ અલ્ગોરિધમ માટે જવાબદાર છો:

હવે પ્રશ્ન ઊભો થાય છે: શું આ સમસ્યા માત્ર HTTP કીપ-લાઇવ પર જ લાગુ પડે છે?

ક્લાયન્ટ-સાઇડ લોડ બેલેન્સિંગ

HTTP એ એકમાત્ર પ્રોટોકોલ નથી કે જે સતત TCP કનેક્શનનો ઉપયોગ કરી શકે.

જો તમારી એપ્લિકેશન ડેટાબેઝનો ઉપયોગ કરે છે, તો દર વખતે જ્યારે તમારે ડેટાબેઝમાંથી કોઈ દસ્તાવેજ મેળવવાની અથવા વિનંતી કરવાની જરૂર હોય ત્યારે 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
AMQP

તમારે આમાંના મોટાભાગના પ્રોટોકોલ્સથી પહેલેથી જ પરિચિત હોવા જોઈએ.

પરંતુ જો આ પ્રોટોકોલ્સ એટલા લોકપ્રિય છે, તો શા માટે પ્રમાણિત સંતુલન ઉકેલ નથી? ક્લાયંટ તર્ક શા માટે બદલવાની જરૂર છે? શું ત્યાં કોઈ મૂળ કુબરનેટ્સ સોલ્યુશન છે?

Kube-proxy અને iptables એ Kubernetes માં જમાવટ કરતી વખતે સૌથી સામાન્ય ઉપયોગના કિસ્સાઓને આવરી લેવા માટે રચાયેલ છે. આ સુવિધા માટે છે.

જો તમે એવી વેબ સેવાનો ઉપયોગ કરી રહ્યાં છો જે REST API ને ઉજાગર કરે છે, તો તમે નસીબદાર છો - આ કિસ્સામાં, સતત TCP કનેક્શન્સનો ઉપયોગ થતો નથી, તમે કોઈપણ Kubernetes સેવાનો ઉપયોગ કરી શકો છો.

પરંતુ એકવાર તમે સતત TCP કનેક્શન્સનો ઉપયોગ કરવાનું શરૂ કરો, તમારે બેકએન્ડમાં લોડને સમાનરૂપે કેવી રીતે વિતરિત કરવું તે શોધવાનું રહેશે. કુબરનેટ્સમાં આ કેસ માટે તૈયાર સોલ્યુશન્સ નથી.

જો કે, ત્યાં ચોક્કસપણે વિકલ્પો છે જે મદદ કરી શકે છે.

Kubernetes માં લાંબા ગાળાના જોડાણોને સંતુલિત કરવું

કુબરનેટ્સમાં ચાર પ્રકારની સેવાઓ છે:

ક્લસ્ટરઆઈપી
નોડપોર્ટ
લોડબેલેન્સર
હેડલેસ

પ્રથમ ત્રણ સેવાઓ વર્ચ્યુઅલ IP એડ્રેસ પર આધારિત છે, જેનો ઉપયોગ iptables નિયમો બનાવવા માટે kube-proxy દ્વારા થાય છે. પરંતુ તમામ સેવાઓનો મૂળભૂત આધાર માથા વિનાની સેવા છે.

હેડલેસ સેવા તેની સાથે સંકળાયેલ કોઈ IP સરનામું ધરાવતું નથી અને માત્ર તેની સાથે સંકળાયેલા પોડ્સ (અંતિમ બિંદુઓ) ના IP સરનામાં અને પોર્ટ્સની સૂચિ પુનઃપ્રાપ્ત કરવા માટેની પદ્ધતિ પ્રદાન કરે છે.

તમામ સેવાઓ હેડલેસ સેવા પર આધારિત છે.

ClusterIP સેવા એ કેટલાક ઉમેરાઓ સાથે હેડલેસ સેવા છે:

મેનેજમેન્ટ લેયર તેને IP સરનામું સોંપે છે.
કુબે-પ્રોક્સી જરૂરી iptables નિયમો બનાવે છે.

આ રીતે તમે કુબે-પ્રોક્સીને અવગણી શકો છો અને તમારી એપ્લિકેશનને બેલેન્સ લોડ કરવા માટે હેડલેસ સેવામાંથી મેળવેલા અંતિમ બિંદુઓની સૂચિનો સીધો ઉપયોગ કરી શકો છો.

પરંતુ અમે ક્લસ્ટરમાં જમાવટ કરાયેલ તમામ એપ્લિકેશનોમાં સમાન તર્ક કેવી રીતે ઉમેરી શકીએ?

જો તમારી એપ્લિકેશન પહેલેથી જ તૈનાત છે, તો આ કાર્ય અશક્ય લાગે છે. જો કે, ત્યાં એક વૈકલ્પિક વિકલ્પ છે.

સર્વિસ મેશ તમને મદદ કરશે

તમે કદાચ પહેલેથી જ નોંધ્યું હશે કે ક્લાયંટ-સાઇડ લોડ બેલેન્સિંગ વ્યૂહરચના એકદમ પ્રમાણભૂત છે.

જ્યારે એપ્લિકેશન શરૂ થાય છે, ત્યારે તે:

સેવામાંથી IP સરનામાઓની સૂચિ મેળવે છે.
કનેક્શન પૂલ ખોલે છે અને જાળવે છે.
સમયાંતરે અંતિમ બિંદુઓ ઉમેરીને અથવા દૂર કરીને પૂલને અપડેટ કરે છે.

એકવાર એપ્લિકેશન વિનંતી કરવા માંગે છે, તે:

કેટલાક તર્કનો ઉપયોગ કરીને ઉપલબ્ધ કનેક્શન પસંદ કરે છે (દા.ત. રાઉન્ડ-રોબિન).
વિનંતીનો અમલ કરે છે.

આ પગલાં WebSockets, gRPC અને AMQP કનેક્શન બંને માટે કામ કરે છે.

તમે આ તર્કને અલગ લાઇબ્રેરીમાં અલગ કરી શકો છો અને તમારી એપ્લિકેશન્સમાં તેનો ઉપયોગ કરી શકો છો.

જો કે, તમે તેના બદલે Istio અથવા Linkerd જેવા સર્વિસ મેશનો ઉપયોગ કરી શકો છો.

સર્વિસ મેશ તમારી એપ્લિકેશનને એવી પ્રક્રિયા સાથે વધારે છે જે:

આપમેળે સેવા IP સરનામાઓ માટે શોધ કરે છે.
વેબસોકેટ્સ અને જીઆરપીસી જેવા જોડાણોની ચકાસણી કરે છે.
યોગ્ય પ્રોટોકોલનો ઉપયોગ કરીને વિનંતીઓને સંતુલિત કરે છે.

સર્વિસ મેશ ક્લસ્ટરની અંદર ટ્રાફિકનું સંચાલન કરવામાં મદદ કરે છે, પરંતુ તે તદ્દન સંસાધન-સઘન છે. અન્ય વિકલ્પો Netflix રિબન જેવી તૃતીય-પક્ષ લાઇબ્રેરીઓ અથવા Envoy જેવી પ્રોગ્રામેબલ પ્રોક્સીઓનો ઉપયોગ કરી રહ્યાં છે.

જો તમે સંતુલન મુદ્દાઓને અવગણશો તો શું થશે?

તમે લોડ બેલેન્સિંગનો ઉપયોગ ન કરવાનું પસંદ કરી શકો છો અને હજુ પણ કોઈપણ ફેરફારોની નોંધ લેતા નથી. ચાલો થોડા કામના દૃશ્યો જોઈએ.

જો તમારી પાસે સર્વર્સ કરતાં વધુ ગ્રાહકો છે, તો આ એટલી મોટી સમસ્યા નથી.

ચાલો કહીએ કે ત્યાં પાંચ ક્લાયન્ટ છે જે બે સર્વર સાથે જોડાય છે. જો ત્યાં કોઈ સંતુલન ન હોય તો પણ, બંને સર્વરનો ઉપયોગ કરવામાં આવશે:

કનેક્શન્સ સમાનરૂપે વિતરિત કરી શકાતા નથી: કદાચ ચાર ક્લાયંટ એક જ સર્વર સાથે જોડાયેલા છે, પરંતુ બંને સર્વરનો ઉપયોગ કરવામાં આવશે તેવી સારી તક છે.

શું વધુ સમસ્યારૂપ છે તે વિપરીત દૃશ્ય છે.

જો તમારી પાસે ઓછા ક્લાયન્ટ્સ અને વધુ સર્વર્સ હોય, તો તમારા સંસાધનોનો ઓછો ઉપયોગ થઈ શકે છે અને સંભવિત અડચણ દેખાશે.

ચાલો કહીએ કે ત્યાં બે ક્લાયન્ટ અને પાંચ સર્વર છે. શ્રેષ્ઠ કિસ્સામાં, પાંચમાંથી બે સર્વર સાથે બે કાયમી જોડાણ હશે.

બાકીના સર્વર્સ નિષ્ક્રિય રહેશે:

જો આ બે સર્વર્સ ક્લાયંટની વિનંતીઓને હેન્ડલ કરી શકતા નથી, તો આડી સ્કેલિંગ મદદ કરશે નહીં.

નિષ્કર્ષ

Kubernetes સેવાઓ મોટાભાગના પ્રમાણભૂત વેબ એપ્લિકેશન દૃશ્યોમાં કામ કરવા માટે રચાયેલ છે.

જો કે, એકવાર તમે એપ્લીકેશન પ્રોટોકોલ સાથે કામ કરવાનું શરૂ કરો કે જે સતત TCP કનેક્શનનો ઉપયોગ કરે છે, જેમ કે ડેટાબેસેસ, gRPC અથવા WebSockets, સેવાઓ હવે યોગ્ય રહેશે નહીં. કુબરનેટ્સ સતત TCP જોડાણોને સંતુલિત કરવા માટે આંતરિક પદ્ધતિઓ પ્રદાન કરતું નથી.

આનો અર્થ એ છે કે તમારે ક્લાયન્ટ-સાઇડ બેલેન્સિંગને ધ્યાનમાં રાખીને એપ્લિકેશન્સ લખવી આવશ્યક છે.

ટીમ દ્વારા તૈયાર કરવામાં આવેલ અનુવાદ Mail.ru માંથી કુબરનેટ્સ એએએસ.

વિષય પર બીજું શું વાંચવું:

સોર્સ: www.habr.com

Kubernetes માં લોડ બેલેન્સિંગ અને સ્કેલિંગ લાંબા ગાળાના જોડાણો