کانټینر ته لیږدونکی: CRI-O اوس په OpenShift کانټینر پلیټ فارم 4 کې ډیفالټ دی

فورمې د ریډ هټ اوپن شاټ کانټینر پلیټ فارم 4 تاسو ته اجازه درکوي چې جوړونه منظم کړئ د کانتینرونو ځای پرځای کولو لپاره کوربهپه شمول د بادل خدماتو چمتو کونکو زیربنا کې ، په مجازی پلیټ فارمونو کې یا د فلزي سیسټمونو کې. د ریښتیني کلاوډ میشته پلیټ فارم رامینځته کولو لپاره ، موږ باید د ټولو کارول شوي عناصرو سخت کنټرول واخلو او پدې توګه د پیچلي اتومات پروسې اعتبار ډیر کړو.

ښکاره حل د Red Hat Enterprise Linux CoreOS (د Red Hat Enterprise Linux یو ډول) او CRI-O د معیاري په توګه کارول و، او دلته ولې ...

څرنګه چې د کښتۍ موضوع د کوبرنیټس او کانټینرونو کار تشریح کولو په وخت کې د مشابهت موندلو لپاره خورا ښه دی ، نو راځئ چې د سوداګرۍ ستونزو په اړه وغږیږو چې CoreOS او CRI-O یې حل کوي ، د مثال په کارولو سره. د ریګینګ بلاکونو تولید لپاره د برونیل اختراعات. په 1803 کې، مارک برونیل ته دنده وسپارل شوه چې د 100 درغلۍ بلاکونه تولید کړي چې د برتانیا د مخ پر ودې بحریانو اړتیاو ته اړتیا لري. د درغلۍ بلاک د درغلۍ یو ډول دی چې د رسیو د نښلولو لپاره کارول کیږي. د 19 پیړۍ تر پیل پورې، دا بلاکونه د لاس په واسطه جوړ شوي، مګر برونیل د تولید اتومات کولو توان درلود او د ماشین آلاتو په کارولو سره یې د معیاري بلاکونو تولید پیل کړ. د دې پروسې اتومات کول پدې معنی دي چې پایله شوي بلاکونه په اصل کې یو شان وو، په اسانۍ سره د ماتیدو په صورت کې بدلیدلی شي، او په لوی مقدار کې تولید کیدی شي.

