හෙල්ම් ආරක්ෂාව

Kubernetes සඳහා වඩාත්ම ජනප්‍රිය පැකේජ කළමනාකරු පිළිබඳ කතාවේ සාරය ඉමොජි භාවිතයෙන් නිරූපණය කළ හැකිය:

• පෙට්ටිය හෙල්ම් (එය නවතම ඉමොජි නිකුතුවට ආසන්නතම දෙයයි);
• අගුල - ආරක්ෂාව;
• කුඩා මිනිසා ගැටලුවට විසඳුමයි.

ඇත්ත වශයෙන්ම, සෑම දෙයක්ම ටිකක් සංකීර්ණ වනු ඇත, සහ කතාව පිළිබඳ තාක්ෂණික විස්තර පිරී ඇත හෙල්ම් ආරක්ෂිත කරන්නේ කෙසේද?.

• ඔබ නොදන්නා හෝ අමතක වූ අවස්ථාවක හෙල්ම් යනු කුමක්ද යන්න කෙටියෙන්. එය විසඳන්නේ කුමන ගැටළු සහ එය පරිසර පද්ධතියේ පිහිටා ඇති ස්ථානයයි.
• හෙල්ම් ගෘහ නිර්මාණ ශිල්පය දෙස බලමු. සංරචකයේ ගෘහ නිර්මාණ ශිල්පය තේරුම් නොගෙන ආරක්ෂාව සහ මෙවලමක් හෝ විසඳුමක් වඩාත් ආරක්ෂිත කරන්නේ කෙසේද යන්න පිළිබඳ කිසිදු සංවාදයක් සම්පූර්ණ නොවේ.
• අපි Helm සංරචක ගැන සාකච්ඡා කරමු.
• වඩාත්ම දැවෙන ප්රශ්නය අනාගතයයි - Helm 3 හි නව අනුවාදය. 

මෙම ලිපියේ ඇති සෑම දෙයක්ම Helm 2 සඳහා අදාළ වේ. මෙම අනුවාදය දැනට නිෂ්පාදනය වෙමින් පවතින අතර බොහෝ විට ඔබ දැනට භාවිතා කරන අනුවාදය වන අතර එය ආරක්ෂක අවදානම් අඩංගු අනුවාදය වේ.

කථිකයා ගැන: ඇලෙක්සැන්ඩර් ඛයෝරොව් (allexx) වසර 10 ක් තිස්සේ සංවර්ධනය වෙමින් පවතී, අන්තර්ගතය වැඩිදියුණු කිරීමට උපකාරී වේ මොස්කව් පයිතන් කන්ෆ් ++ සහ කමිටුවට සම්බන්ධ විය හෙල්ම් සමුළුව. දැන් ඔහු සංවර්ධන නායකයෙකු ලෙස Chainstack හි වැඩ කරයි - මෙය සංවර්ධන කළමනාකරුවෙකු සහ අවසාන නිකුතු ලබා දීමට වගකිව යුතු පුද්ගලයෙකු අතර දෙමුහුන් වර්ගයකි. එනම්, එය යුධ පිටියේ පිහිටා ඇති අතර, නිෂ්පාදනයක් නිර්මාණය කිරීමේ සිට එහි ක්රියාකාරිත්වය දක්වා සියල්ල සිදු වේ.

Chainstack යනු විමධ්‍යගත යෙදුම් ක්‍රියාත්මක කිරීමේ යටිතල පහසුකම් සහ සංකීර්ණතා අමතක කිරීමට ගනුදෙනුකරුවන්ට හැකි කිරීම එහි මෙහෙවර වන කුඩා, ක්‍රියාකාරීව වර්ධනය වන ආරම්භයකි; සංවර්ධන කණ්ඩායම සිංගප්පූරුවේ පිහිටා ඇත. Cryptocurrency විකිණීමට හෝ මිලදී ගැනීමට Chainstackගෙන් ඉල්ලා නොසිටින්න, නමුත් ව්‍යවසාය blockchain රාමු ගැන කතා කිරීමට ඉදිරිපත් වන්න, එවිට ඔවුන් ඔබට සතුටින් පිළිතුරු දෙනු ඇත.

හෙල්ම්

මෙය Kubernetes සඳහා පැකේජ (ප්‍රස්ථාර) කළමනාකරුවෙකි. Kubernetes පොකුරකට යෙදුම් ගෙන ඒමට වඩාත්ම අවබෝධාත්මක සහ විශ්වීය මාර්ගය.

ඇත්ත වශයෙන්ම, අපි ඔබේම YAML මැනිෆෙස්ට් නිර්මාණය කිරීමට සහ කුඩා උපයෝගිතා ලිවීමට වඩා ව්‍යුහාත්මක සහ කාර්මික ප්‍රවේශයක් ගැන කතා කරමු.

හෙල්ම් යනු දැනට පවතින සහ ජනප්‍රිය හොඳම එකයි.

ඇයි හෙල්ම්? මූලික වශයෙන් එය CNCF විසින් සහාය දක්වන බැවිනි. Cloud Native යනු විශාල සංවිධානයක් වන අතර Kubernetes, etcd, Fluentd සහ වෙනත් ව්‍යාපෘති සඳහා මව් සමාගම වේ.

තවත් වැදගත් කරුණක් වන්නේ හෙල්ම් ඉතා ජනප්‍රිය ව්‍යාපෘතියකි. මම 2019 ජනවාරි මාසයේදී Helm ආරක්ෂිත කරන්නේ කෙසේද යන්න ගැන කතා කිරීමට පටන් ගත් විට, ව්‍යාපෘතියට GitHub හි තරු දහසක් තිබුණි. මැයි මාසය වන විට ඔවුන්ගෙන් 12 දහසක් සිටියහ.

බොහෝ අය Helm ගැන උනන්දුයි, එබැවින් ඔබ තවමත් එය භාවිතා නොකළත්, එහි ආරක්ෂාව ගැන දැන ගැනීමෙන් ඔබට ප්‍රයෝජන ලැබෙනු ඇත. ආරක්ෂාව වැදගත්.

Core Helm කණ්ඩායමට Microsoft Azure විසින් සහය දක්වන අතර එම නිසා අනෙකුත් බොහෝ අය මෙන් නොව තරමක් ස්ථාවර ව්‍යාපෘතියකි. ජූලි මැද භාගයේදී Helm 3 Alpha 2 නිකුත් කිරීමෙන් පෙන්නුම් කරන්නේ ව්‍යාපෘතියේ බොහෝ පුද්ගලයින් වැඩ කරන බවත්, හෙල්ම් සංවර්ධනය කිරීමට සහ වැඩිදියුණු කිරීමට ඔවුන්ට ආශාවක් සහ ශක්තියක් ඇති බවත්ය.

හෙල්ම් Kubernetes හි යෙදුම් කළමනාකරණයේ මූලික ගැටළු කිහිපයක් විසඳයි.

