වාර්තාව Kubernetes හි මෙහෙයුම්කරුවෙකු සංවර්ධනය කිරීම, එහි ගෘහ නිර්මාණ ශිල්පය සහ මූලික මෙහෙයුම් මූලධර්ම සැලසුම් කිරීම පිළිබඳ ප්‍රායෝගික ගැටළු සඳහා කැප කර ඇත.
වාර්තාවේ පළමු කොටසේ අපි සලකා බලමු:
- Kubernetes හි ක්රියාකරු යනු කුමක්ද සහ එය අවශ්ය වන්නේ ඇයි;
- ක්රියාකරු සංකීර්ණ පද්ධති කළමනාකරණය සරල කරන්නේ කෙසේද;
- ක්රියාකරුට කළ හැකි සහ කළ නොහැකි දේ.
ඊළඟට, අපි ක්රියාකරුගේ අභ්යන්තර ව්යුහය සාකච්ඡා කිරීමට ඉදිරියට යමු. ක්රියාකරුගේ ගෘහ නිර්මාණ ශිල්පය සහ ක්‍රියාකාරිත්වය පියවරෙන් පියවර බලමු. අපි එය විස්තරාත්මකව බලමු:
- ක්රියාකරු සහ Kubernetes අතර අන්තර්ක්රියා;
- ක්රියාකරු විසින් ඉටු කරන කාර්යයන් සහ එය Kubernetes වෙත පවරන කාර්යයන් මොනවාද.
Kubernetes හි කැබලි සහ දත්ත සමුදා අනුරූ කළමනාකරණය කිරීම දෙස බලමු.
ඊළඟට, අපි දත්ත ගබඩා කිරීමේ ගැටළු සාකච්ඡා කරමු:
- ක්රියාකරුගේ දෘෂ්ටි කෝණයෙන් ස්ථීර ගබඩාව සමඟ වැඩ කරන්නේ කෙසේද;
- දේශීය ගබඩාව භාවිතා කිරීමේ අන්තරායන්.
වාර්තාවේ අවසාන කොටසේදී, අපි යෙදුමේ ප්‍රායෝගික උදාහරණ සලකා බලමු Amazon හෝ Google Cloud Service වෙතින්. වාර්තාව පදනම් වී ඇත්තේ ClickHouse සඳහා ක්‍රියාකරුවෙකුගේ සංවර්ධනය සහ මෙහෙයුම් අත්දැකීම් පිළිබඳ උදාහරණය මතය.
වීඩියෝ:
මගේ නම ව්ලැඩිස්ලාව් ක්ලිමෙන්කෝ. අද මට කතා කිරීමට අවශ්ය වූයේ ක්රියාකරුවෙකු සංවර්ධනය කිරීම සහ ක්රියාත්මක කිරීම පිළිබඳ අපගේ අත්දැකීම් ගැන වන අතර මෙය දත්ත සමුදා පොකුරු කළමනාකරණය සඳහා විශේෂිත ක්‍රියාකරුවෙකි. උදාහරණ වශයෙන් ClickHouse පොකුර කළමනාකරණය කිරීමට.
ක්රියාකරු සහ ClickHouse ගැන කතා කිරීමට අපට අවස්ථාව ලැබෙන්නේ ඇයි?
- අපි ClickHouse සඳහා සහය සහ සංවර්ධනය.
- මේ මොහොතේ, අපි ClickHouse සංවර්ධනය සඳහා අපගේ දායකත්වය සෙමෙන් ලබා දීමට උත්සාහ කරමු. ක්ලික්හවුස් වෙත සිදු කරන ලද වෙනස්කම් පරිමාව අනුව අපි Yandex ට පසුව දෙවනුව සිටිමු.
- අපි ClickHouse පරිසර පද්ධතිය සඳහා අමතර ව්‍යාපෘති නිර්මාණය කිරීමට උත්සාහ කරන්නෙමු.
මෙම ව්‍යාපෘති වලින් එකක් ගැන මම ඔබට කියන්නට කැමැත්තෙමි. මෙය Kubernetes සඳහා ClickHouse-operator ගැනයි.
මගේ වාර්තාවේ මම මාතෘකා දෙකක් ස්පර්ශ කිරීමට කැමතියි:
- පළමු මාතෘකාව වන්නේ අපගේ ClickHouse දත්ත සමුදා කළමනාකරණ ක්රියාකරු Kubernetes හි ක්රියා කරන ආකාරයයි.
- දෙවන මාතෘකාව වන්නේ ඕනෑම ක්රියාකරුවෙකු ක්රියා කරන ආකාරය, එනම් එය Kubernetes සමඟ අන්තර් ක්රියා කරන ආකාරයයි.
කෙසේ වෙතත්, මෙම ප්රශ්න දෙක මගේ වාර්තාව පුරාම ඡේදනය වේ.
මම කියන්න හදන දේ අහන්න කැමති කවුද?
- ක්රියාකරුවන් ක්රියාත්මක කරන අයට එය වඩාත් උනන්දු වනු ඇත.
- නැතහොත් එය අභ්‍යන්තරව ක්රියා කරන ආකාරය, ක්රියාකරු Kubernetes සමඟ අන්තර් ක්රියා කරන ආකාරය සහ කුමන අන්තරායන් මතු විය හැකිද යන්න අවබෝධ කර ගැනීම සඳහා තමන්ගේම කර ගැනීමට කැමති අයට.
අද අපි සාකච්ඡා කරන දේ හොඳින් අවබෝධ කර ගැනීමට, Kubernetes ක්රියා කරන ආකාරය සහ මූලික වලාකුළු පුහුණුවක් ඇති ආකාරය දැන ගැනීම හොඳ අදහසකි.
ClickHouse යනු කුමක්ද? මෙය විශ්ලේෂණාත්මක විමසුම් සබැඳිව සැකසීම සඳහා විශේෂිත විශේෂාංග සහිත තීරු දත්ත ගබඩාවකි. තවද එය සම්පූර්ණයෙන්ම විවෘත මූලාශ්‍රයකි.
ඒවගේම අපිට වැදගත් වෙන්නේ කරුණු දෙකක් විතරයි. මෙය දත්ත සමුදායක් බව ඔබ දැනගත යුතුය, එබැවින් මම ඔබට පවසන දේ ඕනෑම දත්ත ගබඩාවකට පාහේ අදාළ වේ. ක්ලික්හවුස් ඩීබීඑම්එස් ඉතා හොඳින් පරිමාණය කිරීම, පාහේ රේඛීය පරිමාණය ලබා දෙයි. එබැවින්, පොකුරු තත්ත්වය ClickHouse සඳහා ස්වභාවික තත්ත්වයකි. Kubernetes හි ClickHouse පොකුරට සේවය කරන්නේ කෙසේදැයි සාකච්ඡා කිරීමට අපි වඩාත් උනන්දු වෙමු.
ඔහු එහි අවශ්ය වන්නේ ඇයි? ඇයි අපිට ඒක දිගටම කරගෙන යන්න බැරි? සහ පිළිතුරු අර්ධ වශයෙන් තාක්ෂණික සහ අර්ධ වශයෙන් සංවිධානාත්මක වේ.
- ප්රායෝගිකව, විශාල සමාගම්වල සියලුම සංරචක පාහේ දැනටමත් Kubernetes හි ඇති තත්වයකට අපි වැඩි වැඩියෙන් මුහුණ දී සිටිමු. දත්ත සමුදායන් පිටත පවතී.
- “මෙය ඇතුළත තැබිය හැකිද?” යන ප්‍රශ්නය වැඩි වැඩියෙන් අසනු ලැබේ. එමනිසා, විශාල සමාගම් ඔවුන්ගේ දත්ත ගබඩා ඉක්මනින් කළමනාකරණය කිරීමට හැකි වන පරිදි කළමනාකරණයේ උපරිම ඒකාබද්ධතාවයක් ලබා ගැනීමට උත්සාහ කරයි.
- නව ස්ථානයක එකම දේ නැවත කිරීමට ඔබට උපරිම අවස්ථාව අවශ්ය නම් මෙය විශේෂයෙන් උපකාරී වේ, එනම් උපරිම අතේ ගෙන යා හැකි හැකියාව.
එය කොතරම් පහසු හෝ දුෂ්කරද? ඇත්ත වශයෙන්ම, මෙය අතින් කළ හැකිය. නමුත් එය එතරම් සරල නැත, මන්ද අපට Kubernetes කළමනාකරණය කිරීමේ අමතර සංකීර්ණතාවයක් ඇත, නමුත් ඒ සමඟම ClickHouse හි විශේෂතා අධිස්ථාපනය වේ. සහ එවැනි එකතුවක් ප්රතිඵලය.
මේ සියල්ල එක්ව මෙය තරමක් විශාල තාක්‍ෂණ මාලාවක් ලබා දෙයි, එය කළමනාකරණය කිරීම තරමක් අපහසු වේ, මන්ද Kubernetes තමන්ගේම එදිනෙදා ගැටළු ක්රියාත්මක කිරීමට ගෙන එන අතර ClickHouse එදිනෙදා ක්‍රියාකාරිත්වයට තමන්ගේම ගැටළු ගෙන එයි. විශේෂයෙන්ම අපට ClickHouses කිහිපයක් තිබේ නම්, අපි ඔවුන් සමඟ නිරන්තරයෙන් යමක් කළ යුතුය.
ගතික වින්‍යාසයක් සමඟ, ClickHouse හට DevOps මත නිරන්තර බරක් ඇති කරන තරමක් විශාල ගැටළු සංඛ්යාවක් ඇත:
- අපට ClickHouse හි යමක් වෙනස් කිරීමට අවශ්ය වූ විට, උදාහරණයක් ලෙස, අනුරුවක් හෝ කැබැල්ලක් එක් කරන්න, එවිට අපට වින්යාසය කළමනාකරණය කිරීමට අවශ්ය වේ.
- ක්ලික්හවුස් සතුව නිශ්චිත බෙදාගැනීමේ ක්‍රමයක් ඇති බැවින් දත්ත ක්රමය වෙනස් කරන්න. එහිදී ඔබට දත්ත රූප සටහනක් තැබිය යුතුය, වින්යාසයන් තැබිය යුතුය.
- ඔබ අධීක්ෂණ පිහිටුවීමට අවශ්යයි.
- නව කැබලි සඳහා, නව අනුරූ සඳහා ලඝු-සටහන් එකතු කිරීම.
- ප්රතිෂ්ඨාපනය ගැන සැලකිලිමත් වන්න.
- සහ නැවත ආරම්භ කරන්න.
මේවා සාමාන්ය කාර්යයන් වන අතර ඒවා භාවිතයට පහසු කිරීමට මා කැමතිය.
Kubernetes විසින්ම ක්රියාත්මක වීමට හොඳින් උපකාරී වේ, නමුත් මූලික පද්ධති දේවල් මත.
Kubernetes වැනි දේවල් පහසු කිරීමට සහ ස්වයංක්රීය කිරීමට දක්ෂයි:
- ප්‍රතිසාධනය.
- යළි අරඹන්න.
- ගබඩා පද්ධති කළමනාකරණය.
එය හොඳයි, එය නිවැරදි දිශාවයි, නමුත් දත්ත සමුදා පොකුරක් ක්රියාත්මක කරන්නේ කෙසේද යන්න පිළිබඳව ඔහුට සම්පූර්ණයෙන්ම අවබෝධයක් නැත.
අපට තවත් අවශ්යයි, සම්පූර්ණ දත්ත සමුදායම Kubernetes හි වැඩ කිරීමට අපට අවශ්යයි.
ඔබ එබූ විශාල එක් මැජික් රතු බොත්තමක් සහ විසඳිය යුතු එදිනෙදා කාර්යයන් සහිත පොකුරක් එහි මුළු ජීවන චක්රය පුරාවටම යොදවා පවත්වාගෙන යාමට මම කැමතියි. Kubernetes හි ClickHouse පොකුර.
ඒ වගේම අපි වැඩ පහසු කර ගැනීමට උපකාර වන විසඳුමක් සෑදීමට උත්සාහ කළා. මෙය Altinity වෙතින් Kubernetes සඳහා ClickHouse-operator වේ.
ක්රියාකරු යනු වෙනත් වැඩසටහන් කළමනාකරණය කිරීම සඳහා ප්රධාන කාර්යය වන වැඩසටහනකි, එනම් එය කළමනාකරුවෙකි.
තවද එහි හැසිරීම් රටා අඩංගු වේ. ඔබට මෙය විෂය ක්ෂේත්‍රය පිළිබඳ කේතනය කළ දැනුම ලෙස හැඳින්විය හැක.
ඔහුගේ ප්රධාන කාර්යය වන්නේ DevOps ජීවිතය පහසු කිරීම සහ ක්ෂුද්‍ර කළමනාකරණය අඩු කිරීමයි, එවිට ඔහු (DevOps) දැනටමත් ඉහළ මට්ටමේ අදහස් කරයි, එනම්, ඔහු (DevOps) ක්ෂුද්‍ර කළමනාකරණයේ නොයෙදෙන ලෙස, ඔහු වින්යාස නොකරයි. සියලුම විස්තර අතින්.
තවද ක්රියාකරු යනු ක්ෂුද්‍ර කාර්යයන් සමඟ කටයුතු කරන සහ DevOps හට උපකාර කරන රොබෝ සහායකයෙකි.
ඔබට ක්රියාකරු අවශ්ය වන්නේ ඇයි? ඔහු අංශ දෙකකින් විශේෂයෙන් හොඳින් ක්රියා කරයි:
- ClickHouse සමඟ ගනුදෙනු කරන විශේෂඥයාට ප්‍රමාණවත් පළපුරුද්දක් නොමැති නමුත් දැනටමත් ClickHouse ක්රියාත්මක කිරීමට අවශ්ය වූ විට, ක්රියාකරු මෙහෙයුම පහසු කරවන අතර, එය ක්රියාත්මක වන ආකාරය පිළිබඳව වැඩි විස්තරයක් නොමැතිව, තරමක් සංකීර්ණ වින්‍යාසයකින් ClickHouse පොකුරක් ක්රියාත්මක කිරීමට ඔබට ඉඩ සලසයි. තුල. ඔබ ඔහුට ඉහළ මට්ටමේ කාර්යයන් ලබා දෙන අතර එය ක්රියාත්මක වේ.
- එය වඩාත් හොඳින් ඉටු කරන දෙවන කාර්යය වන්නේ සාමාන්ය කාර්යයන් විශාල සංඛ්යාවක් ස්වයංක්රීය කිරීමට අවශ්ය වූ විටය. පද්ධති පරිපාලකයන්ගෙන් මයික්‍රොටාස්ක් ඉවත් කරයි.
මෙය වඩාත් අවශ්ය වන්නේ එක්කෝ ඔවුන්ගේ ගමන ආරම්භ කරන අයට හෝ බොහෝ ස්වයංක්‍රීයකරණය කිරීමට අවශ්ය අයට ය.
ක්රියාකරු මත පදනම් වූ ප්රවේශය අනෙකුත් පද්ධති වලින් වෙනස් වන්නේ කෙසේද? හෙල්ම් ඉන්නවා. එය ClickHouse ස්ථාපනය කිරීමට ද උපකාරී වේ; ඔබට හෙල්ම් ප්‍රස්ථාර අඳින්න පුළුවන්, එය සම්පූර්ණ ClickHouse පොකුරක් පවා ස්ථාපනය කරයි. ක්රියාකරු සහ එකම අතර වෙනස කුමක්ද, උදාහරණයක් ලෙස, හෙල්ම්?
ප්රධාන මූලික වෙනස වන්නේ Helm යනු පැකේජ කළමනාකරණය සහ ක්රියාකරු තවත් පියවරක් ඉදිරියට යාමයි. මෙය සමස්ත ජීවන චක්රය සඳහා ආධාරකයකි. මෙය ස්ථාපනය පමණක් නොවේ, මේවා පරිමාණය කිරීම, බෙදා හැරීම, එනම් ජීවන චක්රය තුළ කළ යුතු සියල්ල (අවශ්ය නම්, පසුව මකාදැමීම ද) ඇතුළත් වන එදිනෙදා කාර්යයන් වේ - මේ සියල්ල ක්රියාකරු විසින් තීරණය කරනු ලැබේ. එය සමස්ත මෘදුකාංග ජීවන චක්‍රයම ස්වයංක්රීය කිරීමට සහ නඩත්තු කිරීමට උත්සාහ කරයි. ඉදිරිපත් කරන අනෙකුත් විසඳුම් වලින් එහි මූලික වෙනස මෙයයි.
එය හඳුන්වාදීමේ කොටස විය, අපි ඉදිරියට යමු.
අපි අපගේ ක්රියාකරු ගොඩනඟන්නේ කෙසේද? අපි ClickHouse පොකුර තනි සම්පතක් ලෙස කළමනාකරණය කිරීමට ගැටලුව වෙත ප්‍රවේශ වීමට උත්සාහ කරන්නෙමු.
මෙන්න අපි පින්තූරයේ වම් පැත්තේ ආදාන දත්ත ඇත. මෙය පොකුරු පිරිවිතරයක් සහිත YAML වේ, එය kubectl හරහා සම්භාව්‍ය ආකාරයෙන් Kubernetes වෙත යවනු ලැබේ. එතනදී අපේ ඔපරේටර් ඒක උස්සලා එයාගේ මැජික් එක කරනවා. නිමැවුමේදී අපට පහත යෝජනා ක්රමය ලැබේ. මෙය Kubernetes හි ClickHouse ක්රියාත්මක කිරීමකි.
ඉන්පසුව අපි ක්රියාකරු හරියටම ක්රියා කරන්නේ කෙසේද, සාමාන්ය කාර්යයන් විසඳිය හැකි ආකාරය දෙස සෙමින් බලමු. අපට සීමිත කාලයක් ඇති බැවින් අපි සාමාන්ය කාර්යයන් පමණක් සලකා බලමු. තවද ක්රියාකරුට තීරණය කළ හැකි සෑම දෙයක්ම සාකච්ඡා නොකෙරේ.
අපි පුහුණුවීම් වලින් පටන් ගනිමු. අපගේ ව්යාපෘතිය සම්පූර්ණයෙන්ම විවෘත මූලාශ්‍රයක් වන අතර, එය GitHub මත ක්රියා කරන ආකාරය ඔබට දැක ගත හැක. ඔබට එය දියත් කිරීමට අවශ්ය නම්, ඔබට ඉක්මන් ආරම්භක මාර්ගෝපදේශය සමඟ ආරම්භ කළ හැකි සලකා බැලීම් වලින් ඔබට ඉදිරියට යා හැකිය.
ඔබට සවිස්තරාත්මකව අවබෝධ කර ගැනීමට අවශ්ය නම්, අපි ලේඛන වඩා අඩු හෝ විනීත ආකාරයකින් පවත්වා ගැනීමට උත්සාහ කරමු.
ප්‍රායෝගික ගැටලුවකින් පටන් ගනිමු. අප සැමට ආරම්භ කිරීමට අවශ්ය පළමු කාර්යය වන්නේ පළමු උදාහරණය කෙසේ හෝ ක්රියාත්මක කිරීමයි. මම එය ක්රියා කරන ආකාරය ඇත්තටම නොදන්නවා වුවද, ක්රියාකරු භාවිතයෙන් ClickHouse දියත් කරන්නේ කෙසේද? අපි ප්‍රතිපත්ති ප්‍රකාශයක් ලියනවා, මොකද... k8s සමඟ ඇති සියලුම සන්නිවේදනය ප්‍රකාශන හරහා සන්නිවේදනය වේ.
මෙය එතරම් සංකීර්ණ ප්‍රකාශනයකි. අපි රතු පැහැයෙන් අවධාරණය කර ඇත්තේ අප අවධානය යොමු කළ යුතු දෙයයි. demo නමින් පොකුරක් නිර්මාණය කරන ලෙස අපි ක්‍රියාකරුගෙන් ඉල්ලා සිටිමු.
මේවා දැනට මූලික උදාහරණ වේ. ගබඩාව තවම විස්තර කර නැත, නමුත් අපි ටික වේලාවකට පසුව නැවත ගබඩාවට යමු. දැනට, අපි පොකුරු සංවර්ධනයේ ගතිකත්වය නිරීක්ෂණය කරන්නෙමු.
අපි මේ ප්‍රතිපත්ති ප්‍රකාශය හැදුවා. අපි එය අපගේ ක්රියාකරුට පෝෂණය කරමු. ඔහු වැඩ කළා, මැජික් කළා.
අපි කොන්සෝලය දෙස බලමු. සංරචක තුනක් උනන්දුවක් දක්වයි: පොඩ් එකක්, සේවා දෙකක් සහ ස්ටේට්ෆුල්සෙට් එකක්.
ක්රියාකරු වැඩ කර ඇති අතර, ඔහු හරියටම නිර්මාණය කළ දේ අපට දැක ගත හැකිය.
ඔහු මෙවැනි දෙයක් නිර්මාණය කරයි. අප සතුව සෑම අනුරුවක් සඳහාම StatefulSet, Pod, ConfigMap, සම්පූර්ණ පොකුර සඳහා ConfigMap ඇත. පොකුරට ඇතුල් වන ස්ථාන ලෙස සේවාවන් අවශ්ය වේ.
සේවා යනු මධ්‍යම ලෝඩ් බැලන්සර් සේවාව වන අතර එක් එක් අනුරුව සඳහා, එක් එක් කැබලි සඳහා ද භාවිතා කළ හැක.
අපේ මූලික පොකුර පෙනෙන්නේ මේ වගේ දෙයක්. එය එක් තනි නෝඩයකින්.
අපි තවත් ඉදිරියට ගොස් දේවල් සංකීර්ණ කරමු. අපි පොකුර කඩා දැමිය යුතුයි.
අපගේ කාර්යයන් වර්ධනය වෙමින් පවතී, ගතිකත්වය ආරම්භ වේ. අපි කෑල්ලක් එකතු කිරීමට අවශ්යයි. අපි සංවර්ධනය අනුගමනය කරමු. අපි අපේ පිරිවිතර වෙනස් කරනවා. අපට කැබලි දෙකක් අවශ්ය බව අපි පෙන්වා දෙමු.
පද්ධතියේ වර්ධනය සමඟ ගතිකව වර්ධනය වන එකම ගොනුව මෙයයි. ගබඩා අංකය, ගබඩා කිරීම තවදුරටත් සාකච්ඡා කරනු ඇත, මෙය වෙනම මාතෘකාවකි.
අපි YAML ක්රියාකරු පෝෂණය කර සිදුවන්නේ කුමක්දැයි බලමු.
ක්රියාකරු කල්පනා කර පහත ආයතන සෑදුවේය. අපට දැනටමත් Pods දෙකක්, සේවා තුනක් සහ, හදිසියේ, StatefulSets 2ක් ඇත. ස්ටේට්ෆුල් සෙට් 2ක් ඇයි?
රූප සටහනේ එය මෙසේ විය - මෙය අපගේ ආරම්භක තත්වයයි, අපට එක් පොඩ් එකක් තිබූ විට.
ඒක මෙහෙම වුණා. මෙතෙක් සෑම දෙයක්ම සරලයි, එය අනුපිටපත් කර ඇත.
සහ රාජ්‍ය කට්ටල දෙකක් බවට පත් වූයේ ඇයි? මෙහිදී අපි Kubernetes හි Pods කළමනාකරණය කරන්නේ කෙසේද යන ප්‍රශ්නය අපගමනය කර සාකච්ඡා කළ යුතුය.
template එකකින් Pods සෙට් එකක් හදන්න පුලුවන් StatefulSet කියලා object එකක් තියෙනවා. මෙහි ප්රධාන සාධකය වන්නේ සැකිල්ලයි. තවද ඔබට එක් StatefulSet එකක එක අච්චුවක් භාවිතයෙන් Pods බොහොමයක් දියත් කළ හැක. මෙහි ප්රධාන වාක්‍ය ඛණ්ඩය වන්නේ “එක් අච්චුවක් සඳහා බොහෝ පොඩ්ස්” යන්නයි.
ඒ වගේම මුළු පොකුරම එක ස්ටේට්ෆුල් සෙට් එකකට අසුරන්න ලොකු පෙළඹවීමක් තිබුණා. එය වැඩ කරනු ඇත, එහි කිසිදු ගැටළුවක් නොමැත. නමුත් එක් අවවාදයක් තිබේ. අපට විෂමජාතීය පොකුරක් එකලස් කිරීමට අවශ්ය නම්, එනම් ClickHouse හි අනුවාද කිහිපයකින්, අපගේ ප්රශ්න ආරම්භ වේ. ඔව්, StatefulSet හට පෙරළීමේ යාවත්කාලීනයක් කළ හැකි අතර, එහිදී ඔබට නව අනුවාදයක් නිකුත් කළ හැකිය, ඔබ එකවර නෝඩ් ගණනකට වඩා උත්සාහ නොකළ යුතු බව පැහැදිලි කරන්න.
නමුත් අපි කාර්යය විකාශනය කර අපට සම්පූර්ණයෙන්ම විෂමජාතීය පොකුරක් සෑදීමට අවශ්ය යැයි පැවසුවහොත් සහ රෝලිං යාවත්කාලීනයක් භාවිතයෙන් පැරණි අනුවාදයේ සිට අලුත් එකකට වෙනස් කිරීමට අපට අවශ්ය නැත, නමුත් අපට අවශ්ය වන්නේ වචන දෙකෙන්ම විෂමජාතීය පොකුරක් සෑදීමයි. ClickHouse හි විවිධ අනුවාදවල සහ විවිධ ගබඩා අනුව. අපට අවශ්ය වන්නේ, උදාහරණයක් ලෙස, වෙනම තැටිවල, මන්දගාමී ඒවා මත, සාමාන්යයෙන්, සම්පූර්ණයෙන්ම විෂමජාතීය පොකුරක් සෑදීමට අනුරූ කිහිපයක් සෑදීමටය. ඒ වගේම StatefulSet එක ටෙම්ප්ලේට් එකකින් ප්‍රමිතිගත විසඳුමක් හදන නිසා මේක කරන්න විදියක් නෑ.
ටිකක් කල්පනා කරලා මේ විදියට කරමු කියලා තීරණය කළා. අපට සෑම අනුරුවක්ම එහිම StatefulSet තුළ ඇත. මෙම විසඳුමෙහි යම් අඩුපාඩු තිබේ, නමුත් ප්රායෝගිකව එය ක්රියාකරු විසින් සම්පූර්ණයෙන්ම ආවරණය කර ඇත. ඒ වගේම වාසි ගොඩක් තියෙනවා. අපට අවශ්ය නිශ්චිත පොකුරක් ගොඩනගා ගත හැකිය, උදාහරණයක් ලෙස, පරම විෂමජාතීය එකක්. එබැවින්, අපට එක් අනුරුවක් සහිත කැබලි දෙකක් ඇති පොකුරක, අපට ස්ටේට්ෆුල්සෙට් 2 ක් සහ පොඩ්ස් 2 ක් ලැබෙනු ඇත, මන්ද අපි විෂමජාතීය පොකුරක් තැනීමට ඉහත සඳහන් කළ හේතු නිසා මෙම ප්රවේශය තෝරා ගත් බැවිනි.
අපි ප්‍රායෝගික ගැටළු වෙත ආපසු යමු. අපගේ පොකුරේ අපට පරිශීලකයන් වින්යාස කිරීමට අවශ්ය වේ, i.e. ඔබ Kubernetes හි ClickHouse හි යම් වින්‍යාසයක් කළ යුතුය. ක්රියාකරු මේ සඳහා සියලු හැකියාවන් සපයයි.
අපිට ඕන දේ කෙලින්ම YAML එකේ ලියන්න පුළුවන්. සියලුම වින්යාස විකල්ප මෙම YAML වෙතින් ClickHouse configs වෙත සෘජුවම සිතියම්ගත කර ඇති අතර පසුව ඒවා පොකුර පුරා බෙදා හරිනු ලැබේ.
ඔබට එය මෙසේ ලිවිය හැකිය. උදාහරණයක් ලෙස මෙයයි. මුරපදය සංකේතනය කළ හැක. නියත වශයෙන්ම සියලුම ClickHouse වින්යාස විකල්ප සඳහා සහය දක්වයි. මෙන්න උදාහරණයක් විතරයි.
පොකුරු වින්යාසය ConfigMap ලෙස බෙදා හැරේ. ප්රායෝගිකව, ConfigMap යාවත්කාලීන කිරීම ක්ෂණිකව සිදු නොවේ, එබැවින් පොකුර විශාල නම්, පසුව වින්යාසය තල්ලු කිරීමේ ක්රියාවලිය යම් කාලයක් ගතවේ. නමුත් මේ සියල්ල භාවිතා කිරීමට ඉතා පහසු වේ.
කාර්යය සංකීර්ණ කරමු. පොකුර සංවර්ධනය වෙමින් පවතී. අපට දත්ත අනුකරණය කිරීමට අවශ්යයි. එනම්, අපට දැනටමත් කැබලි දෙකක් ඇත, එක් අනුරුව බැගින්, සහ පරිශීලකයන් වින්යාස කර ඇත. අපි වර්ධනය වෙමින් පවතින අතර අනුකරණය කිරීමට අවශ්යයි.
අනුකරණය සඳහා අපට අවශ්ය වන්නේ කුමක්ද?
අපිට ZooKeeper අවශ්යයි. ClickHouse හි, ZooKeeper භාවිතයෙන් අනුකරණය ගොඩනගා ඇත. ZooKeeper අවශ්ය වන අතර එමඟින් විවිධ ClickHouse අනුරූ වලට කුමන ClickHouse මත ඇති දත්ත අවහිර කිරීම් පිළිබඳව සම්මුතියක් ඇත.
ZooKeeper ඕනෑම කෙනෙකුට භාවිතා කළ හැකිය. ව්යවසායයට බාහිර සත්ව පාලකයෙකු තිබේ නම්, එය භාවිතා කළ හැකිය. එසේ නොවේ නම්, ඔබට එය අපගේ ගබඩාවෙන් ස්ථාපනය කළ හැකිය. මේ සියල්ල පහසු කරන ස්ථාපකයක් තිබේ.
සමස්ත පද්ධතියේ අන්තර්ක්රියා රූප සටහන මේ ආකාරයට හැරේ. අපට වේදිකාවක් ලෙස Kubernetes ඇත. එය ClickHouse ක්රියාකරු ක්රියාත්මක කරයි. මම මෙහි ZooKeeper ගේ පින්තුරය. තවද ක්රියාකරු ClickHouse සහ ZooKeeper යන දෙකම සමඟ අන්තර් ක්රියා කරයි. එනම්, අන්තර්ක්රියා ප්රතිඵල.
K8s හි දත්ත සාර්ථකව ප්‍රතිනිර්මාණය කිරීමට ClickHouse සඳහා මේ සියල්ල අවශ්ය වේ.
අපි දැන් කාර්යය දෙස බලමු, අනුකරණය සඳහා මැනිෆෙස්ටය කෙබඳු වේද යන්න.
අපි අපේ මැනිෆෙස්ටයට කොටස් දෙකක් එකතු කරනවා. පළමුවැන්න නම් ZooKeeper ලබා ගත හැකි ස්ථානයයි, එය Kubernetes ඇතුළත හෝ බාහිර විය හැකිය. මෙය විස්තරයක් පමණි. අපි අනුපිටපත් ඇණවුම් කරන්නෙමු. එම. අපට අනුරූ දෙකක් අවශ්යයි. සමස්තයක් වශයෙන්, ප්රතිදානයේදී අපට කරල් 4 ක් තිබිය යුතුය. ගබඩාව ගැන අපට මතකයි, එය ටික වේලාවකට පසුව නැවත පැමිණෙනු ඇත. ගබඩා කිරීම වෙනම කතාවකි.
එය මෙසේ විය.
ඒක මෙහෙම වෙනවා. අනුරූ එකතු කරනු ලැබේ. 4 වෙනි එක ගැලපෙන්නේ නැහැ, අපි විශ්වාස කරනවා ඔවුන්ගෙන් බොහෝ දෙනෙක් එහි සිටිය හැකි බව. ඒ වගේම ZooKeeper පැත්තට එකතු වෙනවා. යෝජනා ක්රම වඩාත් සංකීර්ණ වෙමින් පවතී.
ඊළඟ කාර්යය එකතු කිරීමට කාලයයි. අපි ස්ථිර ගබඩාව එකතු කරන්නෙමු.
ස්ථිර ගබඩා කිරීම සඳහා අපට විවිධ විකල්ප තිබේ.
අපි ක්ලවුඩ් සපයන්නෙකු තුළ ක්රියාත්මක වන්නේ නම්, උදාහරණයක් ලෙස, ඇමේසන්, ගූගල් භාවිතා කරමින්, වලාකුළු ආචයනය භාවිතා කිරීමට විශාල පෙළඹවීමක් ඇත. එය ඉතා පහසුයි, එය හොඳයි.
සහ දෙවන විකල්පය ඇත. මෙය දේශීය ගබඩා කිරීම සඳහා වන අතර, අපි එක් එක් නෝඩය මත දේශීය තැටි ඇති විට. මෙම විකල්පය ක්රියාත්මක කිරීම වඩාත් අපහසු වේ, නමුත් ඒ සමගම එය වඩා ඵලදායී වේ.
අපි බලමු Cloud Storage ගැන මොනවද තියෙන්නේ කියලා.
වාසි ඇත. එය වින්යාස කිරීම ඉතා පහසුය. අපි වලාකුළු සපයන්නාගෙන් ඇණවුම් කරන්නෙමු, කරුණාකර එවැනි සහ එවැනි පන්තියක එවැනි ධාරිතාවක් ගබඩා කරන්න. පන්ති ස්වාධීනව සපයන්නන් විසින් සැලසුම් කර ඇත.
ඒ වගේම අඩුපාඩුවක් තියෙනවා. සමහරුන්ට මෙය විවේචනාත්මක නොවන අඩුපාඩුවකි. ඇත්ත වශයෙන්ම, සමහර කාර්ය සාධන ගැටළු ඇති වනු ඇත. එය භාවිතා කිරීමට ඉතා පහසු සහ විශ්වසනීය, නමුත් සමහර විභව කාර්ය සාධන අඩුපාඩු තිබේ.
සහ නිසා ClickHouse ඵලදායිතාව කෙරෙහි විශේෂයෙන් අවධානය යොමු කරයි, එය කළ හැකි සෑම දෙයක්ම මිරිකන බව කෙනෙකුට පැවසිය හැකිය, එබැවින් බොහෝ සේවාදායකයින් උපරිම ඵලදායිතාව මිරිකීමට උත්සාහ කරයි.
තවද එයින් උපරිම ප්‍රයෝජන ලබා ගැනීමට අපට දේශීය ගබඩාව අවශ්ය වේ.
Kubernetes හි දේශීය ගබඩාව භාවිතා කිරීම සඳහා Kubernetes සාරාංශ තුනක් සපයයි. මෙය:
- EmptyDir
- HostPath.
- දේශීය
ඒවා වෙනස් වන්නේ කෙසේද සහ ඒවා සමාන වන්නේ කෙසේදැයි බලමු.
පළමුව, ප්‍රවේශයන් තුනෙහිම අපට ගබඩාව ඇත - මේවා එකම භෞතික k8s නෝඩයේ පිහිටා ඇති දේශීය තැටි වේ. නමුත් ඔවුන්ට යම් වෙනස්කම් තිබේ.
අපි සරලම එකකින් පටන් ගනිමු, එනම් හිස් ඩීර්. ප්රායෝගිකව මෙය කුමක්ද? අපගේ පිරිවිතර අනුව, දේශීය තැටියේ ඇති ෆෝල්ඩරයකට ප්රවේශය ලබා දෙන ලෙස අපි බහාලුම් පද්ධතියෙන් (බොහෝ විට ඩොකර්) ඉල්ලා සිටිමු.
ප්රායෝගිකව, ඩොකර් තමන්ගේම මාර්ග ඔස්සේ කොහේ හරි තාවකාලික ෆෝල්ඩරයක් සාදා එය දිගු හැෂ් ලෙස හඳුන්වයි. සහ එයට ප්‍රවේශ වීමට අතුරු මුහුණතක් සපයයි.
කාර්ය සාධනය අනුව මෙය ක්රියා කරන්නේ කෙසේද? මෙය දේශීය තැටි වේගයෙන් ක්රියා කරනු ඇත, i.e. මෙය ඔබගේ ඉස්කුරුප්පු ඇණ වෙත සම්පූර්ණ ප්රවේශය වේ.
නමුත් මෙම නඩුවේ අවාසි ඇත. මෙම කාරණය සම්බන්ධයෙන් ස්ථීර වීම තරමක් සැක සහිත ය. පළමු වතාවට Docker බහාලුම් සමඟ ගමන් කරන විට, Persistent නැති වී යයි. කිසියම් හේතුවක් නිසා Kubernetes හට මෙම Pod වෙනත් තැටියකට ගෙන යාමට අවශ්ය නම්, දත්ත නැති වී යනු ඇත.
මෙම ප්රවේශය පරීක්ෂණ සඳහා හොඳයි, එය දැනටමත් සාමාන්ය වේගය පෙන්නුම් කරන නිසා, නමුත් බරපතල දෙයක් සඳහා මෙම විකල්පය සුදුසු නොවේ.
එබැවින් දෙවන ප්රවේශයක් ඇත. මෙය hostPath වේ. කලින් Slide එකයි මේකයි බැලුවොත් එක වෙනසක් විතරයි පේන්නේ. අපගේ ෆෝල්ඩරය Docker වෙතින් කෙලින්ම Kubernetes node වෙත මාරු විය. මෙතන ටිකක් සරලයි. අපි අපගේ දත්ත ගබඩා කිරීමට කැමති දේශීය ගොනු පද්ධතියේ මාර්ගය සෘජුවම සඳහන් කරමු.
මෙම ක්රමය වාසි ඇත. මෙය දැනටමත් සැබෑ ස්ථීර එකක් වන අතර එය සම්භාව්‍ය එකක්. අපි යම් ලිපිනයක තැටියේ දත්ත වාර්තා කර ඇත.
අවාසි ද ඇත. කළමනාකරණයේ සංකීර්ණත්වය මෙයයි. අපගේ Kubernetes Pod වෙනත් භෞතික නෝඩයකට ගෙන යාමට අවශ්ය විය හැක. DevOps ක්රියාත්මක වන ස්ථානය මෙයයි. මෙම කරල් මාරු කළ හැක්කේ ඔබ මෙම මාර්ග ඔස්සේ යමක් සවි කර ඇති එම නෝඩ් වෙත පමණක් බවත්, වරකට නෝඩ් එකකට වඩා නොමැති බවත් ඔහු සමස්ත පද්ධතියටම නිවැරදිව පැහැදිලි කළ යුතුය. එය තරමක් අපහසුයි.
විශේෂයෙන්ම මෙම අරමුණු සඳහා, මෙම සියලු සංකීර්ණත්වය සැඟවීම සඳහා අපි අපගේ ක්රියාකරු තුළ සැකිලි සෑදුවෙමු. ඔබට සරලව පැවසිය හැකිය: "මට සෑම භෞතික නෝඩයක් සඳහාම සහ එවැනි මාර්ගයක් ඔස්සේ ClickHouse හි එක් අවස්ථාවක් ලබා ගැනීමට අවශ්යයි."
නමුත් මෙම අවශ්‍යතාවය අපට පමණක් අවශ්ය නොවේ, එබැවින් මිනිසුන්ට භෞතික තැටි වෙත ප්‍රවේශ වීමට අවශ්ය බව Kubernetes හි මහත්වරුන්ට ද වැටහෙන බැවින් ඔවුන් තුන්වන ස්ථරයක් සපයයි.
එය දේශීය ලෙස හැඳින්වේ. පෙර ස්ලයිඩයෙන් ප්රායෝගිකව වෙනසක් නොමැත. අපට මෙම කරල් නෝඩයේ සිට නෝඩයට මාරු කළ නොහැකි බව අතින් තහවුරු කිරීමට අවශ්ය වීමට පෙර පමණක්, ඒවා යම් මාර්ගයක් ඔස්සේ දේශීය භෞතික තැටියකට සම්බන්ධ කළ යුතු නමුත් දැන් මේ සියලු දැනුම කුබර්නෙටස් තුළම කොටු වී ඇත. තවද එය වින්යාස කිරීම වඩාත් පහසු වනු ඇත.
අපි නැවතත් අපගේ ප්‍රායෝගික ගැටලුව වෙත යමු. අපි YAML අච්චුව වෙත ආපසු යමු. මෙන්න අපට නියම ගබඩාව ඇත. අපි ආපහු ඒ පැත්තට ආවා. අපි සම්භාව්‍ය VolumeClaim අච්චුව k8s හි මෙන් සකසමු. තවද අපට අවශ්ය කුමන ආකාරයේ ගබඩාවක්ද යන්න අපි විස්තර කරමු.
මෙයින් පසු, k8s ගබඩාව ඉල්ලා සිටී. එය StatefulSet හි අපට වෙන් කරනු ඇත. අවසානයේ එය ClickHouse හි බැහැර වනු ඇත.
අපිට මේ ක්රමය තිබුණා. අපගේ ස්ථීර ගබඩාව රතු පැහැයෙන් යුක්ත වූ අතර, එය සිදු කළ යුතු බවට ඉඟියක් විය.
සහ එය කොළ පැහැයට හැරේ. දැන් ClickHouse on k8s පොකුරු යෝජනා ක්රමය සම්පූර්ණයෙන්ම අවසන් කර ඇත. අප සතුව කැබලි, අනුරූ, ZooKeeper, අපට සැබෑ Persistent ඇත, එය එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් ක්රියාත්මක වේ. යෝජනා ක්රමය දැනටමත් සම්පූර්ණයෙන්ම ක්රියාත්මක වේ.
අපි දිගටම ජීවත් වෙනවා. අපේ පොකුර දියුණු වෙනවා. සහ ඇලෙක්සි උත්සාහ කර ක්ලික්හවුස් හි නව අනුවාදයක් නිකුත් කරයි.
ප්‍රායෝගික කාර්යයක් පැන නගී - අපගේ පොකුරේ ClickHouse හි නව අනුවාදය පරීක්ෂා කිරීමට. තවද, ස්වාභාවිකවම, ඔබට ඒ සියල්ල පෙරළීමට අවශ්ය නැත; ඔබට නව අනුවාදයක් ඈත කෙළවරේ කොතැනක හෝ එක් අනුරුවක තැබීමට අවශ්ය වේ, සමහර විට එක් නව අනුවාදයක් නොව එකවර දෙකක්, ඒවා බොහෝ විට එළියට එන නිසා.
මේ ගැන අපට කුමක් කිව හැකිද?
මෙන්න අපට ඇත්තේ එවැනි අවස්ථාවක් පමණි. මේවා Pod templates. විෂමජාතීය පොකුරක් සෑදීමට අපගේ ක්රියාකරු සම්පූර්ණයෙන්ම ඉඩ ලබා දෙන බව ඔබට ලිවිය හැකිය. එම. වින්යාස කරන්න, පොකුරක් තුළ ඇති සියලුම අනුරූ වලින් පටන් ගෙන, එක් එක් පුද්ගලික අනුරුවකින් අවසන් වේ, අපට ක්ලික්හවුස් අවශ්ය කුමන අනුවාදයද, අපට ගබඩා කිරීමට අවශ්ය අනුවාදයද. අපට අවශ්ය වින්යාසය සමඟ පොකුර සම්පූර්ණයෙන්ම වින්‍යාසගත කළ හැකිය.
අපි ඇතුළට ටිකක් ගැඹුරට යමු. මෙයට පෙර, අපි ClickHouse හි විශේෂතා සම්බන්ධයෙන් ClickHouse-operator ක්රියා කරන ආකාරය ගැන කතා කළෙමු.
දැන් මම ඕනෑම ක්රියාකරුවෙකු සාමාන්යයෙන් ක්රියා කරන ආකාරය මෙන්ම K8s සමඟ අන්තර් ක්රියා කරන ආකාරය ගැන වචන කිහිපයක් කියන්නට කැමැත්තෙමි.
අපි මුලින්ම K8s සමඟ අන්තර්ක්රියා කිරීම බලමු. අපි kubectl යෙදූ විට කුමක් සිදුවේද? අපගේ වස්තූන් API හරහා etcd හි දිස්වේ.
උදාහරණයක් ලෙස, මූලික Kubernetes වස්තූන්: පොඩ්, ස්ටේට්ෆුල්සෙට්, සේවා, සහ යනාදිය ලැයිස්තුවේ.
ඒ අතරම, තවමත් භෞතික කිසිවක් සිදු නොවේ. මෙම වස්තූන් පොකුරේ ද්‍රව්‍යකරණය කළ යුතුය.
මෙම කාර්යය සඳහා, පාලකයක් දිස්වේ. පාලකය යනු මෙම විස්තර කර ගත හැකි විශේෂ k8s සංරචකයකි. ශාරීරිකව කුමක් කළ යුතුද සහ කෙසේද යන්න ඔහු දනී. ඔහු කන්ටේනර් ධාවනය කරන්නේ කෙසේදැයි දනී, සේවාදායකය ක්රියා කිරීම සඳහා එහි වින්‍යාසගත කළ යුතු දේ.
තවද එය K8s හි අපගේ වස්තූන් ද්‍රව්‍යකරණය කරයි.
නමුත් අපට Pods සහ StatefulSets සමඟ පමණක් ක්රියා කිරීමට අවශ්ය වේ, අපට එය තනි සමස්තයක් ලෙස ක්රියා කිරීම සඳහා ClickHouseInstallation, එනම් ClickHouse ආකාරයේ වස්තුවක් නිර්මාණය කිරීමට අවශ්‍යය. මෙතෙක් එවැනි හැකියාවක් නොමැත.
නමුත් K8s හි පහත හොඳ දෙයක් තිබේ. අපගේ පොකුර කරල් සහ StatefulSet වලින් එකලස් කරන ලද මෙම සංකීර්ණ ආයතනය වැනි කොතැනක හෝ අපට අවශ්ය වේ.
සහ මේ සඳහා කළ යුත්තේ කුමක්ද? පළමුව, අභිරුචි සම්පත් අර්ථ දැක්වීම පින්තූරයට පැමිණේ. එය කුමක්ද? මෙය K8s සඳහා වන විස්තරයකි, ඔබට තවත් එක් දත්ත වර්ගයක් ඇති බව, අපට Pod එකට අභිරුචි සම්පතක් එක් කිරීමට අවශ්ය බව, StatefulSet, එය ඇතුළත සංකීර්ණ වනු ඇත. මෙය දත්ත ව්යුහය පිළිබඳ විස්තරයකි.
අපි kubectl apply හරහාත් එතනට එවනවා. Kubernetes එය සතුටින් භාර ගත්තේය.
දැන් අපගේ ගබඩාවේ, etcd හි ඇති වස්තුවට ClickHouseInstallation නම් අභිරුචි සම්පත් පටිගත කිරීමට අවස්ථාව තිබේ.
නමුත් දැනට තවත් කිසිවක් සිදු නොවනු ඇත. එනම්, අපි දැන් කැබලි සහ අනුපිටපත් විස්තර කිරීමට බැලූ YAML ගොනුව නිර්මාණය කර “kubectl අයදුම් කරන්න” යැයි පැවසුවහොත්, Kubernetes එය පිළිගෙන, එය etcd තුළ තබා මෙසේ කියනු ඇත: “නියමයි, නමුත් මම කුමක් කළ යුතු දැයි මම නොදනිමි. එය සමඟ. ClickHouseInstallation නඩත්තු කරන්නේ කෙසේදැයි මම නොදනිමි."
ඒ අනුව, අපට Kubernetes නව දත්ත වර්ගය සේවය කිරීමට උදවු කිරීමට කෙනෙකු අවශ්යයි. වම් පසින් අපට ස්වදේශීය දත්ත වර්ග සමඟ ක්රියා කරන දේශීය Kubernetes පාලකයක් ඇත. දකුණු පසින් අපට අභිරුචි දත්ත වර්ග සමඟ වැඩ කළ හැකි අභිරුචි පාලකයක් තිබිය යුතුය.
තවත් ආකාරයකින් එය ක්රියාකරු ලෙස හැඳින්වේ. එය K8s වලින් පිටත ක්රියාත්මක කළ හැකි නිසා මම එය විශේෂයෙන්ම Kubernetes ලෙස මෙහි ඇතුළත් කළෙමි. බොහෝ විට, ඇත්ත වශයෙන්ම, සියලුම ක්රියාකරුවන් Kubernetes හි ක්රියාත්මක කරනු ලැබේ, නමුත් කිසිවක් එය පිටත සිටගෙන සිටීම වළක්වන්නේ නැත, එබැවින් මෙහි එය විශේෂයෙන් පිටතට ගෙන යනු ලැබේ.
අනෙක් අතට, අභිරුචි පාලකය, ක්රියාකරු ලෙසද හැඳින්වේ, API හරහා Kubernetes සමඟ අන්තර් ක්රියා කරයි. API සමඟ අන්තර්ක්රියා කරන්නේ කෙසේදැයි එය දැනටමත් දනී. තවද, අභිරුචි සම්පතකින් අපට සෑදීමට අවශ්ය සංකීර්ණ පරිපථය ද්‍රව්‍යකරණය කරන්නේ කෙසේදැයි ඔහු දැනටමත් දනී. ක්රියාකරු කරන්නේ මෙයයි.
ක්රියාකරු ක්රියා කරන්නේ කෙසේද? ඔහු එය කරන්නේ කෙසේදැයි බැලීමට අපි දකුණු පැත්ත දෙස බලමු. ක්රියාකරු මේ සියල්ල ක්‍රියාවට නංවන්නේ කෙසේද සහ K8s සමඟ තවදුරටත් අන්තර්ක්රියා කරන්නේ කෙසේදැයි සොයා බලමු.
ක්රියාකරු යනු වැඩසටහනකි. ඇය සිදුවීම් නැඹුරුයි. ක්රියාකරු Kubernetes API භාවිතයෙන් සිදුවීම් සඳහා දායක වේ. Kubernetes API හට ඔබට සිදුවීම් වලට දායක විය හැකි ප්‍රවේශ ස්ථාන ඇත. K8s හි යමක් වෙනස් වුවහොත්, Kubernetes සෑම කෙනෙකුටම සිදුවීම් යවයි, i.e. මෙම API ලක්ෂ්‍යයට දායක වී ඇති ඕනෑම අයෙකුට දැනුම්දීම් ලැබෙනු ඇත.
ක්රියාකරු සිදුවීම් වලට දායක වන අතර යම් ආකාරයක ප්රතික්රියාවක් කළ යුතුය. එහි කාර්යය වන්නේ නැගී එන සිදුවීම් වලට ප්රතිචාර දැක්වීමයි.
යම් යම් යාවත්කාලීන කිරීම් මගින් සිදුවීම් ජනනය වේ. ClickHouseInstallation පිළිබඳ විස්තරයක් සහිත අපගේ YAML ගොනුව පැමිණේ. ඌ etcd වලට ගියේ kubectl apply හරහා. එහිදී සිදුවීමක් ක්රියාත්මක වූ අතර එහි ප්‍රතිඵලයක් ලෙස මෙම සිදුවීම ClickHouse-operator වෙත පැමිණියේය. ක්රියාකරුට මෙම විස්තරය ලැබුණි. ඒ වගේම ඔහු යමක් කළ යුතුයි. ClickHouseInstallation වස්තුව සඳහා යාවත්කාලීනයක් පැමිණ තිබේ නම්, ඔබ පොකුර යාවත්කාලීන කළ යුතුය. තවද ක්රියාකරුගේ කාර්යය වන්නේ පොකුර යාවත්කාලීන කිරීමයි.
ඔහු මොනවද කරන්නේ? පළමුව, මෙම යාවත්කාලීනය සමඟ අප කරන්නේ කුමක්ද යන්න සඳහා ක්‍රියාකාරී සැලැස්මක් සකස් කළ යුතුය. යාවත්කාලීන ඉතා කුඩා විය හැක, i.e. YAML ක්රියාත්මක කිරීමේදී කුඩා, නමුත් පොකුරේ ඉතා විශාල වෙනස්කම් ඇති කළ හැක. එමනිසා, ක්රියාකරු සැලැස්මක් නිර්මාණය කරයි, පසුව ඔහු එයට ඇලී සිටී.
මෙම සැලැස්මට අනුව, ඔහු කරල්, සේවා, i.e. ඔහුගේ ප්රධාන කාර්යය කරන්න. Kubernetes හි ClickHouse පොකුරක් සාදන ආකාරය මෙයයි.
දැන් අපි එවැනි රසවත් දෙයක් ස්පර්ශ කරමු. මෙය Kubernetes සහ ක්රියාකරු අතර වගකීම් බෙදීමකි, i.e. Kubernetes කරන්නේ කුමක්ද, ක්රියාකරු කරන්නේ කුමක්ද සහ ඔවුන් එකිනෙකා සමඟ අන්තර් ක්රියා කරන ආකාරය.
පද්ධති දේවල් සඳහා Kubernetes වගකිව යුතුය, i.e. පද්ධති විෂය පථය ලෙස අර්ථ දැක්විය හැකි මූලික වස්තු කට්ටලයක් සඳහා. Kubernetes Pods දියත් කරන්නේ කෙසේද, බහාලුම් නැවත ආරම්භ කරන්නේ කෙසේද, පරිමාවන් සවි කරන්නේ කෙසේද, ConfigMap සමඟ වැඩ කරන්නේ කෙසේද, i.e. පද්ධතියක් ලෙස හැඳින්විය හැකි සෑම දෙයක්ම.
ක්රියාකරුවන් වසම් තුළ ක්රියාත්මක වේ. සෑම ක්‍රියාකරුවෙකුම තමන්ගේම විෂය ක්ෂේත්‍රය සඳහා සාදා ඇත. අපි එය ClickHouse සඳහා කළා.
අනුරුවක් එකතු කිරීම, රූප සටහනක් සෑදීම, අධීක්ෂණ සැකසීම වැනි විෂය ක්ෂේත්‍රය අනුව ක්රියාකරු නිශ්චිතවම අන්තර්ක්රියා කරයි. මෙය බෙදීමක් ඇති කරයි.
අපි add replica ක්‍රියාව කරන විට මෙම වගකීම් බෙදීම සිදුවන ආකාරය පිළිබඳ ප්‍රායෝගික උදාහරණයක් බලමු.
ක්රියාකරුට කාර්යයක් ලැබේ - අනුරුවක් එක් කිරීමට. ක්රියාකරු කරන්නේ කුමක්ද? නව StatefulSet එකක් නිර්මාණය කිරීමට අවශ්ය බව ක්රියාකරු විසින් ගණනය කරනු ලබන අතර, එවැනි සහ එවැනි සැකිලි, වෙළුම් හිමිකම් විස්තර කළ යුතුය.
ඔහු ඒ සියල්ල සූදානම් කර K8s වෙත ලබා දෙයි. ConfigMap, StatefulSet, Volume අවශ්ය බව ඔහු පවසයි. Kubernetes වැඩ කරනවා. ඔහු ක්රියාත්මක වන මූලික ඒකක ද්‍රව්‍යකරණය කරයි.
ඉන්පසු ClickHouse-operator නැවත ක්රියාත්මක වේ. ඔහුට දැනටමත් යමක් කළ හැකි භෞතික පොඩ් එකක් තිබේ. සහ ClickHouse-operator නැවතත් වසම් අනුව ක්රියා කරයි. එම. විශේෂයෙන් ClickHouse, පොකුරකට අනුරුවක් ඇතුළත් කිරීම සඳහා, ඔබ පළමුව, මෙම පොකුරේ පවතින දත්ත ක්රමය වින්‍යාසගත කළ යුතුය. තවද, දෙවනුව, මෙම අනුරුව පැහැදිලිව සොයා ගත හැකි වන පරිදි නිරීක්ෂණයට ඇතුළත් කළ යුතුය. ක්රියාකරු දැනටමත් මෙය වින්යාස කර ඇත.
ක්ලික්හවුස් ක්රියාත්මක වන්නේ ඉන් පසුව පමණි, i.e. තවත් ඉහළ මට්ටමේ ආයතනයක්. මෙය දැනටමත් දත්ත සමුදායකි. එයට තමන්ගේම අවස්ථාවක් ඇත, පොකුරට සම්බන්ධ වීමට සූදානම් තවත් වින්යාස කළ අනුරුවකි.
අනුරුවක් එකතු කිරීමේදී ක්රියාත්මක කිරීමේ දාමයක් සහ වගකීම් බෙදා හැරීම තරමක් දිගු බව පෙනේ.
අපි අපේ ප්‍රායෝගික කාර්යයන් දිගටම කරගෙන යනවා. ඔබට දැනටමත් පොකුරක් තිබේ නම්, ඔබට වින්යාසය සංක්‍රමණය කළ හැකිය.
අපි එය සෑදුවේ ඔබට ClickHouse තේරුම් ගන්නා දැනට පවතින xml වෙතට ඇලවිය හැකි පරිදිය.
ඔබට ClickHouse මනාව සකස් කළ හැක. Just zoned deployment යනු hostPath, local storage පැහැදිලි කිරීමේදී මා කතා කළ දෙයයි. කලාපීය යෙදවීම නිවැරදිව සිදු කරන්නේ කෙසේද යන්නයි.
ඊළඟ ප්‍රායෝගික කාර්යය වන්නේ නිරීක්ෂණයයි.
අපගේ පොකුර වෙනස් වුවහොත්, අපි වරින් වර අධීක්ෂණය වින්‍යාසගත කළ යුතුය.
අපි රූප සටහන දෙස බලමු. අපි දැනටමත් මෙහි හරිත ඊතල දෙස බැලුවෙමු. දැන් අපි රතු ඊතල දෙස බලමු. අපගේ පොකුර නිරීක්ෂණය කිරීමට අපට අවශ්ය වන්නේ එලෙසයි. ClickHouse පොකුරෙන් ප්‍රමිතික Prometheus වෙතට සහ පසුව Grafana වෙතට ඇතුල් වන ආකාරය.
නිරීක්ෂණය කිරීමේ දුෂ්කරතාවය කුමක්ද? මෙය යම් ආකාරයක ජයග්‍රහණයක් ලෙස ඉදිරිපත් කරන්නේ ඇයි? දුෂ්කරතාවය ගතිකත්වය තුළ පවතී. අපට එක පොකුරක් ඇති විට සහ එය ස්ථිතික වූ විට, අපට එක් වරක් නිරීක්ෂණ සැකසිය හැකි අතර තවදුරටත් කරදර නොවන්න.
නමුත් අපට පොකුරු ගොඩක් තිබේ නම්, හෝ යමක් නිරන්තරයෙන් වෙනස් වේ නම්, ක්රියාවලිය ගතික වේ. සහ නිරන්තරයෙන් අධීක්ෂණය නැවත සකස් කිරීම සම්පත් හා කාලය නාස්ති කිරීමකි, i.e. කම්මැලිකම පවා. මේක ස්වයංක්රීය කරන්න ඕන. දුෂ්කරතාවය පවතින්නේ ක්රියාවලියේ ගතිකත්වය තුළය. තවද ක්රියාකරු මෙය ඉතා හොඳින් ස්වයංක්රීය කරයි.
අපේ පොකුර දියුණු වුණේ කොහොමද? මුලදී ඔහු එහෙමයි.
එතකොට එයා මෙහෙමයි.
අන්තිමට එයා මෙහෙම උනා.
සහ අධීක්ෂණය ක්රියාකරු විසින් ස්වයංක්රීයව සිදු කරනු ලැබේ. ඇතුල් වීමේ තනි ස්ථානය.
පිටවීමේදී අපි ග්‍රැෆානා උපකරණ පුවරුව දෙස බලා අපගේ පොකුරේ ජීවය ඇතුළත තාපාංකය කරන්නේ කෙසේදැයි බැලීමට.
මාර්ගය වන විට, Grafana උපකරණ පුවරුව ද අපගේ ක්රියාකරු සමඟ සෘජුවම ප්‍රභව කේතයෙන් බෙදා හරිනු ලැබේ. ඔබට සම්බන්ධ වී භාවිතා කළ හැකිය. අපේ DevOps මට මෙම තිර රුවක් ලබා දුන්නා.
අපි ඊළඟට යාමට කැමති කොතැනටද? මෙය:
- පරීක්ෂණ ස්වයංක්‍රීයකරණය සංවර්ධනය කරන්න. ප්රධාන කාර්යය වන්නේ නව අනුවාදයන් ස්වයංක්රීයව පරීක්ෂා කිරීමයි.
- අපට ඇත්ත වශයෙන්ම ZooKeeper සමඟ ඒකාබද්ධ වීම ස්වයංක්රීය කිරීමට අවශ්යයි. තවද ZooKeeper-operator සමඟ ඒකාබද්ධ වීමට සැලසුම් කර ඇත. එම. ZooKeeper සඳහා ක්රියාකරුවෙකු ලියා ඇති අතර වඩාත් පහසු විසඳුමක් ගොඩනැගීම සඳහා ක්රියාකරුවන් දෙදෙනා ඒකාබද්ධ වීමට පටන් ගැනීම තර්කානුකූල ය.
- අපි වඩාත් සංකීර්ණ වැදගත් සංඥා කිරීමට අවශ්යයි.
- අපි සැකිලි වල උරුමය කරා ළඟා වෙමින් සිටින බව මම කොළ පැහැයෙන් අවධාරණය කළෙමි - DONE, එනම් ක්රියාකරුගේ මීළඟ නිකුතුවත් සමඟ අපට දැනටමත් අච්චු වල උරුමය ලැබෙනු ඇත. මෙය ඔබට කෑලි වලින් සංකීර්ණ වින්යාසයන් ගොඩනගා ගැනීමට ඉඩ සලසන බලවත් මෙවලමකි.
- තවද අපට සංකීර්ණ කාර්යයන් ස්වයංක්රීය කිරීම අවශ්ය වේ. ප්රධාන එක තමයි Re-sharding.
අපි බලමු අතරමැදි ප්රතිඵල ටිකක්.
එහි ප්‍රතිඵලයක් වශයෙන් අපට ලැබෙන්නේ කුමක්ද? සහ එය කිරීම වටී ද නැද්ද? දත්ත සමුදාය Kubernetes වෙත ඇදගෙන සාමාන්යයෙන් ක්රියාකරු සහ විශේෂයෙන් Alitnity ක්රියාකරු භාවිතා කිරීමට උත්සාහ කිරීම අවශ්‍යද?
ප්රතිදානයේදී අපට ලැබෙන්නේ:
- වින්යාස කිරීම, යෙදවීම සහ නඩත්තු කිරීම සැලකිය යුතු ලෙස සරල කිරීම සහ ස්වයංක්රීය කිරීම.
- වහාම ගොඩනඟන ලද අධීක්ෂණය.
- සහ සංකීර්ණ අවස්ථාවන් සඳහා භාවිතා කිරීමට සූදානම් සංකේතාත්මක සැකිලි. අනුරුවක් එකතු කිරීම වැනි ක්‍රියාවක් අතින් සිදු කිරීම අවශ්ය නොවේ. ක්රියාකරු මෙය කරයි.
අවසාන ප්‍රශ්නය පමණක් ඉතිරිව ඇත. අපට දැනටමත් Kubernetes, virtualization හි දත්ත ගබඩාවක් ඇත. විශේෂයෙන්ම ClickHouse කාර්ය සාධනය සඳහා ප්‍රශස්ත කර ඇති බැවින් එවැනි විසඳුමක කාර්ය සාධනය ගැන කුමක් කිව හැකිද?
පිළිතුර සෑම දෙයක්ම හොඳයි! මම විස්තරාත්මකව නොයමි; මෙය වෙනම වාර්තාවක මාතෘකාවයි.
නමුත් TSBS වැනි එවැනි ව්යාපෘතියක් තිබේ. එහි ප්රධාන කාර්යය කුමක්ද? මෙය දත්ත සමුදා කාර්ය සාධන පරීක්ෂණයකි. මෙය උණුසුම් සමග උණුසුම්, මෘදු හා මෘදු සමග සංසන්දනය කිරීමේ උත්සාහයකි.
ඔහු වැඩ කරන්නේ කෙසේද? එක් දත්ත කට්ටලයක් ජනනය වේ. එවිට මෙම දත්ත කට්ටලය එකම පරීක්ෂණ කට්ටලයක් භාවිතයෙන් විවිධ දත්ත සමුදායන් මත ධාවනය වේ. තවද සෑම දත්ත සමුදායක්ම එය දන්නා ආකාරයෙන් එක් ගැටළුවක් විසඳයි. එවිට ඔබට ප්රතිඵල සංසන්දනය කළ හැකිය.
එය දැනටමත් විශාල දත්ත සමුදායක් සඳහා සහය දක්වයි. මම ප්රධාන තුනක් හඳුනාගෙන තිබෙනවා. මෙය:
- කාල පරාසයDB.
- InfluxDB.
- ක්ලික් හවුස්.
තවත් සමාන විසඳුමක් සමඟ සැසඳීමක් ද සිදු කරන ලදී. RedShift සමඟ සැසඳීම. සැසඳීම ඇමේසන් මත සිදු කරන ලදී. ClickHouse ද මේ කාරණයේදී සෑම කෙනෙකුටම වඩා බොහෝ ඉදිරියෙන් සිටී.
මා පැවසූ දෙයින් ගත හැකි නිගමන මොනවාද?
- Kubernetes හි DB හැකි ය. බොහෝ විට ඕනෑම දෙයක් හැකි ය, නමුත් සමස්තයක් වශයෙන් එය හැකි බව පෙනේ. Kubernetes හි ClickHouse අපගේ ක්රියාකරුගේ සහාය ඇතිව අනිවාර්යයෙන්ම කළ හැකිය.
- ක්රියාකරු ක්‍රියාවලි ස්වයංක්රීය කිරීමට සහ ජීවිතය පහසු කිරීමට උපකාරී වේ.
- කාර්ය සාධනය සාමාන්යයි.
- තවද මෙය භාවිතා කළ හැකි සහ භාවිතා කළ යුතු බව අපට පෙනේ.
විවෘත මූලාශ්රය - අප හා එක්වන්න!
මම දැනටමත් පවසා ඇති පරිදි, ක්රියාකරු සම්පූර්ණයෙන්ම විවෘත මූලාශ්ර නිෂ්පාදනයක් වන අතර, එය උපරිම පුද්ගලයින් සංඛ්යාවක් භාවිතා කරන්නේ නම් එය ඉතා හොඳයි. අප හා එක් වන්න! අපි ඔබ සියලු දෙනාම බලා සිටිමු!
ඔබ සැමට ස්තූතියි!
ඔබගේ ප්රශ්න
වාර්තාවට ස්තූතියි! මගේ නම ඇන්ටන්. මම SEMrush වලින්. මම කල්පනා කරන්නේ ලොග් එකට මොකද වෙන්නේ කියලා. නිරීක්ෂණ ගැන අපට අසන්නට ලැබේ, නමුත් අපි සම්පූර්ණ පොකුර ගැන කතා කරන්නේ නම්, ලොග් කිරීම ගැන කිසිවක් නැත. උදාහරණයක් ලෙස, අපි දෘඩාංග මත පොකුරක් මතු කර ඇත. අපි මධ්‍යගත ලොග් කිරීම භාවිතා කරමු, ඒවා සම්මත ක්රම භාවිතා කරමින් පොදු ගොඩකට එකතු කරමු. ඊට පස්සේ එතනින් අපිට කැමති දත්ත ලැබෙනවා.
හොඳ ප්‍රශ්නයක්, එනම් todo ලැයිස්තුවකට ලොග් වීම. අපගේ ක්රියාකරු තවමත් මෙය ස්වයංක්රීය කර නැත. එය තවමත් සංවර්ධනය වෙමින් පවතී, ව්යාපෘතිය තවමත් තරමක් තරුණයි. ලොග් කිරීමේ අවශ්‍යතාවය අපි තේරුම් ගනිමු. මෙයද ඉතා වැදගත් මාතෘකාවකි. එය බොහෝ විට නිරීක්ෂණයට වඩා අඩු වැදගත්කමක් නැත. නමුත් ක්රියාත්මක කිරීම සඳහා වූ ලැයිස්තුවේ මුලින්ම තිබුණේ නිරීක්ෂණයයි. ලොග් කිරීමක් සිදුවනු ඇත. ස්වාභාවිකවම, අපි පොකුරේ ජීවිතයේ සියලු අංගයන් ස්වයංක්රීය කිරීමට උත්සාහ කරමු. එමනිසා, පිළිතුර නම්, මේ මොහොතේ ක්රියාකරු, අවාසනාවකට, මෙය කරන්නේ කෙසේදැයි නොදන්නා නමුත්, එය සැලසුම් කර ඇත, අපි එය කරන්නෙමු. ඔබට සම්බන්ධ වීමට අවශ්ය නම්, කරුණාකර ඉල්ලීම අදින්න.
ආයුබෝවන්! වාර්තාවට ස්තූතියි! මට Persistent Volumes සම්බන්ධ සම්මත ප්‍රශ්නයක් තිබේ. අපි මෙම ක්රියාකරු සමඟ වින්‍යාසයක් සාදන විට, අපට විශේෂිත තැටියක් හෝ ෆෝල්ඩරයක් අමුණා ඇත්තේ කුමන නෝඩයේද යන්න ක්රියාකරු තීරණය කරන්නේ කෙසේද? තැටියක් ඇති මෙම නෝඩ් මත කරුණාකර අපගේ ClickHouse එක තැබීමට අපි ඔහුට මුලින්ම පැහැදිලි කළ යුතුද?
මා තේරුම් ගත් පරිදි, මෙම ප්‍රශ්නය දේශීය ගබඩාවේ, විශේෂයෙන්ම එහි hostPath කොටසෙහි අඛණ්ඩ පැවැත්මකි. මෙය, අපට භෞතිකව සම්බන්ධිත තැටියක් ඇති, එවැනි සහ එවැනි මාර්ගයක් ඔස්සේ සවිකර ඇති එවැනි නෝඩයක් මත පොඩ් දියත් කළ යුතු බව සමස්ත පද්ධතියටම පැහැදිලි කිරීමක් වැනිය. මෙය මා ඉතා මතුපිටින් ස්පර්ශ කළ සම්පූර්ණ කොටසකි, මන්ද එහි පිළිතුර තරමක් විශාල බැවිනි.
කෙටියෙන් මේ වගේ. ස්වාභාවිකවම, අපි මෙම වෙළුම් ලබා දිය යුතුය. මේ මොහොතේ, දේශීය ගබඩාවේ ගතික ප්‍රතිපාදන නොමැත, එබැවින් DevOps තැටි තමන් විසින්ම කපා ගත යුතුය, මෙම වෙළුම්. එවැනි සහ එවැනි නෝඩ් මත පිහිටා ඇති එවැනි සහ එවැනි පන්තියේ ස්ථීර වෙළුම් ඔබ සතුව ඇති බව ඔවුන් Kubernetes විධිවිධාන පැහැදිලි කළ යුතුය. එවැනි සහ එවැනි දේශීය ගබඩා පන්තියක් අවශ්ය කරල් ලේබල් භාවිතා කරමින් එවැනි සහ එවැනි නෝඩ් වෙත පමණක් යොමු කළ යුතු බව ඔබට කුබර්නෙටස් වෙත පැහැදිලි කිරීමට අවශ්ය වනු ඇත. මෙම අරමුණු සඳහා, ක්රියාකරුට යම් ආකාරයක ලේබලයක් සහ එක් සත්කාරක අවස්ථාවකට එකක් පැවරීමේ හැකියාව ඇත. අවශ්‍යතා, ලේබල්, සරල වචනවලින් සපුරන නෝඩ් මත පමණක් ක්රියා කිරීමට කුබර්නෙටස් විසින් කරල් යොමු කරන බව පෙනී යයි. පරිපාලකයින් ලේබල් සහ ප්‍රතිපාදන තැටි අතින් පවරයි. ඉන්පසු එය පරිමාණය කරයි.
සහ එය තුන්වන විකල්පය, දේශීය, මෙය ටිකක් පහසු කිරීමට උපකාරී වේ. මම දැනටමත් අවධාරණය කර ඇති පරිදි, මෙය සුසර කිරීම පිළිබඳ වේදනාකාරී කාර්යයක් වන අතර, අවසානයේ උපරිම කාර්ය සාධනය ලබා ගැනීමට උපකාරී වේ.
මට මේ සම්බන්ධ දෙවන ප්‍රශ්නය ඇත. Kubernetes නිර්මාණය කර ඇත්තේ අපට නෝඩයක් නැති වුවත් නැතත් අපට වැදගත් නොවන ආකාරයට ය. අපගේ තුණ්ඩය එල්ලෙන නෝඩය අපට අහිමි වී ඇත්නම් මෙම නඩුවේදී අප කුමක් කළ යුතුද?
ඔව්, Kubernetes මුලින් ස්ථානගත කළේ අපගේ කරල් සමඟ අපගේ සම්බන්ධතාවය ගවයෙකු හා සමාන බවයි, නමුත් මෙහි අප සමඟ සෑම තැටියක්ම සුරතල් සතෙකු වැනි දෙයක් බවට පත්වේ. ඒවා නිකන් විසි කරන්න බැරි තරම් ප්‍රශ්නයක් තියෙනවා. කුබර්නෙටේස්ගේ දියුණුව එය සම්පූර්ණයෙන්ම ඉවතලන සම්පතක් මෙන් දාර්ශනිකව සම්පූර්ණයෙන්ම සැලකිය නොහැකි දිශාවකට ගමන් කරයි.
දැන් ප්‍රායෝගික ප්‍රශ්නයකට. තැටිය තිබූ නෝඩය ඔබට අහිමි වුවහොත් කුමක් කළ යුතුද? මෙහිදී ගැටලුව ඉහළ මට්ටමකින් විසඳනු ලැබේ. ClickHouse සම්බන්ධයෙන් ගත් කල, අපට ඉහළ මට්ටමකින් ක්රියා කරන අනුරූ ඇත, i.e. ClickHouse මට්ටමින්.
එහි ප්රතිඵලය කුමක්ද? දත්ත නැති නොවන බව සහතික කිරීම සඳහා DevOps වගකිව යුතුය. ඔහු නිවැරදිව අනුකරණය සැකසිය යුතු අතර අනුවර්තනය ක්රියාත්මක වන බවට සහතික විය යුතුය. ClickHouse මට්ටමේ අනුරුවෙහි අනුපිටපත් දත්ත තිබිය යුතුය. ක්රියාකරු විසඳන ගැටලුව මෙය නොවේ. කුබර්නෙට්ස් විසින්ම විසඳන ගැටලුව නොවේ. මෙය ClickHouse මට්ටමේ පවතී.
ඔබේ යකඩ නෝඩය වැටී ඇත්නම් කුමක් කළ යුතුද? ඔබට දෙවැන්න ස්ථාපනය කිරීමටත්, එය මත තැටිය නිසියාකාරව සැපයීමටත්, ලේබල් යෙදීමටත් අවශ්ය වනු ඇති බව පෙනේ. ඊට පසු, එය Kubernetes හට එය මත නිදසුන් පොඩ් එකක් දියත් කළ හැකි අවශ්‍යතා සපුරාලනු ඇත. Kubernetes එය දියත් කරනු ඇත. ඔබගේ කරල් ගණන නියමිත සංඛ්‍යාව සපුරාලීමට ප්‍රමාණවත් නොවේ. එය මා පෙන්වූ චක්රය හරහා ගමන් කරනු ඇත. සහ ඉහළම මට්ටමින්, ClickHouse අපි අනුරුවක් ඇතුළත් කර ඇති බව තේරුම් ගනීවි, එය තවමත් හිස්ව පවතින අතර අපි එයට දත්ත මාරු කිරීම ආරම්භ කළ යුතුය. එම. මෙම ක්රියාවලිය තවමත් හොඳින් ස්වයංක්රීය වී නොමැත.
වාර්තාවට ස්තූතියි! සියලු ආකාරයේ නරක දේවල් සිදු වූ විට, ක්රියාකරු බිඳ වැටී නැවත ආරම්භ වන අතර, එම මොහොතේ සිදුවීම් පැමිණෙන විට, ඔබ කෙසේ හෝ මෙය හසුරුවනවාද?
operator එක crash වෙලා Restart උනොත් මොකද වෙන්නේ නේද?
ඔව්. ඒ මොහොතේම සිදුවීම් පැමිණියේය.
මෙම නඩුවේ කුමක් කළ යුතුද යන්න පිළිබඳ කාර්යය ක්රියාකරු සහ Kubernetes අතර අර්ධ වශයෙන් බෙදා ඇත. Kubernetes හට සිදු වූ සිදුවීමක් නැවත ධාවනය කිරීමේ හැකියාව ඇත. ඔහු නැවත ධාවනය කරයි. ක්රියාකරුගේ කර්තව්‍යය වන්නේ සිදුවීම් ලොගය ඔහු මත නැවත ධාවනය වන විට, මෙම සිදුවීම් දුර්වල බව සහතික කිරීමයි. එකම සිදුවීම නැවත නැවත සිදුවීම අපගේ පද්ධතිය බිඳ නොදැමීමට. අපගේ ක්රියාකරු මෙම කාර්යය සමඟ සාර්ථකව කටයුතු කරයි.
ආයුබෝවන්! වාර්තාවට ස්තූතියි! Dmitry Zavyalov, සමාගම ස්මෙඩෝවා. haproxy සමඟ වින්යාස කිරීමේ හැකියාව ක්රියාකරුට එක් කිරීමට සැලසුම් කර තිබේද? සම්මත එක හැර වෙනත් සමතුලිතයක් ගැන මම උනන්දු වනු ඇත, එවිට එය බුද්ධිමත් වන අතර ClickHouse ඇත්ත වශයෙන්ම එහි ඇති බව තේරුම් ගනී.
ඔබ කතා කරන්නේ ඇතුල්වීම ගැනද?
ඔව්, Ingress වෙනුවට haproxy. haproxy වලදී ඔබට එහි අනුරූ ඇති පොකුරේ ස්ථලකය නියම කළ හැක.
අපි තවම ඒ ගැන හිතුවේ නැහැ. ඔබට එය අවශ්ය නම් සහ එය අවශ්ය වන්නේ මන්දැයි පැහැදිලි කළ හැකි නම්, විශේෂයෙන්ම ඔබට සහභාගී වීමට අවශ්ය නම්, එය ක්රියාත්මක කිරීමට හැකි වනු ඇත. විකල්පය සලකා බැලීමට අපි සතුටු වන්නෙමු. කෙටි පිළිතුර නම් නැත, අපට දැනට එවැනි ක්‍රියාකාරීත්වයක් නොමැත. ඔත්තුවට ස්තූතියි, අපි මේ කාරණය ගැන සොයා බලමු. තවද ඔබ භාවිතා කිරීමේ අවස්ථාව සහ එය ප්රායෝගිකව අවශ්ය වන්නේ මන්දැයි පැහැදිලි කරන්නේ නම්, උදාහරණයක් ලෙස, GitHub හි ගැටළු සාදන්න, එවිට එය විශිෂ්ට වනු ඇත.
දැනටමත් ඇත.
හොඳයි. ඕනෑම යෝජනා සඳහා අපි විවෘතයි. ඒවගේම haproxy todo ලැයිස්තුවට එකතු වෙනවා. ටෝඩෝ ලැයිස්තුව වර්ධනය වෙමින් පවතී, තවමත් හැකිලෙන්නේ නැත. නමුත් මෙය හොඳයි, එයින් අදහස් කරන්නේ නිෂ්පාදනයට ඉල්ලුමක් පවතින බවයි.
මූලාශ්රය: www.habr.com