Kubernetes හි දිගුකාලීන සම්බන්ධතා පැටවීම තුලනය කිරීම සහ පරිමාණය කිරීම

මෙම ලිපිය ඔබට Kubernetes හි පැටවුම් තුලනය ක්‍රියා කරන ආකාරය, දිගුකාලීන සම්බන්ධතා පරිමාණය කිරීමේදී කුමක් සිදුවේද, සහ ඔබ HTTP/2, gRPC, RSockets, AMQP, හෝ වෙනත් දිගුකාලීන ප්‍රොටෝකෝල භාවිතා කරන්නේ නම් සේවාලාභී පාර්ශවීය තුලනය සලකා බැලිය යුත්තේ මන්ද යන්න තේරුම් ගැනීමට ඔබට උපකාර වනු ඇත. . 

Kubernetes හි ගමනාගමනය නැවත බෙදා හරින ආකාරය ගැන ටිකක් 

Kubernetes යෙදුම් යෙදවීම සඳහා පහසු සාරාංශ දෙකක් සපයයි: සේවා සහ යෙදවීම්.

ඕනෑම වේලාවක ඔබේ යෙදුමේ පිටපත් කීයක් ක්‍රියාත්මක විය යුතුද සහ කොපමණ ප්‍රමාණයක්ද යන්න යෙදවුම් විස්තර කරයි. සෑම යෙදුමක්ම Pod එකක් ලෙස යොදවා ඇති අතර IP ලිපිනයක් පවරනු ලැබේ.

සේවා බර බැලන්සර් එකකට ක්‍රියාකාරීව සමාන වේ. ඒවා විවිධ කරල් හරහා ගමනාගමනය බෙදා හැරීමට සැලසුම් කර ඇත.

අපි බලමු ඒක මොන වගේද කියලා.

1. පහත රූප සටහනේ ඔබට එකම යෙදුමේ අවස්ථා තුනක් සහ load balancer එකක් දැකිය හැක:

   

2. ලෝඩ් බැලන්සර් සේවාවක් ලෙස හඳුන්වන අතර IP ලිපිනයක් පවරනු ලැබේ. එන ඕනෑම ඉල්ලීමක් පොඩ් එකකට හරවා යවනු ලැබේ:

   

3. යෙදවීමේ අවස්ථාව යෙදුමේ අවස්ථා ගණන තීරණය කරයි. ඔබට කිසිදාක සෘජුවම පුළුල් කිරීමට සිදු නොවනු ඇත:

   

4. සෑම පොඩ් එකකටම තමන්ගේම IP ලිපිනයක් පවරනු ලැබේ:

   

සේවා යනු IP ලිපින එකතුවක් ලෙස සැලකීම ප්‍රයෝජනවත් වේ. ඔබ සේවාවට ප්‍රවේශ වන සෑම අවස්ථාවකම, ලැයිස්තුවෙන් IP ලිපින වලින් එකක් තෝරාගෙන ගමනාන්ත ලිපිනය ලෙස භාවිතා කරයි.

එය මේ ආකාරයෙන් පෙනේ.

1. Curl 10.96.45.152 ඉල්ලීමක් සේවාව වෙත ලැබේ:

   

2. සේවාව ගමනාන්තය ලෙස පොඩ් ලිපින තුනෙන් එකක් තෝරා ගනී:

   

3. ගමනාගමනය විශේෂිත පොඩ් එකකට හරවා යවනු ලැබේ:

   

ඔබගේ යෙදුම ඉදිරිපස සහ පසු අන්තයකින් සමන්විත නම්, එවිට ඔබට එක් එක් සඳහා සේවාවක් සහ යෙදවීමක් ඇත.

ඉදිරිපස කොටස පසු අන්තයට ඉල්ලීමක් කරන විට, එය පසුපෙළ කොපමණ කරල් කීයක් සපයන්නේද යන්න හරියටම දැන ගැනීමට අවශ්‍ය නොවේ: එකක්, දහයක් හෝ සියයක් තිබිය හැකිය.