• යෙදුම් ඇසුරුම්. WordPress හි "Hello, World" වැනි යෙදුමක් පවා දැනටමත් සේවා කිහිපයකින් සමන්විත වන අතර, ඔබට ඒවා එකට ඇසුරුම් කිරීමට අවශ්‍ය වේ.
• මෙම යෙදුම් කළමනාකරණය කිරීමේදී ඇතිවන සංකීර්ණත්වය කළමනාකරණය කිරීම.
• යෙදුම ස්ථාපනය කිරීමෙන් හෝ යෙදවීමෙන් පසු අවසන් නොවන ජීවන චක්‍රයක්. එය දිගටම ජීවත් වේ, එය යාවත්කාලීන කළ යුතු අතර, හෙල්ම් මේ සඳහා උදව් කරන අතර මේ සඳහා නිවැරදි පියවර සහ ප්‍රතිපත්ති ගෙන ඒමට උත්සාහ කරයි.

බෑග් කිරීම එය පැහැදිලි ආකාරයකින් සංවිධානය කර ඇත: Linux, Windows හෝ MacOS සඳහා සාමාන්‍ය පැකේජ කළමණාකරුවෙකුගේ කාර්යයට අනුකූලව පාර-දත්ත ඇත. එනම්, ගබඩාවක්, විවිධ පැකේජ මත යැපීම්, යෙදුම් සඳහා මෙටා තොරතුරු, සැකසුම්, වින්‍යාස කිරීමේ විශේෂාංග, තොරතුරු සුචිගත කිරීම යනාදිය. හෙල්ම් ඔබට මේ සියල්ල ලබා ගැනීමට සහ යෙදුම් සඳහා භාවිතා කිරීමට ඉඩ සලසයි.

සංකීර්ණ කළමනාකරණය. ඔබට එකම ආකාරයේ යෙදුම් බොහොමයක් තිබේ නම්, පරාමිතිකරණය අවශ්ය වේ. සැකිලි පැමිණෙන්නේ මෙයින්, නමුත් ඔබටම සැකිලි සෑදීමේ ක්‍රමයක් ඉදිරිපත් කිරීම වළක්වා ගැනීමට, ඔබට හෙල්ම් පෙට්ටියෙන් ලබා දෙන දේ භාවිතා කළ හැක.

යෙදුම් ජීවන චක්‍ර කළමනාකරණය - මගේ මතය අනුව, මෙය වඩාත් සිත්ගන්නාසුළු හා නොවිසඳුණු ප්රශ්නයයි. මේ නිසා තමයි මම එදා හෙල්ම් එකට ආවේ. අපට යෙදුම් ජීවන චක්‍රය නිරීක්ෂණය කිරීමට අවශ්‍ය වූ අතර අපගේ CI/CD සහ යෙදුම් චක්‍ර මෙම සුසමාදර්ශයට ගෙන යාමට අවශ්‍ය විය.

Helm ඔබට ඉඩ දෙන්නේ:

• යෙදවීම් කළමනාකරණය, වින්‍යාසය සහ සංශෝධනය පිළිබඳ සංකල්පය හඳුන්වා දෙයි;
• ආපසු හැරවීම සාර්ථකව සිදු කරන්න;
• විවිධ සිදුවීම් සඳහා කොකු භාවිතා කරන්න;
• අමතර යෙදුම් චෙක්පත් එකතු කර ඒවායේ ප්‍රතිඵලවලට ප්‍රතිචාර දක්වන්න.

ඊට අමතරව හෙල්ම් සතුව "බැටරි" ඇත - ඔබේ ජීවිතය සරල කරමින් ප්ලගීන ආකාරයෙන් ඇතුළත් කළ හැකි රසවත් දේවල් විශාල ප්‍රමාණයක්. ප්ලගීන ස්වාධීනව ලිවිය හැකිය, ඒවා තරමක් හුදකලා වන අතර එකඟතා ගෘහ නිර්මාණ ශිල්පයක් අවශ්ය නොවේ. ඔබට යමක් ක්‍රියාත්මක කිරීමට අවශ්‍ය නම්, එය ප්ලගිනයක් ලෙස සිදු කිරීමට මම නිර්දේශ කරමි, පසුව එය උඩුගං බලා ඇතුළත් කළ හැක.

හෙල්ම් ප්‍රධාන සංකල්ප තුනක් මත පදනම් වේ:

• ප්‍රස්ථාර රෙපෝ - ඔබගේ මැනිෆෙස්ටය සඳහා හැකි පරාමිතිකරණ විස්තරය සහ අරාව. 
• වින්‍යාසය - එනම්, අදාළ වන අගයන් (පෙළ, සංඛ්‍යාත්මක අගයන්, ආදිය).
• නිකුතු ඉහළ කොටස් දෙක එකතු කරයි, එකට ඒවා මුදා හැරීමට හැරේ. නිකුතු අනුවාද කළ හැක, එමගින් සංවිධිත ජීවන චක්‍රයක් සාක්ෂාත් කර ගත හැක: ස්ථාපනය කරන අවස්ථාවේදී කුඩා වන අතර උත්ශ්‍රේණිගත කිරීමේදී, පහත හෙලන විට හෝ ආපසු හැරීමේදී විශාල වේ.

හෙල්ම් ගෘහ නිර්මාණ ශිල්පය

රූප සටහන සංකල්පමය වශයෙන් හෙල්ම් හි ඉහළ මට්ටමේ ගෘහ නිර්මාණ ශිල්පය නිරූපණය කරයි.

Helm යනු Kubernetes හා සම්බන්ධ දෙයක් බව මම ඔබට මතක් කරමි. එමනිසා, අපට Kubernetes පොකුරක් (සෘජුකෝණාස්රය) නොමැතිව කළ නොහැක. kube-apiserver සංරචකය මාස්ටර් මත පවතී. Helm නොමැතිව අපට Kubeconfig ඇත. හෙල්ම් එක කුඩා ද්විමය එකක් ගෙන එයි, ඔබට එය හැඳින්විය හැකි නම්, පරිගණකයක, ලැප්ටොප් පරිගණකයක, ප්‍රධාන රාමුවක - ඕනෑම දෙයක් මත ස්ථාපනය කර ඇති හෙල්ම් සීඑල්අයි උපයෝගීතාව.

නමුත් මෙය ප්රමාණවත් නොවේ. Helm සතුව Tiller නම් සේවාදායක අංගයක් ඇත. එය පොකුර තුළ හෙල්ම්ගේ අවශ්‍යතා නියෝජනය කරයි; එය වෙනත් ඕනෑම දෙයක් මෙන් Kubernetes පොකුර තුළ යෙදුමකි.

Chart Repo හි මීළඟ සංරචකය වන්නේ ප්‍රස්ථාර සහිත ගබඩාවකි. නිල ගබඩාවක් ඇති අතර, සමාගමක හෝ ව්‍යාපෘතියක පුද්ගලික ගබඩාවක් තිබිය හැක.

අන්තර්ක්රියා

අපි Helm භාවිතයෙන් යෙදුමක් ස්ථාපනය කිරීමට අවශ්‍ය වූ විට ගෘහ නිර්මාණ සංරචක අන්තර්ක්‍රියා කරන ආකාරය බලමු.

• අපි කතා කරනවා Helm install, ගබඩාවට ප්‍රවේශ වන්න (ප්‍රස්ථාර රෙපෝ) සහ හෙල්ම් ප්‍රස්ථාරයක් ලබා ගන්න.

