Konteiner - tootmisliini peale: CRI-O on nüüd OpenShift Container Platform 4 vaikeseade

Platvorm Red Hat OpenShift Container Platform 4 võimaldab automatiseerida loomist hostide konteinerite juurutamiseks, sealhulgas pilveteenuse pakkujate infrastruktuuris, virtualiseerimisplatvormidel või bare-metal süsteemides. Et luua tõeliselt pilveplatvorm, pidime rangelt kontrollima kõiki kasutatavaid komponente, et tõsta keeruka automatiseerimisprotsessi usaldusväärsust.

Ilmselge lahendus oli võtta standardiks Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linuxi variant) ja CRI-O, ja siin on miks…

Kuna mereteema on üsna viljakas, et leida analoogiaid Kubernetes'e ja konteinerite töö selgitamiseks, proovime rääkida neist äriprobleemidest, mida CoreOS ja CRI-O lahendavad, näiteks Bruneli leiutis takelikku plokkide tootmiseks. 1803. aastal seisis Mark Bruneli ees ülesanne toota 100 tuhat takelikku plokki Suurbritannia kasvava merefloodi vajaduste jaoks. Takeliku plokk on põhivarustus, mida kasutatakse köite kinnitamiseks purjepurjedesse. Kuni 19. sajandi alguseni valmistati need plokid käsitsi, kuid Brunel suutis automatiseerida tootmisprotsessi ja hakata valmistama standardiseeritud plokke masinate abil. Selle protsessi automatiseerimine tähendas, et kõik plokid olid praktiliselt identsed, neid oli kerge asendada rikke korral ja neid oli võimalik tootmist suures mahus.

Ja nüüd kujutlege, et Brunel pidi seda tööd tegema 20 erineva laevamudeli (Kubernetes'i versiooni) jaoks ning viie erineva planeedi jaoks, millel olid täiesti erinevad mered ja tuuled (pilveteenuse pakkujad). Lisaks see, et kõik laevad (OpenShift'i klastrid), olenemata planeetidest, millel navigeeritakse, käituvad kaptenite (klastrite haldajate) vaates ühtemoodi. Mereteema jätkates, ei ole laevade kaptenitele absoluutselt oluline, milliseid takelikku plokke (CRI-O) nende laevadel kasutatakse – nende jaoks on peamine, et need plokid oleksid tugevad ja usaldusväärsed.

Enne OpenShift 4, kui pilveplatvorm, seisab silmitsi väga sarnase äriülesandega. Uued sõlmed peavad olema loodud klastrite loomise hetkel, sõlme rikke korral või klastrite laiendamisel. Uue sõlme loomisel ja algatamisel tuleb vastavalt konfigureerida ka hosti kriitilised komponendid, sealhulgas CRI-O. Nagu igas tootmisprotsessis, tuleb alguses esitada "tooraine". Laevade puhul on tooraineks metall ja puit. Siiski, kui luua host konteinerite juurutamiseks OpenShift 4 klastri sees, peab sissepool olema konfiguratsioonifailid ja pakutavad API serverid. Pärast seda tagab OpenShift kogu elutsükli jooksul vajaliku automatiseerimise, pakkudes lõppkasutajatele vajaliku tootetoetuse ja katab seega investeeringud platvormisse.

OpenShift 4 on loodud nii, et võimaldada süsteemi mugavat uuendamist kogu platvormi elutsükli vältel (versioonidele 4.X) kõigi peamiste pilvekompuuteri pakkujate, virtualiseerimisplatvormide ja isegi bare metal süsteemide jaoks. Selleks peavad sõlmed olema loodud asendatavatel komponentidel. Kui klaster vajab uut Kubernetes’i versiooni, saab see ka vastava CRI-O versiooni CoreOS-is. Kuna CRI-O versioon on otseselt seotud Kubernetes’ega, lihtsustab see oluliselt kõikide nihkeid testimise, tõrkeotsingu või toetuse eesmärgil. Lisaks võimaldab selline lähenemine vähendada lõppkasutajate ja Red Hati kulusid.