ඒවගේම බැක්එන්ඩ් එකට සර්විස් කරන පොඩ්ස් වල ඇඩ්රස් ගැන ෆ්‍රෙන්ඩන්ඩ් එක මොකුත් දන්නේ නෑ.

ඉදිරිපස කොටස පසු අන්තයට ඉල්ලීමක් කරන විට, එය වෙනස් නොවන පසුපෙළ සේවාවේ IP ලිපිනය භාවිතා කරයි.

එය පෙනෙන්නේ මෙයයි.

1. 1 යටතේ අභ්‍යන්තර පසුබිම් සංරචකය ඉල්ලයි. පසුපෙළ සඳහා නිශ්චිත එකක් තෝරා ගැනීම වෙනුවට, එය සේවාවට ඉල්ලීමක් කරයි:

   

2. සේවාව ගමනාන්ත ලිපිනය ලෙස පසුපෙළ පොඩ් එකක් තෝරා ගනී:

   

3. සේවාව මගින් තෝරාගත් Pod 1 සිට Pod 5 දක්වා ගමනාගමනය යයි:

   

4. 1 යටතේ 5 යටතේ වැනි කරල් කීයක් සේවාව පිටුපස සැඟවී ඇත්දැයි හරියටම නොදනී:

   

නමුත් සේවාව හරියටම ඉල්ලීම් බෙදාහරින්නේ කෙසේද? රවුන්ඩ් රොබින් තුලනය භාවිතා කර ඇති බව පෙනේද? අපි එය තේරුම් ගනිමු. 

Kubernetes සේවා තුල තුලනය

Kubernetes සේවා නොපවතී. IP ලිපිනයක් සහ තොටක් පවරා ඇති සේවාව සඳහා ක්‍රියාවලියක් නොමැත.

පොකුරේ ඇති ඕනෑම නෝඩයකට ලොග් වී netstat -ntlp විධානය ක්‍රියාත්මක කිරීමෙන් ඔබට මෙය සත්‍යාපනය කළ හැක.

සේවාව සඳහා වෙන් කර ඇති IP ලිපිනය සොයා ගැනීමට පවා ඔබට නොහැකි වනු ඇත.

සේවාවේ IP ලිපිනය පාලක ස්ථරයේ, පාලකයේ පිහිටා ඇති අතර දත්ත ගබඩාවේ සටහන් කර ඇත - etc. එම ලිපිනයම වෙනත් සංරචකයක් භාවිතා කරයි - 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%ක සම්භාවිතාවක් සහිතව තෝරා ගනු ලැබේ.

තවද Pod 2 ට පසුව Pod 1 තෝරා ගන්නා බවට සහතිකයක් නොමැත.

අදහස් දැක්වීම්: iptables අහඹු ව්‍යාප්තිය සහිත සංඛ්‍යාන මොඩියුලයක් භාවිතා කරයි. මේ අනුව, තුලන ඇල්ගොරිතම අහඹු තේරීම මත පදනම් වේ.

සේවා ක්‍රියාත්මක වන ආකාරය දැන් ඔබට වැටහෙන නිසා, අපි වඩාත් රසවත් සේවා අවස්ථා දෙස බලමු.

Kubernetes හි දිගුකාලීන සම්බන්ධතා පෙරනිමියෙන් පරිමාණය නොවේ

ඉදිරිපස සිට පසු අන්තය දක්වා සෑම HTTP ඉල්ලීමක්ම වෙනම TCP සම්බන්ධතාවයක් මගින් සපයනු ලැබේ, එය විවෘත කර වසා ඇත.

ඉදිරිපසින් තත්පරයකට ඉල්ලීම් 100ක් පසු අන්තයට යවන්නේ නම්, විවිධ TCP සම්බන්ධතා 100ක් විවෘත කර වසා දමනු ලැබේ.

