Platform gerir þér kleift að hagræða sköpuninni , þar á meðal í innviðum skýjaþjónustuveitenda, á sýndarvæðingarpöllum eða í berum málmkerfum. Til að búa til raunverulegan skýjabyggðan vettvang þurftum við að hafa stranga stjórn á öllum þáttum sem notaðir voru og auka þannig áreiðanleika flókins sjálfvirkniferlis.
Augljósa lausnin var að nota Red Hat Enterprise Linux CoreOS (afbrigði af Red Hat Enterprise Linux) og CRI-O sem staðal, og hér er ástæðan...
Þar sem viðfangsefnið siglingar er mjög gott til að finna hliðstæður þegar útskýrt er vinnu Kubernetes og gáma, skulum við reyna að tala um viðskiptavandamálin sem CoreOS og CRI-O leysa, með því að nota dæmi . Árið 1803 var Marc Brunel falið að framleiða 100 búnaðarblokkir fyrir þarfir vaxandi breska flotans. Stigablokk er tegund af búnaði sem er notaður til að festa reipi við segl. Fram í byrjun 19. aldar voru þessir kubbar handsmíðaðir, en Brunel tókst að gera sjálfvirkan framleiðslu og byrjaði að framleiða staðlaða kubba með verkfærum. Sjálfvirkni þessa ferlis þýddi að blokkirnar sem mynduðust voru í meginatriðum eins, auðvelt var að skipta um ef brotnar og hægt var að framleiða þær í miklu magni.
Ímyndaðu þér nú ef Brunel þyrfti að vinna þetta verk fyrir 20 mismunandi skipagerðir (Kubernetes útgáfur) og fyrir fimm mismunandi plánetur með gjörólíka sjávarstrauma og vinda (skýjaveitur). Auk þess var gerð krafa um að öll skip (OpenShift þyrpingar), óháð plánetum sem siglingar fara fram á, frá sjónarhóli skipstjóranna (rekstraraðila sem stjórna rekstri þyrpinganna) haga sér eins. Til að halda áfram sjólíkingunni þá er skipstjórum alveg sama hvers konar rigging blokkir (CRI-O) eru notaðir á skipum þeirra - aðalatriðið fyrir þá er að þessar blokkir séu sterkar og áreiðanlegar.
OpenShift 4, sem skýjapallur, stendur frammi fyrir mjög svipaðri viðskiptaáskorun. Nýja hnúta verður að búa til við stofnun klasa, ef bilun verður í einum hnúta eða þegar þyrping er stækkuð. Þegar nýr hnút er búinn til og frumstilltur verða mikilvægir hýsilhlutar, þar á meðal CRI-O, að stilla í samræmi við það. Eins og í allri annarri framleiðslu þarf að útvega „hráefni“ í upphafi. Þegar um er að ræða skip er hráefnið málmur og tré. Hins vegar, ef um er að ræða að búa til hýsil til að dreifa gámum í OpenShift 4 þyrping, þarftu að hafa stillingarskrár og API-miðlara sem inntak. OpenShift mun síðan veita nauðsynlega sjálfvirkni í gegnum allan lífsferilinn, bjóða upp á nauðsynlegan vörustuðning til endanotenda og vinna þannig fjárfestinguna í pallinum til baka.
OpenShift 4 var búið til á þann hátt að það veitir möguleika á að uppfæra kerfið á þægilegan hátt í gegnum allan lífsferil vettvangsins (fyrir útgáfur 4.X) fyrir allar helstu skýjatölvuveitur, sýndarvæðingarkerfi og jafnvel berum málmkerfi. Til að gera þetta verður að búa til hnúta á grundvelli skiptanlegra þátta. Þegar þyrping krefst nýrrar útgáfu af Kubernetes fær hann einnig samsvarandi útgáfu af CRI-O á CoreOS. Þar sem CRI-O útgáfan er tengd beint við Kubernetes, einfaldar þetta til muna allar umbreytingar fyrir prófun, bilanaleit eða stuðningstilgang. Að auki dregur þessi aðferð úr kostnaði fyrir notendur og Red Hat.
Þetta er í grundvallaratriðum ný hugsun um Kubernetes klasa og leggur grunninn að því að skipuleggja mjög gagnlega og sannfærandi nýja eiginleika. CRI-O (Container Runtime Interface - Open Container Initiative, skammstafað CRI-OCI) reyndist farsælasti kosturinn fyrir fjöldagerð hnúta sem eru nauðsynlegir til að vinna með OpenShift. CRI-O mun koma í stað Docker vélarinnar sem áður var notað og býður upp á OpenShift notendur – já, þú heyrðir rétt – leiðinleg gámavél búin til sérstaklega til að vinna með Kubernetes.
Heimur opinna gámanna
Heimurinn hefur lengi verið að færast í átt að opnum gámum. Hvort sem er í Kubernetes, eða á lægri hæðum, skilar sér í vistkerfi nýsköpunar á öllum stigum.
Þetta byrjaði allt með stofnun Open Containers Initiative . Á þessu frumstigi vinnunnar voru gámaforskriftir mótaðar и . Þetta tryggði að tækin gætu notað einn staðal og sameinað snið til að vinna með þeim. Tæknilýsingum var síðar bætt við , sem gerir notendum kleift að deila auðveldlega .
Kubernetes samfélagið þróaði síðan einn staðal fyrir tengjanlegt viðmót, kallaður . Þökk sé þessu gátu notendur Kubernetes tengt ýmsar vélar til að vinna með gáma auk Docker.
Verkfræðingar hjá Red Hat og Google sáu markaðsþörf fyrir gámavél sem gæti samþykkt Kubelet beiðnir um CRI samskiptareglur og kynntu gáma sem voru samhæfðar við OCI forskriftirnar sem nefnd eru hér að ofan. Svo . En fyrirgefðu, sögðum við ekki að þetta efni yrði tileinkað CRI-O? Reyndar er það, bara með útgáfunni verkefnið fékk nafnið CRI-O.
Fig. 1.
Nýsköpun með CRI-O og CoreOS
Með kynningu á OpenShift 4 pallinum var því breytt , notað sjálfgefið í pallinum, og Docker var skipt út fyrir CRI-O, sem býður upp á hagkvæmt, stöðugt, einfalt og leiðinlegt umhverfi til að keyra ílát sem þróast samhliða Kubernetes. Þetta einfaldar stuðning og uppsetningu klasa til muna. Stillingar gámavélarinnar og hýsilsins, sem og stjórnun þeirra, verða sjálfvirk innan OpenShift 4.
Bíddu, hvernig er þetta?
Það er rétt, með tilkomu OpenShift 4 er ekki lengur þörf á að tengjast einstökum gestgjöfum og setja upp gámavél, stilla geymslu, stilla leitarþjóna eða stilla net. OpenShift 4 pallurinn hefur verið algjörlega endurhannaður til að nota ekki aðeins hvað varðar notendaforrit, heldur einnig hvað varðar grunnaðgerðir á vettvangsstigi eins og að dreifa myndum, stilla kerfið eða setja upp uppfærslur.
Kubernetes hefur alltaf leyft notendum að stjórna forritum með því að skilgreina æskilegt ástand og nota , til að tryggja að raunverulegt ástand passi eins vel við markástandið og mögulegt er. Þetta opnar mikla möguleika bæði frá þróunar- og rekstrarsjónarmiði. Hönnuðir geta skilgreint nauðsynlegt ástand með því að til rekstraraðila í formi YAML eða JSON skráar, og þá getur rekstraraðilinn búið til tilskilið forritatilvik í framleiðsluumhverfinu og rekstrarástand þessa tilviks mun að fullu samsvara því tilgreindu.
Með því að nota Operators á pallinum færir OpenShift 4 þessa nýju hugmyndafræði (með því að nota hugmyndina um sett og raunverulegt ástand) til stjórnenda RHEL CoreOS og CRI-O. Verkefnin við að stilla og stjórna útgáfum af stýrikerfi og gámavél eru sjálfvirk með því að nota svokallaða . MCO einfaldar mjög vinnu klasastjórans, gerir í rauninni sjálfvirkan síðustu stig uppsetningar, sem og síðari aðgerðir eftir uppsetningu (dagur tvö aðgerðir). Allt þetta gerir OpenShift 4 að raunverulegum skýjapalli. Við munum koma inn á þetta aðeins síðar.
Gámar í gangi
Notendur hafa haft tækifæri til að nota CRI-O vélina í OpenShift pallinum frá útgáfu 3.7 í tækniforskoðunarstöðu og frá útgáfu 3.9 í almennt tiltækri stöðu (nú studd). Að auki notar Red Hat gríðarlega í OpenShift Online frá útgáfu 3.10. Allt þetta gerði teymið sem vann að CRI-O kleift að öðlast víðtæka reynslu í fjöldaskotsetningu gáma á stórum Kubernetes þyrpingum. Til að fá grunnskilning á því hvernig Kubernetes notar CRI-O skulum við skoða eftirfarandi mynd, sem sýnir hvernig arkitektúrinn virkar.
Hrísgrjón. 2. Hvernig gámar virka í Kubernetes klasa
CRI-O einfaldar stofnun nýrra gámahýsinga með því að samstilla allt efsta stigið við frumstillingu nýrra hnúta og þegar gefnar eru út nýjar útgáfur af OpenShift pallinum. Endurskoðun á öllum pallinum gerir ráð fyrir viðskiptauppfærslum / afturköllun og kemur einnig í veg fyrir stöðvun í ósjálfstæði milli gámabakkjarna, gámavélar, hnúta (Kubelets) og Kubernetes Master hnút. Með miðlægri stjórnun allra kerfishluta, með stjórnun og útgáfu, er alltaf skýr leið frá ástandi A til ástands B. Þetta einfaldar uppfærsluferlið, bætir öryggi, bætir árangursskýrslur og hjálpar til við að draga úr kostnaði við uppfærslur og uppsetningar á nýjum útgáfum .
Að sýna fram á kraft skiptiþátta
Eins og fyrr segir, með því að nota Machine Config Operator til að stjórna gámahýslinum og gámavélinni í OpenShift 4 veitir nýtt stig sjálfvirkni sem ekki var áður möguleg á Kubernetes pallinum. Til að sýna nýju eiginleikana munum við sýna hvernig þú gætir gert breytingar á crio.conf skránni. Til að forðast að ruglast á hugtökum skaltu reyna að einbeita þér að niðurstöðunum.
Fyrst skulum við búa til það sem kallast gámakeyrslustillingar - Container Runtime Config. Hugsaðu um það sem Kubernetes tilföng sem táknar uppsetninguna fyrir CRI-O. Í raun og veru er það sérhæfð útgáfa af einhverju sem kallast MachineConfig, sem er hvaða uppsetning sem er sett á RHEL CoreOS vél sem hluti af OpenShift klasa.
Þetta sérsniðna tilfang, sem kallast ContainerRuntimeConfig, var búið til til að auðvelda klasastjórnendum að stilla CRI-O. Þetta tól er nógu öflugt til að það er aðeins hægt að nota það á ákveðna hnúta, allt eftir stillingum MachineConfigPool. Hugsaðu um það sem hóp af vélum sem þjóna sama tilgangi.
Taktu eftir síðustu tveimur línunum sem við ætlum að breyta í /etc/crio/crio.conf skránni. Þessar tvær línur eru mjög svipaðar línunum í crio.conf skránni, þær eru:
vi ContainerRuntimeConfig.yaml
Ályktun:
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
Nú skulum við ýta þessari skrá í Kubernetes þyrpinguna og athuga hvort hún hafi raunverulega verið búin til. Vinsamlegast athugaðu að aðgerðin er nákvæmlega sú sama og með önnur Kubernetes tilföng:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Ályktun:
NAME AGE
set-log-and-pid 22h
Þegar við höfum búið til ContainerRuntimeConfig þurfum við að breyta einni af MachineConfigPools til að gefa Kubernetes merki um að við viljum beita þessari stillingu á ákveðinn hóp véla í þyrpingunni. Í þessu tilviki munum við breyta MachineConfigPool fyrir aðalhnúta:
oc edit MachineConfigPool/master
Niðurstaða (til glöggvunar er aðalkjarninn eftir):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Á þessum tímapunkti byrjar MCO að búa til nýja crio.conf skrá fyrir þyrpinguna. Í þessu tilviki er hægt að skoða fullbúna stillingarskrá með Kubernetes API. Mundu að ContainerRuntimeConfig er bara sérhæfð útgáfa af MachineConfig, svo við getum séð niðurstöðuna með því að skoða viðeigandi línur í MachineConfigs:
oc get MachineConfigs | grep rendered
Ályktun:
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
Vinsamlegast athugaðu að stillingarskráin sem varð til fyrir aðalhnúta var nýrri útgáfa en upprunalegu stillingarnar. Til að skoða það skaltu keyra eftirfarandi skipun. Í framhjáhlaupi tökum við fram að þetta er ef til vill ein besta einlína í sögu 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
Ályktun:
pids_limit = 2048
Nú skulum við ganga úr skugga um að uppsetningin hafi verið notuð á alla aðalhnúta. Fyrst fáum við lista yfir hnúta í þyrpingunni:
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
Nú skulum við líta á uppsettu skrána. Þú munt sjá að skráin hefur verið uppfærð með nýju gildunum fyrir pid og villuleitartilskipanir sem við tilgreindum í ContainerRuntimeConfig tilfönginni. Glæsileikinn sjálfur:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Ályktun:
...
pids_limit = 2048
...
log_level = "debug"
...
Allar þessar breytingar á klasanum voru gerðar án þess þó að keyra SSH. Öll vinna var unnin með því að fá aðgang að Kuberentes meistarahnútnum. Það er, þessar nýju færibreytur voru aðeins stilltar á aðalhnútum. Starfsmannahnútarnir breyttust ekki, sem sýnir fram á kosti Kubernetes aðferðafræðinnar við að nota tilgreind og raunveruleg ástand í tengslum við gámahýsil og gámavélar með skiptanlegum þáttum.
Dæmið hér að ofan sýnir getu til að gera breytingar á litlum OpenShift Container Platform 4 klasa með þremur framleiðsluhnútum eða risastórum framleiðsluklasa með 3000 hnútum. Í öllum tilvikum mun vinnan vera sú sama - og mjög lítil - stilltu bara ContainerRuntimeConfig skrána og breyttu einu merki í MachineConfigPool. Og þú getur gert þetta með hvaða útgáfu sem er af OpenShift Container Platform 4.X sem keyrir Kubernetes allan lífsferilinn.
Oft þróast tæknifyrirtæki svo hratt að við getum ekki útskýrt hvers vegna við veljum ákveðna tækni fyrir undirliggjandi þætti. Gámavélar hafa í gegnum tíðina verið sá hluti sem notendur hafa bein samskipti við. Þar sem vinsældir gáma hófust eðlilega með tilkomu gámavéla sýna notendur þeim oft áhuga. Þetta er önnur ástæða fyrir því að Red Hat valdi CRI-O. Gámar eru að þróast með áherslu á hljómsveitarsetningu og við höfum komist að því að CRI-O veitir bestu upplifunina þegar unnið er með OpenShift 4.
Heimild: www.habr.com