Llwyfan yn eich galluogi i symleiddio'r greadigaeth , gan gynnwys yn seilwaith darparwyr gwasanaethau cwmwl, ar lwyfannau rhithwiroli neu mewn systemau metel noeth. Er mwyn creu llwyfan gwirioneddol seiliedig ar gwmwl, roedd yn rhaid i ni gymryd rheolaeth lem o'r holl elfennau a ddefnyddiwyd a thrwy hynny gynyddu dibynadwyedd proses awtomeiddio gymhleth.
Yr ateb amlwg oedd defnyddio Red Hat Enterprise Linux CoreOS (amrywiad o Red Hat Enterprise Linux) a CRI-O fel y safon, a dyma pam ...
Gan fod pwnc hwylio yn un da iawn ar gyfer dod o hyd i gyfatebiaethau wrth egluro gwaith Kubernetes a chynwysyddion, gadewch i ni geisio siarad am y problemau busnes y mae CoreOS a CRI-O yn eu datrys, gan ddefnyddio enghraifft . Ym 1803, cafodd Marc Brunel y dasg o gynhyrchu 100 o flociau rigio ar gyfer anghenion llynges gynyddol Prydain. Math o rigio yw bloc rigio a ddefnyddir i gysylltu rhaffau â hwyliau. Hyd at ddechrau'r 19eg ganrif, gwnaed y blociau hyn â llaw, ond llwyddodd Brunel i awtomeiddio cynhyrchu a dechreuodd gynhyrchu blociau safonol gan ddefnyddio offer peiriant. Roedd awtomeiddio'r broses hon yn golygu bod y blociau a ddeilliodd o hyn yn union yr un fath yn eu hanfod, y gellid eu disodli'n hawdd pe baent wedi'u torri, a gellid eu cynhyrchu mewn symiau mawr.
Nawr dychmygwch a oedd yn rhaid i Brunel wneud y gwaith hwn ar gyfer 20 o fodelau llong gwahanol (fersiynau Kubernetes) ac ar gyfer pum planed wahanol gyda cherhyntau môr a gwyntoedd hollol wahanol (darparwyr cwmwl). Yn ogystal, roedd yn ofynnol bod pob llong (clystyrau OpenShift), waeth beth fo'r planedau y mae mordwyo'n cael eu cynnal arnynt, o safbwynt y capteiniaid (gweithredwyr sy'n rheoli gweithrediad y clystyrau) yn ymddwyn yr un peth. Er mwyn parhau â'r gyfatebiaeth forwrol, nid yw capteniaid llongau yn poeni o gwbl pa fath o flociau rigio (CRI-O) sy'n cael eu defnyddio ar eu llongau - y prif beth iddyn nhw yw bod y blociau hyn yn gryf ac yn ddibynadwy.
Mae OpenShift 4, fel llwyfan cwmwl, yn wynebu her fusnes debyg iawn. Rhaid creu nodau newydd ar adeg creu clwstwr, os bydd un o'r nodau'n methu, neu wrth raddio'r clwstwr. Pan fydd nod newydd yn cael ei greu a'i gychwyn, rhaid ffurfweddu cydrannau gwesteiwr critigol, gan gynnwys CRI-O, yn unol â hynny. Fel mewn unrhyw gynhyrchiad arall, rhaid cyflenwi “deunyddiau crai” ar y dechrau. Yn achos llongau, metel a phren yw'r deunyddiau crai. Fodd bynnag, yn achos creu gwesteiwr ar gyfer defnyddio cynwysyddion mewn clwstwr OpenShift 4, mae angen i chi gael ffeiliau ffurfweddu a gweinyddwyr a ddarperir gan API fel mewnbwn. Yna bydd OpenShift yn darparu'r lefel ofynnol o awtomeiddio trwy gydol y cylch bywyd cyfan, gan gynnig y cymorth cynnyrch angenrheidiol i ddefnyddwyr terfynol a thrwy hynny adennill y buddsoddiad yn y platfform.
Crëwyd OpenShift 4 yn y fath fodd ag i ddarparu'r gallu i ddiweddaru'r system yn gyfleus trwy gydol cylch bywyd cyfan y platfform (ar gyfer fersiynau 4.X) ar gyfer yr holl brif ddarparwyr cyfrifiadura cwmwl, llwyfannau rhithwiroli a hyd yn oed systemau metel noeth. I wneud hyn, rhaid creu nodau ar sail elfennau ymgyfnewidiol. Pan fydd clwstwr yn gofyn am fersiwn newydd o Kubernetes, mae hefyd yn derbyn y fersiwn cyfatebol o CRI-O ar CoreOS. Gan fod y fersiwn CRI-O ynghlwm yn uniongyrchol â Kubernetes, mae hyn yn symleiddio'n fawr unrhyw newidiadau at ddibenion profi, datrys problemau neu gefnogi. Yn ogystal, mae'r dull hwn yn lleihau costau i ddefnyddwyr terfynol a Red Hat.
Mae hon yn ffordd sylfaenol newydd o feddwl am glystyrau Kubernetes ac mae'n gosod y sylfaen ar gyfer cynllunio rhai nodweddion newydd defnyddiol a chymhellol iawn. Trodd CRI-O (Rhyngwyneb Rhedeg Cynhwysydd - Menter Cynhwysydd Agored, wedi'i dalfyrru CRI-OCI) i fod y dewis mwyaf llwyddiannus ar gyfer creu nodau màs sy'n angenrheidiol i weithio gydag OpenShift. Bydd CRI-O yn disodli'r injan Docker a ddefnyddiwyd yn flaenorol, gan gynnig OpenShift i ddefnyddwyr - ie, clywsoch yn iawn - injan cynhwysydd diflas a grëwyd yn benodol ar gyfer gweithio gyda Kubernetes.
Byd y cynwysyddion agored
Mae'r byd wedi bod yn symud tuag at gynwysyddion agored ers amser maith. Boed yn Kubernetes, neu ar lefelau is, arwain at ecosystem o arloesi ar bob lefel.
Dechreuodd y cyfan gyda chreu'r Fenter Cynwysyddion Agored . Yn y cyfnod cynnar hwn o waith, ffurfiwyd manylebau cynhwysydd и . Sicrhaodd hyn y gallai'r offer ddefnyddio un safon a fformat unedig ar gyfer gweithio gyda nhw. Ychwanegwyd manylebau yn ddiweddarach , gan ganiatáu i ddefnyddwyr rannu'n hawdd .
Yna datblygodd cymuned Kubernetes un safon ar gyfer rhyngwyneb plygadwy, o'r enw . Diolch i hyn, roedd defnyddwyr Kubernetes yn gallu cysylltu peiriannau amrywiol i weithio gyda chynwysyddion yn ogystal â Docker.
Gwelodd peirianwyr yn Red Hat a Google angen yn y farchnad am injan cynhwysydd a allai dderbyn ceisiadau Kubelet dros y protocol CRI a chyflwynodd gynwysyddion a oedd yn gydnaws â'r manylebau OCI a grybwyllwyd uchod. Felly . Ond esgusodwch fi, oni ddywedasom y byddai'r deunydd hwn yn cael ei gysegru i CRI-O? Mewn gwirionedd y mae, dim ond gyda'r datganiad ailenwyd y prosiect yn CRI-O.
Ffigur: pymtheg.
Arloesedd gyda CRI-O a CoreOS
Gyda lansiad llwyfan OpenShift 4, fe'i newidiwyd , a ddefnyddir yn ddiofyn yn y llwyfan, a disodlwyd Docker gan CRI-O, gan gynnig amgylchedd cost-effeithiol, sefydlog, syml a diflas ar gyfer rhedeg cynhwysydd sy'n datblygu ochr yn ochr â Kubernetes. Mae hyn yn symleiddio cefnogaeth a chyfluniad clwstwr yn fawr. Mae ffurfweddiad injan y cynhwysydd a'r gwesteiwr, yn ogystal â'u rheolaeth, yn dod yn awtomataidd o fewn OpenShift 4.
Arhoswch, sut mae hyn?
Mae hynny'n iawn, gyda dyfodiad OpenShift 4, nid oes angen bellach i gysylltu â gwesteiwyr unigol a gosod injan cynhwysydd, ffurfweddu storfa, ffurfweddu gweinyddwyr chwilio neu ffurfweddu rhwydwaith. Mae platfform OpenShift 4 wedi'i ailgynllunio'n llwyr i ddefnyddio'r nid yn unig o ran cymwysiadau defnyddiwr terfynol, ond hefyd o ran gweithrediadau lefel platfform sylfaenol fel gosod delweddau, ffurfweddu'r system, neu osod diweddariadau.
Mae Kubernetes bob amser wedi caniatáu i ddefnyddwyr reoli cymwysiadau trwy ddiffinio'r cyflwr dymunol a defnyddio , er mwyn sicrhau bod y cyflwr gwirioneddol yn cyd-fynd â'r cyflwr targed mor agos â phosibl. hwn yn agor cyfleoedd gwych o safbwynt datblygu a gweithrediadau. Gall datblygwyr ddiffinio'r cyflwr gofynnol trwy i'r gweithredwr ar ffurf ffeil YAML neu JSON, ac yna gall y gweithredwr greu'r achos cais gofynnol yn yr amgylchedd cynhyrchu, a bydd cyflwr gweithredu'r achos hwn yn cyfateb yn llawn i'r un penodedig.
Trwy ddefnyddio Gweithredwyr yn y platfform, mae OpenShift 4 yn dod â'r patrwm newydd hwn (gan ddefnyddio'r cysyniad o gyflwr gosod a gwirioneddol) i reolaeth RHEL CoreOS a CRI-O. Mae'r tasgau o ffurfweddu a rheoli fersiynau o'r system weithredu a'r injan cynhwysydd yn cael eu hawtomeiddio gan ddefnyddio'r hyn a elwir . Mae MCO yn symleiddio gwaith gweinyddwr y clwstwr yn fawr, gan awtomeiddio camau olaf y gosodiad yn y bôn, yn ogystal â gweithrediadau ôl-osod dilynol (gweithrediadau diwrnod dau). Mae hyn i gyd yn gwneud OpenShift 4 yn blatfform cwmwl go iawn. Byddwn yn mynd i mewn i hyn ychydig yn ddiweddarach.
Cynwysyddion rhedeg
Mae defnyddwyr wedi cael y cyfle i ddefnyddio'r injan CRI-O yn y platfform OpenShift ers fersiwn 3.7 yn y statws Rhagolwg Tech ac o fersiwn 3.9 yn y statws Ar Gael yn Gyffredinol (a gefnogir ar hyn o bryd). Yn ogystal, mae Red Hat yn ei ddefnyddio'n aruthrol yn OpenShift Online ers fersiwn 3.10. Roedd hyn i gyd yn caniatáu i'r tîm sy'n gweithio ar CRI-O ennill profiad helaeth mewn lansio cynwysyddion torfol ar glystyrau Kubernetes mawr. I gael dealltwriaeth sylfaenol o sut mae Kubernetes yn defnyddio CRI-O, gadewch i ni edrych ar y darluniad canlynol, sy'n dangos sut mae'r bensaernïaeth yn gweithio.
Reis. 2. Sut mae cynwysyddion yn gweithio mewn clwstwr Kubernetes
Mae CRI-O yn symleiddio'r broses o greu gwesteiwyr cynwysyddion newydd trwy gydamseru'r lefel uchaf gyfan wrth gychwyn nodau newydd, ac wrth ryddhau fersiynau newydd o'r platfform OpenShift. Mae adolygu'r platfform cyfan yn caniatáu ar gyfer diweddariadau trafodion / dychwelyd yn ôl, a hefyd yn atal datgloi mewn dibyniaethau rhwng craidd cynffon y cynhwysydd, injan y cynhwysydd, nodau (Kubelets) a nod Kubernetes Master. Trwy reoli holl gydrannau'r platfform yn ganolog, gyda rheolaeth a fersiwn, mae llwybr clir bob amser o gyflwr A i gyflwr B. Mae hyn yn symleiddio'r broses ddiweddaru, yn gwella diogelwch, yn gwella adrodd ar berfformiad, ac yn helpu i leihau cost diweddariadau a gosodiadau fersiynau newydd .
Yn dangos pŵer elfennau amnewid
Fel y soniwyd yn gynharach, mae defnyddio'r Gweithredwr Ffurfweddu Peiriant i reoli'r gwesteiwr cynhwysydd a'r injan cynhwysydd yn OpenShift 4 yn darparu lefel newydd o awtomeiddio nad oedd yn bosibl o'r blaen ar lwyfan Kubernetes. I ddangos y nodweddion newydd, byddwn yn dangos sut y gallech wneud newidiadau i'r ffeil crio.conf. Er mwyn osgoi cael eich drysu gan derminoleg, ceisiwch ganolbwyntio ar y canlyniadau.
Yn gyntaf, gadewch i ni greu yr hyn a elwir yn ffurfweddiad amser rhedeg cynhwysydd - Container Runtime Config. Meddyliwch amdano fel adnodd Kubernetes sy'n cynrychioli'r ffurfweddiad ar gyfer CRI-O. Mewn gwirionedd, mae'n fersiwn arbenigol o rywbeth o'r enw MachineConfig, sef unrhyw ffurfweddiad sy'n cael ei ddefnyddio i beiriant RHEL CoreOS fel rhan o glwstwr OpenShift.
Crëwyd yr adnodd pwrpasol hwn, o'r enw ContainerRuntimeConfig, i'w gwneud yn haws i weinyddwyr clwstwr ffurfweddu CRI-O. Mae'r offeryn hwn yn ddigon pwerus fel mai dim ond i nodau penodol y gellir ei gymhwyso yn dibynnu ar osodiadau MachineConfigPool. Meddyliwch amdano fel grŵp o beiriannau sy'n cyflawni'r un pwrpas.
Sylwch ar y ddwy linell olaf rydyn ni'n mynd i'w newid yn y ffeil /etc/crio/crio.conf. Mae'r ddwy linell hyn yn debyg iawn i'r llinellau yn y ffeil crio.conf, sef:
vi ContainerRuntimeConfig.yaml
Casgliad:
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
Nawr, gadewch i ni wthio'r ffeil hon i glwstwr Kubernetes a gwirio ei fod wedi'i greu mewn gwirionedd. Sylwch fod y llawdriniaeth yn union yr un fath ag unrhyw adnodd Kubernetes arall:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Casgliad:
NAME AGE
set-log-and-pid 22h
Unwaith y byddwn wedi creu'r ContainerRuntimeConfig, mae angen i ni addasu un o'r MachineConfigPools i ddangos i Kubernetes ein bod am gymhwyso'r cyfluniad hwn i grŵp penodol o beiriannau yn y clwstwr. Yn yr achos hwn byddwn yn newid y MachineConfigPool ar gyfer y prif nodau:
oc edit MachineConfigPool/master
Casgliad (er eglurder, mae'r prif hanfod ar ôl):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Ar y pwynt hwn, mae MCO yn dechrau creu ffeil crio.conf newydd ar gyfer y clwstwr. Yn yr achos hwn, gellir gweld y ffeil ffurfweddu gwbl orffenedig gan ddefnyddio'r Kubernetes API. Cofiwch, dim ond fersiwn arbenigol o MachineConfig yw ContainerRuntimeConfig, felly gallwn weld y canlyniad trwy edrych ar y llinellau perthnasol yn MachineConfigs:
oc get MachineConfigs | grep rendered
Casgliad:
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
Sylwch fod y ffeil ffurfweddu a ddeilliodd o'r prif nodau yn fersiwn mwy diweddar na'r ffurfweddiadau gwreiddiol. I'w weld, rhedeg y gorchymyn canlynol. Wrth fynd heibio, nodwn efallai mai dyma un o'r chwaraewyr un-lein gorau yn hanes 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
Casgliad:
pids_limit = 2048
Nawr, gadewch i ni sicrhau bod y cyfluniad wedi'i gymhwyso i bob prif nod. Yn gyntaf rydym yn cael rhestr o nodau yn y clwstwr:
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
Nawr, gadewch i ni edrych ar y ffeil gosod. Fe welwch fod y ffeil wedi'i diweddaru gyda'r gwerthoedd newydd ar gyfer y cyfarwyddebau pid a dadfygio a nodwyd gennym yn yr adnodd ContainerRuntimeConfig. Ceinder ei hun:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Casgliad:
...
pids_limit = 2048
...
log_level = "debug"
...
Gwnaethpwyd yr holl newidiadau hyn i'r clwstwr heb redeg SSH hyd yn oed. Gwnaethpwyd yr holl waith trwy gyrchu prif nod Kuberentes. Hynny yw, dim ond ar nodau meistr y ffurfiwyd y paramedrau newydd hyn. Ni newidiodd nodau'r gweithwyr, sy'n dangos manteision methodoleg Kubernetes o ddefnyddio cyflyrau penodol a gwirioneddol mewn perthynas â gwesteiwyr cynwysyddion a pheiriannau cynwysyddion ag elfennau cyfnewidiol.
Mae'r enghraifft uchod yn dangos y gallu i wneud newidiadau i glwstwr Platfform Cynhwysydd OpenShift 4 bach gyda thri nod cynhyrchu neu glwstwr cynhyrchu enfawr gyda 3000 o nodau. Mewn unrhyw achos, bydd maint y gwaith yr un peth - ac yn fach iawn - dim ond ffurfweddu'r ffeil ContainerRuntimeConfig, a newid un label yn MachineConfigPool. A gallwch chi wneud hyn gydag unrhyw fersiwn o'r OpenShift Container Platform 4.X yn rhedeg Kubernetes trwy gydol ei gylch bywyd.
Yn aml mae cwmnïau technoleg yn esblygu mor gyflym fel na allwn esbonio pam rydym yn dewis technolegau penodol ar gyfer y cydrannau sylfaenol. Yn hanesyddol, peiriannau cynhwysydd yw'r gydran y mae defnyddwyr yn rhyngweithio â nhw'n uniongyrchol. Ers i boblogrwydd cynwysyddion ddechrau'n naturiol gyda dyfodiad peiriannau cynhwysydd, mae defnyddwyr yn aml yn dangos diddordeb ynddynt. Dyma reswm arall pam y dewisodd Red Hat CRI-O. Mae cynwysyddion yn esblygu gyda'r ffocws nawr ar offeryniaeth, ac rydym wedi canfod bod CRI-O yn darparu'r profiad gorau wrth weithio gydag OpenShift 4.
Ffynhonnell: hab.com