ඔබට එක් TCP සම්බන්ධතාවයක් විවෘත කිරීමෙන් සහ පසුව ලැබෙන සියලුම HTTP ඉල්ලීම් සඳහා එය භාවිතා කිරීමෙන් ඉල්ලීම් සැකසීමේ කාලය සහ පැටවීම අඩු කළ හැක.

HTTP ප්‍රොටෝකෝලයෙහි HTTP Keep-alive, හෝ සම්බන්ධතා නැවත භාවිතා කිරීම නමින් විශේෂාංගයක් ඇත. මෙම අවස්ථාවේදී, බහු HTTP ඉල්ලීම් සහ ප්‍රතිචාර යැවීමට සහ ලැබීමට තනි TCP සම්බන්ධතාවයක් භාවිතා කරයි:

මෙම විශේෂාංගය පෙරනිමියෙන් සක්‍රීය කර නැත: සේවාදායකය සහ සේවාලාභියා යන දෙකම ඒ අනුව වින්‍යාස කළ යුතුය.

සැකසුම සරල වන අතර බොහෝ ක්‍රමලේඛන භාෂා සහ පරිසරයන් සඳහා ප්‍රවේශ විය හැකිය.

විවිධ භාෂාවලින් උදාහරණ සඳහා සබැඳි කිහිපයක් මෙන්න:

• Node.js හි සජීවීව තබා ගන්න
• ස්ප්‍රින්ග් බූට් එකේ ජීවමානව තබා ගන්න
• පයිතන් හි ජීවමානව තබා ගන්න
• .NET හි ජීවමානව තබා ගන්න

අපි Kubernetes සේවාවක Keep-alive භාවිතා කළහොත් කුමක් සිදුවේද?
අපි හිතමු ඉදිරිපස සහ පසුපෙළ යන දෙකම තබා ගැනීමට සහය දක්වයි කියා.

අප සතුව ඉදිරිපස එක් පිටපතක් සහ පසුපෙළේ පිටපත් තුනක් ඇත. ඉදිරිපස කොටස පළමු ඉල්ලීම සිදු කරන අතර පසු අන්තයට TCP සම්බන්ධතාවයක් විවෘත කරයි. ඉල්ලීම සේවාව වෙත ළඟා වේ, ගමනාන්ත ලිපිනය ලෙස පසුපෙළ පොඩ් එකක් තෝරා ඇත. පසුපෙළ ප්‍රතිචාරයක් යවන අතර ඉදිරිපසින් එය ලැබේ.

ප්‍රතිචාරයක් ලැබීමෙන් පසු TCP සම්බන්ධතාවය වසා ඇති සාමාන්‍ය තත්වය මෙන් නොව, එය තවදුරටත් HTTP ඉල්ලීම් සඳහා විවෘතව තබා ඇත.

frontend එක backend එකට වැඩිපුර requests යැව්වොත් මොකද වෙන්නේ?

මෙම ඉල්ලීම් ඉදිරිපත් කිරීමට, විවෘත TCP සම්බන්ධතාවයක් භාවිතා කරනු ඇත, සියලු ඉල්ලීම් පළමු ඉල්ලීම ගිය පසුපෙළට යයි.

iptables ගමනාගමනය නැවත බෙදා හැරිය යුතු නොවේද?

මෙම නඩුවේ නොවේ.

TCP සම්බන්ධතාවයක් සාදන විට, එය iptables නීති හරහා ගමන් කරයි, එමඟින් ගමනාගමනය යන නිශ්චිත පසුබිමක් තෝරා ගනී.

සියලුම පසු ඉල්ලීම් දැනටමත් විවෘතව ඇති TCP සම්බන්ධතාවයක පවතින බැවින්, iptables රීති තවදුරටත් කැඳවනු නොලැබේ.

අපි බලමු ඒක මොන වගේද කියලා.