• Helm උපයෝගීතාව (Helm CLI) Kubeconfig සමඟ අන්තර්ක්‍රියා කරන්නේ කුමන පොකුර සම්බන්ධ කර ගත යුතුද යන්න සොයා බැලීම සඳහා ය. 
• මෙම තොරතුරු ලැබීමෙන් පසු, උපයෝගීතාව යෙදුමක් ලෙස අපගේ පොකුරේ පිහිටා ඇති ටිලර් වෙත යොමු කරයි. 
• ටිලර් Kubernetes හි ක්‍රියා සිදු කිරීමට, සමහර වස්තු (සේවා, කරල්, අනුරූ, රහස්, ආදිය) නිර්මාණය කිරීමට Kube-apiserver අමතන්න.

ඊළඟට, සමස්ත හෙල්ම් ගෘහ නිර්මාණ ශිල්පය නිරාවරණය කළ හැකි ප්‍රහාරක දෛශිකය බැලීමට අපි රූප සටහන සංකීර්ණ කරමු. එවිට අපි ඇයව ආරක්ෂා කිරීමට උත්සාහ කරමු.

ප්රහාරක දෛශිකය

පළමු විභව දුර්වල ලක්ෂ්යය වේ වරප්රසාදිත API-පරිශීලකයා. යෝජනා ක්‍රමයේ කොටසක් ලෙස, මෙය Helm CLI වෙත පරිපාලක ප්‍රවේශය ලබා ගත් හැකර්වරයෙකි.

වරප්රසාද ලත් API පරිශීලක එය අසල කොතැනක හෝ තිබේ නම් අනතුරුදායක විය හැකිය. එවැනි පරිශීලකයෙකුට වෙනත් සන්දර්භයක් ඇත, උදාහරණයක් ලෙස, ඔහු Kubeconfig සැකසුම් තුළ එක් පොකුරු නාම අවකාශයක් තුළ සවි කළ හැකිය.

වඩාත්ම සිත්ගන්නා ප්‍රහාරක දෛශිකය ටිලර් අසල කොතැනක හෝ පොකුරක් තුළ පවතින ක්‍රියාවලියක් විය හැකි අතර එයට ප්‍රවේශ විය හැක. මෙය පොකුරේ ජාල පරිසරය දකින වෙබ් සේවාදායකයක් හෝ ක්ෂුද්‍ර සේවාවක් විය හැකිය.

විදේශීය, නමුත් වැඩි වැඩියෙන් ජනප්‍රිය, ප්‍රහාරක ප්‍රභේදයකට Chart Repo ඇතුළත් වේ. නිර්දෝෂී කතුවරයෙකු විසින් නිර්මාණය කරන ලද ප්‍රස්ථාරයක අනාරක්ෂිත සම්පත් අඩංගු විය හැකි අතර, ඔබ එය ඇදහිල්ල මත ගෙන එය සම්පූර්ණ කරනු ඇත. නැතහොත් එය ඔබ නිල ගබඩාවෙන් බාගත කරන ප්‍රස්ථාරය ප්‍රතිස්ථාපනය කළ හැකි අතර, උදාහරණයක් ලෙස, ප්‍රතිපත්ති ආකාරයෙන් සම්පතක් නිර්මාණය කර එහි ප්‍රවේශය උත්සන්න කරයි.

අපි මෙම පැති හතරෙන් එල්ල වන ප්‍රහාර වළක්වා ගැනීමට උත්සාහ කරමු සහ හෙල්ම් ගෘහ නිර්මාණ ශිල්පයේ ගැටළු ඇත්තේ කොතැනද සහ සමහර විට ඒවා නොමැති ස්ථාන සොයා බලමු.

අපි රූප සටහන විශාල කරමු, තවත් මූලද්රව්ය එකතු කරමු, නමුත් සියලු මූලික සංරචක තබා ගන්න.

Helm CLI ප්‍රස්ථාර රෙපෝ සමඟ සන්නිවේදනය කරයි, Kubeconfig සමඟ අන්තර් ක්‍රියා කරයි, සහ කාර්යය පොකුරට ටිලර් සංරචකයට මාරු කරනු ලැබේ.

ටිලර් වස්තු දෙකකින් නියෝජනය වේ:

• Tiller-deploy svc, යම් සේවාවක් හෙළිදරව් කරයි;
• ටිලර්-ඩිප්ලෝයි පොඩ් (එක් අනුරුවක තනි පිටපතක රූප සටහනේ), පොකුරට ප්‍රවේශ වන සම්පූර්ණ භාරයම ක්‍රියාත්මක වේ.

අන්තර්ක්‍රියා සඳහා විවිධ ප්‍රොටෝකෝල සහ යෝජනා ක්‍රම භාවිතා වේ. ආරක්ෂක දෘෂ්ටි කෝණයකින්, අපි වඩාත් උනන්දු වන්නේ:

• Helm CLI ප්‍රස්ථාර රෙපෝ වෙත ප්‍රවේශ වන යාන්ත්‍රණය: කුමන ප්‍රොටෝකෝලය, සත්‍යාපනය තිබේද සහ එය සමඟ කළ හැකි දේ.
• හෙල්ම් CLI, kubectl භාවිතා කරමින්, Tiller සමඟ සන්නිවේදනය කරන ප්‍රොටෝකෝලය. මෙය පොකුර තුළ ස්ථාපනය කර ඇති RPC සේවාදායකයකි.
• Tiller විසින්ම පොකුරේ පවතින ක්ෂුද්‍ර සේවා වෙත ප්‍රවේශ විය හැකි අතර Kube-apiserver සමඟ අන්තර් ක්‍රියා කරයි.

අපි මේ සියලු ක්ෂේත්‍ර පිළිවෙලට සාකච්ඡා කරමු.

ආර්බීඒසී

RBAC සක්‍රීය කර ඇත්නම් මිස පොකුර තුළ හෙල්ම් හෝ වෙනත් සේවාවක් සඳහා ආරක්ෂාවක් ගැන කතා කිරීමෙන් පලක් නැත.

මෙය නවතම නිර්දේශය නොවන බව පෙනේ, නමුත් බොහෝ අය තවමත් නිෂ්පාදනයේදී පවා RBAC සක්‍රීය කර නොමැති බව මට විශ්වාසයි, මන්ද එය බොහෝ කලබලකාරී වන අතර බොහෝ දේ වින්‍යාසගත කිරීමට අවශ්‍ය වේ. කෙසේ වෙතත්, මෙය කිරීමට මම ඔබව දිරිමත් කරමි.

https://rbac.dev/ - RBAC සඳහා වෙබ් අඩවිය නීතිඥ. RBAC සැකසීමට, එය හොඳ වන්නේ ඇයි සහ නිෂ්පාදනයේදී එය සමඟ ජීවත් වන්නේ කෙසේද යන්න පෙන්වීමට ඔබට උපකාරී වන රසවත් ද්‍රව්‍ය විශාල ප්‍රමාණයක් එහි අඩංගු වේ.

Tiller සහ RBAC ක්‍රියා කරන ආකාරය පැහැදිලි කිරීමට මම උත්සාහ කරමි. ටිලර් යම් සේවා ගිණුමක් යටතේ පොකුර තුළ ක්‍රියා කරයි. සාමාන්‍යයෙන්, RBAC වින්‍යාස කර නොමැති නම්, මෙය සුපිරි පරිශීලකයා වනු ඇත. මූලික වින්‍යාසය තුළ, ටිලර් පරිපාලකයෙකු වනු ඇත. Tiller යනු ඔබේ පොකුරට SSH උමං මාර්ගයක් බව බොහෝ විට පවසන්නේ මේ නිසාය. ඇත්ත වශයෙන්ම, මෙය සත්‍යයකි, එබැවින් ඔබට ඉහත රූප සටහනේ පෙරනිමි සේවා ගිණුම වෙනුවට වෙනම කැපවූ සේවා ගිණුමක් භාවිතා කළ හැකිය.