See on põhimõtteliselt uus lähenemine Kubernetes’ega klastrite loomisel, mis loob aluse uute väga kasulike ja ahvatlevate funktsioonide planeerimiseks. CRI-O (avatud konteinerite projekti Container Runtime Interface – Open Container Initiative, lühidalt CRI-OCI) osutus kõige õnnestunumaks valikuks massiliseks sõlmede loomiseks, mis on vajalik OpenShift’i jaoks. CRI-O asendab varem kasutatud Docker’i mootori, pakkudes OpenShift’i kasutajatele ökonoomse, stabiilse, lihtsa ja igava – jah, te ei kuulnud valesti – igava konteinerimootori, mis on loodud spetsiaalselt Kubernetes’ega töötamiseks.

Ava konteinerite maailm

Maailm on juba ammu liikunud avatud konteinerite suunas. Olgu need Kuberneteses või madalamal tasemel, konteineristandardite areng toob igasuguseid uuendusi igal tasemel.

Kõik algas Open Containers Initiative’i loomisega juunis 2015.Selle algusfaasis kujundati konteineri pildi (image) ja täitmisaja (runtime)spetsifikatsioonid. See võimaldas tagada, et tööriistad saavad kasutada ühtset standardit konteineri piltide ja ühtset formaati nende töötlemiseks. Hiljem lisati jaotamise (distribution)spetsifikatsioonid, mis võimaldasid kasutajatel mugavalt vahetada konteineripilte..

Seejärel töötas Kubernetes kogukond välja ühtse pluggable interface'i standardi, nimega Container Runtime Interface (CRI).Selle abil suudavad Kubernetes kasutajad liita erinevaid konteinerimootoreid, sealhulgas Dockerit.

Red Hati ja Google'i insenerid märkasid turul olevat vajadust konteinerimootori järele, mis saaks CRI protokolli kaudu Kubelet'i päringuid vastu võtta, ja esitlesid konteinerid, mis olid ülaltoodud OCI spetsifikatsioonidega ühilduvad. Nii sai OCID-ist.Aga oodake, me ütlesime, et see materjal käsitleb CRI-O-d? Tegelikult on see tõsi, lihtsalt versiooni 1.0 väljatulekuga projekt nimetati ümber CRI-O-ks. Joonis 1.

Uuendused CRI-O ja CoreOS-i jaoks.

OpenShift 4 platvormi käivitamisega muudeti

kasutatav konteinerimootor , mis on platvormi vaikimisi, ja Docker asendati CRI-O-ga, mis pakkus ökonoomset, stabiilset, lihtsat ja igavat konteinerite käitamise keskkonda, mis areneb koos Kubernetesega. See lihtsustab oluliselt klasteri haldust ja seadistamist. Konteinerimootori ja hosti seadistamine ning nende haldamine on OpenShift 4 raames automatiseeritud.Oota, kuidas see tõsi on?

Just nii, OpenShift 4 tulekuga pole enam vajalik eraldiseisvatesse hostidesse ühenduda ja konteinerimootor installida, salvestust seadistada, otsinguservereid seadistada ega võrku seadistada. OpenShift 4 platvorm on täielikult ümber kujundatud, et kasutada

Operator Framework. Operator Framework mitte ainult lõppkasutajate rakenduste vaatenurgast, vaid ka platvormi tasandi põhitoimingute, nagu piltide juurutamine, süsteemi seadistamine või värskenduste installimine, vaatenurgast.

Kubernetes on alati võimaldanud kasutajatel hallata rakendusi, määrates soovitud oleku ja kasutades kontrollereid (Controllers), et tagada, et tegelik olek vastaks võimalikult palju määratud olekule. See lähenemine määratud ja tegeliku oleku kasutamisega ava suured võimalused nii arenduse kui ka operatsioonide vaatenurgast. Arendajad saavad määrata nõutud oleku, edastada selle operaatorile YAML või JSON faili kujul ning seejärel saab operaator luua tootmiskeerises vajaliku rakenduse eksemplari, mille tööolek vastab täielikult määratletud olekule.