1. පළමු පොඩ් සේවාව වෙත ඉල්ලීමක් යවයි:

   

2. ඊළඟට කුමක් සිදුවේදැයි ඔබ දැනටමත් දන්නවා. සේවාව නොපවතී, නමුත් ඉල්ලීම සකස් කරන iptables නීති තිබේ:

   

3. ගමනාන්ත ලිපිනය ලෙස පසුපෙළ පොඩ් එකක් තෝරා ගනු ඇත:

   

4. ඉල්ලීම පෝඩ් වෙත ළඟා වේ. මෙම අවස්ථාවේදී, කරල් දෙක අතර ස්ථීර TCP සම්බන්ධතාවයක් ස්ථාපිත වනු ඇත:

   

5. පළමු පොඩ් එකෙන් පසු ඕනෑම ඉල්ලීමක් දැනටමත් ස්ථාපිත සම්බන්ධතාවය හරහා යයි:

   

ප්‍රතිඵලය වේගවත් ප්‍රතිචාර කාලය සහ ඉහළ ප්‍රතිදානය, නමුත් ඔබට පසුපෙළ පරිමාණය කිරීමේ හැකියාව අහිමි වේ.

බැක්එන්ඩ් එකේ පොඩ් දෙකක් තිබ්බත් ස්ථීර සම්භන්ධයකින් ට් රැෆික් එක හැමදාම යනවා.

මෙය නිවැරදි කළ හැකිද?

අඛණ්ඩ සම්බන්ධතා සමතුලිත කරන්නේ කෙසේදැයි Kubernetes නොදන්නා බැවින්, මෙම කාර්යය ඔබ වෙත පැවරේ.

සේවා යනු අන්ත ලක්ෂ්‍ය ලෙස හැඳින්වෙන IP ලිපින සහ වරායන් එකතුවකි.

ඔබගේ යෙදුමට සේවාවෙන් අන්ත ලක්ෂ්‍ය ලැයිස්තුවක් ලබා ගත හැකි අතර ඒවා අතර ඉල්ලීම් බෙදා හරින ආකාරය තීරණය කළ හැක. ඔබට රවුන්ඩ් රොබින් භාවිතයෙන් සෑම පොඩ් එකකටම ස්ථීර සම්බන්ධතාවයක් විවෘත කර මෙම සම්බන්ධතා අතර ඉල්ලීම් සමතුලිත කළ හැක.

නැතහොත් තවත් අයදුම් කරන්න සංකීර්ණ තුලන ඇල්ගොරිතම.

සමතුලිත කිරීම සඳහා වගකිව යුතු සේවාලාභී පාර්ශවීය කේතය මෙම තර්කය අනුගමනය කළ යුතුය:

1. සේවාවෙන් අවසන් ස්ථාන ලැයිස්තුවක් ලබා ගන්න.
2. එක් එක් අන්ත ලක්ෂ්‍යය සඳහා ස්ථීර සම්බන්ධතාවයක් විවෘත කරන්න.
3. ඉල්ලීමක් කළ යුතු විට, විවෘත සම්බන්ධතා වලින් එකක් භාවිතා කරන්න.
4. අන්ත ලක්ෂ්‍ය ලැයිස්තුව නිතිපතා යාවත්කාලීන කරන්න, නව ඒවා සාදන්න හෝ ලැයිස්තුව වෙනස් වුවහොත් පැරණි අඛණ්ඩ සම්බන්ධතා වසා දමන්න.

එය පෙනෙන්නේ මෙයයි.

1. සේවාව වෙත ඉල්ලීම යැවීමේ පළමු පොඩ් වෙනුවට, ඔබට සේවාලාභියාගේ පැත්තෙන් ඉල්ලීම් සමතුලිත කළ හැක:

   

2. ඔබ සේවාවේ කොටසක් වන්නේ කුමන කරල්දැයි අසන කේතය ලිවිය යුතුය:

   

