සටහන. පරිවර්තනය.: ලෝක ප්‍රසිද්ධ ටින්ඩර් සේවාවේ සේවකයින් මෑතකදී ඔවුන්ගේ යටිතල පහසුකම් Kubernetes වෙත සංක්‍රමණය කිරීමේ තාක්ෂණික තොරතුරු කිහිපයක් බෙදා ගත්හ. මෙම ක්රියාවලිය වසර දෙකකට ආසන්න කාලයක් ගත වූ අතර, බහාලුම් 8 දහසක් මත සත්කාරක සේවා 200 කින් සමන්විත K48s මත ඉතා විශාල පරිමාණ වේදිකාවක් දියත් කිරීමට හේතු විය. ටින්ඩර් ඉංජිනේරුවන් මුහුණ දුන් සිත්ගන්නා දුෂ්කරතා මොනවාද සහ ඔවුන් පැමිණි ප්රතිඵල මොනවාද?මෙම පරිවර්තනය කියවන්න.
ඇයි?
වසර දෙකකට පමණ පෙර, Tinder සිය වේදිකාව Kubernetes වෙත ගෙන යාමට තීරණය කළේය. Kubernetes Tinder කණ්ඩායමට වෙනස් කළ නොහැකි යෙදවීම හරහා අවම උත්සාහයකින් බහාලුම් කිරීමට සහ නිෂ්පාදනයට යාමට ඉඩ සලසයි. (වෙනස් කළ නොහැකි යෙදවීම). මෙම අවස්ථාවෙහිදී, යෙදුම් එකලස් කිරීම, ඒවා යෙදවීම සහ යටිතල පහසුකම් කේතය මගින් අනන්‍ය ලෙස නිර්වචනය කරනු ලැබේ.
පරිමාණය සහ ස්ථාවරත්වය පිළිබඳ ගැටලුවට ද අපි විසඳුමක් සොයමින් සිටියෙමු. පරිමාණය තීරණාත්මක වූ විට, අපට බොහෝ විට නව EC2 අවස්ථා භ්‍රමණය වීමට මිනිත්තු කිහිපයක් බලා සිටීමට සිදු විය. බහාලුම් දියත් කිරීම සහ මිනිත්තු වෙනුවට තත්පර කිහිපයකින් ගමනාගමනය ආරම්භ කිරීමේ අදහස අපට ඉතා ආකර්ශනීය විය.
ක්රියාවලිය දුෂ්කර විය. 2019 මුල් භාගයේදී අපගේ සංක්‍රමණය අතරතුර, Kubernetes පොකුර තීරණාත්මක ස්කන්ධයකට ළඟා වූ අතර රථවාහන පරිමාව, පොකුරු ප්රමාණය සහ DNS හේතුවෙන් අපට විවිධ ගැටළු වලට මුහුණ දීමට පටන් ගත්තේය. අතරමගදී, අපි සේවා 200 ක් සංක්‍රමණය කිරීම සහ නෝඩ් 1000 ක්, කරල් 15000 ක් සහ ධාවන බහාලුම් 48000 කින් සමන්විත Kubernetes පොකුරක් පවත්වාගෙන යාම සම්බන්ධ රසවත් ගැටලු රාශියක් විසඳා ගත්තෙමු.
කොහොමද?
2018 ජනවාරි මාසයේ සිට අපි සංක්‍රමණයේ විවිධ අවධීන් පසුකර ඇත්තෙමු. අපි ආරම්භ කළේ අපගේ සියලුම සේවාවන් බහාලුම් කර ඒවා Kubernetes පරීක්ෂණ වලාකුළු පරිසරයන් වෙත යෙදවීමෙනි. ඔක්තෝම්බර් මාසයේ සිට, අපි දැනට පවතින සියලුම සේවාවන් ක්‍රමානුකූලව Kubernetes වෙත සංක්‍රමණය කිරීමට පටන් ගත්තෙමු. ඊළඟ වසරේ මාර්තු වන විට, අපි සංක්‍රමණය සම්පූර්ණ කළ අතර දැන් Tinder වේදිකාව තනිකරම Kubernetes මත ධාවනය වේ.
Kubernetes සඳහා රූප ගොඩනැගීම
අපට Kubernetes පොකුරක් මත ක්‍රියාත්මක වන ක්ෂුද්‍ර සේවා සඳහා ප්‍රභව කේත ගබඩා 30කට වඩා තිබේ. මෙම ගබඩාවල ඇති කේතය එකම භාෂාව සඳහා බහු ධාවන පරිසරයන් සමඟ විවිධ භාෂාවලින් (උදාහරණයක් ලෙස, Node.js, Java, Scala, Go) ලියා ඇත.
ගොඩනැගීම් පද්ධතිය සැලසුම් කර ඇත්තේ එක් එක් ක්ෂුද්‍ර සේවා සඳහා සම්පූර්ණයෙන්ම අභිරුචිකරණය කළ හැකි “ගොඩනැඟීමේ සන්දර්භය” සැපයීම සඳහා ය. එය සාමාන්‍යයෙන් Dockerfile එකකින් සහ shell විධාන ලැයිස්තුවකින් සමන්විත වේ. ඒවායේ අන්තර්ගතය සම්පූර්ණයෙන්ම අභිරුචිකරණය කළ හැකි අතර, ඒ සමඟම, මෙම සියලු ගොඩනැගීමේ සන්දර්භයන් සම්මත ආකෘතියකට අනුව ලියා ඇත. ගොඩනැගීමේ සන්දර්භයන් ප්‍රමිතිගත කිරීම එක් තනි ගොඩනැගීමේ පද්ධතියකට සියලුම ක්ෂුද්‍ර සේවා හැසිරවීමට ඉඩ සලසයි.
රූපය 1-1. Builder බහාලුම් හරහා සම්මත ගොඩනැගීමේ ක්රියාවලිය
ධාවන කාල අතර උපරිම අනුකූලතාවයක් ලබා ගැනීමට (ධාවන කාල පරිසරයන්) සංවර්ධනය සහ පරීක්ෂා කිරීමේදී එකම ගොඩනැගීමේ ක්රියාවලිය භාවිතා වේ. අපි ඉතා සිත්ගන්නා අභියෝගයකට මුහුණ දුන්නෙමු: සමස්ත වේදිකාව හරහා ගොඩනඟන පරිසරයේ අනුකූලතාව සහතික කිරීම සඳහා අපට මාර්ගයක් වර්ධනය කිරීමට සිදු විය. මෙය සාක්ෂාත් කර ගැනීම සඳහා, සියලුම එකලස් කිරීමේ ක්රියාවලීන් විශේෂ බහාලුමක් තුළ සිදු කරනු ලැබේ. Builder.
ඔහුගේ බහාලුම් ක්‍රියාත්මක කිරීම සඳහා උසස් ඩොකර් ශිල්පීය ක්‍රම අවශ්ය විය. පුද්ගලික Tinder ගබඩා වෙත ප්‍රවේශ වීමට අවශ්ය දේශීය පරිශීලක හැඳුනුම්පත සහ රහස් (SSH යතුර, AWS අක්තපත්‍ර, ආදිය) Builder හට උරුම වේ. එය ස්වභාවිකව ගොඩනඟන පුරාවස්තු ගබඩා කිරීම සඳහා මූලාශ්‍ර අඩංගු දේශීය නාමාවලි සවි කරයි. මෙම ප්රවේශය කාර්ය සාධනය වැඩි දියුණු කරයි, මන්ද එය Builder කන්ටේනරය සහ ධාරකය අතර ගොඩනැගීමේ පුරාවස්තු පිටපත් කිරීමේ අවශ්‍යතාවය ඉවත් කරයි. අමතර වින්‍යාසයකින් තොරව ගබඩා කර ඇති ගොඩනඟන කෞතුක වස්තු නැවත භාවිතා කළ හැක.
සමහර සේවාවන් සඳහා, සම්පාදන පරිසරය ධාවන කාල පරිසරයට සිතියම්ගත කිරීමට අපට වෙනත් බහාලුමක් නිර්මාණය කිරීමට සිදු විය (උදාහරණයක් ලෙස, Node.js bcrypt පුස්තකාලය ස්ථාපනය අතරතුර වේදිකාවට විශේෂිත ද්විමය පුරාවස්තු ජනනය කරයි). සම්පාදන ක්‍රියාවලියේදී, සේවා අතර අවශ්‍යතා වෙනස් විය හැකි අතර අවසාන ඩොකර් ගොනුව පියාසර කරන විට සම්පාදනය කෙරේ.
Kubernetes පොකුරු ගෘහ නිර්මාණ ශිල්පය සහ සංක්‍රමණය
පොකුරු ප්රමාණය කළමනාකරණය
අපි භාවිතා කිරීමට තීරණය කළා kube-aws Amazon EC2 අවස්ථා මත ස්වයංක්‍රීය පොකුරු යෙදවීම සඳහා. ආරම්භයේදීම, සෑම දෙයක්ම එක් පොදු නෝඩ් සංචිතයක වැඩ කළේය. සම්පත් වඩාත් කාර්යක්ෂමව භාවිතා කිරීම සඳහා ප්‍රමාණයෙන් සහ අවස්ථා වර්ගය අනුව වැඩ බර වෙන් කිරීමේ අවශ්‍යතාවය අපි ඉක්මනින් අවබෝධ කර ගත්තෙමු. තර්කය වූයේ පටවන ලද බහු-නූල් කරල් කිහිපයක් ධාවනය කිරීම තනි නූල් විශාල සංඛ්‍යාවක් සමඟ ඔවුන්ගේ සහජීවනයට වඩා කාර්ය සාධනය අනුව වඩාත් පුරෝකථනය කළ හැකි දෙයක් බවට පත් වීමයි.
අවසානයේදී අපි තීරණය කළේ:
- m5.4x විශාලයි - අධීක්ෂණය සඳහා (Prometheus);
- c5.4x විශාලයි - Node.js වැඩ බර සඳහා (තනි නූල් වැඩ බර);
- c5.2x විශාලයි - ජාවා සහ ගෝ සඳහා (බහු නූල් සහිත වැඩ බර);
- c5.4x විශාලයි - පාලක පැනලය සඳහා (3 නෝඩ්).
සංක්‍රමණය
පැරණි යටිතල ව්‍යුහයෙන් Kubernetes වෙත සංක්‍රමණය වීම සඳහා වූ එක් සූදානම් කිරීමේ පියවරක් වූයේ සේවා අතර පවතින සෘජු සන්නිවේදනය නව load balancers (Elastic Load Balances (ELB) වෙත හරවා යැවීමයි. ඒවා නිර්මාණය කර ඇත්තේ අතථ්‍ය පුද්ගලික වලාකුළක (VPC) නිශ්චිත උප ජාලයක් මත ය. මෙම උපජාලය Kubernetes VPC වෙත සම්බන්ධ කර ඇත. විශේෂිත සේවා පරායත්තතා අනුපිළිවෙල සැලකිල්ලට නොගෙන ක්‍රමයෙන් මොඩියුල සංක්‍රමණය කිරීමට මෙය අපට ඉඩ සලසයි.
මෙම අන්ත ලක්ෂ්‍ය නිර්මාණය කර ඇත්තේ එක් එක් නව ELB වෙත යොමු වන CNAMEs ඇති DNS වාර්තා වල බරිත කට්ටල භාවිතා කරමිනි. මාරු කිරීම සඳහා, අපි Kubernetes සේවාවේ නව ELB වෙත බර 0ක් සමඟින් නව ප්‍රවේශයක් එක් කළෙමු. පසුව අපි ප්‍රවේශයේ වේලාව (TTL) 0 ලෙස සකස් කළෙමු. මෙයින් පසු, පැරණි සහ නව බර සෙමින් සකස් කරන ලද අතර, අවසානයේදී 100% බර නව සේවාදායකයකට යවන ලදී. මාරු කිරීම අවසන් වූ පසු, TTL අගය වඩාත් ප්රමාණවත් මට්ටමකට ආපසු ගියේය.
අප සතුව තිබූ ජාවා මොඩියුල අඩු TTL DNS සමඟ සාර්ථකව කටයුතු කළ හැකි නමුත් Node යෙදුම් වලට නොහැකි විය. එක් ඉංජිනේරුවෙක් සම්බන්ධතා සංචිත කේතයේ කොටසක් නැවත ලියා සෑම තත්පර 60 කට වරක් තටාක යාවත්කාලීන කරන කළමනාකරුවෙකු තුළ එය ඔතා ඇත. තෝරාගත් ප්රවේශය ඉතා හොඳින් ක්‍රියාත්මක වූ අතර සැලකිය යුතු කාර්ය සාධන පිරිහීමකින් තොරව ක්‍රියාත්මක විය.
පාඩම්
ජාල රෙදි වල සීමාවන්
8 ජනවාරි 2019 වන දින හිමිදිරි උදෑසන ටින්ඩර් වේදිකාව අනපේක්ෂිත ලෙස කඩා වැටුණි. එදින උදෑසන වේදිකා ප්‍රමාදයේ අසම්බන්ධිත වැඩිවීමකට ප්‍රතිචාර වශයෙන්, පොකුරේ ඇති කරල් සහ නෝඩ් ගණන වැඩි විය. මෙය අපගේ සියලුම නෝඩ් වල ARP හැඹිලිය අවසන් වීමට හේතු විය.
ARP හැඹිලියට සම්බන්ධ Linux විකල්ප තුනක් තිබේ:
()
gc_thresh3 - මෙය දුෂ්කර සීමාවකි. ලඝු-සටහනේ "අසල්වැසි වගු පිටාර ගැලීම" ඇතුළත් කිරීම් පෙනුමෙන් අදහස් කළේ සමමුහුර්ත කසළ එකතු කිරීමෙන් (GC) පසුව පවා, ARP හැඹිලියේ අසල්වැසි ප්රවේශය ගබඩා කිරීමට ප්රමාණවත් ඉඩක් නොමැති බවයි. මෙම අවස්ථාවේදී, කර්නලය හුදෙක් පැකට්ටුව සම්පූර්ණයෙන්ම ඉවත දමනු ලැබේ.
අපි පාවිච්චි කරන්නේ Kubernetes හි ජාල රෙදි ලෙස. පැකට් VXLAN හරහා සම්ප්‍රේෂණය වේ. VXLAN යනු L2 ජාලයක් මතින් මතුකර ඇති L3 උමගකි. තාක්ෂණය MAC-in-UDP (MAC Address-in-User Datagram Protocol) සංග්‍රහය භාවිතා කරන අතර ස්ථර 2 ජාල කොටස් පුළුල් කිරීමට ඉඩ සලසයි. භෞතික දත්ත මධ්‍යස්ථාන ජාලයේ ප්‍රවාහන ප්‍රොටෝකෝලය IP සහ UDP වේ.
රූපය 2-1. ෆ්ලැනල් රූප සටහන ()
රූපය 2-2. VXLAN පැකේජය ()
සෑම Kubernetes සේවක නෝඩයක්ම විශාල /24 බ්ලොක් එකකින් /9 ආවරණයක් සහිත අතථ්‍ය ලිපින ඉඩක් වෙන් කරයි. එක් එක් නෝඩ් සඳහා මෙය වේ මාර්ගගත කිරීමේ වගුවේ එක් ප්‍රවේශයක්, ARP වගුවේ එක් ප්‍රවේශයක් (flannel.1 අතුරුමුහුණත මත), සහ මාරු කිරීමේ වගුවේ එක් ප්‍රවේශයක් (FDB). පළමු වරට සේවක නෝඩයක් ආරම්භ වූ විට හෝ නව නෝඩයක් සොයා ගන්නා සෑම අවස්ථාවකම ඒවා එකතු කරනු ලැබේ.
අතිරේකව, node-pod (හෝ pod-pod) සන්නිවේදනය අවසානයේ අතුරු මුහුණත හරහා ගමන් කරයි eth0 (ඉහත Flannel රූප සටහනේ පෙන්වා ඇති පරිදි). මෙහි ප්‍රතිඵලය වන්නේ එක් එක් අනුරූප මූලාශ්‍ර සහ ගමනාන්ත ධාරකය සඳහා ARP වගුවෙහි අතිරේක ප්‍රවේශයකි.
අපේ පරිසරය තුළ, මෙම ආකාරයේ සන්නිවේදනය ඉතා සුලභ ය. Kubernetes හි සේවා වස්තු සඳහා, ELB සාදනු ලබන අතර Kubernetes සෑම node එකක්ම ELB සමඟ ලියාපදිංචි කරයි. ELB කරල් ගැන කිසිවක් නොදන්නා අතර තෝරාගත් නෝඩය පැකට්ටුවේ අවසාන ගමනාන්තය නොවිය හැක. කාරණය නම්, නෝඩයකට ELB වෙතින් පැකට්ටුවක් ලැබුණු විට, එය නීති රීති සැලකිල්ලට ගනිමින් එය සලකයි. iptables නිශ්චිත සේවාවක් සඳහා සහ අහඹු ලෙස වෙනත් නෝඩයක පොඩ් එකක් තෝරා ගනී.
අසාර්ථක වූ අවස්ථාවේදී, පොකුරේ නෝඩ් 605 ක් විය. ඉහත සඳහන් කළ හේතු නිසා, වැදගත්කම මඟහරවා ගැනීමට මෙය ප්රමාණවත් විය gc_thresh3, පෙරනිමිය වන. මෙය සිදු වූ විට, පැකට් වැටීමට පටන් ගන්නවා පමණක් නොව, /24 ආවරණයක් සහිත සම්පූර්ණ Flannel අතථ්‍ය ලිපින අවකාශය ARP වගුවෙන් අතුරුදහන් වේ. නෝඩ්-පොඩ් සන්නිවේදනය සහ ඩීඑන්එස් විමසුම් බාධා ඇත (ඩීඑන්එස් පොකුරක් තුළ සත්කාරකත්වය සපයයි; විස්තර සඳහා මෙම ලිපියෙන් පසුව කියවන්න).
මෙම ගැටළුව විසඳීම සඳහා, ඔබ අගයන් වැඩි කළ යුතුය gc_thresh1, gc_thresh2 и gc_thresh3 සහ නැතිවූ ජාල නැවත ලියාපදිංචි කිරීමට Flannel නැවත ආරම්භ කරන්න.
අනපේක්ෂිත DNS පරිමාණය
සංක්‍රමණ ක්‍රියාවලියේදී, අපි රථවාහන කළමනාකරණය කිරීමට සහ ක්‍රමානුකූලව පැරණි යටිතල ව්‍යුහයේ සිට Kubernetes වෙත සේවා මාරු කිරීමට DNS ක්‍රියාකාරීව භාවිතා කළෙමු. අපි Route53 හි ආශ්‍රිත RecordSets සඳහා සාපේක්ෂව අඩු TTL අගයන් සකස් කරමු. පැරණි යටිතල පහසුකම් EC2 අවස්ථා මත ක්‍රියාත්මක වන විට, අපගේ විසඳුම් වින්‍යාසය Amazon DNS වෙත යොමු විය. අපි මෙය සුළු කොට තැබූ අතර අපගේ සේවාවන්ට සහ Amazon සේවාවන්ට (DynamoDB වැනි) අඩු TTL වල බලපෑම බොහෝ දුරට අවධානයට ලක් නොවීය.
අපි Kubernetes වෙත සේවා සංක්‍රමණය කරන විට, DNS තත්පරයකට ඉල්ලීම් 250 ක් සකසන බව අපට පෙනී ගියේය. එහි ප්‍රතිඵලයක් වශයෙන්, යෙදුම් DNS විමසුම් සඳහා නිරන්තර හා බරපතල කාල සීමාවන් අත්විඳීමට පටන් ගත්තේය. DNS සපයන්නා CoreDNS වෙත ප්‍රශස්ත කිරීමට සහ මාරු කිරීමට ඇදහිය නොහැකි උත්සාහයන් තිබියදී මෙය සිදු විය (උපරිම භාරයේදී එය cores 1000 මත ධාවනය වන කරල් 120 දක්වා ළඟා විය).
විය හැකි වෙනත් හේතු සහ විසඳුම් ගැන පර්යේෂණ කරන අතරතුර, අපි සොයාගත්තා , පැකට් පෙරීමේ රාමුවට බලපාන ධාවන තත්ත්වයන් විස්තර කිරීම නෙට්ෆිල්ටර් ලිනක්ස් වල. වැඩිවන කවුන්ටරයක් සමඟ අප නිරීක්ෂණය කළ කාල සීමාවන් ඇතුළු කිරීම_අසාර්ථකයි Flannel අතුරුමුහුණත ලිපියේ සොයාගැනීම් වලට අනුකූල විය.
ගැටළුව ඇති වන්නේ මූලාශ්‍ර සහ ගමනාන්ත ජාල ලිපින පරිවර්තන (SNAT සහ DNAT) සහ පසුව වගුවට ඇතුළත් කිරීමේ අදියරේදීය. කොන්ට්රැක්. අභ්‍යන්තරව සාකච්ඡා කරන ලද සහ ප්‍රජාව විසින් යෝජනා කරන ලද එක් ක්‍රියාමාර්ගයක් වූයේ DNS සේවක නෝඩයටම ගෙන යාමයි. මේ අවස්ථාවේ දී:
- SNAT අවශ්ය නොවන්නේ ගමනාගමනය node එක තුළම පවතින බැවිනි. එය අතුරු මුහුණත හරහා ගමන් කිරීම අවශ්ය නොවේ eth0.
- ගමනාන්ත IP නෝඩයට දේශීය වන අතර නීතිරීතිවලට අනුව අහඹු ලෙස තෝරාගත් පොඩ් එකක් නොවන බැවින් DNAT අවශ්ය නොවේ. iptables.
අපි මෙම ප්රවේශය සමඟ රැඳී සිටීමට තීරණය කළා. CoreDNS Kubernetes හි DaemonSet ලෙස යොදවා ඇති අතර අපි දේශීය node DNS සේවාදායකයක් ක්‍රියාත්මක කළෙමු resolutionv.conf කොඩියක් සැකසීමෙන් සෑම පොඩ් එකක්ම --cluster-dns විධාන කුබෙලට් . මෙම විසඳුම DNS කල් ඉකුත්වීම් සඳහා ඵලදායී විය.
කෙසේ වෙතත්, අපි තවමත් පැකට් පාඩුව සහ කවුන්ටරයේ වැඩි වීමක් දුටුවෙමු ඇතුළු කිරීම_අසාර්ථකයි Flannel අතුරුමුහුණත තුළ. DNS ගමනාගමනය සඳහා පමණක් SNAT සහ/හෝ DNAT ඉවත් කිරීමට අපට හැකි වූ නිසා විසඳුම් ක්‍රියාත්මක කිරීමෙන් පසුව මෙය දිගටම පැවතුනි. වෙනත් වර්ගවල ගමනාගමනය සඳහා ධාවන තත්ත්වයන් ආරක්ෂා විය. වාසනාවකට මෙන්, අපගේ පැකට් බොහොමයක් TCP වන අතර ගැටළුවක් ඇති වුවහොත් ඒවා සරලව නැවත සම්ප්‍රේෂණය වේ. අපි තවමත් සියලු වර්ගවල රථවාහන සඳහා සුදුසු විසඳුමක් සෙවීමට උත්සාහ කරමු.
වඩා හොඳ බරක් සමතුලිත කිරීම සඳහා එන්වෝයි භාවිතා කිරීම
අපි Kubernetes වෙත පසුපෙළ සේවා සංක්‍රමණය කළ විට, අපි කරල් අතර අසමතුලිත බරකින් පීඩා විඳීමට පටන් ගත්තෙමු. HTTP Keepalive මඟින් ELB සම්බන්ධතා එක් එක් යෙදවුමේ පළමු සූදානම් කරල් මත එල්ලීමට හේතු වූ බව අපට පෙනී ගියේය. මේ අනුව, ගමනාගමනයෙන් වැඩි ප්‍රමාණයක් ලබා ගත හැකි කරල් වලින් කුඩා ප්‍රතිශතයක් හරහා ගියේය. අප විසින් පරීක්ෂා කරන ලද පළමු විසඳුම වූයේ නරකම අවස්ථාවන් සඳහා නව යෙදවීම් මත MaxSurge 100% දක්වා සැකසීමයි. විශාල යෙදවීම් අනුව බලපෑම නොවැදගත් සහ පොරොන්දු විරහිත විය.
අප භාවිතා කළ තවත් විසඳුමක් වූයේ විවේචනාත්මක සේවාවන් සඳහා සම්පත් ඉල්ලීම් කෘතිමව වැඩි කිරීමයි. මෙම අවස්ථාවේ දී, අසල තබා ඇති කරල් අනෙකුත් බර කරල් වලට සාපේක්ෂව උපාමාරු කිරීමට වැඩි ඉඩක් ඇත. එය දිගු කාලීනව ක්‍රියා නොකරනු ඇත්තේ එය සම්පත් නාස්තියක් වන බැවිනි. ඊට අමතරව, අපගේ නෝඩ් යෙදුම් තනි නූල් වූ අතර, ඒ අනුව, භාවිතා කළ හැක්කේ එක් හරයක් පමණි. එකම සැබෑ විසඳුම වූයේ වඩා හොඳ බරක් තුලනය භාවිතා කිරීමයි.
අපි බොහෝ කලක සිට සම්පූර්ණයෙන්ම අගය කිරීමට අවශ්යයි . පවතින තත්ත්වය නිසා එය ඉතා සීමිත ලෙස යෙදවීමටත් ක්ෂණික ප්රතිඵල ලබා ගැනීමටත් අපට හැකි විය. Envoy යනු විශාල SOA යෙදුම් සඳහා නිර්මාණය කර ඇති ඉහළ ක්‍රියාකාරී, විවෘත මූලාශ්‍ර, layer-XNUMX ප්‍රොක්සියකි. ස්වයංක්‍රීය නැවත උත්සාහ කිරීම්, පරිපථ කඩන යන්ත්‍ර සහ ගෝලීය අනුපාත සීමා කිරීම ඇතුළුව උසස් බර සමතුලිත කිරීමේ ක්‍රම ක්‍රියාත්මක කිරීමට එයට හැකිය. (සටහන. පරිවර්තනය.: ඔබට මේ ගැන වැඩිදුර කියවිය හැක එන්වෝයි මත පදනම් වූ ඉස්තියෝ ගැන.)
අපි පහත වින්‍යාසය සමඟ පැමිණියෙමු: එක් එක් පෝඩ් සඳහා එන්වෝයි සයිඩ් කාර් එකක් සහ තනි මාර්ගයක් ඇති අතර, පොකුර දේශීයව වරාය හරහා කන්ටේනරයට සම්බන්ධ කරන්න. විභව කැස්කැඩිං අවම කිරීමට සහ කුඩා පහර අරයක් පවත්වා ගැනීමට, අපි එක් එක් සේවාව සඳහා ලබා ගත හැකි කලාපයකට (AZ) එන්වෝයි ඉදිරිපස ප්‍රොක්සි කරල් සමූහයක් භාවිතා කළෙමු. ඔවුන් අපගේ ඉංජිනේරුවෙකු විසින් ලියන ලද සරල සේවා සොයාගැනීමේ එන්ජිමක් මත විශ්වාසය තැබූ අතර එය ලබා දී ඇති සේවාවක් සඳහා එක් එක් AZ හි ඇති කරල් ලැයිස්තුවක් ලබා දුන්නේය.
සේවා පෙරටුගාමී එන්වොයිස් පසුව මෙම සේවා සොයාගැනීමේ යාන්ත්‍රණය එක් උඩුගං පර්ෂයක් සහ මාර්ගයක් සමඟ භාවිතා කළේය. අපි ප්රමාණවත් කාල සීමාවන් සකස් කර, සියලු පරිපථ කඩන සැකසුම් වැඩි කළ අතර, තනි අසාර්ථක වීම් සඳහා උපකාර කිරීමට සහ සුමට යෙදවීම් සහතික කිරීමට අවම නැවත උත්සාහ කිරීමේ වින්‍යාසය එක් කළෙමු. අපි මෙම එක් එක් සේවා පෙරමුණේ නියෝජිතයන් ඉදිරියේ TCP ELB තැබුවෙමු. අපගේ ප්‍රධාන ප්‍රොක්සි ලේයරයේ ඇති Keepalive සමහර එන්වෝයි පොඩ් මත සිරවී තිබුණද, ඔවුන්ට තවමත් බර වඩා හොඳින් හැසිරවීමට හැකි වූ අතර පසු අන්තයේ අවම_request හරහා සමතුලිත වීමට වින්‍යාස කර ඇත.
යෙදවීම සඳහා, අපි යෙදුම් පොඩ්ස් සහ සයිඩ්කාර් කරල් දෙකෙහිම ප්‍රීස්ටොප් කොක්ක භාවිතා කළෙමු. කොක්කෙන් සයිඩ්කාර් කන්ටේනරයේ පිහිටා ඇති පරිපාලක අන්ත ලක්ෂ්‍යයේ තත්ත්වය පරීක්ෂා කිරීමේ දෝෂයක් ඇති වූ අතර සක්‍රිය සම්බන්ධතා අවසන් වීමට ඉඩ දීම සඳහා ටික වේලාවක් නින්දට ගියේය.
අපට මෙතරම් ඉක්මනින් ගමන් කිරීමට හැකි වූ එක් හේතුවක් නම් සාමාන්‍ය Prometheus ස්ථාපනයකට පහසුවෙන් අනුකලනය කිරීමට හැකි වූ සවිස්තරාත්මක ප්‍රමිතික නිසාය. අපි වින්‍යාස පරාමිතීන් සීරුමාරු කර ගමනාගමනය යලි බෙදා හරින අතරතුර සිදුවන්නේ කුමක්ද යන්න නිවැරදිව බැලීමට මෙය අපට ඉඩ සලසයි.
ප්රතිඵල ක්ෂණික හා පැහැදිලි විය. අප ආරම්භ කළේ වඩාත්ම අසමතුලිත සේවා වලින් වන අතර, මේ මොහොතේ එය ක්‍රියාත්මක වන්නේ පොකුරේ ඇති වැදගත්ම සේවාවන් 12 ඉදිරිපිට ය. මෙම වසරේ අපි වඩාත් උසස් සේවා සොයාගැනීම්, පරිපථ කඩනය, පිටස්තර හඳුනාගැනීම, අනුපාත සීමා කිරීම සහ ලුහුබැඳීම සමඟ පූර්ණ සේවා දැලක් වෙත සංක්‍රමණය වීමට සැලසුම් කරමු.
රූපය 3-1. එන්වෝයි වෙත මාරුවීමේදී එක් සේවාවක CPU අභිසාරී වීම
අවසාන ප්‍රති .ලය
මෙම අත්දැකීම් සහ අමතර පර්යේෂණ හරහා, අපි විශාල Kubernetes පොකුරු සැලසුම් කිරීම, යෙදවීම සහ ක්‍රියාත්මක කිරීම සඳහා ශක්තිමත් කුසලතා ඇති ශක්තිමත් යටිතල පහසුකම් කණ්ඩායමක් ගොඩනගා ඇත. සියලුම Tinder ඉංජිනේරුවන්ට දැන් බහාලුම් ඇසුරුම් කිරීමට සහ Kubernetes වෙත යෙදුම් යෙදවීමට දැනුම සහ පළපුරුද්ද ඇත.
පැරණි යටිතල පහසුකම් මත අමතර ධාරිතාවක් අවශ්ය වූ විට, නව EC2 අවස්ථා දියත් කිරීමට අපට මිනිත්තු කිහිපයක් බලා සිටීමට සිදු විය. දැන් බහාලුම් ක්‍රියාත්මක වීමට පටන් ගෙන මිනිත්තු වෙනුවට තත්පර කිහිපයකින් ගමනාගමනය සැකසීමට පටන් ගනී. තනි EC2 අවස්ථාවක බහු බහාලුම් උපලේඛනගත කිරීම තිරස් සාන්ද්‍රණය වැඩි දියුණු කරයි. එහි ප්‍රතිඵලයක් වශයෙන්, පසුගිය වසරට සාපේක්ෂව 2019 වසරේ EC2 පිරිවැයෙහි සැලකිය යුතු අඩුවීමක් අපි පුරෝකථනය කරමු.
සංක්‍රමණයට වසර දෙකකට ආසන්න කාලයක් ගත වූ නමුත් අපි එය 2019 මාර්තු මාසයේදී සම්පූර්ණ කළෙමු. දැනට, Tinder වේදිකාව තනිකරම ක්‍රියාත්මක වන්නේ සේවා 200ක්, නෝඩ් 1000ක්, කරල් 15ක් සහ ධාවන බහාලුම් 000කින් සමන්විත Kubernetes පොකුරක් මතයි. යටිතල පහසුකම් තවදුරටත් මෙහෙයුම් කණ්ඩායම්වල එකම වසම නොවේ. අපගේ සියලුම ඉංජිනේරුවන් මෙම වගකීම බෙදාහදා ගන්නා අතර කේතය පමණක් භාවිතයෙන් ඔවුන්ගේ යෙදුම් තැනීමේ සහ යෙදවීමේ ක්රියාවලිය පාලනය කරයි.
පරිවර්තකගෙන් PS
අපගේ බ්ලොග් අඩවියේ ලිපි මාලාවක් ද කියවන්න:
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
මූලාශ්රය: www.habr.com