ඔබ Helm ආරම්භ කර එය පළමු වරට සේවාදායකයේ ස්ථාපනය කරන විට, ඔබට භාවිතා කර සේවා ගිණුම සැකසිය හැක --service-account. අවශ්‍ය අවම අයිතිවාසිකම් කට්ටලයක් සහිත පරිශීලකයෙකු භාවිතා කිරීමට මෙය ඔබට ඉඩ සලසයි. ඇත්ත, ඔබට එවැනි "මාලයක්" නිර්මාණය කිරීමට සිදුවනු ඇත: භූමිකාව සහ භූමිකාව බැඳීම.

අවාසනාවකට, Helm ඔබ වෙනුවෙන් මෙය නොකරනු ඇත. ඔබ හෝ ඔබේ Kubernetes පොකුරු පරිපාලකයා Helm සමත් වීම සඳහා සේවා-ගිණුම සඳහා භූමිකාවන් සහ RoleBindings කට්ටලයක් කල්තියා සූදානම් කළ යුතුය.

ප්රශ්නය පැනනගින්නේ - භූමිකාව සහ ClusterRole අතර වෙනස කුමක්ද? වෙනස නම් ClusterRole ක්‍රියා කරන්නේ සාමාන්‍ය Roles සහ RoleBindings මෙන් නොව, විශේෂිත නාම අවකාශයක් සඳහා පමණක් ක්‍රියා කරන බැවිනි. ඔබට සම්පූර්ණ පොකුරු සහ සියලුම නාම අවකාශයන් සඳහා ප්‍රතිපත්ති වින්‍යාස කළ හැක, නැතහොත් එක් එක් නාම අවකාශය සඳහා තනි තනිව පුද්ගලීකරණය කළ හැක.

RBAC තවත් විශාල ගැටළුවක් විසඳන බව සඳහන් කිරීම වටී. බොහෝ අය චෝදනා කරන්නේ හෙල්ම්, අවාසනාවන්ත ලෙස, බහුකාර්යයක් නොවන බවයි (බහුකාර්යයට සහය නොදක්වයි). කණ්ඩායම් කිහිපයක් පොකුරක් පරිභෝජනය කර Helm භාවිතා කරන්නේ නම්, මෙම පොකුර තුළ ප්‍රතිපත්ති සැකසීම සහ ඔවුන්ගේ ප්‍රවේශය සීමා කිරීම මූලික වශයෙන් කළ නොහැක්කකි, මන්ද Helm ක්‍රියාත්මක වන යම් සේවා ගිණුමක් ඇති නිසා සහ එය යටතේ සිට පොකුරේ ඇති සියලුම සම්පත් නිර්මාණය කරයි. , සමහර විට ඉතා අපහසු වේ. මෙය සත්‍යයකි - ද්විමය ගොනුව මෙන්, ක්‍රියාවලිය මෙන්, හෙල්ම් ටිලර්ට බහුකාර්ය සංකල්පයක් නොමැත.

කෙසේ වෙතත්, පොකුරක් තුළ ටිලර් කිහිප වතාවක් ධාවනය කිරීමට ඔබට ඉඩ සලසන විශිෂ්ට ක්රමයක් තිබේ. මේකේ කිසිම ප්‍රශ්නයක් නෑ, හැම namespace එකකම Tiller දියත් කරන්න පුළුවන්. මේ අනුව, ඔබට සන්දර්භයක් ලෙස RBAC, Kubeconfig භාවිතා කළ හැකි අතර, විශේෂ Helm වෙත ප්රවේශය සීමා කරන්න.

එය මේ ආකාරයෙන් පෙනෙනු ඇත.

උදාහරණයක් ලෙස, විවිධ කණ්ඩායම් සඳහා සන්දර්භය සහිත Kubeconfig දෙකක් ඇත (නාම අවකාශයන් දෙකක්): සංවර්ධන කණ්ඩායම සහ පරිපාලක පොකුර සඳහා X කණ්ඩායම. පරිපාලක පොකුරට තමන්ගේම පුළුල් ටිලර් ඇත, එය Kube-system namespace හි පිහිටා ඇත, ඊට අනුරූපව උසස් සේවා-ගිණුමකි. සංවර්ධන කණ්ඩායම සඳහා වෙනම නාම අවකාශයක්, ඔවුන්ගේ සේවාවන් විශේෂ නාම අවකාශයකට යෙදවීමට ඔවුන්ට හැකි වේ.

මෙය ක්‍රියාත්මක කළ හැකි ප්‍රවේශයකි, ටිලර් එතරම් බල තණ්හාවකින් නොසිටින අතර එය ඔබගේ අයවැයට බෙහෙවින් බලපානු ඇත. මෙය ඉක්මන් විසඳුම් වලින් එකකි.

Tiller වෙන වෙනම වින්‍යාස කිරීමට නිදහස් වන්න සහ කණ්ඩායම සඳහා, නිශ්චිත සංවර්ධකයෙකු සඳහා හෝ පරිසරය සඳහා සන්දර්භය සමඟ Kubeconfig ලබා දෙන්න: Dev, Staging, Production (සියල්ල එකම පොකුරේ තිබීම සැක සහිතයි, කෙසේ වෙතත්, මෙය කළ හැකිය).

අපේ කතාව දිගටම කරගෙන යමින්, අපි RBAC වෙතින් මාරු වී ConfigMaps ගැන කතා කරමු.

ConfigMaps

Helm එහි දත්ත ගබඩාව ලෙස ConfigMaps භාවිතා කරයි. අපි architecture ගැන කතා කරනකොට releases, configurations, rollbacks වගේ දේවල් ගබඩා කරන database එකක් කොහෙවත් තිබුනෙ නෑ.මේකට ConfigMaps භාවිතා කරනවා.

ConfigMaps හි ඇති ප්‍රධාන ගැටළුව දන්නා කරුණකි - ඒවා ප්‍රතිපත්තිමය වශයෙන් අනාරක්ෂිත ය; සංවේදී දත්ත ගබඩා කිරීම කළ නොහැක. අපි කතා කරන්නේ සේවාවෙන් ඔබ්බට නොයා යුතු සියල්ල ගැන ය, උදාහරණයක් ලෙස, මුරපද. Helm සඳහා දැනට ඇති වඩාත්ම දේශීය මාර්ගය වන්නේ ConfigMaps භාවිතයෙන් රහස් වෙත මාරු වීමයි.

මෙය ඉතා සරලව සිදු කෙරේ. ටිලර් සැකසුම අභිබවා ගබඩාව රහස් වනු ඇති බව සඳහන් කරන්න. එවිට එක් එක් යෙදවීම සඳහා ඔබට ලැබෙන්නේ ConfigMap එකක් නොව රහසක්.