3. ඔබට ලැයිස්තුව ලැබුණු පසු, එය සේවාදායක පැත්තේ සුරකින්න සහ කරල් වලට සම්බන්ධ වීමට එය භාවිතා කරන්න:

   

4. බර තුලනය කිරීමේ ඇල්ගොරිතම සඳහා ඔබ වගකිව යුතුය:

   

දැන් ප්රශ්නය පැනනගින්නේ: මෙම ගැටළුව 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 සම්බන්ධතා භාවිතා කරන තවත් බොහෝ ප්‍රොටෝකෝල තිබේ:

• WebSockets සහ ආරක්ෂිත WebSockets
• HTTP / 2
• gRPC
• RSockets
• AMQP

ඔබ දැනටමත් මෙම ප්‍රොටෝකෝල බොහොමයක් ගැන හුරුපුරුදු විය යුතුය.

නමුත් මෙම ප්‍රොටෝකෝල එතරම් ජනප්‍රිය නම්, ප්‍රමිතිගත සමතුලිත විසඳුමක් නැත්තේ ඇයි? සේවාදායක තර්කනය වෙනස් කළ යුත්තේ ඇයි? දේශීය Kubernetes විසඳුමක් තිබේද?

Kube-proxy සහ iptables නිර්මාණය කර ඇත්තේ Kubernetes වෙත යෙදවීමේදී බහුලව භාවිතා වන අවස්ථා ආවරණය කිරීමටය. මෙය පහසුව සඳහා ය.

ඔබ REST API නිරාවරණය කරන වෙබ් සේවාවක් භාවිතා කරන්නේ නම්, ඔබ වාසනාවන්තයි - මෙම අවස්ථාවේදී, ස්ථීර TCP සම්බන්ධතා භාවිතා නොකෙරේ, ඔබට ඕනෑම Kubernetes සේවාවක් භාවිතා කළ හැක.

නමුත් ඔබ ස්ථීර TCP සම්බන්ධතා භාවිතා කිරීමට පටන් ගත් පසු, පසුපෙළ හරහා බර ඒකාකාරව බෙදා හරින ආකාරය සොයා ගැනීමට ඔබට සිදුවේ. Kubernetes මෙම නඩුව සඳහා සූදානම් කළ විසඳුම් අඩංගු නොවේ.

කෙසේ වෙතත්, නිසැකවම උපකාර කළ හැකි විකල්ප තිබේ.

Kubernetes හි දිගුකාලීන සම්බන්ධතා සමතුලිත කිරීම

Kubernetes හි සේවා වර්ග හතරක් ඇත:

1. ClusterIP
2. NodePort
3. LoadBalancer
4. හිස නැති

පළමු සේවා තුන ක්‍රියාත්මක වන්නේ අතථ්‍ය IP ලිපිනයක් මත වන අතර එය 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 වැනි සේවා දැල් භාවිතා කළ හැක.

Service Mesh ඔබේ යෙදුම ක්‍රියාවලියක් සමඟින් වැඩි කරයි:

1. සේවා IP ලිපින සඳහා ස්වයංක්‍රීයව සොයයි.
2. WebSockets සහ gRPC වැනි සම්බන්ධතා පරීක්ෂා කරයි.
3. නිවැරදි ප්‍රොටෝකෝලය භාවිතයෙන් ඉල්ලීම් සමතුලිත කරයි.

Service Mesh පොකුර තුළ ගමනාගමනය කළමනාකරණය කිරීමට උපකාරී වේ, නමුත් එය බෙහෙවින් සම්පත්-අධික වේ. වෙනත් විකල්ප වන්නේ Netflix Ribbon වැනි තෙවන පාර්ශවීය පුස්තකාල හෝ Envoy වැනි වැඩසටහන්ගත කළ හැකි ප්‍රොක්සි භාවිතා කිරීමයි.

