Kubernetes යනු පොකුරු නිෂ්පාදන පරිසරයක් තුළ Docker බහාලුම් ධාවනය කිරීම සඳහා විශිෂ්ට මෙවලමකි. කෙසේ වෙතත්, Kubernetes විසඳිය නොහැකි ගැටළු තිබේ. නිරන්තර නිෂ්පාදන යෙදවීම් සඳහා, ක්‍රියාවලියේ අක්රිය කාලය වළක්වා ගැනීම සඳහා අපට සම්පූර්ණ ස්වයංක්‍රීය නිල්/කොළ යෙදවීමක් අවශ්ය වන අතර, බාහිර HTTP ඉල්ලීම් හැසිරවීමට සහ SSL ඕෆ්ලෝඩ් කිරීමටද අවශ්ය වේ. මේ සඳහා ha-proxy වැනි load balancer එකක් සමඟ ඒකාබද්ධ වීම අවශ්ය වේ. තවත් අභියෝගයක් වන්නේ වලාකුළු පරිසරයක ධාවනය වන විට Kubernetes පොකුරේ අර්ධ ස්වයංක්‍රීය පරිමාණය කිරීම, උදාහරණයක් ලෙස රාත්‍රියේදී පොකුර අර්ධ වශයෙන් පරිමාණය කිරීම.
Kubernetes සතුව මෙම විශේෂාංග නොමැති අතර, එය ඔබට සමාන ගැටළු විසඳීමට භාවිතා කළ හැකි API සපයයි. විවෘත මූලාශ්රය මත පදනම්ව නිර්මාණය කරන ලද Cloud RTI ව්‍යාපෘතියේ කොටසක් ලෙස Kubernetes පොකුරක් ස්වයංක්‍රීයව නිල්/කොළ යෙදවීම සහ පරිමාණය කිරීම සඳහා මෙවලම් සංවර්ධනය කරන ලදී.
මෙම ලිපිය, වීඩියෝ පිටපතක්, නිෂ්පාදනයේ අක්රිය කාලයකින් තොරව git කැපවීමකින් කේතයක් පිළිගන්නා නිෂ්පාදන-සුදානම් පරිසරයක් නිර්මාණය කිරීම සඳහා අනෙකුත් විවෘත මූලාශ්‍ර සංරචක සමඟ Kubernetes පිහිටුවන ආකාරය ඔබට පෙන්වයි.
එබැවින්, ඔබට බාහිර ලෝකයෙන් ඔබගේ යෙදුම් වෙත ප්‍රවේශ වූ පසු, ඔබට ස්වයංක්‍රීයකරණය සම්පූර්ණයෙන්ම සැකසීමට පටන් ගත හැකිය, එනම්, ඔබට එය git කැපවීමක් කළ හැකි වේදිකාවට ගෙන ඒම සහ මෙම git කැපවීම නිෂ්පාදනයෙන් අවසන් වන බවට වග බලා ගන්න. ස්වාභාවිකවම, මෙම පියවරයන් ක්රියාත්මක කිරීමේදී, යෙදවීම ක්රියාත්මක කිරීමේදී, අපට අක්රිය කාලය හමුවීමට අවශ්ය නොවේ. එබැවින්, Kubernetes හි ඕනෑම ස්වයංක්‍රීයකරණයක් API සමඟ ආරම්භ වේ.
Kubernetes යනු පෙට්ටියෙන් පිටත ඵලදායී ලෙස භාවිතා කළ හැකි මෙවලමක් නොවේ. ඇත්ත වශයෙන්ම, ඔබට එය කළ හැකිය, kubectl සහ යනාදිය භාවිතා කරන්න, නමුත් තවමත් API මෙම වේදිකාවේ වඩාත්ම සිත්ගන්නාසුළු හා ප්රයෝජනවත් දෙයකි. API ශ්‍රිත කට්ටලයක් ලෙස භාවිතා කිරීමෙන්, ඔබට Kubernetes හි කිරීමට අවශ්ය ඕනෑම දෙයකට ප්‍රවේශ විය හැක. kubectl විසින්ම REST API භාවිතා කරයි.
මෙය REST වේ, එබැවින් ඔබට මෙම API සමඟ වැඩ කිරීමට ඕනෑම භාෂාවක් හෝ මෙවලමක් භාවිතා කළ හැක, නමුත් අභිරුචි පුස්තකාල මගින් ඔබේ ජීවිතය වඩාත් පහසු කරනු ඇත. මගේ කණ්ඩායම එවැනි පුස්තකාල 2ක් ලිවීය: එකක් Java/OSGi සඳහා සහ එකක් Go සඳහා. දෙවැන්න බොහෝ විට භාවිතා නොවේ, නමුත් ඕනෑම අවස්ථාවක ඔබ සතුව මෙම ප්රයෝජනවත් දේවල් තිබේ. ඒවා අර්ධ වශයෙන් බලපත්‍රලාභී විවෘත මූලාශ්‍ර ව්‍යාපෘතියකි. විවිධ භාෂා සඳහා එවැනි පුස්තකාල රාශියක් ඇත, එබැවින් ඔබට වඩාත් ගැලපෙන ඒවා තෝරා ගත හැකිය.
එබැවින්, ඔබ ඔබේ යෙදවීම ස්වයංක්‍රීය කිරීම ආරම්භ කිරීමට පෙර, ක්රියාවලිය කිසිදු අක්‍රීය කාලයකට යටත් නොවන බවට ඔබ සහතික විය යුතුය. උදාහරණයක් ලෙස, අපගේ කණ්ඩායම මිනිසුන් උපරිමයෙන් යෙදුම් භාවිතා කරන දවසේ මැද භාගයේදී නිෂ්පාදන යෙදවීම් සිදු කරයි, එබැවින් මෙම ක්‍රියාවලියේ ප්‍රමාදයන් වළක්වා ගැනීම වැදගත් වේ. අක්රිය කාලය වළක්වා ගැනීම සඳහා, ක්‍රම 2 ක් භාවිතා කරයි: නිල්/කොළ යෙදවීම හෝ පෙරළීමේ යාවත්කාලීන කිරීම. අවසාන අවස්ථාවෙහිදී, ඔබට යෙදුමේ අනුරූ 5 ක් ක්රියාත්මක වේ නම්, ඒවා එකින් එක අනුක්‍රමිකව යාවත්කාලීන වේ. මෙම ක්‍රමය විශිෂ්ට ලෙස ක්‍රියා කරයි, නමුත් යෙදවීමේ ක්‍රියාවලියේදී ඔබට එකවර ක්රියාත්මක වන යෙදුමේ විවිධ අනුවාද තිබේ නම් එය සුදුසු නොවේ. මෙම අවස්ථාවෙහිදී, පසුබිම පැරණි අනුවාදය ධාවනය වන විට ඔබට පරිශීලක අතුරුමුහුණත යාවත්කාලීන කළ හැකි අතර, යෙදුම වැඩ කිරීම නවත්වනු ඇත. එබැවින්, ක්රමලේඛන දෘෂ්ටි කෝණයකින්, එවැනි තත්වයන් තුළ වැඩ කිරීම තරමක් අපහසු වේ.
අපගේ යෙදුම් යෙදවීම ස්වයංක්‍රීය කිරීමට නිල්/කොළ යෙදවීම භාවිතා කිරීමට අප කැමති වීමට මෙය එක් හේතුවක් වේ. මෙම ක්‍රමය සමඟ, වරකට යෙදුමේ එක් අනුවාදයක් පමණක් සක්‍රිය බව ඔබ සහතික කළ යුතුය.
නිල්/කොළ යෙදවීමේ යාන්ත්රණය මේ ආකාරයෙන් පෙනේ. අපි අපගේ යෙදුම් සඳහා ha-proxy හරහා ගමනාගමනය ලබා ගනිමු, එය එකම අනුවාදයේ යෙදුමේ ධාවන අනුරූ වෙත යොමු කරයි.
නව යෙදවීමක් සිදු කරන විට, අපි නව සංරචක ලබා දී නව අනුවාදය යොදවන Deployer භාවිතා කරමු. යෙදුමක නව අනුවාදයක් යෙදවීම යන්නෙන් අදහස් වන්නේ නව අනුරූ කට්ටලයක් "ඔසවා" ඇති බවයි, ඉන් පසුව නව අනුවාදයේ මෙම අනුරූ වෙනම, නව පොඩ් එකකින් දියත් කරනු ලැබේ. කෙසේ වෙතත්, ha-proxy ඔවුන් ගැන කිසිවක් නොදන්නා අතර තවමත් ඔවුන් වෙත කිසිදු වැඩ බරක් යොමු නොකරයි.
එබැවින්, ප්රථමයෙන්, අනුරූ බරට සේවා සැපයීමට සූදානම් බව සහතික කිරීම සඳහා සෞඛ්ය පරීක්ෂා කිරීමේ නව අනුවාදවල කාර්ය සාධන පරීක්ෂාවක් සිදු කිරීම අවශ්ය වේ.
සියලුම යෙදවුම් සංරචක යම් ආකාරයක සෞඛ්ය පරීක්ෂාවකට සහාය විය යුතුය. මෙය ඉතා සරල HTTP ඇමතුම් පරීක්ෂාවක් විය හැකිය, ඔබට තත්ත්වය 200 සහිත කේතයක් ලැබුණු විට, හෝ දත්ත සමුදාය සහ අනෙකුත් සේවාවන් සමඟ අනුරූ සම්බන්ධ කිරීම, ගතික පරිසර සම්බන්ධතා වල ස්ථායීතාවය පරීක්ෂා කරන වඩාත් ගැඹුරු පරීක්ෂාවක්. , සහ සියල්ල ආරම්භ වී නිවැරදිව ක්‍රියා කරන්නේද යන්න. මෙම ක්රියාවලිය තරමක් සංකීර්ණ විය හැකිය.
සියලුම යාවත්කාලීන කළ අනුරූ ක්‍රියා කරන බව පද්ධතිය සත්‍යාපනය කළ පසු, Deployer විසින් වින්‍යාසය යාවත්කාලීන කර නිවැරදි confd ලබා දෙනු ඇත, එය ha-proxy නැවත වින්‍යාස කරනු ඇත.
මෙයින් පසුව පමණක් නව අනුවාදයේ අනුරූ සහිත පොඩ් වෙත ගමනාගමනය යොමු කරනු ලබන අතර පැරණි පෝඩ් අතුරුදහන් වනු ඇත.
මෙම යාන්ත්රණය Kubernetes හි ලක්ෂණයක් නොවේ. නිල්/කොළ යෙදවීම පිළිබඳ සංකල්පය බොහෝ කලක සිට පැවත එන අතර එය සැමවිටම load balancer එකක් භාවිතා කර ඇත. පළමුව, ඔබ යෙදුමේ පැරණි අනුවාදය වෙත සියලු ගමනාගමනය යොමු කරන අතර, යාවත්කාලීන කිරීමෙන් පසුව, ඔබ එය සම්පූර්ණයෙන්ම නව අනුවාදයට මාරු කරයි. මෙම මූලධර්මය Kubernetes හි පමණක් භාවිතා නොවේ.
දැන් මම ඔබට නව යෙදවුම් සංරචකයක් හඳුන්වා දෙන්නම් - Deployer, සෞඛ්ය පරීක්‍ෂණ සිදු කරන, ප්‍රොක්සි නැවත වින්‍යාස කිරීම සහ යනාදිය. මෙය බාහිර ලෝකයට අදාළ නොවන සහ Kubernetes තුළ පවතින සංකල්පයකි. විවෘත මූලාශ්‍ර මෙවලම් භාවිතයෙන් ඔබට ඔබේම Deployer සංකල්පයක් සාදාගත හැකි ආකාරය මම ඔබට පෙන්වන්නම්.
එබැවින්, Deployer විසින් කරන පළමු දෙය නම් Kubernetes API භාවිතයෙන් RC අනුකරණ පාලකයක් නිර්මාණය කිරීමයි. මෙම API තවදුරටත් යෙදවීම සඳහා කරල් සහ සේවා නිර්මාණය කරයි, එනම්, එය අපගේ යෙදුම් සඳහා සම්පූර්ණයෙන්ම නව පොකුරක් නිර්මාණය කරයි. අනුපිටපත් ආරම්භ වී ඇති බව RC ට ඒත්තු ගිය වහාම, එය ඒවායේ ක්‍රියාකාරීත්වය පිළිබඳ සෞඛ්ය පරීක්‍ෂණයක් සිදු කරනු ඇත. මෙය සිදු කිරීම සඳහා, Deployer GET /health විධානය භාවිතා කරයි. එය සුදුසු ස්කෑන් සංරචක ධාවනය කරන අතර පොකුරේ ක්‍රියාකාරිත්වයට සහාය වන සියලුම අංග පරීක්ෂා කරයි.
සියලුම කරල් ඔවුන්ගේ සෞඛ්‍යය වාර්තා කිරීමෙන් පසු, යෙදවුම්කරු නව වින්‍යාස මූලද්‍රව්‍යයක් නිර්මාණය කරයි - etcd බෙදා හරින ලද ගබඩාව, එය කුබර්නෙටස් විසින් අභ්‍යන්තරව භාවිතා කරයි, පැටවුම් සමතුලිත වින්‍යාසය ගබඩා කිරීම ඇතුළුව. අපි etcd වලට දත්ත ලියන අතර, නව දත්ත සඳහා confd monitors etcd නම් කුඩා මෙවලමකි.
එය මූලික වින්‍යාසයේ යම් වෙනසක් හඳුනා ගන්නේ නම්, එය නව සැකසුම් ගොනුවක් ජනනය කර එය ha-proxy වෙත මාරු කරයි. මෙම අවස්ථාවෙහිදී, ha-proxy කිසිදු සම්බන්ධතාවයක් අහිමි නොවී නැවත පණගන්වන අතර අපගේ යෙදුම්වල නව අනුවාදය ක්‍රියා කිරීමට සබල කරන නව සේවාවන් වෙත පැටවීම ආමන්ත්‍රණය කරයි.
ඔබට පෙනෙන පරිදි, සංරචක බහුල වුවද, මෙහි සංකීර්ණ කිසිවක් නොමැත. ඔබ API සහ etcd වෙත වැඩි අවධානයක් යොමු කළ යුතුය. අප විසින්ම භාවිතා කරන විවෘත මූලාශ්‍ර යෙදවුම්කරු ගැන මට ඔබට පැවසීමට අවශ්‍යයි - Amdatu Kubernetes Deployer.
එය Kubernetes යෙදවීම් සංවිධානය කිරීම සඳහා මෙවලමක් වන අතර පහත විශේෂාංග ඇත:
- නිල්/කොළ යෙදවීම;
- බාහිර පැටවුම් ශේෂයක් සැකසීම;
- යෙදවුම් විස්තර කළමනාකරණය;
- සැබෑ යෙදවීම කළමනාකරණය කිරීම;
- යෙදවීමේදී සෞඛ්ය පරීක්‍ෂණවල ක්‍රියාකාරීත්වය පරීක්ෂා කිරීම;
- පරිසර විචල්‍යයන් කරල් වලට ක්රියාත්මක කිරීම.
මෙම Deployer Kubernetes API මත ගොඩනගා ඇති අතර හසුරුවීම් සහ යෙදවීම් කළමනාකරණය සඳහා REST API මෙන්ම යෙදවීමේ ක්‍රියාවලියේදී ලොග ප්‍රවාහ කිරීම සඳහා Websocket API ද සපයයි.
එය load balancer වින්‍යාස දත්ත etcd වලට දමයි, එබැවින් ඔබට පෙට්ටියෙන් පිටත සහාය ඇතිව ha-proxy භාවිතා කිරීමට අවශ්ය නැත, නමුත් පහසුවෙන් ඔබගේම load balancer වින්‍යාස ගොනුව භාවිතා කරන්න. Amdatu Deployer Kubernetes වැනි Go හි ලියා ඇති අතර Apache විසින් බලපත්‍ර ලබා ඇත.
මම යෙදවුම්කරුගේ මෙම අනුවාදය භාවිතා කිරීමට පෙර, මම පහත යෙදවුම් විස්තරය භාවිතා කළෙමි, එය මට අවශ්ය පරාමිති නියම කරයි.
මෙම කේතයේ එක් වැදගත් පරාමිතියක් වන්නේ "useHealthCheck" ධජය සක්‍රීය කිරීමයි. යෙදවීමේ ක්‍රියාවලියේදී සනීපාරක්ෂාව පරීක්ෂාවක් සිදු කළ යුතු බව අපි සඳහන් කළ යුතුයි. යෙදවීම සත්‍යාපනය කිරීමට අවශ්ය නොවන තෙවන පාර්ශවීය බහාලුම් භාවිතා කරන විට මෙම සැකසුම අක්රිය කළ හැක. මෙම විස්තරය මඟින් ha-proxy සඳහා අවශ්ය අනුරූ ගණන සහ ඉදිරිපස URL ද දක්වයි. අවසානයේ පොඩ් පිරිවිතර ධජය "podspec" ඇත, එය වරාය වින්‍යාසය, රූපය ආදිය පිළිබඳ තොරතුරු සඳහා Kubernetes අමතයි. මෙය තරමක් සරල JSON විස්තරයකි.
විවෘත මූලාශ්‍ර Amdatu ව්‍යාපෘතියේ කොටසක් වන තවත් මෙවලමක් වන්නේ Deploymentctl වේ. එහි යෙදවුම් වින්‍යාස කිරීම සඳහා UI එකක් ඇත, යෙදවුම් ඉතිහාසය ගබඩා කරයි, සහ තෙවන පාර්ශවීය පරිශීලකයින් සහ සංවර්ධකයින්ගෙන් ඇමතුම් සඳහා webhooks අඩංගු වේ. Amdatu Deployer විසින්ම REST API එකක් වන බැවින් ඔබ UI භාවිතා නොකරනු ඇත, නමුත් මෙම අතුරුමුහුණත කිසිදු API සම්බන්ධ නොකර ඔබට යෙදවීම වඩාත් පහසු කළ හැක. Deploymentctl OSGi/Vertx වලින් ලියා ඇත්තේ Angular 2 භාවිතා කරමිනි.
මම දැන් ඔබට බලා සිටීමට අවශ්ය නොවන පරිදි කලින් පටිගත කරන ලද පටිගත කිරීමක් භාවිතයෙන් ඉහත දේ තිරය මත නිරූපණය කරමි. අපි සරල Go යෙදුමක් යොදවන්නෙමු. ඔබ මීට පෙර Go උත්සාහ කර නොමැති නම් කණගාටු නොවන්න, එය ඉතා සරල යෙදුමක් බැවින් ඔබට එය තේරුම් ගැනීමට හැකි විය යුතුය.
මෙහිදී අපි /සෞඛ්‍යයට පමණක් ප්‍රතිචාර දක්වන HTTP සේවාදායකයක් සාදන්නෙමු, එබැවින් මෙම යෙදුම සෞඛ්ය පරීක්ෂාව පමණක් පරීක්ෂා කරන අතර අන් කිසිවක් නැත. චෙක්පත සමත් වුවහොත්, පහත දැක්වෙන JSON ව්‍යුහය භාවිතා වේ. එහි යෙදවුම්කරු විසින් යොදවනු ලබන යෙදුමේ අනුවාදය, ගොනුවේ ඉහළින් ඔබ දකින පණිවිඩය සහ බූලියන් දත්ත වර්ගය - අපගේ යෙදුම ක්‍රියා කරයිද නැද්ද යන්න අඩංගු වේ.
මම අවසාන පේළිය සමඟ ටිකක් වංචා කළෙමි, මන්ද මම ගොනුවේ මුදුනේ ස්ථාවර බූලියන් අගයක් තැබූ නිසා අනාගතයේදී එය “සෞඛ්‍යයට අහිතකර” යෙදුමක් පවා යෙදවීමට මට උපකාරී වනු ඇත. අපි මේ ගැන පසුව කටයුතු කරමු.
එහෙනම් අපි පටන් ගනිමු. පළමුව, අපි ~ kubectl get pods යන විධානය භාවිතයෙන් ධාවනය වන කරල් තිබේදැයි පරීක්ෂා කර, ඉදිරිපස URL වෙතින් ප්‍රතිචාරයක් නොමැතිකම මත පදනම්ව, දැනට කිසිදු යෙදවීමක් සිදු නොවන බවට අපි සහතික වෙමු.
මීළඟට තිරයේ ඔබ මා සඳහන් කළ Deploymentctl අතුරුමුහුණත දකියි, එහි යෙදවුම් පරාමිතීන් සකසා ඇත: නාම අවකාශය, යෙදුම් නම, යෙදවීමේ අනුවාදය, අනුරූ ගණන, ඉදිරිපස URL, බහාලුම් නම, රූපය, සම්පත් සීමාවන්, සෞඛ්ය පරීක්ෂාව සඳහා වරාය අංකය, ආදිය. සම්පත් සීමාවන් ඉතා වැදගත් වේ, ඒවා ඔබට හැකි උපරිම දෘඪාංග භාවිතා කිරීමට ඉඩ සලසයි. මෙහිදී ඔබට Deployment log එකද බැලිය හැක.
ඔබ දැන් ~ kubectl get pods යන විධානය නැවත නැවත කළහොත්, පද්ධතිය තත්පර 20 ක් “කැටි” වන බව ඔබට දැක ගත හැකිය, එම කාලය තුළ ha-proxy නැවත සකස් කර ඇත. මෙයින් පසු, පොඩ් එක ආරම්භ වන අතර, අපගේ අනුරුව යෙදවුම් ලොගයේ දැකිය හැකිය.
මම වීඩියෝවෙන් තත්පර 20 ක් බලා සිටීම කපා හැරිය අතර, දැන් ඔබට යෙදුමේ පළමු අනුවාදය යොදවා ඇති බව තිරය මත දැකිය හැකිය. මේ සියල්ල කළේ UI පමණක් භාවිතා කරමිනි.
දැන් අපි දෙවන අනුවාදය උත්සාහ කරමු. මෙය සිදු කිරීම සඳහා, මම යෙදුමේ පණිවිඩය "Hello, Kubernetes!" වෙතින් වෙනස් කරමි. “Hello, Deployer!” මත, පද්ධතිය විසින් මෙම රූපය නිර්මාණය කර එය Docker රෙජිස්ට්‍රිය තුළ තබයි, ඉන් පසුව අපි Deploymentctl කවුළුවේ නැවත “Deploy” බොත්තම ක්ලික් කරන්නෙමු. මෙම අවස්ථාවෙහිදී, යෙදවුම් ලොගය යෙදුමේ පළමු අනුවාදය යෙදවීමේදී සිදු වූ ආකාරයටම ස්වයංක්‍රීයව දියත් කෙරේ.
~ kubectl get pods යන විධානය මඟින් දැනට ක්රියාත්මක වන යෙදුමේ අනුවාද 2 ක් පවතින බව පෙන්වයි, නමුත් ඉදිරිපසින් පෙන්වන්නේ අපි තවමත් 1 අනුවාදය ක්රියාත්මක කරන බවයි.
නව අනුවාදය වෙත ගමනාගමනය යළි හරවා යැවීමට පෙර load balancer සෞඛ්ය පරීක්ෂාව සම්පූර්ණ වන තෙක් බලා සිටී. තත්පර 20 කට පසු, අපි curl වෙත මාරු වන අතර, අපි දැන් යෙදුමේ 2 අනුවාදය යොදවා ඇති අතර, පළමු එක මකා දමා ඇති බව දකිමු.
මෙය "සෞඛ්ය සම්පන්න" යෙදුමක් යෙදවීමයි. යෙදුමේ නව අනුවාදයක් සඳහා මම සෞඛ්ය සම්පන්න පරාමිතිය සත්‍ය සිට අසත්‍ය ලෙස වෙනස් කළහොත් කුමක් සිදුවේදැයි බලමු, එනම් සෞඛ්ය පරීක්ෂාව අසාර්ථක වූ සෞඛ්‍යයට අහිතකර යෙදුමක් යෙදවීමට මම උත්සාහ කරමි. සංවර්ධන අදියරේදී යෙදුමේ සමහර වින්‍යාස දෝෂ සිදු කර ඇති අතර එය මෙම පෝරමයේ නිෂ්පාදනයට යවනු ලැබුවහොත් මෙය සිදුවිය හැකිය.
ඔබට පෙනෙන පරිදි, යෙදවීම ඉහත සියලුම පියවර හරහා යන අතර ~kubectl get pods පෙන්වන්නේ කරල් දෙකම ක්රියාත්මක වන බවයි. නමුත් පෙර යෙදවීම මෙන් නොව, ලොගය කල් ඉකුත්වීමේ තත්ත්වය පෙන්වයි. එනම්, සෞඛ්ය පරීක්ෂාව අසාර්ථක වූ නිසා, යෙදුමේ නව අනුවාදය යෙදවිය නොහැක. එහි ප්‍රතිඵලයක් ලෙස, පද්ධතිය යෙදුමේ පැරණි අනුවාදය භාවිතා කිරීමට ප්‍රතිවර්තනය වී ඇති බවත්, නව අනුවාදය සරලව අස්ථාපනය කර ඇති බවත් ඔබට පෙනේ.
මෙහි ඇති හොඳ දෙය නම්, ඔබට යෙදුමට එකවර ඉල්ලීම් විශාල ප්‍රමාණයක් පැමිණියද, ඔවුන් යෙදවීමේ ක්‍රියා පටිපාටිය ක්රියාත්මක කිරීමේදී අක්‍රීය කාලය නොදැන සිටීමයි. ඔබ මෙම යෙදුමට හැකි තරම් ඉල්ලීම් යවන Gatling රාමුව භාවිතයෙන් මෙම යෙදුම පරීක්ෂා කරන්නේ නම්, මෙම ඉල්ලීම් කිසිවක් අත් නොහරිනු ඇත. මෙයින් අදහස් කරන්නේ අපගේ පරිශීලකයින් තථ්‍ය කාලය තුළ අනුවාද යාවත්කාලීන කිරීම් පවා නොදකින බවයි. එය අසාර්ථක වුවහොත්, පැරණි අනුවාදයේ වැඩ දිගටම කරගෙන යනු ඇත; එය සාර්ථක නම්, පරිශීලකයින් නව අනුවාදයට මාරු වනු ඇත.
අසමත් විය හැක්කේ එක් දෙයක් පමණි - සෞඛ්ය පරීක්‍ෂණය සාර්ථක වුවහොත්, නමුත් වැඩ ප්‍රමාණය එයට යෙදූ විගසම යෙදුම අසාර්ථක වේ, එනම් කඩා වැටීම සිදුවන්නේ යෙදවීම අවසන් වූ පසුව පමණි. මෙම අවස්ථාවේදී, ඔබට පැරණි අනුවාදයට අතින් පෙරළීමට සිදුවේ. එබැවින්, අපි ඒ සඳහා නිර්මාණය කර ඇති විවෘත මූලාශ්‍ර මෙවලම් සමඟ Kubernetes භාවිතා කරන්නේ කෙසේදැයි සොයා බැලුවෙමු. ඔබ මෙම මෙවලම් ඔබේ Build/Deploy නල මාර්ග තුළට ගොඩනගා ගන්නේ නම් යෙදවීමේ ක්රියාවලිය වඩාත් පහසු වනු ඇත. ඒ සමගම, යෙදවීම ආරම්භ කිරීම සඳහා, ඔබට පරිශීලක අතුරුමුහුණත භාවිතා කළ හැකිය, නැතහොත් භාවිතා කිරීමෙන් මෙම ක්රියාවලිය සම්පුර්ණයෙන්ම ස්වයංක්‍රීය කිරීම, උදාහරණයක් ලෙස, ප්‍රගුණ කිරීමට කැපවීම.
අපගේ Build Server විසින් Docker රූපයක් සාදනු ඇත, එය Docker Hub වෙත හෝ ඔබ භාවිතා කරන ඕනෑම රෙජිස්ට්‍රියකට තල්ලු කරනු ඇත. Docker Hub webhook සඳහා සහය දක්වයි, එබැවින් අපට ඉහත පෙන්වා ඇති ආකාරයට Deployer හරහා දුරස්ථ යෙදවීම ආරම්භ කළ හැක. මේ ආකාරයෙන් ඔබට ඔබේ යෙදුම විභව නිෂ්පාදනයට යෙදවීම සම්පූර්ණයෙන්ම ස්වයංක්‍රීය කළ හැක.
අපි ඊළඟ මාතෘකාවට යමු - කුබර්නෙටස් පොකුර පරිමාණය කිරීම. kubectl විධානය පරිමාණ විධානයක් බව සලකන්න. වැඩි උපකාරයක් ඇතිව, අපගේ පවතින පොකුරේ ඇති අනුරූ ගණන පහසුවෙන් වැඩි කළ හැක. කෙසේ වෙතත්, ප්රායෝගිකව, සාමාන්යයෙන් අපට අවශ්ය වන්නේ කරල් වලට වඩා නෝඩ් ගණන වැඩි කිරීමයි.
ඒ අතරම, වැඩ කරන වේලාවන් තුළ ඔබට වැඩි කිරීමට අවශ්ය විය හැකි අතර, රාත්‍රියේදී, Amazon සේවාවන්හි පිරිවැය අඩු කිරීම සඳහා, ඔබට ධාවනය වන යෙදුම් අවස්ථා ගණන අඩු කිරීමට අවශ්ය විය හැකිය. මින් අදහස් වන්නේ කරල් ගණන පමණක් පරිමාණය කිරීම ප්‍රමාණවත් නොවන බවයි, මන්ද යත් එක් නෝඩ් එකක් ක්‍රියා විරහිත වුවද, ඔබට ඒ සඳහා ඇමේසන් වෙත ගෙවීමට සිදුවනු ඇති බැවිනි. එනම්, කරල් පරිමාණය කිරීමත් සමඟ, ඔබ භාවිතා කරන යන්ත්ර ගණන පරිමාණය කිරීමට අවශ්ය වනු ඇත.
මෙය අභියෝගාත්මක විය හැක්කේ අපි Amazon හෝ වෙනත් ක්ලවුඩ් සේවාවක් භාවිතා කළත්, Kubernetes භාවිතා කරන යන්ත්ර ගණන ගැන කිසිවක් නොදන්නා බැවිනි. නෝඩ් මට්ටමින් පද්ධතිය පරිමාණය කිරීමට ඔබට ඉඩ සලසන මෙවලමක් එහි නොමැත.
එබැවින් අපි නෝඩ් සහ කරල් දෙකම ගැන සැලකිලිමත් විය යුතුය. Kubernetes සේවක නෝඩ් ගණන වින්‍යාස කිරීම සඳහා AWS API සහ Scaling කණ්ඩායම් යන්ත්ර භාවිතයෙන් නව නෝඩ් දියත් කිරීම අපට පහසුවෙන් පරිමාණය කළ හැකිය. Kubernetes පොකුරේ නෝඩ් ලියාපදිංචි කිරීමට ඔබට cloud-init හෝ ඒ හා සමාන ස්ක්‍රිප්ට් එකක් ද භාවිතා කළ හැක.
නව යන්ත්‍රය Scaling කණ්ඩායමෙන් ආරම්භ වී, නෝඩයක් ලෙස ආරම්භ වී, මාස්ටර්ගේ රෙජිස්ට්‍රියේ ලියාපදිංචි වී වැඩ කිරීමට පටන් ගනී. මෙයින් පසු, ඔබට ලැබෙන නෝඩ් වල භාවිතය සඳහා අනුරූ ගණන වැඩි කළ හැකිය. එවැනි පියවරක් "අනවශ්ය" යන්ත්ර අක්රිය කිරීමෙන් පසු දැනටමත් ක්රියාත්මක වන යෙදුම් විනාශ කිරීමට හේතු නොවන බවට වග බලා ගත යුතු බැවින්, පරිමාණය අඩු කිරීම සඳහා වැඩි උත්සාහයක් අවශ්ය වේ. එවැනි තත්වයක් වැලැක්වීම සඳහා, ඔබ "නොසැලකිලිමත්" තත්ත්වයට නෝඩ් සකස් කළ යුතුය. මෙයින් අදහස් කරන්නේ DaemonSet පොඩ් කාලසටහන්ගත කිරීමේදී පෙරනිමි කාලසටහන්කරු මෙම නෝඩ් නොසලකා හරින බවයි. උපලේඛකයා මෙම සේවාදායකයන්ගෙන් කිසිවක් මකා නොදමනු ඇත, නමුත් එහි නව බහාලුම් දියත් නොකරනු ඇත. මීලඟ පියවර වන්නේ කාණු නෝඩය ඉවත් කිරීමයි, එනම් ධාවන කරල් එයින් වෙනත් යන්ත්‍රයකට හෝ මේ සඳහා ප්‍රමාණවත් ධාරිතාවක් ඇති වෙනත් නෝඩ් වලට මාරු කිරීමයි. මෙම නෝඩ් වල තවදුරටත් බහාලුම් නොමැති බව ඔබ සහතික කළ පසු, ඔබට ඒවා Kubernetes වෙතින් ඉවත් කළ හැක. මෙයින් පසු, ඒවා කුබර්නෙටස් සඳහා පවතිනු ඇත. ඊළඟට, අනවශ්ය නෝඩ් හෝ යන්ත්ර අක්රිය කිරීමට ඔබ AWS API භාවිතා කළ යුතුය.
ඔබට AWS API හා සමාන තවත් විවෘත මූලාශ්‍ර පරිමාණ මෙවලමක් වන Amdatu Scalerd භාවිතා කළ හැක. එය පොකුරක් තුළ නෝඩ් එකතු කිරීමට හෝ ඉවත් කිරීමට CLI සපයයි. එහි සිත්ගන්නා ලක්ෂණය වන්නේ පහත json ගොනුව භාවිතයෙන් උපලේඛනය වින්‍යාස කිරීමේ හැකියාවයි.
පෙන්වා ඇති කේතය රාත්‍රී කාලය තුළ පොකුරු ධාරිතාව අඩකින් අඩු කරයි. එය ඇමසන් පොකුරේ ඇති අනුරූ ගණන සහ අපේක්ෂිත ධාරිතාව යන දෙකම වින්‍යාස කරයි. මෙම කාලසටහන භාවිතා කිරීමෙන් රාත්‍රියේ ස්වයංක්‍රීයව නෝඩ් සංඛ්‍යාව අඩු වන අතර උදෑසන ඒවා වැඩි කරයි, Amazon වැනි ක්ලවුඩ් සේවාවකින් නෝඩ් භාවිතා කිරීමේ පිරිවැය ඉතිරි වේ. මෙම විශේෂාංගය Kubernetes තුළ ගොඩනගා නැත, නමුත් Scalerd භාවිතා කිරීමෙන් ඔබට අවශ්ය පරිදි මෙම වේදිකාව පරිමාණය කිරීමට ඔබට ඉඩ සලසයි.
බොහෝ අය මට කියන බව පෙන්වා දීමට කැමැත්තෙමි, “ඒ සියල්ල හොඳයි, නමුත් සාමාන්යයෙන් ස්ථිතික වන මගේ දත්ත සමුදාය ගැන කුමක් කිව හැකිද?” Kubernetes වැනි ගතික පරිසරයක මෙවැනි දෙයක් ධාවනය කරන්නේ කෙසේද? මගේ මතය අනුව, ඔබ මෙය නොකළ යුතුය, ඔබ Kubernetes හි දත්ත ගබඩාවක් පවත්වාගෙන යාමට උත්සාහ නොකළ යුතුය. මෙය තාක්ෂණික වශයෙන් කළ හැකි අතර, මෙම විෂය පිළිබඳ අන්තර්ජාලයේ නිබන්ධන ඇත, නමුත් එය ඔබගේ ජීවිතය බරපතල ලෙස සංකීර්ණ කරනු ඇත.
ඔව්, Kubernetes හි ස්ථීර ගබඩා සංකල්පයක් ඇත, ඔබට Mongo හෝ MySQL වැනි දත්ත ගබඩා ක්රියාත්මක කිරීමට උත්සාහ කළ හැකිය, නමුත් මෙය තරමක් ශ්‍රම-දැඩි කාර්යයකි. මෙයට හේතුව දත්ත ගබඩාවන් ගතික පරිසරයක් සමඟ අන්තර්ක්‍රියා කිරීමට සම්පූර්ණයෙන්ම සහාය නොදක්වන බැවිනි. බොහෝ දත්ත සමුදායන් සඳහා සැලකිය යුතු වින්‍යාසයක් අවශ්ය වේ, පොකුරේ අතින් වින්‍යාස කිරීම ඇතුළුව, ස්වයංක්‍රීය පරිමාණය සහ වෙනත් සමාන දේවල් වලට කැමති නැත.
එමනිසා, ඔබ Kubernetes හි දත්ත ගබඩාවක් පවත්වාගෙන යාමට උත්සාහ කිරීමෙන් ඔබේ ජීවිතය සංකීර්ණ කර නොගත යුතුය. හුරුපුරුදු සේවාවන් භාවිතා කරමින් සාම්ප්‍රදායික ආකාරයෙන් ඔවුන්ගේ වැඩ සංවිධානය කර ඒවා භාවිතා කිරීමේ හැකියාව Kubernetes වෙත ලබා දෙන්න.
මාතෘකාව අවසන් කිරීම සඳහා, මගේ කණ්ඩායම වැඩ කරමින් සිටින Kubernetes මත පදනම් වූ Cloud RTI වේදිකාව වෙත ඔබව හඳුන්වා දීමට මම කැමැත්තෙමි. එය මධ්‍යගත ලොග් කිරීම, යෙදුම් සහ පොකුරු අධීක්ෂණය සහ ප්රයෝජනවත් වන තවත් බොහෝ ප්රයෝජනවත් විශේෂාංග සපයයි. එය අධීක්ෂණය සංදර්ශන කිරීමට Grafana වැනි විවිධ විවෘත මූලාශ්‍ර මෙවලම් භාවිතා කරයි.
Kubernetes සමඟ ha-proxy load balancer භාවිතා කරන්නේ ඇයිද යන්න පිළිබඳව ප්‍රශ්නයක් විය. දැනට බර තුලනය කිරීමේ මට්ටම් 2ක් ඇති නිසා හොඳ ප්‍රශ්නයක්. Kubernetes සේවාවන් තවමත් අථත්‍ය IP ලිපින මත පවතී. ඔබට ඒවා බාහිර සත්කාරක යන්ත්‍රවල වරායන් සඳහා භාවිත කළ නොහැක, මන්ද Amazon එහි වලාකුළු ධාරකය අධික ලෙස පටවන්නේ නම්, ලිපිනය වෙනස් වනු ඇත. Kubernetes සමඟ බාධාවකින් තොරව සන්නිවේදනය කිරීමට ගමනාගමනය සඳහා වඩාත් ස්ථිතික ව්‍යුහයක් නිර්මාණය කිරීමට - අපි සේවාවන් ඉදිරිපිට ha-proxy තබන්නේ එබැවිනි.
තවත් හොඳ ප්‍රශ්නයක් නම්, නිල්/කොළ යෙදවීමේදී දත්ත සමුදා ක්‍රම වෙනස්වීම් ගැන ඔබට බලාගන්නේ කෙසේද? කාරණය නම්, Kubernetes භාවිතය කුමක් වුවත්, දත්ත සමුදා සැලැස්ම වෙනස් කිරීම දුෂ්කර කාර්යයකි. පැරණි සහ නව යෝජනා ක්‍රමය ගැළපෙන බව ඔබ සහතික කළ යුතුය, ඉන්පසු ඔබට දත්ත සමුදාය යාවත්කාලීන කළ හැකි අතර පසුව යෙදුම් යාවත්කාලීන කළ හැකිය. ඔබට දත්ත සමුදාය උණුසුම්ව හුවමාරු කර යෙදුම් යාවත්කාලීන කළ හැකිය. මම දන්නවා සම්පූර්ණයෙන්ම අලුත් දත්ත සමුදා පොකුරක් නව ක්‍රමයකින් ආරම්භ කළ අය ගැන, ඔබට මොංගෝ වැනි යෝජනා ක්‍රම රහිත දත්ත ගබඩාවක් තිබේ නම් මෙය විකල්පයකි, නමුත් එය කෙසේ හෝ පහසු කාර්යයක් නොවේ. ඔබට තවත් ප්‍රශ්න නොමැති නම්, ඔබේ අවධානයට ස්තූතියි!
සමහර දැන්වීම් 🙂
අප සමඟ රැඳී සිටීම ගැන ඔබට ස්තුතියි. ඔබ අපේ ලිපි වලට කැමතිද? වඩාත් රසවත් අන්තර්ගතය බැලීමට අවශ්‍යද? ඇණවුමක් කිරීමෙන් හෝ මිතුරන්ට නිර්දේශ කිරීමෙන් අපට සහාය වන්න, , ඔබ වෙනුවෙන් අප විසින් නිර්මාණය කරන ලද ප්‍රවේශ මට්ටමේ සේවාදායකයන්ගේ අද්විතීය ප්‍රතිසමයක්: (RAID1 සහ RAID10, cores 24 දක්වා සහ 40GB DDR4 දක්වා ඇත).
Dell R730xd ඇම්ස්ටර්ඩෑම් හි Equinix Tier IV දත්ත මධ්‍යස්ථානයේ 2 ගුණයක් ලාභදායීද? මෙතන විතරයි නෙදර්ලන්තයේ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 සිට! ගැන කියවන්න
මූලාශ්රය: www.habr.com