රහස් යනු අමුතු සංකල්පයක් වන අතර එතරම් ආරක්ෂිත නොවන බව ඔබට තර්ක කළ හැකිය. කෙසේ වෙතත්, Kubernetes සංවර්ධකයින් විසින්ම මෙය කරන බව වටහා ගැනීම වටී. 1.10 අනුවාදයෙන් ආරම්භ වේ, i.e. දැන් සෑහෙන කාලයක් තිස්සේ, අවම වශයෙන් පොදු වලාකුළු තුළ, රහස් ගබඩා කිරීම සඳහා නිවැරදි ගබඩාව සම්බන්ධ කිරීමට හැකි වී ඇත. කණ්ඩායම දැන් රහස්, තනි කරල් හෝ වෙනත් ආයතන වෙත ප්‍රවේශය වඩා හොඳින් බෙදා හැරීමේ ක්‍රම පිළිබඳව ක්‍රියා කරයි.

ගබඩා හෙල්ම් රහස් වෙත මාරු කිරීම වඩා හොඳ වන අතර, ඒවා මධ්යස්ථව සුරක්ෂිත කර ඇත.

ඇත්ත වශයෙන්ම එය පවතිනු ඇත දත්ත ගබඩා සීමාව 1 MB. Helm මෙහි configMaps සඳහා බෙදා හරින ලද ගබඩාව ලෙස etcd භාවිතා කරයි. එහිදී ඔවුන් සැලකුවේ මෙය ප්‍රතිනිර්මාණය කිරීම යනාදිය සඳහා සුදුසු දත්ත කොටසක් බවයි. Reddit හි මේ ගැන රසවත් සාකච්ඡාවක් ඇත, සති අන්තයේ මෙම විනෝදජනක කියවීම සොයා ගැනීමට හෝ උපුටා ගැනීම කියවීමට මම නිර්දේශ කරමි මෙහි.

ප්‍රස්ථාර ගබඩා

ප්‍රස්ථාර යනු සමාජීය වශයෙන් වඩාත්ම අවදානමට ලක්විය හැකි අතර, විශේෂයෙන් ඔබ කොටස් විසඳුමක් භාවිතා කරන්නේ නම්, "මැද මිනිසා" ප්‍රභවයක් බවට පත්විය හැකිය. පළමුවෙන්ම, අපි කතා කරන්නේ HTTP හරහා නිරාවරණය වන ගබඩාවන් ගැන ය.

ඔබ අනිවාර්යයෙන්ම HTTPS හරහා Helm Repo හෙළිදරව් කළ යුතුය - මෙය හොඳම විකල්පය වන අතර මිල අඩුය.

අවධානය යොමු කරන්න ප්රස්ථාර අත්සන යාන්ත්රණය. තාක්ෂණය අපායක් තරම් සරලයි. පොදු සහ පුද්ගලික යතුරු සහිත සාමාන්‍ය PGP යන්ත්‍රයක් වන GitHub හි ඔබ භාවිතා කරන එකම දෙය මෙයයි. සකසන්න සහ සහතික වන්න, අවශ්‍ය යතුරු තිබීම සහ සියල්ල අත්සන් කිරීම, මෙය සැබවින්ම ඔබේ ප්‍රස්ථාරය බව.

ඊට අමතරව, හෙල්ම් සේවාදායකයා TLS සඳහා සහය දක්වයි (සේවාදායක පැත්තේ HTTP අර්ථයෙන් නොව, අන්‍යෝන්‍ය TLS). ඔබට සන්නිවේදනය කිරීම සඳහා සේවාදායකය සහ සේවාදායක යතුරු භාවිතා කළ හැකිය. අවංකවම, මම අන්යෝන්ය සහතික වලට කැමති නැති නිසා මම එවැනි යාන්ත්රණයක් භාවිතා නොකරමි. මූලික වශයෙන්, ප්රස්ථාර කෞතුකාගාරය - Helm 2 සඳහා Helm Repo පිහිටුවීමේ ප්‍රධාන මෙවලම - මූලික සත්‍යාපනය සඳහාද සහය දක්වයි. එය වඩාත් පහසු සහ නිහඬ නම් ඔබට මූලික සත්‍යාපනය භාවිතා කළ හැක.

Plugin එකකුත් තියෙනවා helm-gcs, එය ඔබට Google Cloud Storage හි Chart Repos සත්කාරකත්වය ලබා දීමට ඉඩ සලසයි. විස්තර කර ඇති සියලුම යාන්ත්‍රණ ප්‍රතිචක්‍රීකරණය කර ඇති බැවින් මෙය තරමක් පහසු ය, විශිෂ්ට ලෙස ක්‍රියා කරන අතර තරමක් ආරක්ෂිත ය.

ඔබ HTTPS හෝ TLS සබල කරන්නේ නම්, mTLS භාවිත කර, අවදානම් තවදුරටත් අඩු කිරීමට මූලික සත්‍යාපනය සක්‍රීය කරන්නේ නම්, ඔබට Helm CLI සහ Chart Repo සමඟින් ආරක්ෂිත සන්නිවේදන නාලිකාවක් ලැබෙනු ඇත.

gRPC API

ඊළඟ පියවර ඉතා වැදගත් වේ - පොකුරේ පිහිටා ඇති සහ එක් අතකින් සේවාදායකයක් වන ටිලර් සුරක්ෂිත කිරීම, අනෙක් අතට, එයම වෙනත් සංරචක වෙත ප්‍රවේශ වී කෙනෙකු ලෙස පෙනී සිටීමට උත්සාහ කරයි.

මම දැනටමත් පවසා ඇති පරිදි, ටිලර් යනු gRPC නිරාවරණය කරන සේවාවකි, හෙල්ම් සේවාදායකයා එයට පැමිණෙන්නේ gRPC හරහාය. පෙරනිමියෙන්, ඇත්ත වශයෙන්ම, TLS අක්රිය කර ඇත. මෙය සිදු කළේ ඇයිද යන්න විවාදාත්මක ප්‍රශ්නයකි, ආරම්භයේදීම සැකසුම සරල කිරීමට මට පෙනේ.

නිෂ්පාදනය සහ වේදිකාගත කිරීම සඳහා, මම gRPC මත TLS සක්‍රීය කිරීමට නිර්දේශ කරමි.

මගේ මතය අනුව, ප්‍රස්ථාර සඳහා mTLS මෙන් නොව, මෙය මෙහි සුදුසු වන අතර ඉතා සරලව සිදු කරයි - PQI යටිතල පහසුකම් ජනනය කරන්න, සහතිකයක් සාදන්න, ටිලර් දියත් කරන්න, ආරම්භයේදී සහතිකය මාරු කරන්න. මෙයින් පසු, ඔබට සියලු හෙල්ම් විධානයන් ක්‍රියාත්මක කළ හැකිය, ජනනය කරන ලද සහතිකය සහ පුද්ගලික යතුර සමඟ ඔබ ඉදිරිපත් වේ.

මේ ආකාරයෙන් ඔබ පොකුරෙන් පිටත සිට ටිලර් වෙත කරන සියලුම ඉල්ලීම් වලින් ඔබ ආරක්ෂා වනු ඇත.

එබැවින්, අපි ටිලර් වෙත සම්බන්ධතා නාලිකාව සුරක්ෂිත කර ඇත, අපි දැනටමත් RBAC ගැන සාකච්ඡා කර Kubernetes apiserver හි අයිතිවාසිකම් සකස් කර ඇති අතර, එය අන්තර්ක්‍රියා කළ හැකි වසම අඩු කර ඇත.

