Platforma lejon le ta themel , 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ë gjithë elementët e përdorur dhe kështu të rrisim besueshmërinë e procesit të ndërlikuar të automatizimit.
Zgjidhja tërheqëse ishte përdorimi si standard i Red Hat Enterprise Linux CoreOS (një variant i Red Hat Enterprise Linux) dhe CRI-O, dhe ja pse...
Duke qenë se tema e lundrimit është shumë e përshtatshme për të gjetur analogji në shpjegimin e funksionimit të Kubernetes dhe kontejnerëve, le të përpiqemi të flasim për problemet biznesore që zgjidhin CoreOS dhe CRI-O, në shembullin e . Në vitin 1803, Mark Brunel u përball me sfidën për të prodhuar 100 mijë bllokime rigging për nevojat e flotës detare në rritje të Britanisë. Blloku i rigging është një lloj pajisjeje që përdoret për të lidhur litarët me velat. Deri në fillim të shekullit të 19-të, këto bllokime prodhoheshin me dorë, por Brunel arriti të automatizonte prodhimin dhe të fillonte prodhimin e bllokimeve të standardizuara me ndihmën e makinerive. Automatizimi i këtij procesi do të thoshte që të gjitha bllokimet përfunduan pothuajse të njëjta, mund të zëvendësoheshin lehtësisht në rast dështimi dhe mund të prodhoheshin në sasi të mëdha.
Tani imagjinoni se Brunel do t'i duhej tĂ« bĂ«nte kĂ«tĂ« punĂ« pĂ«r 20 modele tĂ« ndryshme anijesh (versionet e Kubernetes) dhe pĂ«r pesĂ« planete tĂ« ndryshme me rrjedha dhe erĂ«ra detare krejtĂ«sisht tĂ« ndryshme (ofruesit e cloud). PĂ«r mĂ« tepĂ«r, kĂ«rkohej qĂ« tĂ« gjitha anijet (klasterĂ«t OpenShift), pavarĂ«sisht nga planetet mbi tĂ« cilat po navigohej, nĂ« sytĂ« e kapitanĂ«ve (operatorĂ«ve qĂ« menaxhojnĂ« funksionimin e klasterĂ«ve) tĂ« silleshin tĂ« njĂ«jtĂ«. Duke vazhduar analogjinĂ« detare, kapitanĂ«ve tĂ« anijeve nuk u intereson aspak se cilat bllokime rigging (CRI-O) pĂ«rdoren nĂ« anijet e tyre â e rĂ«ndĂ«sishme pĂ«r ta Ă«shtĂ« qĂ« kĂ«to bllokime tĂ« jenĂ« tĂ« forta dhe tĂ« besueshme.
Para OpenShift 4, si një platformë cloud, qëndron një detyrë shumë e ngjashme biznesi. Njësi të reja duhet të krijohen në momentin e krijimit të klasterit, në rast dështimi të njërit prej nyjave, ose gjatë shkallëzimit të klasterit. Gjatë krijimit dhe inicializimit të një nyje të re, komponentët kritikë të hostit, përfshirë CRI-O, duhet të konfigurohen në përputhje me nevojat. Ashtu si në çdo prodhim tjetër, në fillim duhet të ofrosh "lëndën e parë". Në rastin e anijeve, lënda e parë përbëhet nga metal dhe dru. Megjithatë, në rastin e krijimit të një hosti për vendosjen e konteinerëve në klasterin OpenShift 4, në hyrje duhet të kemi skedarë konfigurimi dhe shërbime API të ofruara. Pas kësaj, OpenShift do të sigurojë nivelin e duhur të automatizimit gjatë gjithë ciklit të jetës, duke ofruar mbështetje produkti të nevojshme për përdoruesit e fundit dhe përfitimin nga investimet në platformë.
OpenShift 4 u krijua në mënyrë që të sigurojë mundësinë për të përditësuar sistemin në mënyrë të lehtë gjatë gjithë ciklit të jetës së platformës (për versionet 4.X) për të gjithë ofruesit kryesorë të cloud computing, platformave të virtualizimit dhe madje sistemëve bare metal. Për këtë, nyjat duhet të krijohen mbi baza të elementeve të ndërrueshëm. Kur klasteri kërkon një version të ri të Kubernetes, ai gjithashtu merr versionin përkatës të CRI-O në CoreOS. Duke qenë se versioni i CRI-O është i lidhur drejtpërdrejt me Kubernetes, e gjithë kjo e thjeshton ndjeshëm çdo lëvizje me qëllim testimi, zgjidhjeje problematikash ose mbështetje. Për më tepër, ky qasje ndihmon në uljen e kostove për përdoruesit e fundit dhe Red Hat.
Ky Ă«shtĂ« njĂ« qĂ«ndrim krejtĂ«sisht i ri ndaj klasterĂ«ve Kubernetes, qĂ« ngre bazat pĂ«r planifikimin e veçorive shumĂ« tĂ« dobishme dhe tĂ«rheqĂ«se. CRI-O (projekti i hapur i Container Runtime Interface â Open Container Initiative, e njohur shkurt CRI-OCI) ka rezultuar si zgjedhja mĂ« e mirĂ« pĂ«r krijimin masiv tĂ« nyjave, e nevojshme pĂ«r funksionimin me OpenShift. CRI-O do tĂ« zĂ«vendĂ«sojĂ« motorin Docker tĂ« pĂ«rdorur mĂ« parĂ«, duke ofruar pĂ«rdoruesve tĂ« OpenShift â po, nuk jeni duke dĂ«gjuar gabim â njĂ« motor konteinerĂ«sh i mĂ«rzitshĂ«m, i krijuar posaçërisht pĂ«r tĂ« punuar me Kubernetes.
Bota e konteinerëve të hapur
Bota ka një kohë të gjatë që bota po lëviz në drejtim të kontejnerëve të hapur. Sidoqoftë, në Kubernetes, ose në nivele më të ulëta, ka çuar në krijimin e një ekosistemi inovacionesh në çdo nivel.
Të gjitha filluan me krijimin e iniciativës Open Containers Initiative Në këtë fazë të hershme, u formuan specifikimet për dhe Kjo garantoi që mjetet mund të përdorin një standard të vetëm dhe një format të vetëm për të punuar me to. Më vonë u shkruan specifikimet çka lehtësoi përdoruesit për të ndarë .
Pastaj, komuniteti i Kubernetes zhvilloi një standard të vetëm të ndërfaqes së bashkëngjitur (pluggable interface), të quajtur Falë kësaj, përdoruesit e Kubernetes mund të lidhin motorë të ndryshëm për të punuar me kontejnerët përveç Docker-it.
Inxhinierët e Red Hat dhe Google panë nevojën në treg për një motor kontejneri që mund të pranojë kërkesat nga Kubelet përmes protokollit CRI dhe paraqitën kontejnerë që ishin të përshtatshëm me specifikimet e përmendura më sipër të OCI. Kështu Por, ndaloni, ne thamë se ky material do të jetë për CRI-O? Në të vërtetë, kështu është, thjesht me lëshimin projekti u ribemë CRI-O.
Fig. 1.
Inovacionet me CRI-O dhe CoreOS
Me lançimin e platformës OpenShift 4, u ndryshua , që përdorej si standard në platformë, dhe në vend të Docker erdhi CRI-O, duke ofruar një ambient ekonomik, stabil, të thjeshtë dhe të qetë për ekzekutimin e kontejnerëve që zhvillohet paralelisht me Kubernetes. Kjo e bën të thjeshtë mbështetje dhe konfigurimin e grumbullit. Konfigurimi i motorit të kontejnerëve dhe hostit, si dhe menaxhimi i tyre bëhet automatik në kuadër të OpenShift 4.
Ndaloni, si është kjo?
Pikërisht kështu, me daljen e OpenShift 4, tani nuk ka nevojë të lidheni me hoste të veçantë dhe të instaloni motorin e kontejnerëve, të konfiguroni magazinën, të konfiguroni serverët për kërkimin ose të konfiguroni rrjetin. Platforma OpenShift 4 është rishikuar plotësisht për të përdorur jo jo nga pikëpamja e aplikacioneve të përdoruesve të fundit, por edhe nga pikëpamja 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ë ua ka mundësuar përdoruesve të menaxhojnë aplikacionet duke përcaktuar gjendjen e dëshiruar dhe duke përdorur , për të siguruar që gjendja reale të jetë sa më e afërt me gjendjen e përcaktuar. Ky hap mundësi të mëdha si për zhvillimin ashtu edhe për operacionet. Zhvilluesit mund të përcaktojnë gjendjen e kërkuar, operatorit në formën e një dosjeje YAML ose JSON, dhe pastaj operatori mund të krijojë në mjedisin operativ ekzemplar të nevojshëm të aplikacionit, duke garantuar që gjendja operuese e këtij ekzemplar do të përputhet plotësisht me atë të përcaktuar.
Duke përdorur operatorët (Operators) në platformë, OpenShift 4 sjell këtë paradigëm të re (përmes konceptit të gjendjes së përcaktuar dhe gjendjes reale) 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 ashtuquajturit . MCO e thjeshton ndjeshëm punën e administratorit të klashtër, duke automatizuar thelbësisht fazat e fundit të instalimit, si dhe operacionet e mëpasme pas instalimit (ditët e dyta). Të gjitha këto e bëjnë OpenShift 4 një platformë të vërtetë cloud. Ne do të ndalojmë te kjo pak më vonë.
Fillimi i kontejnerëve
Përdoruesit patën mundësinë të përdornin motorin CRI-O në platformën OpenShift që nga versioni 3.7 në statusin e Tech Preview dhe që nga versioni 3.9 në statusin e Generally Available (tani i mbështetur). Përveç kësaj, Red Hat e përdor gjerësisht në OpenShift Online që nga versioni 3.10. Të gjitha këto i dhanë ekipit që punon me CRI-O një përvojë të madhe në nisjen masive të kontejnerëve në klasterë të mëdhenj Kubernetes. Për të marrë disa ide bazë se si Kubernetes përdor CRI-O, le të shikojmë ilustimin e mëposhtëm, që tregon parimin e funksionimit të arkitekturës.
Fig. 2. Si punojnë kontejnerët në një klaster Kubernetes
CRI-O thjeshton krijimin e hosteve të rinj të konteinerëve përmes sinkronizimit të gjithë nivelit të lartë gjatë inicializimit të nodave të rinj dhe gjatë lëshimit të versioneve të reja të platformës OpenShift. Rishikimi i gjithë platformës si një e tërë lejon që të kryhen azhurnime / rikthime transaksionale dhe parandalon bllokimet reciproke në varësi midis bërthamës së hosteve të konteinerëve, motorit të konteinerëve, nodave (Kubelets) dhe nodës kryesore të Kubernetes Master. Me menaxhimin qendror të të gjithë komponenteve të platformës, duke kontrolluar dhe menaxhuar versionet, mund të ndiqet gjithmonë një rrugë e qartë nga gjendja A në gjendjen B. Kjo lejon thjeshtimin e procesit të azhurnimeve, rrit sigurinë, përmirëson raportimin e performancës dhe ndihmon në uljen e kostove për azhurnimet dhe instalimin e versioneve të reja.
Demonstrare e fuqisë së komponentëve të ndërveprueshëm
Siç u përmend më parë, përdorimi i Machine Config Operator për menaxhimin e hostit të konteinerëve dhe motorit të konteinerë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, do të tregojmë se si mund të bënit ndryshime në skedarin crio.conf. Për të mos u ngatërruar në terminologji, përpiquni të përqendroheni në rezultate.
SĂ« pari, le tĂ« krijojmĂ« atĂ« qĂ« quhet konfigurimi i mjedisit tĂ« ekzekutimit tĂ« konteinerit â Container Runtime Config. Mendojeni kĂ«tĂ« si njĂ« burim Kubernetes, i cili pĂ«rfaqĂ«son konfigurimin pĂ«r CRI-O. NĂ« fakt, kjo Ă«shtĂ« njĂ« version i specializuar i asaj qĂ« quhet MachineConfig, e cila pĂ«rfaqĂ«son çdo konfigurim tĂ« shpĂ«rndarĂ« nĂ« makinĂ«n RHEL CoreOS brenda kornizĂ«s sĂ« klasterit OpenShift.
Ky burim i personalizuar, i quajtur ContainerRuntimeConfig, u krijua për të lehtësuar për administratorët e klasterit konfigurimin e CRI-O. Ky është një mjet mjaft i fuqishëm, saqë mund të aplikohet vetëm në disa nodë varësisht nga ndihmesat e MachineConfigPool. Përdoreni këtë si një grup makinash që shërbejnë për të njëjtin qëllim.
Vini re dy rreshtat e fundit, të cilat ne do të ndryshojmë në skedarin /etc/crio/crio.conf. Këto dy rreshta janë shumë të ngjashëm me rreshtat në skedarin crio.conf, këto janë:
vi ContainerRuntimeConfig.yaml
PĂ«rfundimi:
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 mund ta dërgojmë këtë skedar në grupin Kubernetes dhe të verifikojmë se ai është në të vërtetë krijuar. Vini re se puna zhvillohet pikërisht ashtu si me çdo burim tjetër të Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
PĂ«rfundimi:
EMRI MOSHA
set-log-and-pid 22h
Pasi krijuam ContainerRuntimeConfig, duhet të ndryshojmë një nga MachineConfigPools, për t'i bërë të ditur Kubernetes-it se duam ta aplikojmë këtë konfigurim për një grup të caktuar makinash në grup. Në këtë rast, do të ndryshojmë MachineConfigPool për nodet kryesor:
oc edit MachineConfigPool/master
Output (për qartësi është lënë thelbi i situatës):
...
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ë skedar të ri crio.conf për grupin. Gjithashtu, skedari përfundimtar i konfigurimit mund të shikohet përmes API-së Kubernetes. Mbani mend, ContainerRuntimeConfig është thjesht një version i specializuar i MachineConfig, prandaj mund ta shohim rezultatin duke e shikuar rreshtat e nevojshëm në MachineConfigs:
oc get MachineConfigs | grep rendered
PĂ«rfundimi:
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 kryesor doli të jetë një version më i ri se konfigurimet fillestare. Për ta parë, ekzekutoni komandën e mëposhtme. Dhe të theksojmë se ndoshta ky është një nga skriptet më të mira të një rreshti 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
PĂ«rfundimi:
pids_limit = 2048
Tani le të sigurohemi se konfigurimi është aplikuar në të gjitha nodet kryesor. Së pari, le të marrë listën e nodëve në grup:
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
Tani le të shohim skedarin e instaluar. Ju do të shihni se skedari është përditësuar me vlerat e reja të drejtorive pid dhe debug që kemi specifikuar në burimin ContainerRuntimeConfig. Eleganca vetë:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal â cat /host/etc/crio/crio.conf | egrep 'debug||pidâ
PĂ«rfundimi:
...
pids_limit = 2048
...
log_level = "debug"
...
Të gjitha këto ndryshime në klaster janë bërë pa nisur SSH. Të gjitha punët janë kryer duke iu drejtuar master-nodit të Kuberentes. Kjo do të thotë se këto parametra të rinj janë konfiguruar vetëm në master-nodet. Nodet punuese nuk janë ndryshuar, çka tregon përfitimet e metodologjisë Kubernetes me përdorimin e stanjave të caktuara dhe të aktualizuara lidhur me hostet e konteinerëve dhe motorët e konteinerëve me elementë të ndërrueshëm.
Shembulli i mĂ«sipĂ«rm tregon mundĂ«sinĂ« e bĂ«rjes sĂ« ndryshimeve nĂ« njĂ« klaster tĂ« vogĂ«l OpenShift Container Platform 4 me tre nodet punuese ose nĂ« njĂ« klaster tĂ« madh prodhimi me 3000 nodet. NĂ« çdo rast, volumi i punĂ«s do tĂ« jetĂ« i njĂ«jtĂ« â dhe shumĂ« i vogĂ«l â mjafton tĂ« konfiguroni skedarin ContainerRuntimeConfig dhe tĂ« ndryshoni njĂ« etiketĂ« (label) nĂ« MachineConfigPool. Dhe ju mund ta bĂ«ni kĂ«tĂ« me çdo version tĂ« platformĂ«s Kubernetes OpenShift Container Platform 4.X gjatĂ« tĂ«rĂ« ciklit tĂ« saj tĂ« jetĂ«s.
Shpesh herë kompanitë teknologjike zhvillohen kaq shpejt saqë ne nuk jemi në gjendje të shpjegojmë pse zgjedhim teknologji të caktuara për komponentët bazë. Motorët e konteinerëve historikisht kanë qenë komponenti me të cilin përdoruesit interaktojnë drejtpërdrejt. Duke qenë se popullariteti i konteinerëve natyrisht ka filluar me shfaqjen e motorëve të konteinerëve, përdoruesit shpesh shfaqin interes për ta. Kjo është edhe një arsye tjetër pse Red Hat zgjodhi CRI-O. Konteinerët po evoluojnë, dhe sot vëmendja kryesore është për orkestrimin, dhe ne arritëm në përfundimin se CRI-O ofron përvojën më të mirë kur punohet me OpenShift 4.
Burimi: habr.com
