සටහන. පරිවර්තනය.: GitLab හි Kubernetes දරුකමට හදා ගැනීම සමාගමේ වර්ධනයට දායක වන ප්‍රධාන සාධක දෙකෙන් එකක් ලෙස සැලකේ. කෙසේ වෙතත්, මෑතක් වන තුරු, GitLab.com ඔන්ලයින් සේවාවේ යටිතල පහසුකම් අතථ්‍ය යන්ත්‍ර මත ගොඩනගා ඇති අතර, වසරකට පමණ පෙර K8s වෙත එහි සංක්‍රමණය ආරම්භ වූ අතර එය තවමත් සම්පූර්ණ කර නොමැත. මෙය සිදු වන්නේ කෙසේද සහ ව්‍යාපෘතියට සහභාගී වන ඉංජිනේරුවන් කුමන නිගමනවලට එළඹෙන්නේද යන්න පිළිබඳව GitLab SRE ඉංජිනේරුවෙකු විසින් මෑතකදී පළ කරන ලද ලිපියක පරිවර්තනයක් ඉදිරිපත් කිරීමට අපි සතුටු වෙමු.
දැන් වසරක පමණ කාලයක සිට, අපගේ යටිතල පහසුකම් අංශය GitLab.com හි ක්‍රියාත්මක වන සියලුම සේවාවන් Kubernetes වෙත සංක්‍රමණය කර ඇත. මෙම කාලය තුළ, අපි Kubernetes වෙත සේවා ගෙනයාමට පමණක් නොව, සංක්‍රාන්තිය තුළ දෙමුහුන් යෙදවීම කළමනාකරණයට සම්බන්ධ අභියෝගවලට මුහුණ දුන්නෙමු. අප ඉගෙනගත් වටිනා පාඩම් මෙම ලිපියෙන් සාකච්ඡා කෙරේ.
GitLab.com ආරම්භයේ සිටම, එහි සේවාදායකයන් අථත්‍ය යන්ත්‍රවල වලාකුළෙහි ක්‍රියාත්මක විය. මෙම අතථ්‍ය යන්ත්‍ර චෙෆ් විසින් කළමනාකරණය කරන අතර අපගේ භාවිතයෙන් ස්ථාපනය කර ඇත . යෙදුම යාවත්කාලීන කිරීමට අවශ්‍ය නම්, CI නල මාර්ගයක් භාවිතයෙන් සම්බන්ධීකරණ, අනුක්‍රමික ආකාරයෙන් සේවාදායක ඇණිය සරලව යාවත්කාලීන කිරීම සමන්විත වේ. මෙම ක්රමය - මන්දගාමී හා ටිකක් වුවද - GitLab.com නොබැඳි භාවිතා කරන්නන් මෙන් එකම ස්ථාපන සහ වින්‍යාසකරණ භාවිතයන් භාවිතා කරන බව සහතික කරයි (ස්වයං කළමනාකරණය) මේ සඳහා අපගේ Linux පැකේජ භාවිතා කරමින් GitLab ස්ථාපනයන්.
අපි මෙම ක්රමය භාවිතා කරන්නේ සාමාන්‍ය ප්‍රජාවේ සාමාජිකයින් ඔවුන්ගේ GitLab පිටපත් ස්ථාපනය කිරීමේදී සහ වින්‍යාස කිරීමේදී අත්විඳින සියලු දුක සහ සතුට අත්විඳීම අතිශයින්ම වැදගත් වන බැවිනි. මෙම ප්‍රවේශය යම් කාලයක් සඳහා හොඳින් ක්‍රියාත්මක විය, නමුත් GitLab හි ව්‍යාපෘති සංඛ්‍යාව මිලියන 10 ඉක්මවූ විට, එය තවදුරටත් පරිමාණය සහ යෙදවීම සඳහා අපගේ අවශ්‍යතා සපුරාලන්නේ නැති බව අපට වැටහුණි.
Kubernetes සහ cloud-native GitLab වෙත පළමු පියවර
මෙම ව්යාපෘතිය 2017 දී නිර්මාණය කරන ලදී වලාකුළු යෙදවීම සඳහා GitLab සූදානම් කිරීමට සහ Kubernetes පොකුරු මත GitLab ස්ථාපනය කිරීමට පරිශීලකයින්ට හැකියාව ලබා දීමට. GitLab Kubernetes වෙත ගෙන යාම SaaS වේදිකාවේ පරිමාණය වැඩි කිරීමටත්, යෙදවීම් සරල කිරීමටත්, පරිගණක සම්පත්වල කාර්යක්ෂමතාව වැඩි කිරීමටත් හේතු වන බව අපි එදා දැන සිටියෙමු. ඒ අතරම, අපගේ යෙදුමේ බොහෝ කාර්යයන් සවිකර ඇති NFS කොටස් මත රඳා පවතී, එය අථත්‍ය යන්ත්‍ර වලින් සංක්‍රමණය වීම මන්දගාමී විය.
ක්ලවුඩ් නේටිව් සහ කුබර්නෙටස් දෙසට තල්ලු වීම අපගේ ඉංජිනේරුවන්ට ක්‍රමානුකූල සංක්‍රමණයක් සැලසුම් කිරීමට ඉඩ සලසයි, එම කාලය තුළ අපි නව විශේෂාංග සංවර්ධනය කරමින් සිටින අතරේ ජාල ආචයනය මත යෙදුමේ සමහර පරායත්තතා අත්හැරියෙමු. අපි 2019 ගිම්හානයේදී සංක්‍රමණය සැලසුම් කිරීමට පටන් ගත් දා සිට, මෙම සීමාවන් බොහොමයක් විසඳා ඇති අතර, GitLab.com Kubernetes වෙත සංක්‍රමණය කිරීමේ ක්‍රියාවලිය දැන් හොඳින් සිදුවෙමින් පවතී!
Kubernetes හි GitLab.com හි විශේෂාංග
GitLab.com සඳහා, අපි සියලුම යෙදුම් ගමනාගමනය හසුරුවන තනි කලාපීය GKE පොකුරක් භාවිතා කරමු. (දැනටමත් උපක්‍රමශීලී) සංක්‍රමණයේ සංකීර්ණත්වය අවම කිරීම සඳහා, අපි දේශීය ගබඩාව හෝ NFS මත රඳා නොපවතින සේවාවන් වෙත අවධානය යොමු කරමු. GitLab.com ප්‍රධාන වශයෙන් මොනොලිතික් රේල්ස් කේත පදනමක් භාවිතා කරන අතර, අපි ඔවුන්ගේම නෝඩ් තටාකවලට හුදකලා වූ විවිධ අන්ත ලක්ෂ්‍ය වෙත කාර්ය භාර ලක්ෂණ මත පදනම්ව ගමනාගමනය යොමු කරමු.
ඉදිරිපස සම්බන්ධයෙන් ගත් කල, මෙම වර්ග web, API, Git SSH/HTTPS සහ Registry වෙත ඉල්ලීම් වලට බෙදා ඇත. පසුපෙළ සම්බන්ධයෙන් ගත් කල, අපි පෝලිමේ රැකියා විවිධ ලක්ෂණ අනුව බෙදන්නෙමු , විවිධ වැඩ බර සඳහා සේවා මට්ටමේ අරමුණු (SLOs) සැකසීමට අපට ඉඩ සලසයි.
මෙම GitLab.com සේවාවන් සියල්ලම වෙනස් නොකළ GitLab Helm ප්‍රස්ථාරයක් භාවිතයෙන් වින්‍යාස කර ඇත. වින්‍යාස කිරීම උප ප්‍රස්ථාරවල සිදු කරනු ලබන අතර, අප ක්‍රමයෙන් සේවා පොකුරට සංක්‍රමණය වන විට තෝරා සක්‍රීය කළ හැක. Redis, Postgres, GitLab Pages සහ Gitaly වැනි අපගේ රාජ්‍ය සේවා සමහරක් සංක්‍රමණයට ඇතුළත් නොකිරීමට අපි තීරණය කළද, Kubernetes භාවිතා කිරීමෙන් Chef දැනට කළමනාකරණය කරන VM ගණන රැඩිකල් ලෙස අඩු කිරීමට අපට ඉඩ සලසයි.
Kubernetes වින්‍යාස දෘශ්‍යතාව සහ කළමනාකරණය
සියලුම සැකසුම් GitLab විසින්ම කළමනාකරණය කරනු ලැබේ. මේ සඳහා Terraform සහ Helm මත පදනම් වූ වින්‍යාස ව්‍යාපෘති තුනක් භාවිතා වේ. GitLab ධාවනය කිරීමට හැකි සෑම විටම GitLab භාවිතා කිරීමට අපි උත්සාහ කරමු, නමුත් මෙහෙයුම් කාර්යයන් සඳහා අපට වෙනම GitLab ස්ථාපනයක් ඇත. GitLab.com යෙදවීම් සහ යාවත්කාලීන කිරීම් සිදු කිරීමේදී ඔබ GitLab.com හි ඇති බව මත රඳා නොපවතින බව සහතික කිරීමට මෙය අවශ්‍ය වේ.
Kubernetes පොකුර සඳහා වන අපගේ නල මාර්ග වෙනම GitLab ස්ථාපනයකින් ක්‍රියාත්මක වුවද, පහත ලිපිනයන්හි ප්‍රසිද්ධියේ ලබා ගත හැකි කේත ගබඩාවල දර්පණ තිබේ:
- - GitLab Helm ප්‍රස්ථාරය සඳහා GitLab.com වින්‍යාස රාමුව;
- - GitLab යෙදුම සමඟ සෘජුවම සම්බන්ධ නොවන සේවාවන් සඳහා වින්‍යාසයන් අඩංගු වේ. මේවාට ලොග් කිරීම සහ පොකුරු අධීක්‍ෂණය සඳහා වින්‍යාස කිරීම් මෙන්ම PlantUML වැනි ඒකාබද්ධ මෙවලම් ඇතුළත් වේ;
- - Kubernetes සඳහා Terraform වින්‍යාසය සහ පැරණි VM යටිතල පහසුකම්. මෙහිදී ඔබ පොකුර ක්‍රියාත්මක කිරීමට අවශ්‍ය සියලුම සම්පත්, පොකුර, නෝඩ් සංචිත, සේවා ගිණුම් සහ IP ලිපින වෙන් කිරීම් ඇතුළුව වින්‍යාස කරයි.
වෙනස්කම් සිදු කරන විට මහජන දර්ශනය පෙන්වයි. පොකුරට වෙනස්කම් කිරීමට පෙර SRE විශ්ලේෂණය කරන සවිස්තරාත්මක වෙනස වෙත සබැඳියක් සමඟ.
SRE සඳහා, සබැඳිය GitLab ස්ථාපනයේ සවිස්තරාත්මක වෙනසකට මඟ පාදයි, එය නිෂ්පාදනය සඳහා භාවිතා කරන අතර ප්‍රවේශය සීමා වේ. මෙය සේවකයින්ට සහ ප්‍රජාවට, මෙහෙයුම් ව්‍යාපෘතියට ප්‍රවේශය නොමැතිව (එය SRE සඳහා පමණක් විවෘත වේ), යෝජිත වින්‍යාස වෙනස්කම් බැලීමට ඉඩ සලසයි. CI නල මාර්ග සඳහා පුද්ගලික අවස්ථාවක් සමඟ කේතය සඳහා පොදු GitLab අවස්ථාවක් ඒකාබද්ධ කිරීමෙන්, වින්‍යාස යාවත්කාලීන කිරීම් සඳහා GitLab.com වෙතින් ස්වාධීනත්වය සහතික කරන අතරම අපි තනි කාර්ය ප්‍රවාහයක් පවත්වා ගනිමු.
සංක්‍රමණය අතරතුර අපි සොයා ගත් දේ
මෙම පියවර අතරතුර, අපි Kubernetes හි නව සංක්‍රමණ සහ යෙදවීම් සඳහා අදාළ වන බවට අත්දැකීම් ලබා ගන්නා ලදී.
1. පවතින කලාප අතර ගමනාගමනය හේතුවෙන් පිරිවැය වැඩි වීම
GitLab.com හි Git ගබඩා බලඇණිය සඳහා දෛනික පිටවීමේ සංඛ්‍යාලේඛන (දිනකට බයිට්)
ගූගල් සිය ජාලය කලාපවලට බෙදා ඇත. ඒවා අනෙක් අතට ප්‍රවේශ්‍යතා කලාප (AZ) ලෙස බෙදා ඇත. Git සත්කාරකත්වය විශාල දත්ත ප්‍රමාණයක් සමඟ සම්බන්ධ වේ, එබැවින් අපට ජාල පිටවීම පාලනය කිරීම වැදගත් වේ. අභ්‍යන්තර ගමනාගමනය සඳහා, පිටවීම නොමිලයේ එය එකම පවතින කලාපය තුළ පවතී නම් පමණි. මෙම ලිපිය ලියන විට, අපි සාමාන්‍ය වැඩ දිනයකදී දළ වශයෙන් 100 TB දත්ත ලබා දෙන්නෙමු (සහ එය Git ගබඩා සඳහා පමණි). අපගේ පැරණි VM-පාදක ස්ථල විද්‍යාවේ එකම අතථ්‍ය යන්ත්‍රවල පැවති සේවාවන් දැන් විවිධ Kubernetes කරල්වල ක්‍රියාත්මක වේ. මෙයින් අදහස් කරන්නේ කලින් VM වෙත දේශීයව තිබූ සමහර ගමනාගමනය පවතින කලාපවලින් පිටත ගමන් කළ හැකි බවයි.
කලාපීය GKE පොකුරු ඔබට අතිරික්තය සඳහා බහුවිධ ලබා ගත හැකි කලාප විහිදීමට ඉඩ සලසයි. හැකියාව අපි සලකා බලනවා විශාල වාහන තදබදයක් ඇති කරන සේවාවන් සඳහා. මෙය පොකුරු මට්ටමේ අතිරික්තය පවත්වා ගනිමින් පිටවීමේ පිරිවැය අඩු කරනු ඇත.
2. සීමාවන්, සම්පත් ඉල්ලීම් සහ පරිමාණය
registry.gitlab.com හි නිෂ්පාදන ගමනාගමනය සකසන අනුරූ ගණන. වාහන තදබදය ~15:00 UTC ට ඉහළ යයි.
අපගේ සංක්‍රමණ කතාව ආරම්භ වූයේ 2019 අගෝස්තු මාසයේදී, අපි අපගේ පළමු සේවාව වන GitLab බහාලුම් රෙජිස්ට්‍රිය Kubernetes වෙත සංක්‍රමණය කළ අවස්ථාවේදීය. මෙම මෙහෙවර-විවේචනාත්මක, අධික තදබදය සහිත සේවාව පළමු සංක්‍රමණය සඳහා හොඳ තේරීමක් වූයේ එය බාහිර පරායත්තතා කිහිපයක් සහිත රාජ්‍ය රහිත යෙදුමක් වන බැවිනි. අපි මුහුණ දුන් පළමු ගැටළුව වූයේ නෝඩ් වල මතකය නොමැතිකම නිසා ඉවත් කරන ලද කරල් විශාල ප්‍රමාණයක් ය. මේ නිසා අපට ඉල්ලීම් සහ සීමාවන් වෙනස් කිරීමට සිදු විය.
කාලයත් සමඟ මතක පරිභෝජනය වැඩි වන යෙදුමකදී, ඉල්ලීම් සඳහා අඩු අගයන් (එක් එක් පොඩ් සඳහා මතකය වෙන් කිරීම) සහ භාවිතයේ "ත්‍යාගශීලී" දැඩි සීමාවක් සමඟ සංතෘප්ත වීමට හේතු වන බව සොයා ගන්නා ලදී. (සංතෘප්තිය) නෝඩ් සහ ඉහළ මට්ටමේ ඉවත් කිරීම්. මෙම ගැටලුව සමඟ කටයුතු කිරීමට, එය විය . මෙමගින් නෝඩ් වල පීඩනය ඉවත් කර නෝඩය මත වැඩි පීඩනයක් නොතබන ජීවන චක්‍රයක් කරල් වල ඇති බව සහතික විය. දැන් අපි ත්‍යාගශීලී (සහ පාහේ සමාන) ඉල්ලීම් සහ සීමාවන් අගයන් සමඟ සංක්‍රමණයන් ආරම්භ කරමු, අවශ්‍ය පරිදි ඒවා සකස් කරමු.
3. මෙට්රික් සහ ලඝු-සටහන්
යටිතල පහසුකම් අංශය ප්‍රමාදය, දෝෂ අනුපාත සහ ස්ථාපිත සමග සංතෘප්තිය කෙරෙහි අවධානය යොමු කරයි (SLO) වෙත සම්බන්ධ කර ඇත .
පසුගිය වසර පුරා, යටිතල පහසුකම් අංශයේ එක් ප්‍රධාන සිදුවීමක් වූයේ SLOs සමඟ අධීක්‍ෂණය සහ වැඩ කිරීම වැඩිදියුණු කිරීමයි. සංක්‍රමණය අතරතුර අපි සමීපව නිරීක්ෂණය කළ තනි සේවාවන් සඳහා ඉලක්ක තැබීමට SLOs අපට ඉඩ දී ඇත. නමුත් මෙම වැඩිදියුණු කළ නිරීක්ෂණ හැකියාව සමඟ වුවද, ප්‍රමිතික සහ ඇඟවීම් භාවිතයෙන් ගැටළු වහාම දැකීමට සැමවිටම නොහැකි ය. උදාහරණයක් ලෙස, ප්‍රමාද සහ දෝෂ අනුපාත කෙරෙහි අවධානය යොමු කිරීමෙන්, සංක්‍රමණයට ලක්වන සේවාවක් සඳහා වන සියලුම භාවිත අවස්ථා අපි සම්පූර්ණයෙන්ම ආවරණය නොකරමු.
සමහර වැඩ බර පොකුරට සංක්‍රමණය වූ වහාම මෙම ගැටළුව සොයා ගන්නා ලදී. ඉල්ලීම් සංඛ්‍යාව කුඩා වූ නමුත් ඉතා නිශ්චිත වින්‍යාස පරායත්තතා ඇති කාර්යයන් පරීක්ෂා කිරීමට අපට සිදු වූ විට එය විශේෂයෙන් තීව්‍ර විය. සංක්‍රමණයේ එක් ප්‍රධාන පාඩමක් වූයේ නිරීක්ෂණය කිරීමේදී ප්‍රමිතික පමණක් නොව, ලොග සහ “දිගු වලිගය” ද සැලකිල්ලට ගැනීමේ අවශ්‍යතාවයයි. (මේ ගැන වගුවේ - දළ වශයෙන්. පරිවර්තනය.) වැරදි. දැන් එක් එක් සංක්‍රමණය සඳහා අපි ලොග් විමසුම්වල සවිස්තර ලැයිස්තුවක් ඇතුළත් කරමු (ලොග් විමසුම්) ගැටළු මතු වුවහොත් එක් මාරුවක සිට ඊළඟ මාරුව වෙත මාරු කළ හැකි පැහැදිලි ආපසු හැරවීමේ ක්‍රියා පටිපාටි සැලසුම් කරන්න.
පැරණි VM යටිතල පහසුකම් සහ නව Kubernetes මත පදනම් වූ යටිතල ව්‍යූහයට සමාන්තරව එම ඉල්ලීම් ඉටු කිරීම සුවිශේෂී අභියෝගයක් ඉදිරිපත් කළේය. ලිෆ්ට්-ඇන්ඩ්-ෂිෆ්ට් සංක්‍රමණය මෙන් නොව (නව යටිතල ව්‍යුහයකට "පවතින පරිදි" යෙදුම් ඉක්මනින් මාරු කිරීම; වැඩි විස්තර කියවිය හැක, උදාහරණයක් ලෙස, - ආසන්න වශයෙන්. පරිවර්තනය.), "පැරණි" VMs සහ Kubernetes හි සමාන්තර වැඩ සඳහා අධීක්ෂණ මෙවලම් පරිසරයන් දෙකටම අනුකූල වීම සහ ප්‍රමිතික එක් දසුනකට ඒකාබද්ධ කිරීමට හැකි වීම අවශ්‍ය වේ. සංක්‍රාන්ති කාලපරිච්ඡේදය තුළ ස්ථාවර නිරීක්ෂණ හැකියාවක් ලබා ගැනීම සඳහා අපි එකම උපකරණ පුවරු සහ ලොග් විමසුම් භාවිතා කිරීම වැදගත් වේ.
4. ගමනාගමනය නව පොකුරකට මාරු කිරීම
GitLab.com සඳහා, සේවාදායකයන්ගෙන් කොටසක් කැප කර ඇත . කැනරි උද්‍යානය අපගේ අභ්‍යන්තර ව්‍යාපෘති සඳහාද සේවය කරයි . නමුත් එය මූලික වශයෙන් සැලසුම් කර ඇත්තේ යටිතල පහසුකම් සහ යෙදුමේ සිදු කරන ලද වෙනස්කම් පරීක්ෂා කිරීම සඳහා ය. පළමු සංක්‍රමණ සේවාව ආරම්භ වූයේ සීමිත අභ්‍යන්තර ගමනාගමන ප්‍රමාණයක් පිළිගැනීමෙන් වන අතර, සියලුම ගමනාගමනය පොකුරට යැවීමට පෙර SLOs සපුරාලීම සහතික කිරීමට අපි මෙම ක්රමය දිගටම භාවිතා කරන්නෙමු.
සංක්‍රමණයේදී, මෙයින් අදහස් කරන්නේ අභ්‍යන්තර ව්‍යාපෘති සඳහා වන ඉල්ලීම් මුලින්ම Kubernetes වෙත යවනු ලබන බවත්, පසුව HAProxy හරහා පසුපෙළ සඳහා බර වෙනස් කිරීමෙන් ක්‍රමයෙන් ඉතිරි ගමනාගමනය පොකුරට මාරු කරන බවත්ය. VM සිට Kubernetes වෙත සංක්‍රමණය වීමේදී, පැරණි සහ නව යටිතල පහසුකම් අතර ගමනාගමනය යළි හරවා යැවීමට පහසු ක්‍රමයක් තිබීම ඉතා ප්‍රයෝජනවත් බව පැහැදිලි වූ අතර, ඒ අනුව, සංක්‍රමණයෙන් පසු පළමු දින කිහිපය තුළ පැරණි යටිතල පහසුකම් ආපසු හැරවීමට සූදානම්ව තබා ගන්න.
5. කරල්වල සංචිත ධාරිතාව සහ ඒවායේ භාවිතය
පහත සඳහන් ගැටලුව වහාම පාහේ හඳුනා ගන්නා ලදී: රෙජිස්ට්‍රි සේවාව සඳහා කරල් ඉක්මනින් ආරම්භ වූ නමුත් Sidekiq සඳහා පොඩ්ස් දියත් කිරීම දක්වා ගත විය . Sidekiq Pods සඳහා දිගු ධාවන කාලය ගැටලුවක් වූයේ අපි ඉක්මනින් රැකියා සැකසීමට සහ ඉක්මනින් පරිමාණය කිරීමට අවශ්‍ය කම්කරුවන් සඳහා Kubernetes වෙත වැඩ බර සංක්‍රමණය කිරීම ආරම්භ කළ විටය.
මෙම අවස්ථාවෙහිදී, පාඩම වූයේ, Kubernetes හි Horizontal Pod Autoscaler (HPA) රථවාහන වර්ධනය හැසිරවීමේ හොඳ කාර්යයක් කරන අතර, වැඩ බරෙහි ලක්ෂණ සැලකිල්ලට ගැනීම සහ කරල් සඳහා අමතර ධාරිතාව වෙන් කිරීම වැදගත් වේ (විශේෂයෙන් ඉල්ලුම අසමාන ලෙස බෙදා හරිනු ලැබේ). අපගේ නඩුවේදී, නෝඩ් සංචිතය පරිමාණය කිරීමට කාලය ලැබීමට පෙර CPU සම්පත් සංතෘප්ත වීමට තුඩු දුන් වේගවත් පරිමාණයට තුඩු දුන් රැකියාවල හදිසි වැඩිවීමක් ඇති විය.
සෑම විටම පොකුරකින් හැකිතාක් මිරිකීමට පෙළඹීමක් ඇත, කෙසේ වෙතත්, මුලින් කාර්ය සාධන ගැටළු වලට මුහුණ දී ඇති බැවින්, අපි දැන් ත්‍යාගශීලී පොඩ් බජට් එකකින් ආරම්භ කර පසුව එය අඩු කරමු, SLOs ගැන සමීපව විමසිල්ලෙන් සිටින්න. Sidekiq සේවාව සඳහා කරල් දියත් කිරීම සැලකිය යුතු ලෙස වේගවත් කර ඇති අතර දැන් සාමාන්‍යයෙන් තත්පර 40ක් පමණ ගත වේ. GitLab.com සහ නිල GitLab Helm ප්‍රස්ථාරය සමඟ වැඩ කරන ස්වයං-කළමනාකරන ස්ථාපනයන් භාවිතා කරන්නන් යන දෙකම දිනා ඇත.
නිගමනය
එක් එක් සේවාව සංක්‍රමණය කිරීමෙන් පසුව, නිෂ්පාදනයේදී Kubernetes භාවිතා කිරීමේ ප්‍රතිලාභ ගැන අපි ප්‍රීති වෙමු: වේගවත් සහ ආරක්ෂිත යෙදුම් යෙදවීම, පරිමාණය කිරීම සහ වඩා කාර්යක්ෂම සම්පත් වෙන් කිරීම. එපමණක් නොව, සංක්‍රමණයේ වාසි GitLab.com සේවාවෙන් ඔබ්බට යයි. නිල හෙල්ම් ප්‍රස්ථාරයේ සෑම වැඩිදියුණු කිරීමක්ම එහි පරිශීලකයින්ට ප්‍රතිලාභ ලබා දෙයි.
අපගේ Kubernetes සංක්‍රමණ වික්‍රමාන්විත කතාව ඔබ රස වින්දා යැයි මම සිතමි. අපි සියලුම නව සේවාවන් පොකුරට සංක්‍රමණය කිරීම දිගටම කරගෙන යන්නෙමු. අමතර තොරතුරු පහත ප්‍රකාශනවලින් සොයාගත හැකිය:
- «»;
- «»;
- .
පරිවර්තකගෙන් PS
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «»;
- «»;
- «»;
- «".
මූලාශ්රය: www.habr.com