මෙම කතාව අපි නිෂ්පාදනයේදී, විශේෂයෙන් Kubernetes යටතේ බහාලුම් භාවිතා කරන ආකාරය පිළිබඳ වේ. එය බහාලුම් වලින් මිනුම් සහ ලොග් එකතු කිරීම මෙන්ම රූප ගොඩනැගීම ද ආවරණය කරයි.
අපි Exness, B2B සහ B2C සඳහා මාර්ගගත වෙළඳ සේවා සහ fintech නිෂ්පාදන සංවර්ධනය කරන fintech සමාගමකි. අපගේ පර්යේෂණ සහ සංවර්ධන කණ්ඩායම විවිධ කණ්ඩායම් වලින් සමන්විත වන අතර, අපගේ සංවර්ධන දෙපාර්තමේන්තුවේ සේවකයින් 100 කට වඩා සිටී.
අපගේ සංවර්ධකයින් කේත එකතු කර ක්රියාත්මක කිරීමට භාවිතා කරන වේදිකාව සඳහා වගකිව යුතු කණ්ඩායම අපියි. විශේෂයෙන්, යෙදුම් වලින් මිනුම්, ලොග් සහ සිදුවීම් එකතු කිරීම, ගබඩා කිරීම සහ බෙදා හැරීම සඳහා අපි වගකිව යුතුය. අපි දැනට නිෂ්පාදනයේ ඩොකර් බහාලුම් 3,000 ක් පමණ ක්රියාත්මක කරන අතර, අපගේ 50 TB විශාල දත්ත ගබඩාව නඩත්තු කරන අතර, අපගේ යටිතල පහසුකම් වටා ගොඩනගා ඇති වාස්තු විද්යාත්මක විසඳුම් සපයන්නෙමු: කුබර්නෙට්ස්, රැන්චර් සහ විවිධ පොදු වලාකුළු සපයන්නන්.
අපගේ අභිප්රේරණය
මොකක්ද මේ පිච්චෙන්නේ? කාටවත් කියන්න බෑ. මූලාශ්රය කොහෙද? කියන්න අමාරුයි. ඒක කවදා පටන් ගත්තද? ඒක හොයාගන්න පුළුවන්, නමුත් ඒ වෙලාවෙම නෙවෙයි.
සමහර බහාලුම් සිටගෙන සිටියදී අනෙක් ඒවා වැටී ඇත්තේ ඇයි? කුමන බහාලුමද දොස් පැවරිය යුත්තේ? සියල්ලට පසු, බහාලුම් පිටතින් එක හා සමානව පෙනේ, නමුත් සෑම එකකටම ඇතුළත තමන්ගේම නියෝ ඇත.
අපේ සංවර්ධකයින් දක්ෂයි. ඔවුන් සමාගමට ලාභ උපදවන විශිෂ්ට සේවාවන් ගොඩනඟනවා. නමුත් සමහර විට බහාලුම් සහ යෙදුම් සමමුහුර්ත නොවන විට දේවල් වැරදී යයි. එක් බහාලුමක් ඕනෑවට වඩා CPU පරිභෝජනය කරයි, තවත් එකක් ඕනෑවට වඩා ජාල කලාප පළල පරිභෝජනය කරයි, තුනෙන් එකක් ඕනෑවට වඩා I/O පරිභෝජනය කරයි, සහ හතරෙන් එකක් සොකට් සමඟ කරන්නේ කුමක්දැයි පවා නොදනී. මේ සියල්ල කඩා වැටෙන අතර නැව ගිලෙයි.
නියෝජිතයන්
ඇතුළත සිදුවන්නේ කුමක්ද යන්න තේරුම් ගැනීමට, අපි නියෝජිතයන් කෙලින්ම බහාලුම් තුළට දැමීමට තීරණය කළෙමු.
මෙම නියෝජිතයන් යනු බහාලුම් එකිනෙක කැඩී යාම වළක්වන තත්වයක පවත්වා ගෙන යන බහාලුම් වැඩසටහන් වේ. බහාලුම් නඩත්තු කිරීම සඳහා ප්රමිතිගත ප්රවේශයකට ඉඩ සලසන නියෝජිතයන් ප්රමිතිගත කර ඇත.
අපගේ නඩුවේදී, නියෝජිතයින් ටැග් කර තෙරපුම් කරන ලද සම්මත ආකෘතියකින් ලොග් සැපයිය යුතුය. ව්යාපාරික යෙදුම් සඳහා දීර්ඝ කළ හැකි ප්රමිතික මිනුම් ද ඔවුන් අපට ලබා දිය යුතුය.
විවිධ වාද්ය වෘන්ද පද්ධතිවල ක්රියා කළ හැකි සහ විවිධ රූප (ඩේබියන්, ඇල්පයින්, සෙන්ටෝස්, ආදිය) සඳහා සහය දැක්විය හැකි මෙහෙයුම් සහ නඩත්තුව සඳහා උපයෝගිතා ද නියෝජිතයින්ට ඇතුළත් වේ.
අවසාන වශයෙන්, නියෝජිතයන් Dockerfiles ඇතුළු සරල CI/CD සඳහා සහාය විය යුතුය. එසේ නොවුවහොත්, දෝෂ සහිත ධාවන පථවල බහාලුම් බෙදා හරින බැවින්, නැව කඩා වැටෙනු ඇත.
එකලස් කිරීමේ ක්රියාවලිය සහ ඉලක්ක රූප උපාංගය
සෑම දෙයක්ම ප්රමිතිගත කර කළමනාකරණය කළ හැකි ලෙස තබා ගැනීමට, අපි යම් ආකාරයක සම්මත ගොඩනැගීමේ ක්රියාවලියකට අනුගත විය යුතුයි. ඒ නිසා අපි බහාලුම් තැනීමෙන් බහාලුම් තැනීමට තීරණය කළා - එය එක්තරා ආකාරයක පුනරාවර්තනයක්.
මෙහිදී, බහාලුම් ඝන දළ සටහන් මගින් නිරූපණය කෙරේ. "ජීවිතය රෝස මල් යහනාවක් මෙන් නොපෙනෙන පරිදි" අපි ඒවායේ බෙදාහැරීම් ඇතුළත් කිරීමට ද තීරණය කළෙමු. මේ සඳහා හේතුව අපි පහතින් පැහැදිලි කරන්නෙමු.
ප්රතිඵලය වන්නේ ගොඩනැගීමේ මෙවලමකි - නිශ්චිත බෙදාහැරීමේ අනුවාද සහ නිශ්චිත ස්ක්රිප්ට් අනුවාද යොමු කරන නිශ්චිත අනුවාදයක බහාලුමකි.
අපි එය භාවිතා කරන්නේ කෙසේද? අපට බහාලුමක් සහිත ඩොකර් හබ් එකක් තිබේ. බාහිර පරායත්තතා ඉවත් කිරීම සඳහා අපි එය අපගේ පද්ධතිය තුළ පිළිබිඹු කරමු. ප්රතිඵලයක් ලෙස ලැබෙන බහාලුම කහ පැහැයෙන් උද්දීපනය කර ඇත. අවශ්ය සියලුම බෙදාහැරීම් සහ ස්ක්රිප්ට් බහාලුම තුළට ස්ථාපනය කිරීම සඳහා අපි අච්චුවක් නිර්මාණය කරමු. ඊට පසු, අපි නිෂ්පාදනයට සූදානම් රූපයක් ගොඩනඟමු: සංවර්ධකයින් ඔවුන්ගේ කේතය සහ ඕනෑම නිශ්චිත පරායත්තතාවයක් එයට එක් කරයි.
මෙම ප්රවේශයේ ඇති හොඳ කුමක්ද?
- පළමුව, ගොඩනැගීමේ මෙවලම්වල සම්පූර්ණ අනුවාද පාලනය - ගොඩනැගීමේ බහාලුම්, ස්ක්රිප්ට් අනුවාද සහ බෙදාහැරීම්.
- දෙවනුව, අපි ප්රමිතිකරණය සාක්ෂාත් කර ගෙන ඇත්තෙමු: අපි සැකිලි, අතරමැදි ඒවා සහ භාවිතයට සූදානම් රූප එකම ආකාරයකින් නිර්මාණය කරමු.
- තෙවනුව, බහාලුම් අපට අතේ ගෙන යා හැකි හැකියාව ලබා දෙයි. අද අපි Gitlab භාවිතා කරන අතර, හෙට අපි TeamCity හෝ Jenkins වෙත මාරු වී අපගේ බහාලුම් එලෙසම ක්රියාත්මක කිරීමට හැකි වෙමු.
- හතරවනුව, පරායත්තතා අවම කිරීම. බෙදාහැරීම් අපි බහාලුම්ගත කිරීම අහම්බයක් නොවේ, මන්ද මෙය සෑම අවස්ථාවකම අන්තර්ජාලයෙන් ඒවා බාගත කිරීමේ අවශ්යතාවය ඉවත් කරයි.
- පස්වනුව, ගොඩනැගීමේ වේගය වැඩි වී ඇත - රූපවල දේශීය පිටපත් තිබීම යන්නෙන් අදහස් වන්නේ දේශීය රූපයක් ඇති බැවින් ඒවා බාගත කිරීමට කාලය නාස්ති කිරීමට අවශ්ය නොවන බවයි.
වෙනත් වචන වලින් කිවහොත්, අපි පාලිත සහ නම්යශීලී ගොඩනැගීමේ ක්රියාවලියක් සාක්ෂාත් කර ගෙන ඇත්තෙමු. සම්පූර්ණ අනුවාදකරණයක් සහිත ඕනෑම බහාලුමක් තැනීමට අපි එකම මෙවලම් භාවිතා කරමු.
අපගේ එකලස් කිරීමේ ක්රියාවලිය ක්රියාත්මක වන ආකාරය
ගොඩනැගීම තනි විධානයකින් දියත් කරන අතර, ක්රියාවලිය රූපයේ ක්රියාත්මක වේ (රතු පැහැයෙන් උද්දීපනය කර ඇත). සංවර්ධකයා සතුව ඩොකර් ගොනුවක් ඇත (කහ පැහැයෙන් උද්දීපනය කර ඇත), අපි එය විචල්යයන් අගයන් සමඟ ප්රතිස්ථාපනය කරමින් විචල්යයන් ප්රතිස්ථාපනය කරමු. අපි මඟ දිගේ ශීර්ෂ සහ පාදක ද එකතු කරමු - මේවා අපගේ නියෝජිතයන් වේ.
ශීර්ෂකය අනුරූප රූප වලින් බෙදාහැරීම් එකතු කරයි. පාදකය අපගේ සේවාවන් ස්ථාපනය කරයි, වැඩ බර දියත් කිරීම, ලොග් කිරීම සහ අනෙකුත් නියෝජිතයන් වින්යාස කරයි, ප්රවේශ ලක්ෂ්යය ප්රතිස්ථාපනය කරයි, යනාදිය.
අපි දීර්ඝ කාලයක් තිස්සේ අධීක්ෂකවරයෙකු ස්ථාපනය කළ යුතුද යන්න පිළිබඳව විවාද කළෙමු. අවසානයේ, අපට එකක් අවශ්ය බව අපි තීරණය කළෙමු. අපි S6 තෝරා ගත්තෙමු. අධීක්ෂකවරයා බහාලුම කළමනාකරණය කරයි: ප්රධාන ක්රියාවලිය බිඳ වැටුනහොත් එය ඔබට එයට සම්බන්ධ වීමට ඉඩ සලසන අතර එය නැවත නිර්මාණය නොකර බහාලුම අතින් පාලනය කරයි. ලොග් සහ මිනුම් යනු බහාලුම තුළ ක්රියාත්මක වන ක්රියාවලීන් වේ. ඒවා කෙසේ හෝ නිරීක්ෂණය කළ යුතු අතර, අපි මෙය අධීක්ෂකවරයා සමඟ කරන්නෙමු. අවසාන වශයෙන්, S6 ගෘහ පාලනය, සංඥා සැකසීම සහ අනෙකුත් කාර්යයන් හසුරුවයි.
අපි විවිධ වාද්ය වෘන්ද පද්ධති භාවිතා කරන බැවින්, ගොඩනඟා දියත් කිරීමෙන් පසු, බහාලුම එය ඇති පරිසරය තේරුම් ගෙන ඒ අනුව ක්රියා කළ යුතුය. උදාහරණයක් ලෙස:
මෙය අපට තනි රූපයක් ගොඩනගා එය විවිධ වාද්ය වෘන්ද පද්ධතිවල ක්රියාත්මක කිරීමට ඉඩ සලසන අතර, එක් එක් වාද්ය වෘන්ද පද්ධතියේ විශේෂතා සැලකිල්ලට ගනිමින් එය දියත් කෙරේ.
එකම බහාලුම සඳහා, අපට Docker සහ Kubernetes හි විවිධ ක්රියාවලි ගස් ලැබේ:
ගෙවීම් භාරය S6 අධීක්ෂක යටතේ ක්රියාත්මක වේ. එකතු කරන්නා සහ සිදුවීම් සටහන් කර ගන්න - මොවුන් ලොග් සහ මිනුම් සඳහා වගකිව යුතු අපගේ නියෝජිතයන් වේ. කුබර්නෙට්ස් සතුව ඒවා නැත, නමුත් ඩෝකර් සතුව තිබේ. ඇයි?
අපි "pod" පිරිවිතරය (මින් ඉදිරියට Kubernetes pod ලෙස හඳුන්වනු ලැබේ) දෙස බැලුවහොත්, සිදුවීම් බහාලුම පොඩ් එකක ක්රියාත්මක වන බව අපට පෙනෙනු ඇත, එහි මිනුම් සහ ලොග් එකතු කරන වෙනම එකතුකරන්නන්ගේ බහාලුමක් අඩංගු වේ. අපට Kubernetes හි හැකියාවන් උපයෝගී කර ගත හැකිය: තනි පොඩ් එකක, තනි ක්රියාවලියක සහ/හෝ ජාල අවකාශයක බහාලුම් ධාවනය කිරීම. මෙය අපට අපගේම නියෝජිතයන් ඵලදායී ලෙස එන්නත් කිරීමට සහ නිශ්චිත කාර්යයන් ඉටු කිරීමට ඉඩ සලසයි. තවද මෙම එකම බහාලුම Docker හි ධාවනය කරන්නේ නම්, එයට එකම හැකියාවන් ඇත, එනම් නියෝජිතයින් තුළ ක්රියාත්මක වන බැවින් එයට ලොග් සහ මිනුම් ලබා දීමට හැකි වනු ඇත.
මිනුම් සහ ලොග
මිනුම් සහ ලොග් ලබා දීම සංකීර්ණ කාර්යයකි. එය විසඳීමට අංශ කිහිපයක් සම්බන්ධ වේ.
යටිතල පහසුකම් ගොඩනගා ඇත්තේ බර පැටවීමේ ක්රියාත්මක කිරීම සඳහා මිස තොග ලොග් බෙදා හැරීම සඳහා නොවේ. මෙයින් අදහස් කරන්නේ ක්රියාවලිය අවම බහාලුම් සම්පත් අවශ්යතා සමඟ සිදු කළ යුතු බවයි. අපි අපගේ සංවර්ධකයින්ට උපකාර කිරීමට උත්සාහ කරමු: "ඩොකර් හබ් බහාලුමක් ලබා ගන්න, එය ක්රියාත්මක කරන්න, එවිට අපට ලොග් ලබා දිය හැකිය."
දෙවන අංගය වන්නේ ලොග් පරිමාව සීමා කිරීමයි. බහාලුම් කිහිපයක ලොග් පරිමාවේ ස්පයික් එකක් සිදුවුවහොත් (යෙදුම ස්ටැක් හෝඩුවාවක් ලූප් කර ප්රතිදානය කරයි), CPU, සන්නිවේදන නාලිකා සහ ලොග් සැකසුම් පද්ධතියේ බර වැඩි වන අතර, එය සමස්තයක් ලෙස ධාරකයට සහ ධාරකයේ අනෙකුත් බහාලුම් වලට බලපාන අතර, සමහර විට ධාරක බිඳවැටීමකට මග පාදයි.
තුන්වන අංගය වන්නේ හැකි තරම් මිනුම් එකතු කිරීමේ ක්රම සඳහා කොටුවෙන් පිටත සහාය දැක්වීමේ අවශ්යතාවයයි. ගොනු කියවීමේ සිට ප්රොමිතියස් අන්ත ලක්ෂ්යය මත විමසුම දක්වා යෙදුම්-විශේෂිත ප්රොටෝකෝල භාවිතා කිරීම දක්වා.
අවසාන අංගය වන්නේ සම්පත් පරිභෝජනය අවම කිරීම අවශ්ය වීමයි.
අපි Go හි Telegraf ලෙස හඳුන්වන විවෘත මූලාශ්ර විසඳුමක් තෝරා ගත්තෙමු. එය ආදාන ප්ලගීන 140 කට වඩා සහ ප්රතිදාන ප්ලගීන 30 කට වඩා සහය දක්වන විශ්වීය සම්බන්ධකයකි. අපි එය තවදුරටත් සංවර්ධනය කර ඇති අතර, දැන් අපි එය Kubernetes හි භාවිතා කරන ආකාරය පැහැදිලි කරන්නෙමු.
සංවර්ධකයෙකු වැඩ බරක් යොදවන අතර, Kubernetes හට පොඩ් එකක් නිර්මාණය කිරීමට ඉල්ලීමක් ලැබේ යැයි කියමු. මෙම අවස්ථාවේදී, එක් එක් පොඩ් සඳහා කලෙක්ටර් නම් බහාලුමක් ස්වයංක්රීයව නිර්මාණය වේ (අපි විකෘති වෙබ් කොක්කක් භාවිතා කරමු). එකතු කරන්නා අපගේ නියෝජිතයා වේ. ආරම්භයේදී, මෙම බහාලුම Prometheus සහ ලොග් එකතු කිරීමේ පද්ධතිය සමඟ වැඩ කිරීමට වින්යාස කරයි.
- මෙය සිදු කිරීම සඳහා, එය පොඩ් විවරණ භාවිතා කරන අතර, එහි අන්තර්ගතය මත පදනම්ව, උදාහරණයක් ලෙස, ප්රොමිතියස් අන්ත ලක්ෂ්යයක් නිර්මාණය කරයි;
- පොඩ් පිරිවිතර සහ බහාලුම්-නිශ්චිත සැකසුම් මත පදනම්ව, එය ලොග් ලබා දෙන ආකාරය තීරණය කරයි.
අපි Docker API හරහා ලොග් එකතු කරමු: සංවර්ධකයින්ට ඒවා stdout හෝ stderr තුළ තැබීමට අවශ්ය වන අතර, ඉතිරිය එකතු කරන්නා විසින් හසුරුවනු ඇත. විභව ධාරක අධි බර වැළැක්වීම සඳහා ලොග් සුළු ප්රමාදයකින් කොටස් වශයෙන් එකතු කරනු ලැබේ.
බහාලුම්වල වැඩ බර අවස්ථා (ක්රියාවලි) සඳහා මිනුම් එකතු කරනු ලැබේ. සෑම දෙයක්ම නම්, පොඩ් ආදිය සමඟ ටැග් කර, පසුව ප්රොමිතියස් ආකෘතියට පරිවර්තනය කර, එය එකතු කිරීම සඳහා ලබා ගත හැකිය (ලොග් හැර). අපි කෆ්කා වෙත ලොග්, මිනුම් සහ සිදුවීම් ද යවමු සහ තවත්:
- ලොග් ග්රේලොග් වලින් ලබා ගත හැකිය (දෘශ්ය විශ්ලේෂණය සඳහා);
- දිගු කාලීන ගබඩා කිරීම සඳහා ලොග්, මිනුම් සහ සිදුවීම් Clickhouse වෙත යවනු ලැබේ.
AWS වලත් හැම දෙයක්ම ඒ විදියටම වැඩ කරනවා, අපි Graylog එක Kafka සහ Cloudwatch වලින් ප්රතිස්ථාපනය කරනවා හැර. අපි එතනට ලොග් යවනවා, හැම දෙයක්ම හරිම පහසුයි: ඒවා අයත් වෙන්නේ මොන cluster එකටද කියලා වහාම පැහැදිලි වෙනවා. Google Stackdriver වලටත් ඒකම තමයි. මෙයින් අදහස් කරන්නේ අපේ සැකසුම Kafka එක්ක සහ cloud එකේ පරිශ්රයේ වැඩ කරන බවයි.
අපට කරල් සහිත කුබර්නෙට්ස් නොමැති නම්, යෝජනා ක්රමය ටිකක් සංකීර්ණයි, නමුත් එකම මූලධර්ම මත ක්රියා කරයි.
S6 භාවිතයෙන් සංවිධානය කරන ලද, කන්ටේනරය තුළ එකම ක්රියාවලීන් ක්රියාත්මක වේ. එකම ක්රියාවලීන් සියල්ලම තනි බහාලුමක් තුළ ක්රියාත්මක වේ.
එහි ප්රතිඵලයක් ලෙස,
රූප ගොඩනැගීම සහ යෙදවීම සඳහා අපි පුළුල් විසඳුමක් නිර්මාණය කර ඇති අතර, ලොග් සහ මිනුම් එකතු කිරීම සහ බෙදා හැරීම සඳහා විකල්ප ඇත:
- අපි රූප එකලස් කිරීම සඳහා ප්රමිතිගත ප්රවේශයක් සකස් කළ අතර, එය මත පදනම්ව, අපි CI සැකිලි සකස් කළෙමු;
- දත්ත රැස් කිරීමේ නියෝජිතයන් අපගේ ටෙලිග්රාෆ් දිගුවන් වේ. අපි ඒවා නිෂ්පාදනයේදී හොඳින් පරීක්ෂා කර ඇත්තෙමු;
- අපි කරල් වලට කාරක සහිත බහාලුම් එන්නත් කිරීමට විකෘති වෙබ් කොක්ක භාවිතා කරමු;
- කුබර්නෙට්ස්/රැන්චර් පරිසර පද්ධතියට ඒකාබද්ධ වී ඇත;
- අපට එකම බහාලුම් විවිධ වාද්ය වෘන්ද පද්ධතිවල ක්රියාත්මක කර අප අපේක්ෂා කරන ප්රතිඵලය ලබා ගත හැකිය;
- සම්පූර්ණයෙන්ම ගතික බහාලුම් කළමනාකරණ වින්යාසයක් නිර්මාණය කරන ලදී.
සම කර්තෘ: ඉල්යා පෘඩ්නිකොව්
මූලාශ්රය: www.habr.com