ආරක්ෂිත හෙල්ම්

අපි අවසාන රූප සටහන දෙස බලමු. එය එකම ඊතල සහිත එකම ගෘහ නිර්මාණ ශිල්පයයි.

සියලුම සම්බන්ධතා දැන් ආරක්ෂිතව කොළ පැහැයෙන් ඇඳිය ​​හැකිය:

• Chart Repo සඳහා අපි TLS හෝ mTLS සහ මූලික සත්‍යාපනය භාවිතා කරමු;
• ටිලර් සඳහා mTLS, සහ එය TLS සමඟ gRPC සේවාවක් ලෙස නිරාවරණය වේ, අපි සහතික භාවිතා කරමු;
• පොකුර කාර්යභාරය සහ භූමිකාව බැඳීම සමඟ විශේෂ සේවා ගිණුමක් භාවිතා කරයි. 

අපි පොකුර සැලකිය යුතු ලෙස සුරක්ෂිත කර ඇත, නමුත් බුද්ධිමත් කෙනෙක් මෙසේ පැවසීය:

"එකක් විය හැක්කේ පරම ආරක්ෂිත විසඳුමක් පමණි - කොන්ක්‍රීට් පෙට්ටියක පිහිටා ඇති සහ සොල්දාදුවන් විසින් ආරක්ෂා කරන ලද පරිගණකය ක්‍රියා විරහිත කර ඇත."

දත්ත හැසිරවීමට සහ නව ප්‍රහාරක දෛශික සොයා ගැනීමට විවිධ ක්‍රම තිබේ. කෙසේ වෙතත්, මෙම නිර්දේශ මඟින් ආරක්ෂාව සඳහා මූලික කර්මාන්ත ප්‍රමිතියක් අත්කර ගනු ඇතැයි මට විශ්වාසයි.

පාරිතෝෂිකය

මෙම කොටස සෘජුවම ආරක්ෂාවට සම්බන්ධ නොවේ, නමුත් ප්රයෝජනවත් වනු ඇත. ස්වල්ප දෙනෙක් දන්නා රසවත් කරුණු කිහිපයක් මම ඔබට පෙන්වන්නම්. උදාහරණයක් ලෙස, ප්‍රස්ථාර සොයන්නේ කෙසේද - නිල සහ නිල නොවන.

ගබඩාවේ github.com/helm/charts දැන් ප්‍රස්ථාර 300 ක් පමණ සහ ප්‍රවාහ දෙකක් ඇත: ස්ථාවර සහ ඉන්කියුබේටර්. ඉන්කියුබේටරයෙන් ස්ථායී තත්ත්වයට යාම කොතරම් දුෂ්කර ද, ස්ථාවරයෙන් පිටතට පියාසර කිරීම කොතරම් පහසු ද යන්න දායක වන ඕනෑම අයෙක් හොඳින් දනී. කෙසේ වෙතත්, මෙය Prometheus සහ ඔබ කැමති වෙනත් ඕනෑම දෙයක් සඳහා ප්‍රස්ථාර සෙවීමට හොඳම මෙවලම නොවේ, එක් සරල හේතුවක් නිසා - එය ඔබට පහසුවෙන් පැකේජ සෙවිය හැකි ද්වාරයක් නොවේ.

නමුත් සේවාවක් තිබේ hub.helm.sh, එය ප්‍රස්ථාර සොයා ගැනීම වඩාත් පහසු කරයි. වැදගත්ම දෙය නම්, තවත් බොහෝ බාහිර ගබඩාවන් සහ චාම් 800 කට ආසන්න ප්‍රමාණයක් තිබේ. ඊට අමතරව, යම් හේතුවක් නිසා ඔබට ඔබේ ප්‍රස්ථාර ස්ථාවර වෙත යැවීමට අවශ්‍ය නැතිනම් ඔබට ඔබේ ගබඩාව සම්බන්ධ කළ හැක.

hub.helm.sh උත්සාහ කර අපි එය එක්ව සංවර්ධනය කරමු. මෙම සේවාව Helm ව්‍යාපෘතිය යටතේ වන අතර, ඔබ ඉදිරිපස සංවර්ධකයෙකු නම් සහ පෙනුම වැඩි දියුණු කිරීමට අවශ්‍ය නම් ඔබට එහි UI වෙත දායක විය හැක.

යන්න පිළිබඳවද ඔබේ අවධානය යොමු කිරීමට කැමැත්තෙමි සේවා තැරැව්කාර API ඒකාබද්ධ කිරීම විවෘත කරන්න. එය අපහසු සහ නොපැහැදිලි බවක් පෙනේ, නමුත් එය සෑම කෙනෙකුම මුහුණ දෙන ගැටළු විසඳයි. මම සරල උදාහරණයකින් පැහැදිලි කරන්නම්.

අපට සම්භාව්‍ය යෙදුමක් ක්‍රියාත්මක කිරීමට අවශ්‍ය Kubernetes පොකුරක් ඇත - WordPress. සාමාන්‍යයෙන්, සම්පූර්ණ ක්‍රියාකාරීත්වය සඳහා දත්ත සමුදායක් අවශ්‍ය වේ. විවිධ විසඳුම් තිබේ, උදාහරණයක් ලෙස, ඔබට ඔබේම රාජ්ය සේවාවක් දියත් කළ හැකිය. මෙය එතරම් පහසු නැත, නමුත් බොහෝ අය එය කරයි.

Chainstack හි අප වැනි වෙනත් අය, ඔවුන්ගේ සේවාදායකයන් සඳහා MySQL හෝ PostgreSQL වැනි කළමනාකරණය කළ දත්ත සමුදායන් භාවිතා කරයි. අපේ දත්ත සමුදායන් වලාකුළේ කොතැනක හෝ පිහිටා ඇත්තේ එබැවිනි.

නමුත් ගැටළුවක් පැන නගී: අපට අපගේ සේවාව දත්ත සමුදායක් සමඟ සම්බන්ධ කිරීමට, දත්ත සමුදා රසයක් නිර්මාණය කිරීමට, අක්තපත්‍ර මාරු කිරීමට සහ එය කෙසේ හෝ කළමනාකරණය කිරීමට අවශ්‍ය වේ. මේ සියල්ල සාමාන්යයෙන් පද්ධති පරිපාලක හෝ සංවර්ධකයා විසින් අතින් සිදු කරනු ලැබේ. ඒවගේම ඇප්ලිකේෂන් ටිකක් තියෙනකොට කිසිම ප්‍රශ්නයක් නෑ. ඒවා ගොඩක් ඇති විට, ඔබට සංයෝජනයක් අවශ්ය වේ. එවැනි අස්වැන්නක් තිබේ - එය සේවා තැරැව්කරු වේ. එය ඔබට පොදු වලාකුළු පොකුරක් සඳහා විශේෂ ප්ලගිනයක් භාවිතා කිරීමට සහ එය API එකක් මෙන් තැරැව්කරු හරහා සැපයුම්කරුගෙන් සම්පත් ඇණවුම් කිරීමට ඉඩ සලසයි. මෙය සිදු කිරීම සඳහා, ඔබට දේශීය Kubernetes මෙවලම් භාවිතා කළ හැකිය.

