Platformë ju lejon të thjeshtoni krijimin , duke përfshirë infrastrukturën e ofruesve të shërbimeve cloud, në platformat e virtualizimit ose në sistemet metalike të zhveshur. Për të krijuar një platformë të vërtetë të bazuar në cloud, na u desh të merrnim kontroll të rreptë të të gjithë elementëve të përdorur dhe kështu të rrisnim besueshmërinë e një procesi kompleks automatizimi.
Zgjidhja e dukshme ishte përdorimi i Red Hat Enterprise Linux CoreOS (një variant i Red Hat Enterprise Linux) dhe CRI-O si standard, dhe ja pse...
Meqenëse tema e lundrimit është një temë shumë e mirë për të gjetur analogji kur shpjegoni punën e Kubernetes dhe kontejnerëve, le të përpiqemi të flasim për problemet e biznesit që zgjidhin CoreOS dhe CRI-O, duke përdorur një shembull . Në 1803, Marc Brunel u ngarkua me prodhimin e 100 blloqeve të manipulimit për nevojat e marinës britanike në rritje. Një bllok manipulimi është një lloj manipulimi që përdoret për të lidhur litarë me vela. Deri në fillim të shekullit të 19-të, këto blloqe bëheshin me dorë, por Brunel arriti të automatizojë prodhimin dhe filloi të prodhojë blloqe të standardizuara duke përdorur vegla makinerie. Automatizimi i këtij procesi nënkuptonte që blloqet që rezultonin ishin në thelb identike, mund të zëvendësoheshin lehtësisht nëse thyheshin dhe mund të prodhoheshin në sasi të mëdha.
Tani imagjinoni nëse Brunel duhet ta bënte këtë punë për 20 modele të ndryshme anijesh (versionet Kubernetes) dhe për pesë planetë të ndryshëm me rryma detare dhe erëra krejtësisht të ndryshme (ofruesit e reve). Për më tepër, kërkohej që të gjitha anijet (grupet OpenShift), pavarësisht nga planetët në të cilët kryhet lundrimi, nga pikëpamja e kapitenëve (operatorët që menaxhojnë funksionimin e grupimeve) të silleshin njësoj. Për të vazhduar analogjinë detare, kapitenëve të anijeve nuk u intereson fare se çfarë lloj blloqe manipulimi (CRI-O) përdoren në anijet e tyre - gjëja kryesore për ta është që këto blloqe të jenë të forta dhe të besueshme.
OpenShift 4, si një platformë cloud, përballet me një sfidë shumë të ngjashme biznesi. Nyjet e reja duhet të krijohen në momentin e krijimit të grupimit, në rast të një dështimi në një nga nyjet, ose gjatë shkallëzimit të grupimit. Kur krijohet dhe inicializohet një nyje e re, përbërësit kryesorë të hostit, duke përfshirë CRI-O, duhet të konfigurohen në përputhje me rrethanat. Si në çdo prodhim tjetër, “lëndët e para” duhet të furnizohen në fillim. Në rastin e anijeve, lëndët e para janë metali dhe druri. Sidoqoftë, në rastin e krijimit të një hosti për vendosjen e kontejnerëve në një grupim OpenShift 4, duhet të keni skedarë konfigurimi dhe serverë të ofruar nga API si hyrje. OpenShift do të sigurojë më pas nivelin e kërkuar të automatizimit gjatë gjithë ciklit jetësor, duke ofruar mbështetjen e nevojshme të produktit për përdoruesit fundorë dhe duke rikuperuar kështu investimin në platformë.
OpenShift 4 u krijua në mënyrë të tillë që të ofrojë mundësinë e përditësimit të përshtatshëm të sistemit gjatë gjithë ciklit jetësor të platformës (për versionet 4.X) për të gjithë ofruesit kryesorë të informatikës cloud, platformat e virtualizimit dhe madje edhe sistemet metalike të zhveshura. Për ta bërë këtë, nyjet duhet të krijohen në bazë të elementeve të këmbyeshëm. Kur një grup kërkon një version të ri të Kubernetes, ai gjithashtu merr versionin përkatës të CRI-O në CoreOS. Meqenëse versioni CRI-O është i lidhur drejtpërdrejt me Kubernetes, kjo thjeshton shumë çdo ndryshim për qëllime testimi, zgjidhjeje të problemeve ose mbështetje. Përveç kësaj, kjo qasje redukton kostot për përdoruesit përfundimtarë dhe Red Hat.
Kjo është një mënyrë thelbësisht e re e të menduarit për grupimet Kubernetes dhe hedh themelet për planifikimin e disa veçorive të reja shumë të dobishme dhe bindëse. CRI-O (Container Runtime Interface - Open Container Initiative, shkurtuar CRI-OCI) doli të jetë zgjidhja më e suksesshme për krijimin masiv të nyjeve që është e nevojshme për të punuar me OpenShift. CRI-O do të zëvendësojë motorin Docker të përdorur më parë, duke u ofruar përdoruesve të OpenShift - po, keni dëgjuar mirë - një motor i mërzitshëm kontejnerësh i krijuar posaçërisht për të punuar me Kubernetes.
Bota e kontejnerëve të hapur
Bota ka kohë që po shkon drejt kontejnerëve të hapur. Qoftë në Kubernetes, qoftë në nivele më të ulëta, rezulton në një ekosistem inovacioni në çdo nivel.
Gjithçka filloi me krijimin e Iniciativës Open Containers . Në këtë fazë të hershme të punës, u formuan specifikimet e kontejnerëve и . Kjo siguroi që mjetet të mund të përdornin një standard të vetëm dhe një format të unifikuar për të punuar me ta. Specifikimet u shtuan më vonë , duke i lejuar përdoruesit të ndajnë lehtësisht .
Komuniteti Kubernetes më pas zhvilloi një standard të vetëm për një ndërfaqe të mbyllshme, të quajtur . Falë kësaj, përdoruesit e Kubernetes ishin në gjendje të lidhnin motorë të ndryshëm për të punuar me kontejnerë përveç Docker.
Inxhinierët në Red Hat dhe Google panë një nevojë të tregut për një motor kontejneri që mund të pranonte kërkesat Kubelet mbi protokollin CRI dhe prezantuan kontejnerë që ishin në përputhje me specifikimet OCI të përmendura më sipër. Kështu që . Por më falni, a nuk thamë që ky material do t'i kushtohej CRI-O? Në fakt është, vetëm me lirimin projekti u riemërua CRI-O.
Fik. 1
Inovacion me CRI-O dhe CoreOS
Me lëshimin e platformës OpenShift 4, ajo u ndryshua , i përdorur si parazgjedhje në platformë dhe Docker u zëvendësua nga CRI-O, duke ofruar një mjedis me kosto efektive, të qëndrueshëm, të thjeshtë dhe të mërzitshëm për drejtimin e një kontejneri që zhvillohet paralelisht me Kubernetes. Kjo thjeshton shumë mbështetjen dhe konfigurimin e grupeve. Konfigurimi i motorit të kontejnerit dhe hostit, si dhe menaxhimi i tyre, bëhet i automatizuar brenda OpenShift 4.
Prit, si është kjo?
Kjo është e drejtë, me ardhjen e OpenShift 4, nuk ka më nevojë për t'u lidhur me hostet individualë dhe për të instaluar një motor kontejneri, konfigurim të ruajtjes, konfigurimin e serverëve të kërkimit ose konfigurimin e një rrjeti. Platforma OpenShift 4 është ridizajnuar plotësisht për të përdorur jo vetëm për sa i përket aplikacioneve të përdoruesit fundor, por edhe për sa i përket operacioneve bazë të nivelit të platformës, si vendosja e imazheve, konfigurimi i sistemit ose instalimi i përditësimeve.
Kubernetes ka lejuar gjithmonë përdoruesit të menaxhojnë aplikacionet duke përcaktuar gjendjen e dëshiruar dhe duke përdorur , për të siguruar që gjendja aktuale të përputhet me gjendjen e synuar sa më afër që të jetë e mundur. Kjo hap mundësi të mëdha si nga perspektiva e zhvillimit ashtu edhe nga këndvështrimi i funksionimit. Zhvilluesit mund të përcaktojnë gjendjen e kërkuar nga te operatori në formën e një skedari YAML ose JSON, dhe më pas operatori mund të krijojë shembullin e kërkuar të aplikacionit në mjedisin e prodhimit, dhe gjendja e funksionimit të këtij shembulli do të korrespondojë plotësisht me atë të specifikuar.
Duke përdorur Operatorët në platformë, OpenShift 4 sjell këtë paradigmë të re (duke përdorur konceptin e grupit dhe gjendjes aktuale) në menaxhimin e RHEL CoreOS dhe CRI-O. Detyrat e konfigurimit dhe menaxhimit të versioneve të sistemit operativ dhe motorit të kontejnerit janë automatizuar duke përdorur të ashtuquajturat . MCO thjeshton shumë punën e administratorit të grupit, duke automatizuar në thelb fazat e fundit të instalimit, si dhe operacionet pasuese pas instalimit (operacionet e ditës së dytë). E gjithë kjo e bën OpenShift 4 një platformë të vërtetë cloud. Ne do të hyjmë në këtë pak më vonë.
Kontejnerët e rrjedhshëm
Përdoruesit kanë pasur mundësinë të përdorin motorin CRI-O në platformën OpenShift që nga versioni 3.7 në statusin Tech Preview dhe nga versioni 3.9 në statusin Generally Available (aktualisht i mbështetur). Përveç kësaj, Red Hat përdor masivisht në OpenShift Online që nga versioni 3.10. E gjithë kjo i lejoi ekipit që punonte në CRI-O të fitonte përvojë të gjerë në lëshimin masiv të kontejnerëve në grupime të mëdha Kubernetes. Për të kuptuar bazën se si Kubernetes përdor CRI-O, le të shohim ilustrimin e mëposhtëm, i cili tregon se si funksionon arkitektura.
Oriz. 2. Si funksionojnë kontejnerët në një grup Kubernetes
CRI-O thjeshton krijimin e hosteve të reja të kontejnerëve duke sinkronizuar të gjithë nivelin e lartë kur inicializon nyjet e reja dhe kur lëshon versione të reja të platformës OpenShift. Rishikimi i të gjithë platformës lejon përditësime/kthime të transaksioneve, dhe gjithashtu parandalon bllokimet në varësitë midis bërthamës së bishtit të kontejnerit, motorit të kontejnerit, nyjeve (Kubelets) dhe nyjes Master Kubernetes. Duke menaxhuar në mënyrë qendrore të gjithë komponentët e platformës, me kontroll dhe versionim, ka gjithmonë një rrugë të qartë nga gjendja A në gjendjen B. Kjo thjeshton procesin e përditësimit, përmirëson sigurinë, përmirëson raportimin e performancës dhe ndihmon në uljen e kostos së përditësimeve dhe instalimeve të versioneve të reja .
Demonstrimi i fuqisë së elementëve zëvendësues
Siç u përmend më herët, përdorimi i Operatorit të Konfigurimit të Makinerisë për të menaxhuar hostin e kontejnerit dhe motorin e kontejnerit në OpenShift 4 ofron një nivel të ri automatizimi që nuk ishte i mundur më parë në platformën Kubernetes. Për të demonstruar veçoritë e reja, ne do të tregojmë se si mund të bëni ndryshime në skedarin crio.conf. Për të mos u ngatërruar nga terminologjia, përpiquni të përqendroheni te rezultatet.
Së pari, le të krijojmë atë që quhet një konfigurim i kohës së funksionimit të kontejnerit - Konfigurimi i kohës së funksionimit të kontejnerit. Mendoni si një burim Kubernetes që përfaqëson konfigurimin për CRI-O. Në realitet, është një version i specializuar i diçkaje të quajtur MachineConfig, që është çdo konfigurim që vendoset në një makinë RHEL CoreOS si pjesë e një grupi OpenShift.
Ky burim i personalizuar, i quajtur ContainerRuntimeConfig, u krijua për ta bërë më të lehtë për administratorët e grupeve të konfigurojnë CRI-O. Ky mjet është mjaft i fuqishëm sa mund të aplikohet vetëm në nyje të caktuara në varësi të cilësimeve të MachineConfigPool. Mendoni si një grup makinerish që i shërbejnë të njëjtit qëllim.
Vini re dy rreshtat e fundit që do të ndryshojmë në skedarin /etc/crio/crio.conf. Këto dy rreshta janë shumë të ngjashme me rreshtat në skedarin crio.conf, ato janë:
vi ContainerRuntimeConfig.yaml
Përfundim:
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 le ta shtyjmë këtë skedar në grupin Kubernetes dhe të kontrollojmë nëse është krijuar në të vërtetë. Ju lutemi vini re se operacioni është saktësisht i njëjtë si me çdo burim tjetër Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Përfundim:
NAME AGE
set-log-and-pid 22h
Pasi të kemi krijuar ContainerRuntimeConfig, duhet të modifikojmë një nga MachineConfigPools për t'i sinjalizuar Kubernetes se duam ta zbatojmë këtë konfigurim në një grup specifik makinash në grup. Në këtë rast, ne do të ndryshojmë MachineConfigPool për nyjet kryesore:
oc edit MachineConfigPool/master
Përfundim (për qartësi, thelbi kryesor është lënë):
...
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ë pikë, MCO fillon të krijojë një skedar të ri crio.conf për grupin. Në këtë rast, skedari i konfigurimit i përfunduar plotësisht mund të shihet duke përdorur Kubernetes API. Mos harroni, ContainerRuntimeConfig është vetëm një version i specializuar i MachineConfig, kështu që ne mund ta shohim rezultatin duke parë linjat përkatëse në MachineConfigs:
oc get MachineConfigs | grep rendered
Përfundim:
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
Ju lutemi vini re se skedari i konfigurimit që rezulton për nyjet kryesore ishte një version më i ri se konfigurimet origjinale. Për ta parë atë, ekzekutoni komandën e mëposhtme. Në kalim, ne vërejmë se ky është ndoshta një nga më të mirët me një linjë 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ërfundim:
pids_limit = 2048
Tani le të sigurohemi që konfigurimi është aplikuar në të gjitha nyjet kryesore. Së pari marrim një listë të nyjeve 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. Do të shihni që skedari është përditësuar me vlerat e reja për direktivat pid dhe debug që kemi specifikuar në burimin ContainerRuntimeConfig. Vetë eleganca:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Përfundim:
...
pids_limit = 2048
...
log_level = "debug"
...
Të gjitha këto ndryshime në grup u bënë edhe pa ekzekutuar SSH. E gjithë puna u krye duke hyrë në nyjen master Kuberentes. Kjo do të thotë, këto parametra të rinj u konfiguruan vetëm në nyjet kryesore. Nyjet e punëtorëve nuk ndryshuan, gjë që tregon përfitimet e metodologjisë Kubernetes të përdorimit të gjendjeve të specifikuara dhe aktuale në lidhje me hostet e kontejnerëve dhe motorët e kontejnerëve me elementë të këmbyeshëm.
Shembulli i mësipërm tregon aftësinë për të bërë ndryshime në një grup të vogël OpenShift Container Platform 4 me tre nyje prodhimi ose një grup të madh prodhimi me 3000 nyje. Në çdo rast, sasia e punës do të jetë e njëjtë - dhe shumë e vogël - thjesht konfiguroni skedarin ContainerRuntimeConfig dhe ndryshoni një etiketë në MachineConfigPool. Dhe këtë mund ta bëni me çdo version të OpenShift Container Platform 4.X që përdor Kubernetes gjatë gjithë ciklit të tij jetësor.
Shpesh kompanitë e teknologjisë evoluojnë aq shpejt sa nuk jemi në gjendje të shpjegojmë pse zgjedhim disa teknologji për komponentët themelorë. Motorët e kontejnerëve kanë qenë historikisht komponenti me të cilin përdoruesit ndërveprojnë drejtpërdrejt. Meqenëse popullariteti i kontejnerëve filloi natyrshëm me ardhjen e motorëve të kontejnerëve, përdoruesit shpesh tregojnë interes për to. Kjo është një tjetër arsye pse Red Hat zgjodhi CRI-O. Kontejnerët po evoluojnë me fokus tani në orkestrimin dhe ne kemi zbuluar se CRI-O ofron përvojën më të mirë kur punoni me OpenShift 4.
Burimi: www.habr.com