Kasutades platvormis operaatoreid (Operators), toob OpenShift 4 uue paradigma (kasutades määratud ja tegeliku oleku kontseptsiooni) RHEL CoreOS ja CRI-O haldamisse. Operatsioonisüsteemi ja konteinerimootori versioonide seadistamise ja haldamise ülesanded automatiseeritakse nn masina seadistamise operaatori (Machine Config Operator, MCO). MCO lihtsustab klastrihalduri tööd, automatiseerides põhimõtteliselt paigalduse viimased etapid ja ka sellele järgnenud toimingud (day two operations). Kõik see teeb OpenShift 4 tõeliseks pilveplatvormiks. Peatume sellel natuke hiljem.

Konteinerite käivitamine

Kasutajatel oli võimalik kasutada CRI-O mootorit OpenShiftis alates versioonist 3.7 tech preview'na ja versioonist 3.9 üldiselt saadaval (praegu toetatakse). Samuti kasutab Red Hat ulatuslikult CRI-O tootmislastete käivitamiseks OpenShift Online'is alates versioonist 3.10. See kõik on võimaldanud CRI-O arendustiimil saada tohutut kogemust konteinerite massiliseks käivitamiseks suurtes Kubernetes klastrites. Et saada põhiteadmisi, kuidas Kubernetes kasutab CRI-O-d, vaatame järgmist illustratsiooni, mis näitab arhitektuuri tööpõhimõtet.

Joon. 2. Kuidas konteinerid töötavad Kubernetes klastris

CRI-O lihtsustab uute konteinerite hostide loomist, sünkroniseerides kogu ülemise tasandi, kui algatatakse uusi nodusid ja uute OpenShift platvormi versioonide väljalaskmisel. Kogu platvormi revideerimine võimaldab teostada tehingulisi värskendusi / tagasivõtmisi ning takistab omavahelisi blokeeringuid sõltuvustes konteinerite hosti tuumade, konteerimismootori, nodude (Kubelets) ja Kubernetes Masteri vahel. Kõigi platvormi komponentide tsentraliseeritud haldamisega, versioonide jälgimise ning juhtimisega, on alati võimalik jälgida selget teed seisundist A seisundisse B. See lihtsustab värskenduste protsessi, suurendab turvalisust, parandab jõudluse aruandlust ning aitab vähendada värskenduste ja uute versioonide paigaldamise kulusid.

Vahetatavate komponentide jõu demonstreerimine

Nagu juba mainitud, tagab Machine Config Operator'i kasutamine konteinerite hostide ja konteerimismootori haldamiseks OpenShift 4-s uue automatiseerimise taseme, mis ei olnud varem platvormi Kubernetes puhul võimalik. Uute võimaluste demonstreerimiseks näitame, kuidas võiksite teha muudatusi failis crio.conf. Et mitte segadusse minna terminoloogiaga, proovige keskenduda tulemustele.

Esiteks loome midagi, mida nimetatakse konteineri käitamise konfiguratsiooniks – Container Runtime Config. Peate seda mõtlema kui Kubernetes ressurssi, mis esindab CRI-O konfiguratsiooni. Tegelikult on see spetsialiseeritud versioon sellest, mida nimetatakse MachineConfig'iks, mis esindab igasugust konfiguratsiooni, mis on rakendatud RHEL CoreOS masinasse OpenShift klastris.

See kohandatud ressurss, tuntud kui ContainerRuntimeConfig, on välja töötatud selleks, et hõlbustada klastrite administraatorite jaoks CRI-O seadistamist. See on piisavalt võimas tööriist, et seda saaks rakendada ainult teatud nodude suhtes sõltuvalt MachineConfigPooli seadistustest. Peate seda mõtlema kui masinate rühmana, mis teenib sama eesmärki.

Pange tähele kahte viimast rida, mida kavatseme muuta failis /etc/crio/crio.conf. Need kaks rida sarnanevad väga crio.conf failis olevate ridadega, need on:

vi ContainerRuntimeConfig.yaml