එය ඉතා සරලයි. ඔබට විමසිය හැක, උදාහරණයක් ලෙස, Azure හි කළමනාකරණය කළ MySQL පාදක ස්ථරයක් සමඟින් (මෙය වින්‍යාසගත කළ හැක). Azure API භාවිතා කරමින්, දත්ත සමුදාය නිර්මාණය කර භාවිතයට සූදානම් වනු ඇත. ඔබ මෙයට මැදිහත් වීමට අවශ්ය නැත, ප්ලගිනය මේ සඳහා වගකිව යුතුය. උදාහරණයක් ලෙස, OSBA (Azure ප්ලගිනය) සේවාව වෙත අක්තපත්‍ර ආපසු ලබා දී එය Helm වෙත ලබා දෙනු ඇත. ඔබට වලාකුළු MySQL සමඟ WordPress භාවිතා කිරීමට හැකි වනු ඇත, කළමනාකරණය කළ දත්ත සමුදායන් සමඟ කිසිසේත් ගනුදෙනු නොකරන අතර ඇතුළත රාජ්‍ය පූර්ණ සේවාවන් ගැන කරදර නොවන්න.

එක් අතකින් ඔබට සේවා යෙදවීමට ඉඩ සලසන මැලියම් ලෙස හෙල්ම් ක්‍රියා කරන බව අපට පැවසිය හැකිය, අනෙක් පැත්තෙන් වලාකුළු සපයන්නන්ගේ සම්පත් පරිභෝජනය කරයි.

ඔබට ඔබේම ප්ලගිනයක් ලියා මෙම සම්පූර්ණ කතාව පරිශ්‍රයේ භාවිතා කළ හැකිය. එවිට ඔබට ආයතනික Cloud සපයන්නා සඳහා ඔබේම ප්ලගිනයක් ඇත. මෙම ප්‍රවේශය උත්සාහ කිරීමට මම නිර්දේශ කරමි, විශේෂයෙන් ඔබට විශාල පරිමාණයක් තිබේ නම් සහ විශේෂාංගයක් සඳහා ඉක්මනින් dev, වේදිකාගත කිරීම හෝ සම්පූර්ණ යටිතල පහසුකම් යෙදවීමට අවශ්‍ය නම්. මෙය ඔබගේ මෙහෙයුම් හෝ DevOps සඳහා ජීවිතය පහසු කරනු ඇත.

මා කලින් සඳහන් කළ තවත් සොයා ගැනීමකි helm-gcs ප්ලගිනය, හෙල්ම් ප්‍රස්ථාර ගබඩා කිරීම සඳහා Google-බාල්දි (වස්තු ගබඩාව) භාවිතා කිරීමට ඔබට ඉඩ සලසයි.

එය භාවිතා කිරීම ආරම්භ කිරීමට ඔබට අවශ්‍ය වන්නේ විධාන හතරක් පමණි:

1. ප්ලගිනය ස්ථාපනය කරන්න;
2. එය ආරම්භ කරන්න;
3. gcp හි පිහිටා ඇති බාල්දියට මාර්ගය සකසන්න;
4. සම්මත ආකාරයෙන් ප්‍රස්ථාර ප්‍රකාශයට පත් කරන්න.

අලංකාරය නම් අවසරය සඳහා දේශීය gcp ක්‍රමය භාවිතා කිරීමයි. ඔබට සේවා ගිණුමක්, සංවර්ධක ගිණුමක්, ඔබට අවශ්‍ය ඕනෑම දෙයක් භාවිතා කළ හැක. එය ඉතා පහසු වන අතර ක්රියාත්මක කිරීමට කිසිවක් වැය නොවේ. ඔබ, මා මෙන්, opsless දර්ශනය ප්‍රවර්ධනය කරන්නේ නම්, මෙය ඉතා පහසු වනු ඇත, විශේෂයෙන් කුඩා කණ්ඩායම් සඳහා.

විකල්ප

හෙල්ම් එකම සේවා කළමනාකරණ විසඳුම නොවේ. ඒ ගැන ප්‍රශ්න රාශියක් ඇත, තුන්වන අනුවාදය මෙතරම් ඉක්මනින් දර්ශනය වූයේ ඒ නිසා විය හැකිය. ඇත්ත වශයෙන්ම විකල්ප තිබේ.

මේවා විශේෂිත විසඳුම් විය හැකිය, උදාහරණයක් ලෙස, Ksonnet හෝ Metaparticle. මා කතා කළ එකම අරමුණු සඳහා ඔබට ඔබේ සම්භාව්‍ය යටිතල පහසුකම් කළමනාකරණ මෙවලම් (Ansible, Terraform, Chef, ආදිය) භාවිතා කළ හැකිය.

අවසානයේ විසඳුමක් තිබේ ක්රියාකරු රාමුව, එහි ජනප්‍රියත්වය වර්ධනය වෙමින් පවතී.

Operator Framework යනු සලකා බැලිය යුතු ඉහළම හෙල්ම් විකල්පයයි.

එය CNCF සහ Kubernetes වලට වඩා නිජබිම වේ. නමුත් ඇතුල් වීමට ඇති බාධකය බෙහෙවින් වැඩි ය, ඔබ වැඩිපුර ක්‍රමලේඛනය කිරීමට සහ ප්‍රකාශන අඩුවෙන් විස්තර කිරීමට අවශ්‍ය වේ.

Draft, Scaffold වැනි විවිධ ඇඩෝන තිබේ. ඔවුන් ජීවිතය වඩාත් පහසු කරයි, නිදසුනක් වශයෙන්, පරීක්ෂණ පරිසරයක් යෙදවීම සඳහා සංවර්ධකයින් සඳහා හෙල්ම් යැවීමේ සහ දියත් කිරීමේ චක්‍රය ඔවුන් සරල කරයි. මම ඔවුන්ව බලවතුන් ලෙස හඳුන්වමි.

මෙන්න සෑම දෙයක්ම ඇති ස්ථානයේ දෘශ්‍ය ප්‍රස්ථාරයක්.

x-අක්ෂයේ සිදුවන්නේ කුමක්ද යන්න පිළිබඳ ඔබේ පුද්ගලික පාලනයේ මට්ටමයි, y-අක්ෂයේ කුබර්නෙටේස්ගේ ස්වදේශීය මට්ටමයි. හෙල්ම් අනුවාදය 2 මැද කොහේ හරි වැටේ. 3 වන අනුවාදයේ, විශාල වශයෙන් නොව, පාලනය සහ ස්වදේශීය මට්ටම යන දෙකම වැඩිදියුණු කර ඇත. Ksonnet මට්ටමේ විසඳුම් තවමත් Helm 2 ට වඩා පහත් මට්ටමක පවතී. කෙසේ වෙතත්, මේ ලෝකයේ තවත් මොනවාදැයි දැන ගැනීමට ඒවා බැලීම වටී. ඇත්ත වශයෙන්ම, ඔබේ වින්‍යාස කළමනාකරු ඔබේ පාලනය යටතේ පවතිනු ඇත, නමුත් එය නියත වශයෙන්ම Kubernetes හි නිජබිම නොවේ.