ඔබ සමතුලිත ගැටළු නොසලකා හැරියහොත් කුමක් සිදුවේද?

ඔබට බර තුලනය භාවිතා නොකිරීමට තෝරා ගත හැකි අතර තවමත් කිසිදු වෙනසක් නොදකියි. අපි වැඩ අවස්ථා කිහිපයක් බලමු.

ඔබට සේවාදායකයන්ට වඩා සේවාදායකයින් සිටී නම්, මෙය එතරම් විශාල ගැටළුවක් නොවේ.

සේවාදායකයන් දෙකකට සම්බන්ධ වන සේවාදායකයින් පහක් ඇතැයි සිතමු. සමතුලිතතාවයක් නොමැති වුවද, සේවාදායකයන් දෙකම භාවිතා කරනු ඇත:

සම්බන්ධතා ඒකාකාරව බෙදා හැරිය නොහැක: සමහර විට සේවාදායකයන් හතරක් එකම සේවාදායකයට සම්බන්ධ වී ඇත, නමුත් සේවාදායකයන් දෙකම භාවිතා කිරීමට හොඳ අවස්ථාවක් තිබේ.

වඩාත් ගැටලුකාරී වන්නේ ප්රතිවිරුද්ධ අවස්ථාවයි.

ඔබට අඩු සේවාලාභීන් සහ වැඩි සේවාදායක තිබේ නම්, ඔබේ සම්පත් අඩුවෙන් භාවිත කළ හැකි අතර විභව බාධකයක් දිස්වනු ඇත.

අපි හිතමු ක්ලයන්ට්ලා දෙන්නයි සර්වර් පහයි කියලා. හොඳම අවස්ථාවෙහිදී, සේවාදායක පහෙන් දෙකකට ස්ථිර සම්බන්ධතා දෙකක් ඇත.

ඉතිරි සේවාදායකයන් අක්‍රිය වනු ඇත:

මෙම සේවාදායකයන් දෙකට සේවාලාභී ඉල්ලීම් හැසිරවිය නොහැකි නම්, තිරස් පරිමාණය උදව් නොවනු ඇත.

නිගමනය

Kubernetes සේවාවන් බොහෝ සම්මත වෙබ් යෙදුම් අවස්ථා වල වැඩ කිරීමට සැලසුම් කර ඇත.

කෙසේ වෙතත්, ඔබ දත්ත සමුදායන්, gRPC හෝ WebSockets වැනි ස්ථීර TCP සම්බන්ධතා භාවිතා කරන යෙදුම් ප්‍රොටෝකෝල සමඟ වැඩ කිරීමට පටන් ගත් පසු, සේවා තවදුරටත් සුදුසු නොවේ. ස්ථීර TCP සම්බන්ධතා සමතුලිත කිරීම සඳහා Kubernetes අභ්‍යන්තර යාන්ත්‍රණ සපයන්නේ නැත.

මෙයින් අදහස් කරන්නේ ඔබ සේවාලාභියා-පාර්ශවීය තුලනය මනසේ තබාගෙන යෙදුම් ලිවිය යුතු බවයි.

කණ්ඩායම විසින් සකස් කරන ලද පරිවර්තනය Mail.ru වෙතින් Kubernetes aaS.

මාතෘකාව පිළිබඳ තවත් කියවිය යුතු දේ:

1. Kubernetes හි ස්වයං පරිමාණය කිරීමේ මට්ටම් තුනක් සහ ඒවා ඵලදායී ලෙස භාවිතා කරන්නේ කෙසේද. 
2. ක්‍රියාත්මක කිරීම සඳහා අච්චුවක් සමඟ මුහුදු කොල්ලකෑමේ ආත්මය තුළ Kubernetes.
3. ඩිජිටල් පරිවර්තනය පිළිබඳ අපගේ ටෙලිග්‍රාම් නාලිකාව.

මූලාශ්රය: www.habr.com