හෙලෝ, හබ්ර්!
අපි Exness වේදිකාව කණ්ඩායම නියෝජනය කරනවා. මීට පෙර, අපගේ සගයන් දැනටමත් ලිපියක් ලියා ඇත . අද අපි Kubernetes වෙත සේවා සංක්‍රමණය කිරීමේ අපගේ අත්දැකීම් බෙදා ගැනීමට අවශ්‍යයි.
ආරම්භ කිරීම සඳහා, සාකච්ඡා කරනු ලබන දේ පිළිබඳ වඩා හොඳ අවබෝධයක් සඳහා අපි ඔබට අංක කිහිපයක් පිරිනමන්නෙමු:
- අපගේ සංවර්ධන දෙපාර්තමේන්තුව ස්වයංපෝෂිත QA, DevOps සහ Scrum ක්‍රියාවලි සහිත විවිධ කණ්ඩායම් 100කට වඩා ඇතුළුව පුද්ගලයන් 10+ කින් සමන්විත වේ. සංවර්ධන තොගය - පයිතන්, PHP, C++, Java සහ Golang.
- පරීක්ෂණ සහ නිෂ්පාදන පරිසරයන්හි විශාලත්වය බහාලුම් 2000ක් පමණ වේ. ඔවුන් ඔවුන්ගේම අථත්‍යකරණය සහ VMware යටතේ Rancher v1.6 ධාවනය කරයි.
අභිප්රේරණය
ඔවුන් පවසන පරිදි, කිසිවක් සදහටම පවතින්නේ නැත, සහ Rancher 1.6 අනුවාදය සඳහා සහය දැක්වීම බොහෝ කලකට පෙර නිවේදනය කළේය. ඔව්, වසර තුනකට වැඩි කාලයක් තුළ අපි එය සකස් කරන්නේ කෙසේද සහ පැන නගින ගැටළු විසඳන්නේ කෙසේදැයි ඉගෙන ගෙන ඇත, නමුත් බොහෝ විට අපි කිසි විටෙකත් නිවැරදි කළ නොහැකි ගැටළු වලට මුහුණ දී සිටිමු. Rancher 1.6 හි අයිතීන් නිකුත් කිරීම සඳහා අස්ථිගත පද්ධතියක් ද ඇත, එහිදී ඔබට සෑම දෙයක්ම පාහේ හෝ කිසිවක් කළ හැකිය.
හිමිකාර අථත්‍යකරණය දත්ත ගබඩා කිරීම සහ එහි ආරක්‍ෂාව පිළිබඳ වැඩි පාලනයක් සැපයූවද, එය සමාගමේ නිරන්තර වර්ධනය, ව්‍යාපෘති ගණන සහ ඒවා සඳහා අවශ්‍යතා අනුව පිළිගැනීමට අපහසු මෙහෙයුම් වියදම් පැනවීය.
අපට IaC ප්‍රමිතීන් අනුගමනය කිරීමට අවශ්‍ය වූ අතර, අවශ්‍ය නම්, ඕනෑම භූගෝලීය ස්ථානයක සහ විකුණුම්කරු අගුලක් නොමැතිව ඉක්මනින් ධාරිතාව ලබා ගැනීමටත්, එය ඉක්මනින් අත්හැරීමටත් හැකි විය.
පළමු පියවර
පළමුවෙන්ම, අපට අවශ්‍ය වූයේ කණ්ඩායම්වලට වේගවත් සංවර්ධන චක්‍රයක් ලබා ගැනීමට සහ බලය සපයන වේදිකාව සමඟ අන්තර් ක්‍රියා කිරීම සඳහා මෙහෙයුම් වියදම් අවම කිරීමට ඉඩ සලසන නවීන තාක්ෂණයන් සහ විසඳුම් මත විශ්වාසය තැබීමටයි.
ඇත්ත වශයෙන්ම, අපගේ මතකයට පැමිණි පළමු දෙය Kubernetes ය, නමුත් අපි කලබල නොවී එය නිවැරදි තේරීම දැයි බැලීමට කුඩා පර්යේෂණයක් කළෙමු. අපි විවෘත මූලාශ්‍ර විසඳුම් පමණක් ඇගයීමට ලක් කළ අතර, අසාධාරණ සටනකදී, Kubernetes කොන්දේසි විරහිතව ජයග්‍රහණය කළේය.
ඊළඟට පොකුරු නිර්මාණය කිරීම සඳහා මෙවලමක් තෝරා ගැනීමේ ප්රශ්නය මතු විය. අපි වඩාත් ජනප්රිය විසඳුම් සංසන්දනය කළෙමු: kops, kubespray, kubeadm.
ආරම්භ කිරීම සඳහා, kubeadm අපට පෙනුනේ "බයිසිකලයක්" නිපැයුම්කරුවෙකු මෙන් සංකීර්ණ මාර්ගයක් ලෙස වන අතර kops හට ප්රමාණවත් නම්යශීලී බවක් නොතිබුණි.
සහ ජයග්රාහකයා වූයේ:
අපි අපගේම අථත්‍යකරණය සහ AWS සමඟ අත්හදා බැලීම ආරම්භ කළෙමු, අපගේ පෙර සම්පත් කළමනාකරණ රටාවට දළ වශයෙන් සමාන යමක් ප්‍රතිනිර්මාණය කිරීමට උත්සාහ කළෙමු, එහිදී සියලු දෙනාම එකම “පොකුරු” බෙදා ගත්තෙමු. දැන් අපට කුඩා අතථ්‍ය යන්ත්‍ර 10 කින් යුත් අපගේ පළමු පොකුරක් ඇත, ඒවායින් කිහිපයක් AWS හි පිහිටා ඇත. අපි එහි කණ්ඩායම් සංක්‍රමණය වීමට උත්සාහ කළෙමු, සෑම දෙයක්ම “හොඳයි” බව පෙනෙන්නට තිබුණි, සහ කතාව අවසන් කළ හැකිය, නමුත් ...
පළමු ගැටළු
Ansible යනු kubespray ගොඩනගා ඇති දෙයයි, එය ඔබට IaC අනුගමනය කිරීමට ඉඩ සලසන මෙවලමක් නොවේ: නෝඩ් කොමිස් කිරීමේදී/විසන්ධි කිරීමේදී, යමක් නිරන්තරයෙන් වැරදී ගිය අතර යම් ආකාරයක මැදිහත්වීමක් අවශ්‍ය විය, සහ විවිධ OS භාවිතා කරන විට, ප්ලේබුක් වෙනස් ලෙස හැසිරුණි. . පොකුරේ කණ්ඩායම් සහ නෝඩ් ගණන වැඩි වන විට, ක්‍රීඩා පොත සම්පූර්ණ කිරීමට වැඩි කාලයක් හා වැඩි කාලයක් ගත වන බව අපි දැකීමට පටන් ගත් අතර, එහි ප්‍රතිඵලයක් ලෙස, අපගේ වාර්තාව පැය 3,5 ක් විය, ඔබේ ගැන කුමක් කිව හැකිද? 🙂
කුබෙස්ප්‍රේ නිකම්ම ඇන්සිබල් බව පෙනේ, බැලූ බැල්මට සියල්ල පැහැදිලිය, නමුත්:
ගමන ආරම්භයේදී, කාර්යය වූයේ AWS සහ අථත්‍යකරණය මත පමණක් ධාරිතාවන් දියත් කිරීමයි, නමුත් පසුව, බොහෝ විට සිදු වන පරිදි, අවශ්‍යතා වෙනස් විය.
මේ අනුව, අපගේ පැරණි සම්පත් එක් වාද්‍ය වෘන්ද පද්ධතියකට ඒකාබද්ධ කිරීමේ රටාව නොගැලපෙන බව පැහැදිලි විය - පොකුරු ඉතා දුරස්ථ වන අතර විවිධ සැපයුම්කරුවන් විසින් කළමනාකරණය කරනු ලැබේ.
තවද. සියලුම කණ්ඩායම් එකම පොකුරක් තුළ ක්‍රියා කරන විට, වැරදි ලෙස ස්ථාපනය කර ඇති NodeSelectors සහිත විවිධ සේවාවන් වෙනත් කණ්ඩායමක “විදේශීය” සත්කාරක වෙත පියාසර කර එහි සම්පත් භාවිතා කළ හැකි අතර, අපවිත්‍ර වී ඇත්නම්, එක් හෝ තවත් සේවාවක් ක්‍රියා නොකරන බවට නිරන්තර ඉල්ලීම් තිබුණි. මානව සාධකය නිසා නිවැරදිව බෙදා හරිනු නොලැබේ. තවත් ගැටළුවක් වූයේ පිරිවැය ගණනය කිරීම, විශේෂයෙන්ම නෝඩ් හරහා සේවා බෙදා හැරීමේ ගැටළු සලකා බැලීමයි.
වෙනම කතාවක් වූයේ සේවකයින්ට අයිතිවාසිකම් නිකුත් කිරීමයි: සෑම කණ්ඩායමකටම අවශ්‍ය වූයේ පොකුරේ “ප්‍රධානියා” වන අතර එය සම්පූර්ණයෙන්ම කළමනාකරණය කිරීමටයි, එය කණ්ඩායම් මූලික වශයෙන් එකිනෙකාගෙන් ස්වාධීන බැවින් සම්පූර්ණ බිඳවැටීමක් ඇති කළ හැකිය.
කෙසේ විය යුතුද?
ඉහත කරුණු සහ වඩාත් ස්වාධීන වීමට කණ්ඩායම්වල කැමැත්ත සැලකිල්ලට ගනිමින්, අපි සරල නිගමනයකට එළඹෙමු: එක් කණ්ඩායමක් - එක් පොකුරක්.
ඉතින් අපිට දෙවෙනි එකක් ලැබුණා:
ඉන්පසු තුන්වන පොකුර:
ඊට පස්සේ අපි හිතන්න පටන් ගත්තා: අවුරුද්දකින් අපේ කණ්ඩායම් වලට පොකුරු එකකට වඩා ඇති බව කියමු? විවිධ භූගෝලීය ප්රදේශ වල, උදාහරණයක් ලෙස, හෝ විවිධ සැපයුම්කරුවන්ගේ පාලනය යටතේද? සමහර පරීක්ෂණ සඳහා තාවකාලික පොකුරක් ඉක්මනින් යෙදවීමට ඔවුන්ගෙන් සමහරෙකුට අවශ්‍ය වනු ඇත.
සම්පූර්ණ Kubernetes පැමිණෙනු ඇත! මෙය MultiKubernetes වර්ගයකි, එය හැරෙනවා.
ඒ අතරම, අප සියල්ලන්ටම මෙම සියලු පොකුරු කෙසේ හෝ නඩත්තු කිරීමටත්, ඒවාට ප්‍රවේශය පහසුවෙන් කළමනාකරණය කිරීමටත්, නව ඒවා නිර්මාණය කිරීමටත්, අතින් මැදිහත් වීමකින් තොරව පැරණි ඒවා ඉවත් කිරීමටත් අවශ්‍ය වනු ඇත.
Kubernetes ලෝකයේ අපගේ ගමන ආරම්භයේ සිට යම් කාලයක් ගත වී ඇති අතර, පවතින විසඳුම් නැවත පරීක්ෂා කිරීමට අපි තීරණය කළෙමු. එය දැනටමත් වෙළඳපොලේ පවතින බව පෙනී ගියේය - Rancher 2.2.
අපගේ පර්යේෂණයේ පළමු අදියරේදී, Rancher Labs දැනටමත් 2 අනුවාදයේ පළමු නිකුතුව සිදු කර ඇත, නමුත් පරාමිති කිහිපයක් සමඟ බාහිර පරායත්තතාවයකින් තොරව බහාලුමක් දියත් කිරීමෙන් හෝ නිල HELM ප්‍රස්ථාරය භාවිතා කිරීමෙන් එය ඉතා ඉක්මනින් ඉහළ නැංවිය හැකි වුවද, එය අමු බව පෙනෙන්නට තිබුණි. අපට, සහ මෙම තීරණය මත විශ්වාසය තැබිය හැකිදැයි අපි දැන සිටියේ නැත, එය සංවර්ධනය කිරීම හෝ ඉක්මනින් අත්හැර දමනු ඇත. UI හි ඇති cluster = clicks paradigm ද අපට නොගැලපෙන අතර, RKE සමඟ සම්බන්ධ වීමට අපට අවශ්‍ය නොවීය, මන්ද එය තරමක් පටු ලෙස නාභිගත වූ මෙවලමකි.
Rancher 2.2 අනුවාදය දැනටමත් වඩාත් ක්‍රියා කළ හැකි පෙනුමක් ඇති අතර, පෙර ඒවා සමඟින්, බොහෝ බාහිර සැපයුම්කරුවන් සමඟ ඒකාබද්ධ වීම, අයිතිවාසිකම් බෙදා හැරීමේ තනි ලක්ෂ්‍යයක් සහ kubeconfig ගොනු, kubectl දියත් කිරීම වැනි සිත්ගන්නාසුලු විශේෂාංග රාශියක් තිබුණි. UI, කැදැලි නාම අවකාශ හෝ ව්‍යාපෘති තුළ ඔබේ අයිතීන් සහිත රූපය.
Rancher 2 වටා දැනටමත් ප්‍රජාවක් පිහිටුවා ඇති අතර, එය කළමනාකරණය කිරීම සඳහා HashiCorp Terraform නම් සැපයුම්කරුවෙකු නිර්මාණය කරන ලදී, එය අපට සියල්ල එකට තැබීමට උපකාරී විය.
සිදුවුයේ කුමක් ද
එහි ප්‍රතිඵලයක් වශයෙන්, අපි අවසන් කළේ Rancher ක්‍රියාත්මක වන එක් කුඩා පොකුරක් සමඟින්, අනෙකුත් සියලුම පොකුරු වලට ප්‍රවේශ විය හැකි, මෙන්ම එයට සම්බන්ධ බොහෝ පොකුරු, ldap බහලුම වෙත පරිශීලකයෙකු එක් කිරීම තරම් සරලව ප්‍රවේශය ලබා දිය හැක. එය පිහිටා ඇති ස්ථානය සහ එය භාවිතා කරන සැපයුම්කරුගේ සම්පත්.
gitlab-ci සහ Terraform භාවිතා කරමින්, ක්ලවුඩ් සපයන්නන්ගේ හෝ අපගේම යටිතල පහසුකම්වල ඕනෑම වින්‍යාසයක පොකුරක් සාදා ඒවා Rancher වෙත සම්බන්ධ කිරීමට ඔබට ඉඩ සලසන පද්ධතියක් නිර්මාණය කරන ලදී. මේ සියල්ල සිදු කරනු ලබන්නේ IaC විලාසයෙනි, එහිදී එක් එක් පොකුරු ගබඩාවක් මගින් විස්තර කර ඇති අතර එහි තත්වය අනුවාදනය කර ඇත. ඒ අතරම, බොහෝ මොඩියුල බාහිර ගබඩා වලින් සම්බන්ධ වී ඇති අතර එමඟින් ඉතිරිව ඇත්තේ විචල්‍යයන් සම්මත කිරීම හෝ අවස්ථා සඳහා ඔබේ අභිරුචි වින්‍යාසය විස්තර කිරීම පමණි, එය කේත පුනරාවර්තන ප්‍රතිශතය අඩු කිරීමට උපකාරී වේ.
ඇත්ත වශයෙන්ම, අපගේ ගමන බොහෝ දුරට අවසන් වී ඇති අතර, ඕනෑම පොකුරු වල ලඝු-සටහන් සහ ප්‍රමිතික සමඟ තනි වැඩ ලක්ෂයක්, සේවා දැලක්, බහු පොකුරක බර කළමනාකරණය කිරීම සඳහා gitops සහ තවත් බොහෝ දේ වැනි බොහෝ රසවත් කාර්යයන් තවමත් ඉදිරියෙන් ඇත. අපගේ අත්දැකීම් ඔබට රසවත් වනු ඇතැයි අපි බලාපොරොත්තු වෙමු!
ලිපිය ලියා ඇත්තේ A. Antipov, A. Ganush, Platform Engineers විසිනි.
මූලාශ්රය: www.habr.com