Kokkuvõte:

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üüd saadame selle faili Kubernetesi klastrisse ja kontrollime, kas see on tõeliselt loodud. Pange tähele, et töö toimub täpselt samamoodi nagu teiste Kubernetes'i ressurssidega:

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

Kokkuvõte:

NAME              AGE
set-log-and-pid   22h

Pärast ContainerRuntimeConfig'i loomist peame muutma üht MachineConfigPooli, et anda Kubernetes'ile teada, et soovime seda konfiguratsiooni rakendada teatud grupile masinatest klastris. Sel juhul muudame masina konfiguratsioonide poodi meister-sõlmedele:

oc edit MachineConfigPool/master

Väljund (selguse huvides on jäetud välja põhisisu):

...
metadata:
 creationTimestamp: 2019-04-10T23:42:28Z
 generation: 1
 labels:
   debug-crio: config-log-and-pid
   operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...

Sel hetkel hakkab MCO looma uut faili crio.conf klastrile. Sellega seoses saame täieliku konfiguratsioonifaili vaadata Kubernetes API vahendite kaudu. Pidage meeles, et ContainerRuntimeConfig on lihtsalt spetsialiseeritud versioon MachineConfig'ist, seega saame näha tulemust, vaadates MachineConfigs'i sobivaid ridu:

oc get MachineConfigs | grep rendered

Kokkuvõte:

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

Pange tähele, et saadud konfiguratsioonifail meister-sõlmedele osutus uuemaks versiooniks kui algsed konfiguratsioonid. Selle vaatamiseks käivitage järgmine käsk. Küll aga märkige, et see võib olla üks parimaid ühelarulisi skripte kogu Kubernetes'e ajaloos:

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

Kokkuvõte:

pids_limit = 2048

Nüüd veendume, et konfiguratsioon rakendati kõikidele meister-sõlmedele. Esiteks saame klastris sõlmede nimekirja:

oc get node | grep master

Väljund:

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üüd vaatame installitud faili. Näete, et fail on uuendatud vastavalt uutele pid ja debug direktiivide väärtustele, mille me määrasime ContainerRuntimeConfig ressurssis. Isegi elegants:

oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid‘

Kokkuvõte:

...
pids_limit = 2048
...
log_level = "debug"
...

Kõik need muudatused klastris tehti isegi ilma SSH käivitamiseta. Kogu töö tehti peatükiksite Kubernetes'i meistrisõlmele. See tähendab, et need uued parameetrid konfigureeriti ainult meistrisõlmedes. Töötlussõlmed ei muutunud, mis näitab Kubernetes'i metodoloogia eeliseid, kasutades määratud ja reaalseid seisundeid, mis on seotud konteinerite hostimise ja konteinerite mootorsõidukitega, millel on vahetatavad elemendid.

Ülaltoodud näide näitab, et muudatusi saab teha väikese OpenShift Container Platform 4 klastriga, kus on kolm töötlussõlme, või tohutu tootmisklastriga, kus on 3000 sõlme. Igal juhul on töö ulatus sama – see on üsna väike – piisab, kui seadistada ContainerRuntimeConfig fail ja muuta üks sild (label) MachineConfigPoolis. Ja seda saab teha mis tahes OpenShift Container Platform 4.X Kubernetes'i versiooniga kogu selle eluea jooksul.

Sageli arenevad tehnoloogiaettevõtted nii kiiresti, et me ei suuda selgitada, miks me valime teatud tehnoloogiaid oma põhikomponentide jaoks. Konteinerite mootorsõidukid on ajalooliselt olnud see komponent, millega kasutajad otseselt suhelda saavad. Kuna konteinerite populaarsus tekkis loomulikult koos konteinerite mootorsõidukite tõusmisega, näitavad kasutajad sageli nende vastu huvi. See on veel üks põhjus, miks Red Hat valis CRI-O. Konteinerid arenevad, samas on tänapäeval peamine tähelepanu koondunud orkestreerimisele ja oleme jõudnud järeldusele, et CRI-O pakub parimat kogemust OpenShift 4 kasutamisel.

Allikas: habr.com