නිවාඩු කාලය අවසන් වී ඇති අතර, අපි Istio Service Mesh මාලාවේ අපගේ දෙවන පළ කිරීම සමඟ නැවත පැමිණෙමු.
අද මාතෘකාව වන්නේ සර්කිට් බ්‍රේකර්, එය රුසියානු විදුලි ඉංජිනේරු විද්‍යාවට පරිවර්තනය කර ඇත්තේ “පරිපථ කඩනය” යන්නයි, සාමාන්‍ය භාෂාවෙන් - “පරිපථ කඩනය”. Istio හි පමණක් මෙම යන්ත්‍රය කෙටි වූ හෝ අධික ලෙස පැටවූ පරිපථයක් විසන්ධි නොකරයි, නමුත් දෝෂ සහිත බහාලුම්.
මෙය පරමාදර්ශීව ක්රියා කළ යුතු ආකාරය
ක්ෂුද්ර සේවා Kubernetes විසින් කළමනාකරණය කරන විට, උදාහරණයක් ලෙස OpenShift වේදිකාව තුළ, ඒවා භාරය මත පදනම්ව ස්වයංක්රීයව ඉහළට සහ පහළට පරිමාණය කරයි. ක්ෂුද්ර සේවා කරල්වල ක්රියාත්මක වන බැවින්, එක් අන්ත ලක්ෂ්‍යයක බහාලුම් කරන ලද ක්ෂුද්ර සේවා අවස්ථා කිහිපයක් තිබිය හැකි අතර, Kubernetes ඉල්ලීම් යොමු කර ඒවා අතර ශේෂය පැටවීම සිදු කරයි. සහ - ඉතා මැනවින් - මේ සියල්ල පරිපූර්ණ ලෙස ක්රියා කළ යුතුය.
ක්ෂුද්ර සේවා කුඩා සහ තාවකාලික බව අපට මතකයි. මතුවීම සහ නැතිවීම යන පහසුව මෙහි අර්ථය වන කල්පවත්නා බව බොහෝ විට අවතක්සේරු කරනු ලැබේ. Pod එකක ඇති microservice එකක උපත සහ මරණය බොහෝ දුරට බලාපොරොත්තු වන දේවල් වේ, OpenShift සහ Kubernetes මෙය හොඳින් හසුරුවන අතර සෑම දෙයක්ම හොඳින් ක්රියාත්මක වේ - නමුත් නැවතත් න්‍යායිකව.
එය ඇත්තටම ක්රියා කරන ආකාරය
දැන් සිතන්න, ක්ෂුද්ර සේවාවක නිශ්චිත අවස්ථාවක්, එනම් බහාලුමක් භාවිතයට ගත නොහැකි වී ඇති බව: එක්කෝ එය ප්‍රතිචාර නොදක්වයි (දෝෂය 503), නැතහොත්, වඩාත් අප්‍රසන්න දේ, එය ප්‍රතිචාර දක්වයි, නමුත් ඉතා සෙමින්. වෙනත් වචන වලින් කිවහොත්, එය දෝෂ සහිත වේ හෝ ඉල්ලීම් වලට ප්‍රතිචාර නොදක්වයි, නමුත් එය ස්වයංක්රීයව සංචිතයෙන් ඉවත් නොවේ. මෙම නඩුවේ කළ යුත්තේ කුමක්ද? නැවත උත්සාහ කිරීමට? මම එය මාර්ගගත යෝජනා ක්‍රමයෙන් ඉවත් කළ යුතුද? "ඉතා මන්දගාමී" යන්නෙන් අදහස් කරන්නේ කුමක්ද - එය සංඛ්‍යාවෙන් කොපමණද, සහ ඒවා තීරණය කරන්නේ කවුද? සමහර විට එයට විවේකයක් දී පසුව නැවත උත්සාහ කළ හැකිද? එසේ නම්, කොපමණ පසුවද?
Istio හි Pool Ejection යනු කුමක්ද?
තවද මෙහි Istio එහි Circuit Breaker ආරක්ෂණ යන්ත්‍ර සමඟින් ගලවා ගැනීමට පැමිණෙයි, එමඟින් මාර්ගගත කිරීම සහ පැටවුම් තුලනය කිරීමේ සම්පත් සංචිතයෙන් දෝෂ සහිත බහාලුම් තාවකාලිකව ඉවත් කර, Pool Ejection පටිපාටිය ක්රියාත්මක කරයි.
පිටතින් හඳුනාගැනීමේ උපාය මාර්ගයක් භාවිතා කරමින්, ඉස්ටියෝ විසින් රේඛාවෙන් පිටත ඇති වක්‍ර කරල් හඳුනාගෙන ඒවා නිද්‍රා කවුළුවක් ලෙස හැඳින්වෙන නිශ්චිත කාලයක් සඳහා සම්පත් සංචිතයෙන් ඉවත් කරයි.
OpenShift වේදිකාවේ Kubernetes හි මෙය ක්රියා කරන ආකාරය පෙන්වීමට, ගබඩාවේ ඇති උදාහරණයෙන් සාමාන්‍යයෙන් ක්රියාත්මක වන ක්ෂුද්ර සේවාවල තිර රුවක් සමඟ ආරම්භ කරමු. . මෙන්න අපට v1 සහ v2 යන කරල් දෙකක් ඇත, එක් එක් කන්ටේනරය ධාවනය වේ. Istio මාර්ගගත කිරීමේ නීති භාවිතා නොකරන විට, Kubernetes ඒකාකාරව සමතුලිත රවුන්ඩ් රොබින් මාර්ගගත කිරීමට පෙරනිමි වේ:
කඩාවැටීමකට සූදානම් වීම
Pool Ejection කරන්න කලින් Istio routing rule එකක් හදන්න ඕන. අපි හිතමු අපිට ඉල්ලීම් 50/50 අනුපාතයට කරල් අතර බෙදාහරින්න ඕන කියලා. මීට අමතරව, අපි මේ ආකාරයට v2 බහාලුම් ගණන එක සිට දෙක දක්වා වැඩි කරන්නෙමු:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
දැන් අපි රවුටින් රීතියක් සකසනවා එවිට 50/50 අනුපාතයට කරල් අතර ගමනාගමනය බෙදා හරිනු ලැබේ.
මෙම රීතියේ ප්‍රතිඵලය පෙනෙන්නේ කෙසේද යන්න මෙන්න:
මෙම තිරය 50/50 නොව, 14:9, නමුත් කාලයත් සමඟ තත්වය වැඩිදියුණු වනු ඇති බවට ඔබට වරදක් සොයාගත හැකිය.
දෝෂයක් ඇති කිරීම
දැන් අපි v2 බහාලුම් දෙකෙන් එකක් අක්‍රිය කරමු එවිට අපට එක් සෞඛ්‍ය සම්පන්න v1 කන්ටේනරයක්, එක් සෞඛ්‍ය සම්පන්න v2 කන්ටේනරයක් සහ එක් දෝෂ සහිත v2 බහාලුමක් ඇත:
දෝෂය නිවැරදි කිරීම
ඉතින්, අප සතුව දෝෂ සහිත බහාලුමක් ඇති අතර, එය තටාක පිටකිරීමේ කාලයයි. ඉතා සරල වින්‍යාසයක් භාවිතා කරමින්, අපි මෙම අසාර්ථක කන්ටේනරය සෞඛ්‍ය සම්පන්න තත්වයකට (නැවත ආරම්භ කිරීම හෝ ක්‍රියාකාරීත්වය ප්‍රතිසාධනය කිරීම) යන බලාපොරොත්තුවෙන් තත්පර 15ක් සඳහා ඕනෑම මාර්ගගත යෝජනා ක්‍රමයකින් බැහැර කරමු. මෙම වින්‍යාසය පෙනෙන්නේ කෙසේද සහ එහි කාර්යයේ ප්‍රති results ල මෙයයි:
ඔබට පෙනෙන පරිදි, අසාර්ථක වූ v2 කන්ටේනරය සංචිතයෙන් ඉවත් කර ඇති නිසා එය මාර්ගගත කිරීමේ ඉල්ලීම් සඳහා තවදුරටත් භාවිතා නොවේ. නමුත් තත්පර 15 කට පසු එය ස්වයංක්රීයව නැවත සංචිතයට පැමිණෙනු ඇත. ඇත්ත වශයෙන්ම, අපි Pool Ejection ක්රියා කරන ආකාරය පෙන්වා දුන්නා.
අපි ගෘහ නිර්මාණ ශිල්පය ගොඩනැගීම ආරම්භ කරමු
Pool Ejection, Istio හි අධීක්ෂණ හැකියාවන් සමඟ ඒකාබද්ධව, ඔබට දෝෂ සහිත බහාලුම් ස්වයංක්රීයව ප්‍රතිස්ථාපනය කිරීම සඳහා රාමුවක් තැනීම ආරම්භ කිරීමට ඉඩ සලසයි.
නාසා ආයතනයට එක් උස් ආදර්ශ පාඨයක් ඇත - අසාර්ථකත්වය විකල්පයක් නොවේ, එහි කතුවරයා පියාසර අධ්‍යක්ෂක ලෙස සැලකේ . එය රුසියානු භාෂාවට "අසාර්ථකත්වය විකල්පයක් නොවේ" ලෙස පරිවර්තනය කළ හැකි අතර, මෙහි අර්ථය වන්නේ ඔබට ප්රමාණවත් කැමැත්තක් තිබේ නම් සෑම දෙයක්ම ක්රියාත්මක කළ හැකි බවයි. කෙසේ වෙතත්, සැබෑ ජීවිතයේ දී, අසාර්ථකත්වයන් පමණක් සිදු නොවේ, ඒවා නොවැළැක්විය හැකිය, සෑම තැනකම සහ සෑම දෙයකම. සහ ක්ෂුද්ර සේවා සම්බන්ධයෙන් ඔවුන් සමඟ කටයුතු කරන්නේ කෙසේද? අපගේ මතය අනුව, කැමැත්ත මත නොව, බහාලුම්වල හැකියාවන් මත රඳා සිටීම වඩා හොඳය. , හා .
ඉස්තියෝ, අප ඉහත ලියා ඇති පරිදි, භෞතික ලෝකයේ හොඳින් ඔප්පු කර ඇති පරිපථ කඩන සංකල්පය ක්රියාත්මක කරයි. විද්‍යුත් පරිපථ කඩන යන්ත්‍රයක් පරිපථයක ගැටළු සහිත කොටසක් ක්රියා විරහිත කරනවා සේම, ඉස්ටියෝගේ මෘදුකාංග Circuit Breaker මඟින් ඉල්ලීම් ප්‍රවාහයක් සහ ගැටළු සහිත බහාලුමක් අතර සම්බන්ධය විවෘත කරයි අන්ත ලක්ෂ්‍යයේ යම් දෝෂයක් ඇති විට, උදාහරණයක් ලෙස, සේවාදායකය බිඳ වැටුණු විට හෝ ආරම්භ වූ විට. වේගය අඩු කරන්න.
එපමණක් නොව, දෙවන අවස්ථාවේ දී ඇත්තේ තවත් ගැටළු පමණි, මන්ද එක් කන්ටේනරයක තිරිංග එයට ප්‍රවේශ වන සේවාවන්හි ප්‍රමාදයන් ඇති කරනවා පමණක් නොව, සමස්තයක් ලෙස පද්ධතියේ ක්‍රියාකාරිත්වය අඩු කරයි, නමුත් නැවත නැවත උත්පාදනය කරයි. දැනටමත් මන්දගාමීව ක්රියාත්මක වන සේවාවක් සඳහා ඉල්ලීම්, එය තත්වය තවත් උග්‍ර කරයි.
න්‍යායාත්මකව පරිපථ කඩනය
Circuit Breaker යනු අවසාන ලක්ෂ්‍යයකට ඉල්ලීම් ගලායාම පාලනය කරන ප්‍රොක්සියකි. මෙම ලක්ෂ්‍යය ක්රියා කිරීම නැවැත්වූ විට හෝ, නිශ්චිතව දක්වා ඇති සැකසුම් මත පදනම්ව, මන්දගාමී වීමට පටන් ගන්නා විට, ප්‍රොක්සි කන්ටේනරය සමඟ සම්බන්ධතාවය බිඳ දමයි. බර සමතුලිතතාවය හේතුවෙන් ගමනාගමනය වෙනත් බහාලුම් වෙත හරවා යවනු ලැබේ. ලබා දී ඇති නින්ද කවුළුවක් සඳහා සම්බන්ධතාවය විවෘතව පවතී, මිනිත්තු දෙකක් කියන්න, පසුව අඩක් විවෘතව සලකනු ලැබේ. ඊළඟ ඉල්ලීම යැවීමට උත්සාහ කිරීම සම්බන්ධතාවයේ තවදුරටත් තත්වය තීරණය කරයි. සේවාව සමඟ සෑම දෙයක්ම හරි නම්, සම්බන්ධතාවය නැවත වැඩ කරන තත්ත්වයට පැමිණ නැවත වසා දමනු ලැබේ. සේවාව සමඟ තවමත් යම් දෝෂයක් තිබේ නම්, සම්බන්ධතාවය විසන්ධි වී ඇති අතර නින්ද කවුළුව නැවත සක්රිය කර ඇත. සරල කළ Circuit Breaker රාජ්‍ය රූප සටහනක් පෙනෙන්නේ කෙසේද යන්න මෙන්න:
මේ සියල්ල සිදුවන්නේ පද්ධති ගෘහ නිර්මාණ ශිල්පයේ මට්ටමින් බව මෙහිදී සැලකිල්ලට ගැනීම වැදගත්ය. එමනිසා, යම් අවස්ථාවක දී, ඔබට ඔබේ යෙදුම් වලට Circuit Breaker සමඟ වැඩ කිරීමට ඉගැන්වීමට සිදුවනු ඇත, උදාහරණයක් ලෙස ප්‍රතිචාර වශයෙන් පෙරනිමි අගයක් ලබා දීමෙන් හෝ, හැකි නම්, සේවාවේ පැවැත්ම නොසලකා හැරීමෙන්. මේ සඳහා තොග ශීර්ෂ රටාවක් භාවිතා කරයි, නමුත් එය මෙම ලිපියේ විෂය පථයෙන් ඔබ්බට ය.
ප්‍රායෝගිකව පරිපථ කඩනය
උදාහරණයක් ලෙස, අපි OpenShift මත අපගේ නිර්දේශ microservice අනුවාද දෙකක් ධාවනය කරන්නෙමු. අනුවාදය 1 හොඳින් ක්රියා කරයි, නමුත් v2 හි අපි සේවාදායකයේ මන්දගාමිත්වය අනුකරණය කිරීමට ප්‍රමාදයක් ගොඩනඟමු. ප්රතිඵල බැලීම සඳහා, මෙවලම භාවිතා කරන්න :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
සෑම දෙයක්ම වැඩ කරන බව පෙනේ, නමුත් කුමන වියදමකින්ද? මුලින්ම බැලූ බැල්මට, අපට 100% ලබා ගැනීමේ හැකියාව ඇත, නමුත් සමීපව බලන්න - උපරිම ගනුදෙනු කාලය තත්පර 12 ක් තරම් වේ. මෙය පැහැදිලිවම බාධාවක් වන අතර එය පුළුල් කළ යුතුය.
මෙය සිදු කිරීම සඳහා, අපි මන්දගාමී බහාලුම් සඳහා වන ඇමතුම් ඉවත් කිරීමට Istio භාවිතා කරන්නෙමු. Circuit Breaker භාවිතයෙන් අනුරූප වින්‍යාසය පෙනෙන්නේ මෙයයි:
httpMaxRequestsPerConnection පරාමිතිය සමඟ ඇති අවසාන පේළිය දැනට පවතින සම්බන්ධතාවයට අමතරව තවත් - දෙවන - සම්බන්ධතාවයක් නිර්මාණය කිරීමට උත්සාහ කරන විට සම්බන්ධතාවය විසන්ධි කළ යුතු බවට සංඥා කරයි. අපගේ කන්ටේනරය මන්දගාමී සේවාවක් අනුකරණය කරන බැවින්, එවැනි තත්වයන් වරින් වර පැන නගිනු ඇත, එවිට ඉස්ටියෝ 503 දෝෂයක් ලබා දෙනු ඇත, නමුත් වැටලීම පෙන්නුම් කරන්නේ මෙයයි:
හරි, අපිට Circuit Breaker එකක් තියෙනවා, ඊළඟට මොකක්ද?
එබැවින්, අපි සේවාවන්හි මූල කේතය ස්පර්ශ නොකර ස්වයංක්රීයව වසා දැමීම ක්රියාත්මක කළෙමු. Circuit Breaker සහ ඉහත විස්තර කර ඇති Pool Ejection ක්‍රියාපටිපාටිය භාවිතා කරමින්, අපට ඒවා සාමාන්‍ය තත්වයට පත් වන තෙක් සම්පත් සංචිතයෙන් තිරිංග බහාලුම් ඉවත් කළ හැකි අතර, ඒවායේ තත්ත්වය නිශ්චිත සංඛ්‍යාතයකින් පරීක්ෂා කළ හැකිය - අපගේ උදාහරණයේ, මෙය මිනිත්තු දෙකකි (sleepWindow පරාමිතිය).
503 දෝෂයකට ප්‍රතිචාර දැක්වීමේ යෙදුමක හැකියාව තවමත් ප්‍රභව කේත මට්ටමින් සකසා ඇති බව සලකන්න. තත්වය අනුව Circuit Breaker භාවිතා කිරීම සඳහා බොහෝ උපාය මාර්ග තිබේ.
ඊළඟ පෝස්ට් එකේ: අපි දැනටමත් ගොඩනඟා ඇති හෝ Istio වෙත පහසුවෙන් එකතු කර ඇති ලුහුබැඳීම සහ අධීක්ෂණය ගැන මෙන්ම හිතාමතාම පද්ධතියට දෝෂ හඳුන්වා දෙන්නේ කෙසේද යන්න ගැන කතා කරමු.
මූලාශ්රය: www.habr.com