වේදිකාව නිර්මාණය විධිමත් කිරීමට ඔබට ඉඩ සලසයි , ක්ලවුඩ් සේවා සපයන්නන්ගේ යටිතල පහසුකම්, අථත්‍යකරණ වේදිකාවල හෝ හිස්-ලෝහ පද්ධති ඇතුළුව. සැබවින්ම වලාකුළු මත පදනම් වූ වේදිකාවක් නිර්මාණය කිරීම සඳහා, අපට භාවිතා කරන සියලුම මූලද්‍රව්‍ය දැඩි ලෙස පාලනය කිරීමට සිදු වූ අතර එමඟින් සංකීර්ණ ස්වයංක්‍රීයකරණ ක්‍රියාවලියක විශ්වසනීයත්වය වැඩි කිරීමට සිදු විය.
පැහැදිලි විසඳුම වූයේ Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux හි ප්‍රභේදයකි) සහ CRI-O ප්‍රමිතිය ලෙස භාවිතා කිරීමයි, සහ මෙන්න ඇයි...
Kubernetes සහ බහාලුම්වල වැඩ පැහැදිලි කිරීමේදී යාත්‍රා කිරීම යන මාතෘකාව ඉතා හොඳ එකක් බැවින්, උදාහරණයක් භාවිතා කරමින් CoreOS සහ CRI-O විසඳන ව්‍යාපාරික ගැටළු ගැන කතා කිරීමට උත්සාහ කරමු . 1803 දී, වර්ධනය වන බ්‍රිතාන්‍ය නාවික හමුදාවේ අවශ්‍යතා සඳහා රිගින් බ්ලොක් 100 ක් නිෂ්පාදනය කිරීමේ වගකීම මාක් බෘනෙල්ට පැවරී ඇත. රිගින් බ්ලොක් එකක් යනු රුවල් වලට ලණු ඇමිණීමට භාවිතා කරන රිගින් වර්ගයකි. 19 වන ශතවර්ෂයේ ආරම්භය වන තුරුම මෙම කුට්ටි අතින් සාදන ලද නමුත් නිෂ්පාදනය ස්වයංක්‍රීය කිරීමට බෘනෙල් සමත් වූ අතර යන්ත්‍ර මෙවලම් භාවිතයෙන් ප්‍රමිතිගත කුට්ටි නිෂ්පාදනය කිරීමට පටන් ගත්තේය. මෙම ක්‍රියාවලියේ ස්වයංක්‍රීයකරණය යනු ප්‍රතිඵලයක් ලෙස ලැබෙන කුට්ටි අත්‍යවශ්‍යයෙන්ම සමාන වන අතර කැඩී ගියහොත් පහසුවෙන් ප්‍රතිස්ථාපනය කළ හැකි අතර විශාල ප්‍රමාණවලින් නිපදවිය හැකිය.
දැන් සිතන්න, විවිධ නැව් ආකෘති 20 ක් (කුබර්නෙටේස් අනුවාදයන්) සහ සම්පූර්ණයෙන්ම වෙනස් මුහුදු ධාරා සහ සුළං සහිත විවිධ ග්‍රහලෝක පහක් සඳහා (වලාකුළු සපයන්නන්) බෘනෙල්ට මෙම කාර්යය කිරීමට සිදු විය. ඊට අමතරව, කපිතාන්වරුන්ගේ (පොකුරුවල ක්‍රියාකාරිත්වය කළමනාකරණය කරන ක්‍රියාකරුවන්) දෘෂ්ටි කෝණයෙන් බලන කල, සංචාලනය සිදු කරන ග්‍රහලෝක නොසලකා සියලුම නැව් (OpenShift පොකුරු) එකම ලෙස හැසිරීම අවශ්‍ය විය. සමුද්‍රීය ප්‍රතිසමය දිගටම කරගෙන යාම සඳහා, නැව් කපිතාන්වරු ඔවුන්ගේ නැව්වල කුමන ආකාරයේ රිගින් බ්ලොක් (CRI-O) භාවිතා කරන්නේද යන්න කිසිසේත් තැකීමක් නොකරයි - ඔවුන්ට ප්රධාන දෙය නම් මෙම කුට්ටි ශක්තිමත් සහ විශ්වාසදායක වීමයි.
වලාකුළු වේදිකාවක් ලෙස OpenShift 4, ඉතා සමාන ව්‍යාපාරික අභියෝගයකට මුහුණ දෙයි. පොකුරු සෑදීමේදී, එක් නෝඩයක අසාර්ථක වූ විට හෝ පොකුර පරිමාණය කිරීමේදී නව නෝඩ් සෑදිය යුතුය. නව නෝඩයක් නිර්මාණය කර ආරම්භ කරන විට, CRI-O ඇතුළුව තීරණාත්මක ධාරක සංරචක, ඒ අනුව වින්‍යාස කළ යුතුය. වෙනත් ඕනෑම නිෂ්පාදනයකදී මෙන්, "අමුද්රව්ය" ආරම්භයේදීම සැපයිය යුතුය. නැව් සම්බන්ධයෙන් ගත් කල, අමුද්රව්ය ලෝහ සහ දැව වේ. කෙසේ වෙතත්, OpenShift 4 පොකුරක් තුළ බහාලුම් යෙදවීම සඳහා ධාරකයක් සෑදීමේදී, ඔබට ආදානය ලෙස වින්‍යාස ගොනු සහ API-සපයා ඇති සේවාදායකයන් තිබිය යුතුය. OpenShift විසින් සම්පූර්ණ ජීවන චක්‍රය පුරාවටම අවශ්‍ය මට්ටමේ ස්වයංක්‍රීයකරණය සපයනු ඇත, අවසාන පරිශීලකයින්ට අවශ්‍ය නිෂ්පාදන සහාය ලබා දෙන අතර එමඟින් වේදිකාවේ ආයෝජනය ආපසු ලබා දෙනු ඇත.
OpenShift 4 නිර්මාණය කර ඇත්තේ සියලුම ප්රධාන වලාකුළු පරිගණක සපයන්නන්, අථත්‍යකරණ වේදිකා සහ හිස් ලෝහ පද්ධති සඳහා වේදිකාවේ සම්පූර්ණ ජීවන චක්‍රය පුරාම (4.X අනුවාද සඳහා) පද්ධතිය පහසුවෙන් යාවත්කාලීන කිරීමේ හැකියාව ලබා දීම සඳහා ය. මෙය සිදු කිරීම සඳහා, එකිනෙකට හුවමාරු කළ හැකි මූලද්රව්යවල පදනම මත නෝඩ් සෑදිය යුතුය. පොකුරකට Kubernetes හි නව අනුවාදයක් අවශ්‍ය වූ විට, එය CoreOS හි CRI-O හි අනුරූප අනුවාදය ද ලබා ගනී. CRI-O අනුවාදය කෙලින්ම Kubernetes වෙත බැඳී ඇති බැවින්, මෙය පරීක්ෂා කිරීම, දෝශ නිරාකරණය කිරීම හෝ සහාය අරමුණු සඳහා ඕනෑම ප්‍රගමනයක් බෙහෙවින් සරල කරයි. මීට අමතරව, මෙම ප්රවේශය අවසන් පරිශීලකයන් සහ Red Hat සඳහා පිරිවැය අඩු කරයි.
මෙය Kubernetes පොකුරු ගැන සිතීමේ මූලික වශයෙන් නව ක්‍රමයක් වන අතර ඉතා ප්‍රයෝජනවත් සහ බලගතු නව විශේෂාංග කිහිපයක් සැලසුම් කිරීමට පදනම දමයි. CRI-O (කන්ටේනර් ධාවන කාල අතුරුමුහුණත - විවෘත බහාලුම් මුලපිරීම, කෙටියෙන් CRI-OCI) OpenShift සමඟ වැඩ කිරීමට අවශ්‍ය නෝඩ් විශාල වශයෙන් නිර්මාණය කිරීම සඳහා වඩාත්ම සාර්ථක තේරීම බවට පත් විය. CRI-O විසින් OpenShift භාවිතා කරන්නන් සඳහා කලින් භාවිතා කරන ලද Docker එන්ජිම ප්‍රතිස්ථාපනය කරනු ඇත - ඔව්, ඔබ ඇසූ හරිය - කුබර්නෙට්ස් සමඟ වැඩ කිරීම සඳහා විශේෂයෙන් නිර්මාණය කරන ලද නීරස බහාලුම් එන්ජිමක්.
විවෘත බහාලුම් ලෝකය
ලෝකය දිගු කලක් විවෘත බහාලුම් කරා ගමන් කරයි. Kubernetes හි වේවා, හෝ පහත මට්ටම්වල වේවා, සෑම මට්ටමකින්ම නවෝත්පාදන පරිසර පද්ධතියක් ඇති කරයි.
ඒ සියල්ල ආරම්භ වූයේ විවෘත බහාලුම් මුලපිරීම නිර්මාණය කිරීමෙනි . කාර්යයේ මෙම මුල් අවධියේදී, බහාලුම් පිරිවිතරයන් පිහිටුවන ලදී и . මෙවලම්වලට තනි ප්‍රමිතියක් භාවිතා කළ හැකි බව මෙයින් සහතික විය සහ ඔවුන් සමඟ වැඩ කිරීම සඳහා ඒකාබද්ධ ආකෘතියක්. පසුව පිරිවිතර එකතු කරන ලදී , පරිශීලකයින්ට පහසුවෙන් බෙදා ගැනීමට ඉඩ සලසයි .
පසුව Kubernetes ප්‍රජාව විසින් ප්ලග් කළ හැකි අතුරු මුහුණතක් සඳහා තනි ප්‍රමිතියක් සංවර්ධනය කරන ලදී . මෙයට ස්තූතියි, Kubernetes පරිශීලකයින්ට Docker වලට අමතරව බහාලුම් සමඟ වැඩ කිරීමට විවිධ එන්ජින් සම්බන්ධ කිරීමට හැකි විය.
Red Hat සහ Google හි ඉංජිනේරුවන් CRI ප්‍රොටෝකෝලය හරහා Kubelet ඉල්ලීම් පිළිගත හැකි බහාලුම් එන්ජිමක වෙළඳපල අවශ්‍යතාවයක් දුටු අතර ඉහත සඳහන් OCI පිරිවිතරයන්ට අනුකූල වන බහාලුම් හඳුන්වා දෙන ලදී. ඒ නිසා . නමුත් මට සමාවෙන්න, මෙම ද්රව්යය CRI-O වෙත කැප කරන බව අපි කීවේ නැද්ද? ඇත්ත වශයෙන්ම එය නිකුතුව සමඟ පමණි ව්‍යාපෘතිය CRI-O ලෙස නම් කරන ලදී.
රූපය. 1.
CRI-O සහ CoreOS සමඟ නවෝත්පාදනය
OpenShift 4 වේදිකාව දියත් කිරීමත් සමඟ එය වෙනස් විය , වේදිකාවේ පෙරනිමියෙන් භාවිතා වන අතර, ඩොකර් වෙනුවට CRI-O මගින් ප්‍රතිස්ථාපනය කරන ලද අතර, Kubernetes සමග සමාන්තරව වර්ධනය වන බහාලුමක් ධාවනය කිරීම සඳහා පිරිවැය-ඵලදායී, ස්ථාවර, සරල සහ නීරස පරිසරයක් ලබා දෙයි. මෙය පොකුරු ආධාරක සහ වින්‍යාසය බෙහෙවින් සරල කරයි. බහාලුම් එන්ජිමේ සහ ධාරකයේ වින්‍යාසය මෙන්ම ඒවායේ කළමනාකරණය OpenShift 4 තුළ ස්වයංක්‍රීය වේ.
ඉන්න, මේක කොහොමද?
ඒක හරි, OpenShift 4 පැමිණීමත් සමඟ, තවදුරටත් තනි සත්කාරක වෙත සම්බන්ධ වීමට සහ බහාලුම් එන්ජිමක් ස්ථාපනය කිරීමට, ගබඩාව වින්‍යාස කිරීමට, සෙවුම් සේවාදායකයන් වින්‍යාස කිරීමට හෝ ජාලයක් වින්‍යාස කිරීමට අවශ්‍ය නොවේ. OpenShift 4 වේදිකාව භාවිතා කිරීම සඳහා සම්පූර්ණයෙන්ම ප්‍රතිනිර්මාණය කර ඇත අවසාන පරිශීලක යෙදුම් සම්බන්ධයෙන් පමණක් නොව, රූප යෙදවීම, පද්ධතිය වින්‍යාස කිරීම හෝ යාවත්කාලීන ස්ථාපනය කිරීම වැනි මූලික වේදිකා මට්ටමේ මෙහෙයුම් අනුවද වේ.
Kubernetes සෑම විටම පරිශීලකයින්ට අවශ්‍ය තත්වය නිර්වචනය කිරීමෙන් සහ භාවිතා කිරීමෙන් යෙදුම් කළමනාකරණය කිරීමට ඉඩ දී ඇත , සැබෑ තත්ත්වය ඉලක්ක තත්ත්වයට හැකිතාක් සමීපව ගැළපෙන බව සහතික කිරීමට. මෙය සංවර්ධන සහ මෙහෙයුම් යන දෙඅංශයෙන්ම විශාල අවස්ථා විවෘත කරයි. සංවර්ධකයින්ට අවශ්‍ය තත්වය නිර්වචනය කළ හැකිය YAML හෝ JSON ගොනුවක් ආකාරයෙන් ක්රියාකරු වෙත, පසුව ක්‍රියාකරුට නිෂ්පාදන පරිසරය තුළ අවශ්‍ය යෙදුම් අවස්ථාව නිර්මාණය කළ හැකි අතර, මෙම අවස්ථාවෙහි මෙහෙයුම් තත්ත්වය නිශ්චිතව දක්වා ඇති එකට සම්පූර්ණයෙන්ම අනුරූප වේ.
වේදිකාවේ ක්‍රියාකරුවන් භාවිතා කිරීමෙන්, OpenShift 4 RHEL CoreOS සහ CRI-O හි කළමනාකාරිත්වයට මෙම නව සුසමාදර්ශය (කට්ටල සහ සත්‍ය තත්ත්වය යන සංකල්පය භාවිතා කරමින්) ගෙන එයි. මෙහෙයුම් පද්ධතියේ සහ බහාලුම් එන්ජිමේ අනුවාද වින්‍යාස කිරීම සහ කළමනාකරණය කිරීමේ කාර්යයන් ඊනියා භාවිතයෙන් ස්වයංක්‍රීය වේ. . MCO විසින් පොකුරු පරිපාලකගේ කාර්යය බෙහෙවින් සරල කරයි, ස්ථාපනයේ අවසාන අදියරයන් මෙන්ම පසුකාලීන පසු ස්ථාපන මෙහෙයුම් (දින දෙකේ මෙහෙයුම්) ස්වයංක්‍රීය කරයි. මේ සියල්ල OpenShift 4 සැබෑ වලාකුළු වේදිකාවක් බවට පත් කරයි. අපි ටිකක් පස්සේ මේකට බහිමු.
ධාවන බහාලුම්
Tech Preview තත්ත්‍වයේ 3.7 අනුවාදයේ සිට OpenShift වේදිකාවේ CRI-O එන්ජිම භාවිතා කිරීමට පරිශීලකයින්ට අවස්ථාව ලැබී ඇත. මීට අමතරව, Red Hat විශාල වශයෙන් භාවිතා කරයි 3.10 අනුවාදයේ සිට OpenShift ඔන්ලයින් හි. මේ සියල්ලෙන් CRI-O හි වැඩ කරන කණ්ඩායමට විශාල Kubernetes පොකුරු මත විශාල බහාලුම් දියත් කිරීමේ පුළුල් අත්දැකීමක් ලබා ගැනීමට හැකි විය. Kubernetes CRI-O භාවිතා කරන ආකාරය පිළිබඳ මූලික අවබෝධයක් ලබා ගැනීම සඳහා, ගෘහ නිර්මාණ ශිල්පය ක්රියා කරන ආකාරය පෙන්වන පහත දැක්වෙන නිදර්ශනය දෙස බලමු.
සහල්. 2. Kubernetes පොකුරක් තුළ බහාලුම් ක්රියා කරන ආකාරය
CRI-O නව නෝඩ් ආරම්භ කිරීමේදී සහ OpenShift වේදිකාවේ නව අනුවාද නිකුත් කිරීමේදී සම්පූර්ණ ඉහළ මට්ටම සමමුහුර්ත කිරීමෙන් නව බහාලුම් ධාරක නිර්මාණය කිරීම සරල කරයි. සම්පූර්ණ වේදිකාවේ සංශෝධනය මඟින් ගණුදෙණු යාවත්කාලීන කිරීම්/ආපසු හැරීම් සඳහා ඉඩ ලබා දෙන අතර, බහාලුම් වලිගය, බහාලුම් එන්ජිම, නෝඩ් (කුබෙලෙට්ස්) සහ කුබර්නෙටස් මාස්ටර් නෝඩය අතර පරායත්තතා වල අවහිරතා වළක්වයි. සියලුම වේදිකා සංරචක මධ්‍යගතව කළමනාකරණය කිරීමෙන්, පාලනය සහ අනුවාදනය සමඟින්, සෑම විටම A සිට B ප්‍රාන්තය දක්වා පැහැදිලි මාර්ගයක් ඇත. මෙය යාවත්කාලීන ක්‍රියාවලිය සරල කරයි, ආරක්ෂාව වැඩි දියුණු කරයි, කාර්ය සාධන වාර්තාකරණය වැඩි දියුණු කරයි, සහ නව අනුවාදවල යාවත්කාලීන කිරීම් සහ ස්ථාපන පිරිවැය අඩු කිරීමට උපකාරී වේ. .
ප්රතිස්ථාපන මූලද්රව්යවල බලය විදහා දැක්වීම
කලින් සඳහන් කළ පරිදි, OpenShift 4 හි බහාලුම් ධාරකය සහ බහාලුම් එන්ජිම කළමනාකරණය කිරීම සඳහා Machine Config Operator භාවිතා කිරීම, Kubernetes වේදිකාවේ කලින් කළ නොහැකි වූ නව මට්ටමේ ස්වයංක්‍රීයකරණයක් සපයයි. නව විශේෂාංග විදහා දැක්වීමට, අපි ඔබට crio.conf ගොනුවට වෙනස්කම් කළ හැකි ආකාරය පෙන්වන්නෙමු. පාරිභාෂිතය මගින් ව්යාකූල නොවීම සඳහා, ප්රතිඵල කෙරෙහි අවධානය යොමු කිරීමට උත්සාහ කරන්න.
පළමුව, බහාලුම් ධාවන කාල වින්‍යාසය ලෙස හඳුන්වන දේ නිර්මාණය කරමු - Container Runtime Config. එය CRI-O සඳහා වින්‍යාසය නියෝජනය කරන Kubernetes සම්පතක් ලෙස සිතන්න. යථාර්ථය නම්, එය MachineConfig ලෙස හඳුන්වන දෙයක විශේෂිත අනුවාදයකි, එය OpenShift පොකුරක කොටසක් ලෙස RHEL CoreOS යන්ත්‍රයකට යොදවා ඇති ඕනෑම වින්‍යාසයකි.
ContainerRuntimeConfig ලෙස හඳුන්වන මෙම අභිරුචි සම්පත, CRI-O වින්‍යාස කිරීම පොකුරු පරිපාලකයින්ට පහසු කිරීම සඳහා නිර්මාණය කරන ලදී. මෙම මෙවලම MachineConfigPool සැකසුම් මත පදනම්ව ඇතැම් නෝඩ් වලට පමණක් යෙදිය හැකි තරම් බලවත් වේ. එය එකම අරමුණක් ඉටු කරන යන්ත්‍ර සමූහයක් ලෙස සිතන්න.
අපි /etc/crio/crio.conf ගොනුවේ වෙනස් කිරීමට යන අවසාන පේළි දෙක සැලකිල්ලට ගන්න. මෙම රේඛා දෙක crio.conf ගොනුවේ ඇති රේඛා වලට බෙහෙවින් සමාන ය, ඒවා නම්:
vi ContainerRuntimeConfig.yaml
නිගමනය:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
දැන් අපි මෙම ගොනුව Kubernetes පොකුරට තල්ලු කර එය සැබවින්ම නිර්මාණය කර ඇත්දැයි පරීක්ෂා කරමු. මෙහෙයුම වෙනත් ඕනෑම Kubernetes සම්පතක් හා සමාන බව කරුණාවෙන් සලකන්න:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
නිගමනය:
NAME AGE
set-log-and-pid 22h
අපි ContainerRuntimeConfig නිර්මාණය කළ පසු, අපට මෙම වින්‍යාසය පොකුරේ ඇති විශේෂිත යන්ත්‍ර සමූහයකට යෙදීමට අවශ්‍ය බව Kubernetes වෙත සංඥා කිරීමට MachineConfigPools වලින් එකක් වෙනස් කිරීමට අවශ්‍ය වේ. මෙම අවස්ථාවේදී අපි ප්රධාන නෝඩ් සඳහා MachineConfigPool වෙනස් කරන්නෙමු:
oc edit MachineConfigPool/master
නිගමනය (පැහැදිලි භාවය සඳහා, ප්රධාන සාරය ඉතිරි වේ):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
මෙම අවස්ථාවේදී, MCO පොකුර සඳහා නව crio.conf ගොනුවක් සෑදීමට පටන් ගනී. මෙම අවස්ථාවෙහිදී, සම්පූර්ණයෙන් නිමවූ වින්‍යාස ගොනුව Kubernetes API භාවිතයෙන් නැරඹිය හැක. මතක තබා ගන්න, ContainerRuntimeConfig යනු MachineConfig හි විශේෂිත අනුවාදයක් පමණි, එබැවින් අපට MachineConfigs හි අදාළ රේඛා බැලීමෙන් ප්‍රතිඵලය දැකිය හැකිය:
oc get MachineConfigs | grep rendered
නිගමනය:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
ප්රධාන නෝඩ් සඳහා ලැබෙන වින්‍යාස ගොනුව මුල් වින්‍යාසයන්ට වඩා නව අනුවාදයක් බව කරුණාවෙන් සලකන්න. එය බැලීම සඳහා පහත විධානය ක්‍රියාත්මක කරන්න. පසුකරමින්, මෙය සමහර විට Kubernetes ඉතිහාසයේ හොඳම එක පෙලට එකක් බව අපි සටහන් කරමු:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
නිගමනය:
pids_limit = 2048
දැන් අපි සියලු ප්රධාන නෝඩ් වලට වින්‍යාසය යෙදී ඇති බවට වග බලා ගනිමු. මුලින්ම අපි පොකුරේ ඇති නෝඩ් ලැයිස්තුවක් ලබා ගනිමු:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
දැන් අපි බලමු ස්ථාපිත ගොනුව දෙස. ContainerRuntimeConfig සම්පතෙහි අප සඳහන් කර ඇති pid සහ debug විධාන සඳහා නව අගයන් සමඟ ගොනුව යාවත්කාලීන කර ඇති බව ඔබට පෙනෙනු ඇත. අලංකාරය ම:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
නිගමනය:
...
pids_limit = 2048
...
log_level = "debug"
...
පොකුරට මෙම සියලු වෙනස්කම් සිදු කර ඇත්තේ SSH ක්‍රියාත්මක නොවීමයි. Kuberentes master node වෙත පිවිසීමෙන් සියලු කටයුතු සිදු කරන ලදී. එනම්, මෙම නව පරාමිතීන් වින්‍යාස කර ඇත්තේ ප්රධාන නෝඩ් මත පමණි. හුවමාරු කළ හැකි මූලද්‍රව්‍ය සහිත බහාලුම් ධාරක සහ බහාලුම් එන්ජින් සම්බන්ධයෙන් නිශ්චිත සහ සත්‍ය තත්වයන් භාවිතා කිරීමේ Kubernetes ක්‍රමවේදයේ ප්‍රතිලාභ පෙන්නුම් කරන සේවක නෝඩ් වෙනස් නොවීය.
ඉහත උදාහරණයෙන් පෙන්නුම් කරන්නේ නිෂ්පාදන නෝඩ් තුනක් සහිත කුඩා OpenShift Container Platform 4 පොකුරකට හෝ නෝඩ් 3000ක් සහිත දැවැන්ත නිෂ්පාදන පොකුරකට වෙනස්කම් කිරීමේ හැකියාවයි. ඕනෑම අවස්ථාවක, වැඩ ප්‍රමාණය සමාන වනු ඇත - සහ ඉතා කුඩා - ContainerRuntimeConfig ගොනුව වින්‍යාස කරන්න, සහ MachineConfigPool හි එක් ලේබලයක් වෙනස් කරන්න. තවද ඔබට OpenShift Container Platform 4.X එහි ජීවන චක්‍රය පුරා ධාවනය වන Kubernetes හි ඕනෑම අනුවාදයකින් මෙය කළ හැක.
බොහෝ විට තාක්‍ෂණ සමාගම් ඉතා ඉක්මනින් පරිණාමය වන අතර යටින් පවතින සංරචක සඳහා අප යම් තාක්‍ෂණයන් තෝරා ගන්නේ මන්දැයි පැහැදිලි කිරීමට අපට නොහැකි වේ. බහාලුම් එන්ජින් ඓතිහාසිකව පරිශීලකයන් සමඟ සෘජුව අන්තර් ක්රියා කරන සංරචකය වේ. බහාලුම්වල ජනප්‍රියතාවය ස්වාභාවිකවම බහාලුම් එන්ජින් පැමිණීමත් සමඟ ආරම්භ වූ බැවින්, පරිශීලකයින් බොහෝ විට ඒවා කෙරෙහි උනන්දුවක් දක්වයි. Red Hat CRI-O තෝරා ගැනීමට මෙය තවත් හේතුවකි. දැන් වාද්‍ය වෘන්දය කෙරෙහි අවධානය යොමු කරමින් බහාලුම් පරිණාමය වෙමින් පවතින අතර, OpenShift 4 සමඟ වැඩ කිරීමේදී CRI-O හොඳම අත්දැකීම සපයන බව අපි සොයා ගත්තෙමු.
මූලාශ්රය: www.habr.com