Operator Framework නිරපේක්ෂ වශයෙන් Kubernetes හි නිජබිම වන අතර ඔබට එය වඩාත් අලංකාරව සහ සූක්ෂම ලෙස කළමනාකරණය කිරීමට ඉඩ සලසයි (නමුත් ප්‍රවේශ මට්ටම ගැන මතක තබා ගන්න). ඒ වෙනුවට, මෙය හෙල්ම් භාවිතයෙන් යෙදුම් විශාල ප්‍රමාණයක් ඇසුරුම් කිරීම සඳහා විශාල අස්වනු නෙළන යන්ත්‍රයකට වඩා විශේෂිත යෙදුමක් සහ ඒ සඳහා කළමනාකරණයක් නිර්මාණය කිරීම සඳහා සුදුසු වේ.

විස්තාරක විසින් පාලනය ටිකක් වැඩි දියුණු කරයි, වැඩ ප්‍රවාහය අනුපූරක කරයි, නැතහොත් CI/CD නල මාර්ගවල කොන් කපා දමන්න.

හෙල්ම්ගේ අනාගතය

ශුභාරංචිය නම් Helm 3 එනවා. Helm 3.0.0-alpha.2 හි ඇල්ෆා අනුවාදය දැනටමත් නිකුත් කර ඇත, ඔබට එය උත්සාහ කළ හැකිය. එය තරමක් ස්ථායී වේ, නමුත් ක්රියාකාරිත්වය තවමත් සීමිතය.

ඔබට හෙල්ම් 3 අවශ්‍ය වන්නේ ඇයි? මුලින්ම කියන්න ඕන මේක ගැන කතාවක් ටිලර් අතුරුදහන් වීම, සංරචකයක් ලෙස. මෙය, ඔබ දැනටමත් තේරුම් ගෙන ඇති පරිදි, විශාල ඉදිරි පියවරකි, මන්ද ගෘහ නිර්මාණ ශිල්පයේ ආරක්ෂාව පිළිබඳ දෘෂ්ටි කෝණයෙන් සෑම දෙයක්ම සරල කර ඇත.

Helm 2 නිර්මාණය කරන විට, එය Kubernetes 1.8 හෝ ඊටත් පෙර කාලයේ දී, බොහෝ සංකල්ප නොමේරූ විය. උදාහරණයක් ලෙස, CRD සංකල්පය දැන් ක්රියාකාරීව ක්රියාත්මක වන අතර, Helm වනු ඇත CRD භාවිතා කරන්නව්යුහයන් ගබඩා කිරීමට. සේවාදායකයා පමණක් භාවිතා කිරීමට සහ සේවාදායක කොටස නඩත්තු කිරීමට නොහැකි වනු ඇත. ඒ අනුව, ව්‍යුහයන් සහ සම්පත් සමඟ වැඩ කිරීමට දේශීය Kubernetes විධාන භාවිතා කරන්න. මෙය විශාල ඉදිරි පියවරකි.

දිස් වනු ඇත දේශීය OCI ගබඩා සඳහා සහාය (විවෘත බහාලුම් මුලපිරීම). මෙය විශාල මුලපිරීමක් වන අතර, හෙල්ම් මූලික වශයෙන් එහි ප්‍රස්ථාර පළ කිරීමට උනන්දු වෙයි. උදාහරණයක් ලෙස, ඩොකර් හබ් බොහෝ OCI ප්‍රමිතීන් සඳහා සහය දක්වන බව කාරණයට පැමිණේ. මම අනුමාන කරන්නේ නැහැ, නමුත් සමහර විට සම්භාව්‍ය ඩොකර් ගබඩා සපයන්නන් ඔබට ඔබේ හෙල්ම් ප්‍රස්ථාර සත්කාරකත්වය ලබා දීමට අවස්ථාව ලබා දෙනු ඇත.

මට නම් ආන්දෝලනාත්මක කතාව Lua සහාය, ස්ක්‍රිප්ට් ලිවීම සඳහා සැකිලි එන්ජිමක් ලෙස. මම ලුවාගේ විශාල රසිකයෙක් නොවේ, නමුත් මෙය සම්පූර්ණයෙන්ම විකල්ප අංගයක් වනු ඇත. මම මෙය 3 වතාවක් පරීක්ෂා කළා - Lua භාවිතා කිරීම අවශ්‍ය නොවේ. ඒ නිසා Lua පාවිච්චි කරන්න කැමති අය, Go වලට කැමති අය අපේ දැවැන්ත කඳවුරට එකතු වෙලා go-tmpl මේකට පාවිච්චි කරන්න.

අවසාන වශයෙන්, මට අනිවාර්යයෙන්ම නැතිවූ දෙය විය schema මතුවීම සහ දත්ත වර්ගය වලංගු කිරීම. int හෝ string සමඟ තවත් ගැටළු ඇති නොවනු ඇත, ද්විත්ව උද්ධෘත වල බිංදුව එතීමට අවශ්‍ය නොවේ. අගයන් සඳහා මෙය පැහැදිලිව විස්තර කිරීමට ඔබට ඉඩ සලසන JSONS යෝජනා ක්‍රමයක් දිස්වනු ඇත.

දැඩි ලෙස නැවත සකස් කරනු ඇත සිදුවීම්-ධාවන ආකෘතිය. එය දැනටමත් සංකල්පීය ලෙස විස්තර කර ඇත. Helm 3 ශාඛාව දෙස බලන්න, සිදුවීම් සහ කොකු සහ වෙනත් දේවල් කීයක් එකතු කර ඇත්දැයි ඔබට පෙනෙනු ඇත, එය බොහෝ සෙයින් සරල කරන අතර, අනෙක් අතට, ඒවාට යෙදවීමේ ක්‍රියාවලීන් සහ ප්‍රතික්‍රියා පාලනය කිරීම එක් කරයි.

Helm 3 සරල, ආරක්ෂිත සහ වඩාත් විනෝදජනක වනු ඇත, අපි Helm 2 ට අකමැති නිසා නොව, Kubernetes වඩාත් දියුණු වෙමින් පවතින නිසා. ඒ අනුව, හෙල්ම්ට Kubernetes හි වර්ධනයන් භාවිතා කළ හැකි අතර ඒ මත Kubernetes සඳහා විශිෂ්ට කළමනාකරුවන් නිර්මාණය කළ හැකිය.

තවත් හොඳ ආරංචියක් තමයි DevOpsConf ඇලෙක්සැන්ඩර් ඛයෝරොව් ඔබට කියයි, බහාලුම් ආරක්ෂිත විය හැකිද? සංවර්ධනය, පරීක්ෂණ සහ මෙහෙයුම් ක්‍රියාවලීන් ඒකාබද්ධ කිරීම පිළිබඳ සමුළුව මොස්කව්හිදී පැවැත්වෙන බව අපි ඔබට මතක් කරමු සැප්තැම්බර් 30 සහ ඔක්තෝබර් 1. ඔබට තවමත් අගෝස්තු 20 දක්වා එය කළ හැක වාර්තාවක් ඉදිරිපත් කරන්න සහ විසඳුම සමඟ ඔබේ අත්දැකීම් අපට කියන්න බොහෝ අයගෙන් එකක් DevOps ප්රවේශයේ කාර්යයන්.

සම්මන්ත්‍රණ මුරපොලවල් සහ ප්‍රවෘත්ති අනුගමනය කරන්න තැපැල් ලැයිස්තුව и විදුලි පණිවුඩ නාලිකාව.

මූලාශ්රය: www.habr.com