اوس تصور وکړئ که برونیل دا کار د 20 مختلف کښتۍ ماډلونو (کوبرنیټس نسخو) لپاره او د پنځه مختلف سیارونو لپاره په بشپړ ډول مختلف سمندري جریانونو او بادونو (د ورېځې چمتو کونکي) لپاره ترسره کړي. سربیره پردې ، دا اړینه وه چې ټولې کښتۍ (د اوپن شیف کلسترونه) ، پرته له دې چې سیارې په کوم کې چې نیویګیشن ترسره کیږي ، د کپتان له نظره (آپریټران چې د کلسترونو عملیات اداره کوي) ورته چلند وکړي. د سمندري مشابهت ته دوام ورکولو لپاره ، د کښتۍ کپتانان هیڅ پروا نه کوي چې کوم ډول درغلۍ بلاکونه (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 کاروونکو وړاندیز کوي اقتصادي، باثباته، ساده او ستړي - هو، تاسو سم اوریدلي - د بورینګ کانټینر انجن په ځانګړي ډول د کوبرنیټس سره کار کولو لپاره رامینځته شوی.

د خلاص کانټینرونو نړۍ

نړۍ د اوږدې مودې لپاره د خلاص کانټینرونو په لور روانه ده. که په کوبرنیټس کې وي، یا په ټیټه کچه، د کانټینر معیارونو پراختیا په هره کچه د نوښت د ایکوسیستم پایله.

دا ټول د خلاص کانټینر نوښت رامینځته کولو سره پیل شوي په جون 2015 کې. د کار په دې لومړی پړاو کې، د کانټینر مشخصات جوړ شول انځور и د چلولو چاپیریال. دا ډاډ ترلاسه کړ چې وسایل کولی شي یو واحد معیار وکاروي د کانټینر انځورونه او د دوی سره د کار کولو لپاره یو متحد شکل. مشخصات وروسته اضافه شول ویش، کاروونکو ته اجازه ورکوي چې په اسانۍ سره شریک کړي د کانټینر انځورونه.

د کوبرنیټس ټولنې بیا د پلګ ایبل انٹرفیس لپاره یو واحد معیار رامینځته کړ ، چې نومیږي د کانټینر چلولو وخت انٹرفیس (CRI). د دې څخه مننه ، د کوبرنیټس کارونکي وکولی شول د ډاکر سربیره د کانټینرونو سره کار کولو لپاره مختلف انجنونه وصل کړي.

په ریډ هټ او ګوګل کې انجینرانو د کانټینر انجن لپاره بازار ته اړتیا لیدلې چې کولی شي د CRI پروتوکول په اړه د کوبیلټ غوښتنې ومني او هغه کانټینرونه معرفي کړي چې د پورته ذکر شوي OCI مشخصاتو سره مطابقت لري. نو OCID ښکاره شو. مګر بخښنه غواړم، ایا موږ نه وایو چې دا مواد به CRI-O ته وقف شي؟ په حقیقت کې دا یوازې د خوشې کیدو سره نسخه. 1.0 پروژه د CRI-O په نوم بدله شوه.

اينځر. 1.

د CRI-O او CoreOS سره نوښت

د OpenShift 4 پلیټ فارم په لاره اچولو سره، دا بدل شو کانتینر انجن، په پلیټ فارم کې د ډیفالټ لخوا کارول کیږي ، او ډاکر د CRI-O لخوا ځای په ځای شوی ، د کانټینر چلولو لپاره ارزانه ، باثباته ، ساده او ستړي کونکي چاپیریال وړاندیز کوي چې د کوبرنیټس سره موازي وده کوي. دا د کلستر ملاتړ او ترتیب خورا ساده کوي. د کانټینر انجن او کوربه تنظیم کول، او همدارنګه د دوی مدیریت، په OpenShift 4 کې اتومات کیږي.

انتظار وکړئ، دا څنګه دی؟

دا سمه ده، د OpenShift 4 په راتګ سره، نور اړتیا نشته چې د انفرادي کوربه سره وصل شئ او د کانټینر انجن نصب کړئ، ذخیره تنظیم کړئ، د لټون سرورونه تنظیم کړئ یا شبکه تنظیم کړئ. د OpenShift 4 پلیټ فارم د کارولو لپاره په بشپړه توګه له سره ډیزاین شوی د چلونکي چوکاټ نه یوازې د پای کارونکي غوښتنلیکونو شرایطو کې ، بلکه د لومړني پلیټ فارم کچې عملیاتو شرایطو کې هم لکه د عکسونو ځای په ځای کول ، د سیسټم تنظیم کول ، یا د تازه معلوماتو نصب کول.

Kubernetes تل کاروونکو ته اجازه ورکړې چې د مطلوب حالت په ټاکلو او کارولو سره غوښتنلیکونه اداره کړي کنټرولراند دې لپاره چې ډاډ ترلاسه شي چې اصلي حالت د هدف حالت سره د امکان تر حده نږدې دی. دا هدف دولت او د دولت حقیقي چلند د پراختیا او عملیاتي لید دواړو څخه عالي فرصتونه خلاصوي. پرمخ وړونکي کولی شي د اړتیا وړ حالت په واسطه تعریف کړي وړاندې تېرول آپریټر ته د YAML یا JSON فایل په شکل کې، او بیا آپریټر کولی شي د تولید چاپیریال کې د غوښتنلیک اړین مثال رامینځته کړي، او د دې مثال عملیاتي حالت به په بشپړ ډول د ټاکل شوي سره مطابقت ولري.

په پلیټ فارم کې د آپریټرانو په کارولو سره ، OpenShift 4 دا نوی تمثیل راوړي (د سیټ او ریښتیني حالت مفهوم په کارولو سره) د RHEL CoreOS او CRI-O مدیریت ته. د عملیاتي سیسټم او کانټینر انجن نسخو ترتیب او اداره کولو دندې د تش په نوم په کارولو سره اتومات دي د ماشین ترتیب کوونکی (MCO). MCO د کلستر مدیر کار خورا ساده کوي ، په لازمي ډول د نصب کولو وروستي مرحلې اتومات کوي ، او همدارنګه د نصب کولو وروسته وروسته عملیات (دوهمه ورځ عملیات). دا ټول OpenShift 4 د ریښتیني کلاوډ پلیټ فارم جوړوي. موږ به لږ وروسته دې ته ورسیږو.

د کانتینرونو چلول

کاروونکو فرصت درلود چې د CRI-O انجن د OpenShift پلیټ فارم کې د 3.7 نسخه څخه د تخنیکي مخکتنې حالت کې او د 3.9 نسخه څخه په عمومي ډول موجود حالت کې (اوس مهال ملاتړ شوی) وکاروي. سربیره پردې، Red Hat په پراخه کچه کاروي CRI-O د تولید کاري بار چلولو لپاره په OpenShift آنلاین کې د 3.10 نسخه راهیسې. دې ټولو هغه ټیم ته اجازه ورکړه چې په CRI-O کې کار کوي ترڅو په لویو کبرنیټس کلسترونو کې د ډله ایز لانچ کانټینرونو کې پراخه تجربه ترلاسه کړي. د دې لپاره چې Kubernetes څنګه CRI-O کاروي اساسي پوهه ترلاسه کړئ، راځئ چې لاندې انځور ته وګورو، کوم چې ښیي چې جوړښت څنګه کار کوي.

وريجې. 2. څنګه کانټینرونه د Kubernetes په کلستر کې کار کوي

CRI-O د نوي نوډونو پیل کولو پرمهال ، او کله چې د OpenShift پلیټ فارم نوې نسخې خپروي د ټولې لوړې کچې ترکیب کولو سره د نوي کانټینر کوربه رامینځته کول ساده کوي. د ټول پلیټ فارم بیاکتنه د لیږد تازه معلوماتو/رول بیکس ته اجازه ورکوي، او همدارنګه د کانټینر ټیل کور، کانټینر انجن، نوډونو (کوبیلیټس) او د کوبرنیټس ماسټر نوډ ترمنځ انحصار کې د ځنډ مخه نیسي. په مرکزي توګه د ټولو پلیټ فارم اجزاوو اداره کولو سره، د کنټرول او نسخه کولو سره، تل د A حالت څخه ریاست B ته روښانه لاره شتون لري. دا د تازه کولو پروسه ساده کوي، امنیت ښه کوي، د فعالیت راپور ورکول ښه کوي، او د نوي نسخو تازه کولو او نصبولو لګښت کمولو کې مرسته کوي. .

د بدیل عناصرو ځواک ښودل

لکه څنګه چې مخکې یادونه وشوه، په OpenShift 4 کې د کانټینر کوربه او کانټینر انجن اداره کولو لپاره د ماشین کنفیګ آپریټر کارول د اتوماتیک نوې کچې چمتو کوي چې مخکې د کبرنیټس پلیټ فارم کې ممکن نه و. د نویو ځانګړتیاوو د ښودلو لپاره، موږ به وښیو چې تاسو څنګه کولی شئ د crio.conf فایل کې بدلونونه راولي. د اصطلاحاتو په واسطه د ګډوډۍ څخه مخنیوي لپاره، هڅه وکړئ په پایلو تمرکز وکړئ.

لومړی، راځئ هغه څه رامینځته کړو چې د کانټینر رنټایم ترتیب په نوم یادیږي - د کانټینر چلولو ترتیب. د Kubernetes سرچینې په توګه فکر وکړئ چې د CRI-O لپاره ترتیب استازیتوب کوي. په واقعیت کې، دا د ماشین کانفیګ په نوم د یو څه ځانګړی نسخه ده، کوم چې هر هغه ترتیب دی چې د RHEL CoreOS ماشین ته د OpenShift کلستر برخې په توګه ګمارل کیږي.

دا دودیز سرچینه چې د 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

یوځل چې موږ د کانټینرRuntimeConfig رامینځته کړو ، موږ اړتیا لرو چې یو د MachineConfigPools تعدیل کړو ترڅو Kubernetes ته سیګنال ورکړو چې موږ غواړو دا ترتیب په کلستر کې د ماشینونو ځانګړي ګروپ ته پلي کړو. پدې حالت کې به موږ د ماسټر نوډونو لپاره 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

مهرباني وکړئ په یاد ولرئ چې د ماسټر نوډونو لپاره د ترتیب کولو پایله د اصلي تشکیلاتو په پرتله نوې نسخه وه. د لیدلو لپاره، لاندې کمانډ چل کړئ. په تیریدو سره ، موږ یادونه کوو چې دا شاید د کوبرنیټس په تاریخ کې یو له غوره یو لینرونو څخه وي:

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 سرچینې کې مشخص کړی. پخپله ښکلا:

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 ماسټر نوډ ته د لاسرسي له لارې ترسره شو. دا ، دا نوي پیرامیټونه یوازې په ماسټر نوډونو کې تنظیم شوي. د کارګر نوډونه نه دي بدل شوي، کوم چې د تبادلې وړ عناصرو سره د کانټینر کوربه او کانټینر انجنونو په اړه د مشخصو او حقیقي حالتونو کارولو لپاره د Kubernetes میتودولوژي ګټې څرګندوي.

پورته مثال د دریو تولید نوډونو یا د 4 نوډونو سره لوی تولید کلستر سره د کوچني OpenShift کانټینر پلیټ فارم 3000 کلستر کې د بدلون کولو وړتیا ښیې. په هر حالت کې، د کار اندازه به ورته وي - او خورا کوچنی - یوازې د ContainerRuntimeConfig فایل تنظیم کړئ، او په MachineConfigPool کې یو لیبل بدل کړئ. او تاسو کولی شئ دا د OpenShift کانټینر پلیټ فارم 4.X هرې نسخې سره ترسره کړئ چې د خپل ژوند په اوږدو کې Kubernetes چلوي.

ډیری وختونه د ټیکنالوژۍ شرکتونه دومره چټک پرمختګ کوي چې موږ نشو کولی تشریح کړو چې ولې موږ د اصلي برخو لپاره ځینې ټیکنالوژي غوره کوو. کانټینر انجنونه په تاریخي توګه هغه برخه وه چې کاروونکي یې په مستقیم ډول سره اړیکه لري. له هغه وخته چې د کانټینرونو شهرت په طبیعي ډول د کانټینر انجنونو په راتګ سره پیل شو، کاروونکي اکثرا په دوی کې دلچسپي څرګندوي. دا یو بل دلیل دی چې ولې Red Hat CRI-O غوره کړ. کانټینرونه اوس په آرکیسټریشن باندې د تمرکز سره وده کوي، او موږ وموندله چې CRI-O غوره تجربه وړاندې کوي کله چې د OpenShift 4 سره کار کوي.

سرچینه: www.habr.com