Platforma lejon që të vendosë në rrjedhë krijimin , duke përfshirë në infrastrukturën e ofruesve të shërbimeve të cloud, në platforma virtualizimi ose në sisteme bare-metal. Për të krijuar një platformë të vërtetë cloud, na duhej të merrnim nën kontroll të gjitha elementet e përdorura dhe kështu të rrisnin besueshmërinë e procesit kompleks të automatizimit.
Zgjidhja evidente ishte pĂ«rdorimi si standard i Red Hat Enterprise Linux CoreOS (njĂ« variant i Red Hat Enterprise Linux) dhe CRI-O, dhe ja pseâŠ
Pasi tema e drejtimit është mjaft e suksesshme për të gjetur analogji në shpjegimin e funksionimit të Kubernetes dhe konteinerëve, le të përpiqemi të flasim për ato probleme biznesi që zgjidhin CoreOS dhe CRI-O, duke e ilustruar me . Në vitin 1803, Mark Brunel iu përball me detyrën për të prodhuar 100 mijë blloqe të riggingut për nevojat e flotës detare në rritje të Britanisë së Madhe. Blloku i riggingut është një lloj pajisjeje që përdoret për të lidhur corda me vela. Deri në fillim të shekullit të 19-të, këto blloqe ishin prodhuar me dorë, por Brunel arriti të automatizojë prodhimin dhe të fillojë prodhimin e blloqeve standardizuese me ndihmën e maqinave. Automatizimi i këtij procesi nënkuptonte se të gjitha blloqet ishin praktikisht identike, mund të zëvendësoheshin lehtësisht në rast defekte dhe mund të prodhoheshin në sasi të mëdha.
Tani, imagjinoni se Bryunel duhet ta bënte këtë punë për 20 modele të ndryshme anijesh (versionet e Kubernetes) dhe për pesë planeta të ndryshëm me rrjedha dhe erëra deti krejtësisht të ndryshme (furnizuesit e cloud). Për më tepër, të gjithë anijet (klasteret OpenShift), pavarësisht nga planetet që po navigojnë, duhet të sillen të njëjtë për kapitenët (operatoret që menaxhojnë punën e klasterëve). Duke vazhduar me metaforën detare, kapitenët e anijeve nuk i intereson fare se cilat blloqe shtrimi (CRI-O) përdoren në anijet e tyre - ata vetëm duan që këto blloqe të jenë të forta dhe të besueshme.
Para OpenShift 4, si një platformë cloud, qëndron një detyrë biznesi shumë e ngjashme. Njësitë e reja duhet të krijohen në momentin e krijimit të klasterit, në rast të një dështimi në një nga nyjat, ose kur klasteri të skalitet. Gjatë krijimit dhe inicializimit të një nyje të re, komponentët kritikë të hostit duhet të konfigurohen gjithashtu, duke përfshirë CRI-O. Siç ndodh edhe në çdo prodhim tjetër, së pari duhet të sillni "lëndën e parë". Në rastin e anijeve, lënda e parë është metali dhe druri. Megjithatë, kur krijoni një host për shpërndarjen e kontejnerëve në klasterin OpenShift 4, në hyrje duhet të keni skedarët e konfigurimit dhe shërbimet e ofruara nga API. Pas kësaj, OpenShift do të sigurojë nivelin e nevojshëm të automatizimit gjatë gjithë ciklit të jetës, duke ofruar suportin e nevojshëm për produktet për përdoruesit përfundimtarë dhe kështu shpërblen investimet në platformë.
OpenShift 4 është krijuar për të siguruar një përditësim të lehtë të sistemit gjatë gjithë ciklit të jetës së platformës (për versionet 4.X) për të gjithë ofruesit kryesorë të llogaritjes në re, platformave të virtualizimit dhe madje edhe sistemeve bare metal. Për këtë, nyjat duhet të krijohen mbi baza zëvendësueshmërisht. Kur një grup kërkon një version të ri të Kubernetes, ai merr gjithashtu versionin përkatës të CRI-O në CoreOS. Duke qenë se versioni i CRI-O është i lidhur drejtpërdrejt me Kubernetes, kjo e bën shumë më të thjeshtë çdo rregullim për qëllime testimi, zgjidhjeje të problemeve ose mbështetje. Për më tepër, një qasje e tillë ndihmon në uljen e kostove për përdoruesit përfundimtarë dhe Red Hat.
Ky Ă«shtĂ« njĂ« kĂ«ndvĂ«shtrim krejt tĂ« ri pĂ«r klasterĂ«t Kubernetes, i cili shtron themelet pĂ«r planifikimin e funksioneve tĂ« reja shumĂ« tĂ« dobishme dhe tĂ«rheqĂ«se. CRI-O (projekti i Container Runtime Interface â Open Container Initiative, shkurtuar CRI-OCI) ka rezultuar tĂ« jetĂ« zgjedhja mĂ« e mirĂ« pĂ«r krijimin e masave tĂ« nyjeve tĂ« nevojshme pĂ«r funksionimin me OpenShift. CRI-O do tĂ« zĂ«vendĂ«sojĂ« motorin e mĂ«parshĂ«m Docker, duke ofruar pĂ«rdoruesve tĂ« OpenShift. â po, nuk jeni duke dĂ«gjuar gabim â njĂ« motor kontejner mĂ«rzitĂ«s, i krijuar posaçërisht pĂ«r tĂ« punuar me Kubernetes.
Bota e kontejnerëve të hapur
Bota ka kohë që po i drejtohet kontejnerëve të hapur. Qoftë në Kubernetes, ose në nivele më të ulëta, çon në krijimin e një ekosistemi inovacionesh në çdo nivel.
Gjithçka filloi me krijimin e iniciativës Open Containers Initiative . Në këtë fazë të hershme, u formuan specifikimet për dhe . Kjo mundësoi të garantohet se mjetet mund të përdorin një standard të vetëm dhe një format i vetëm për punë me ta. Më vonë u shtuan specifikimet , çka u mundësoi përdoruesve të shkëmbejnë me lehtësi .
Pastaj, komuniteti i Kubernetes krijoi një standard të vetëm të interfesës së lidhjes (pluggable interface), të quajtur . Falë kësaj, përdoruesit e Kubernetes mund të lidhin engine të ndryshme për punë me konteinerë përveç Docker.
Inxhinierët e Red Hat dhe Google panë një nevojë në treg për një engine konteinerësh që mund të priste kërkesat nga Kubelet nëpërmjet protokollit CRI dhe prezantuan konteinerë që ishin të përputhshëm me specifikimet e përmendura më sipër të OCI. Kështu Por le të themi, sepse ne thamë se ky material do të ishte i dedikuar CRI-O? Në të vërtetë po, thjesht me lëshimin projekti u riemërua në CRI-O.
Fig. 1.
Novacionet me CRI-O dhe CoreOS
Me fillimin e platformës OpenShift 4, u ndryshua , e përdorur në platformën e parazgjedhur, dhe në vend të Docker ka ardhur CRI-O, i cili ofron një mjedis të thjeshtë, të qëndrueshëm dhe gjithëpërfshirës për ekzekutimin e kontejnerëve, që zhvillohet paralelisht me Kubernetes. Kjo e thjeshton ndjeshëm mbështetjen dhe konfigurimin e klasit. Konfigurimi dhe menaxhimi i motorit të kontejnerëve dhe hostit bëhet automatizuar brenda OpenShift 4.
Prit, si është kjo?
Saktesisht, me shfaqjen e OpenShift 4, nuk është më e nevojshme të lidheni me hoste të veçantë dhe të instaloni motorin e kontejnerëve, të konfiguroni ruajtjen, të vendosni serverë për kërkim, ose të konfiguroni rrjetin. Platforma OpenShift 4 është ristruktuar plotësisht për t'u përdorur me jo vetëm nga perspektiva e aplikacioneve të përdoruesve përfundimtarë, por edhe nga perspektiva e operacioneve thelbësore në nivelin e platformës, si shpërndarja e imazheve, konfigurimi i sistemit ose instalimi i përditësimeve.
Kubernetes gjithmonë u ka lejuar përdoruesve të menaxhojnë aplikacione, duke përcaktuar gjendjen e dëshiruar dhe duke përdorur , për të garantuar që gjendja aktuale përputhet sa më shumë me gjendjen e caktuar. Ky hap mundësi të mëdha si nga pikëpamja e zhvillimit ashtu edhe nga ajo e operacioneve. Zhvilluesit mund të përcaktojnë gjendjen e kërkuar, operatorit në formën e një skedari YAML ose JSON, dhe pastaj operatori mund të krijojë në mjedisin operativ instancën e nevojshme të aplikacionit, ku gjendja operative e kësaj instance do të përputhet plotësisht me atë të caktuar.
Duke përdorur operatorët (Operators) në platformën OpenShift 4, kjo paradigëm e re (duke përdorur konceptin e gjendjes së caktuar dhe atyre aktuale) përfshihet në menaxhimin e RHEL CoreOS dhe CRI-O. Detyrat e konfigurimit dhe menaxhimit të versioneve të sistemit operativ dhe motorit të kontejnerëve automatizohen përmes asaj që quhet . MCO ndihmon ndjeshëm administratën e grupit, duke automatizuar esencialisht fazat e fundit të instalimit dhe operacionet pas instalimit (operacionet e ditës dy). Të gjitha këto e bëjnë OpenShift 4 një platformë reale në re. Ne do të ndalemi tek kjo pak më vonë.
Nisja e konteinerëve
Përdoruesit kishin mundësinë të përdorin motorin CRI-O në platformën OpenShift që nga versioni 3.7 në statusin Teknik Preview dhe nga versioni 3.9 në statusin e Disponueshmërisë së Përgjithshme (momentalisht mbështetur). Për më tepër, Red Hat përdor gjerësisht në OpenShift Online që nga versioni 3.10. Të gjitha këto i dhanë ekipit që punon mbi CRI-O një përvojë të jashtëzakonshme në nisjen masive të konteinerëve në klasterët e mëdhenj Kubernetes. Për të marrë një pasqyrë të bazës së asaj se si Kubernetes përdor CRI-O, le të shqyrtojmë ilustrimin e mëposhtëm, i cili tregon parimin e funksionimit të arkitekturës.
Fig. 2. Si funksionojnë konteinerët në klasterin Kubernetes
CRI-O e thjeshtëson krijimin e hosteve të rinj të kontejnerëve duke sinkronizuar të gjithë nivelin e sipërm gjatë inicializimit të nyjeve të reja dhe kur lëshohen versione të reja të platformës OpenShift. Rishikimi i tërë platformës lejon përditësime dhe rikthime tranzaksionale, si dhe parandalon bllokimet e ndërsjella në varësitë mes bërthamës së kontejnerëve, motorit të kontejnerëve, nyjeve (Kubelets) dhe master-it të Kubernetes. Me menaxhimin e centralizuar të të gjithë komponenteve të platformës, me kontroll dhe menaxhim versionesh, gjithmonë mund të ndjekim një rrugë të qartë nga gjendja A në gjendjen B. Kjo e lehtëson procesin e përditësimeve, rrit sigurinë, përmirëson raportimin e performancës dhe ndihmon në uljen e kostove për përditësimet dhe instalimin e versioneve të reja.
Demonstrimi i fuqisë së elementeve të këmbyeshëm
Si është përmendur më parë, përdorimi i Machine Config Operator për menaxhimin e host-it të kontejnerëve dhe motorit të kontejnerëve në OpenShift 4 siguron një nivel të ri automatizimi, që nuk ishte i mundur më parë në platformën Kubernetes. Për të demonstruar mundësitë e reja, ne do të tregojmë se si mund të bëni ndryshime në skedarin crio.conf. Për të mos u ngatërruar në terminologji, përpiquni të përqendroheni te rezultatet.
SĂ« pari, le tĂ« krijojmĂ« atĂ« qĂ« quhet konfigurimi i mjedisit tĂ« ekzekutimit tĂ« kontejnerĂ«ve â Container Runtime Config. Mendoni pĂ«r kĂ«tĂ« si njĂ« burim Kubernetes qĂ« pĂ«rfaqĂ«son konfigurimin pĂ«r CRI-O. NĂ« tĂ« vĂ«rtetĂ«, kjo Ă«shtĂ« njĂ« version i specializuar i asaj qĂ« quhet MachineConfig, qĂ« pĂ«rfaqĂ«son çdo konfigurim qĂ« shpĂ«rndahet nĂ« makinĂ«n RHEL CoreOS brenda klasterit OpenShift.
Ky burim i personalizuar, i quajtur ContainerRuntimeConfig, u shpik për të lehtësuar për administratorët e klasterit konfigurimin e CRI-O. Ky është një mjet mjaft i fuqishëm, sa që mund të aplikohet vetëm për node të caktuara në varësi të konfigurimeve të MachineConfigPool. Mendoni për këtë si një grup makinash që shërbejnë për të njëjtin qëllim.
Kini një vërejtje për dy rreshtat e fundit që do të ndryshojmë në skedarin /etc/crio/crio.conf. Këto dy rreshta janë shumë të ngjashëm me rreshtat në skedarin crio.conf, ato janë:
vi ContainerRuntimeConfig.yaml
Dalja:
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
Tani do ta dërgojmë këtë skedar në klusterin Kubernetes dhe do të kontrollojmë nëse është krijuar me të vërtetë. Vini re se puna bëhet në të njëjtën mënyrë si me çdo burim tjetër Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Dalja:
NAME AGE
set-log-and-pid 22h
Pasi krijuam ContainerRuntimeConfig, na nevojitet të ndryshojmë një nga MachineConfigPools, që të bëjmë të qartë për Kubernetes se duam ta aplikojmë këtë konfiguracion për një grup të caktuar makinash në kluster. Në këtë rast do të ndryshojmë MachineConfigPool për nodet kryesore:
oc edit MachineConfigPool/master
Dalja (për qartësi është lënë thelbi):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Në këtë moment, MCO fillon të krijojë një skedë të re crio.conf për klasterin. Gjatë kësaj, skeda e plotë e konfigurimit mund të shikohet përmes API-së së Kubernetes. Mbani në mend se ContainerRuntimeConfig është thjesht një version i specializuar i MachineConfig, prandaj mund të shohim rezultatin duke e vështruar rreshtat e nevojshëm në MachineConfigs:
oc get MachineConfigs | grep rendered
Dalja:
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
Vini re se skedari i marrë i konfigurimeve për nodet master doli të jetë një version më i ri se konfigurimet origjinale. Për ta parë atë, ekzekutoni komandën e mëposhtme. Po ashtu, le të theksojmë se ky mund të jetë një nga skipt e një rreshti më të mira në historinë e 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
Dalja:
pids_limit = 2048
Tani le t'u sigurohemi që konfigurimi është aplikuar në të gjitha nodet master. Së pari, le të marrim një listë të nodeve në klaster:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Gatshëm master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Gatshëm master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Gatshëm master 23h v1.12.4+509916ce1
Tani do tĂ« shohim skedarin e instaluar. Do tĂ« shihni se skedari Ă«shtĂ« pĂ«rditĂ«suar sipas vlerave tĂ« reja tĂ« drejtorive pid dhe debug, tĂ« cilat i especĂfica nĂ« burimin ContainerRuntimeConfig. Eleganca e vetĂ«:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal â cat /host/etc/crio/crio.conf | egrep 'debug||pidâ
Dalja:
...
pids_limit = 2048
...
log_level = "debug"
...
Të gjitha këto ndryshime në klaster janë bërë edhe pa e aktivizuar SSH. Të gjitha punët janë kryer duke u drejtuar në nodin master të Kubernetes. Domethënë, këto parametra të rinj janë konfiguruar vetëm në nodet master. Nodet punuese nuk kanë ndryshuar, që tregon përfitimet e metodologjisë Kubernetes duke përdorur gjendje të caktuara dhe aktuale për hostet e kontejnerëve dhe motorët e kontejnerëve me komponente të ndërrueshme.
Shembulli i mĂ«sipĂ«rm tregon mundĂ«sinĂ« pĂ«r tĂ« bĂ«rĂ« ndryshime nĂ« njĂ« grup tĂ« vogĂ«l tĂ« OpenShift Container Platform 4 me tre nyje punuese ose nĂ« njĂ« grup tĂ« madh prodhimi me 3000 nyje. NĂ« çdo rast, volumi i punĂ«s do tĂ« jetĂ« i njĂ«jtĂ« â dhe mjaft i vogĂ«l â mjafton tĂ« konfiguroni skedarin ContainerRuntimeConfig dhe tĂ« ndryshoni njĂ« etiketĂ« nĂ« MachineConfigPool. Dhe mund ta bĂ«ni kĂ«tĂ« me çdo version tĂ« platformĂ«s OpenShift Container Platform 4.X qĂ« pĂ«rdoret nĂ« Kubernetes gjatĂ« gjithĂ« ciklit tĂ« saj tĂ« jetĂ«s.
shpesh kompanitë teknologjike zhvillohen aq shpejt saqë ne nuk jemi në gjendje të shpjegojmë pse zgjedhim teknologji të caktuara për komponentët bazë. Motorët e kontejnerëve historikisht kanë qenë komponenti me të cilin përdoruesit ndërveprojnë drejtpërdrejt. Duke qenë se popullariteti i kontejnerëve filloi natyrshëm me shfaqjen e motorëve të kontejnerëve, përdoruesit shpesh shprehin interes për ta. Kjo është një arsye tjetër pse Red Hat zgjodhi CRI-O. Kontejnerët po zhvillohen, ndërsa sot vëmendja kryesore është për orkestrimin, dhe ne arritëm në përfundimin se CRI-O ofron eksperiencën më të mirë kur punon me OpenShift 4.
Burimi: habr.com
