Konteinereid – konveieril: CRI-O on nüüd OpenShift Container Platform 4-s vaikimisi

Platvorm Red Hat OpenShift Container Platform 4 on pööramine lihtsustamine majutuskohtade loomine konteinerite kasutamiseks, sealhulgas pilveteenuse pakkujate infrastruktuuris, virtualiseerimisplatvormidel või bare-metal süsteemides. Et luua tõeliselt pilvepõhine platvorm, pidime rangelt kontrollima kõiki kasutatavaid komponente, suurendades seeläbi keeruka automatiseerimisprotsessi usaldusväärsust.

Ilmselge lahendus oli kasutada standardina Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linuxi variant) ja CRI-O, ja see on põhjus…

Kuna mereteema sobib hästi analoogiate leidmiseks Kubernetes'i ja konteinerite töö selgitamiseks, proovime rääkida äriprobleemidest, mida CoreOS ja CRI-O lahendavad, tuues näiteks Bruneli leiutist takelauablokkide tootmiseks.. 1803. aastal esitati Mark Brunele ülesanne valmistada 100 000 takelžaari plokki, mis on vajalik Suurbritannia kasvava mereväe jaoks. Takelžaari plokk on seadmed, mida kasutatakse köite kinnitamiseks purjedesse. Kuni 19. sajandi alguseni valmistati neid plokke käsitööna, kuid Brunele suutis tootmise automatiseerida ja hakata valmistama standartiseeritud plokke masinate abil. Selle protsessi automatiseerimine tähendas, et kõik plokid olid peaaegu identsed, neid sai kergesti asendada, kui need purunesid, ja neid sai toota suures koguses.

Kujutage nüüd ette, et Brjunel peab seda tööd tegema 20 erineva laevamudeli (Kubernetesi versiooni) jaoks ja viie erineva planeedi puhul, millel on täiesti erinevad ookeanivoolud ja tuuled (pilveteenuse pakkujad). Samuti pidi kõik laevad (OpenShifti klastrid) käituma kaptenite (klastrite haldajate) silmis samamoodi sõltumata planeetidest, millel orienteeritakse. Jätkates mereteemat, ei ole kaptenitele oluline, milliseid takeliike (CRI-O) nende laevadel kasutatakse - oluline on, et need olema tugevad ja usaldusväärsed.

Enne OpenShift 4, mis on pilveplatvorm, seisab silmitsi sarnase äriülesandega. Uued nodid peavad looma klastrit luues, sõlme rikke korral või klastrit skaleerides. Uue sõlme loomisel ja algatamisel peavad olema õigesti konfigureeritud ka hosti kriitilised komponendid, sealhulgas CRI-O. Nagu igas tootmisprotsessis, tuleb kõigepealt esitada "toorained". Laevade puhul on tooraineteks metall ja puit. Kuid OpenShift 4 klastris konteinerite kujundamiseks hosti loomisel on sisse vaja faile ja API-serverite konfiguratsioonifailid. Seejärel tagab OpenShift kogu elutsükli vältel vajaliku automatiseerimise taseme, pakkudes lõppkasutajatele vajalikku tootetoe ning tasuvates investeeringutesse platvormisse.

OpenShift 4 on loodud nii, et see võimaldab mugavat süsteemi värskendamist kogu platvormi elutsükli jooksul (versioonide 4.X) kõikide peamiste pilvearvutuse, virtualiseerimisplatvormide ja isegi bare metal süsteemide tarnijate jaoks. Selleks peavad sõlmed olema loodud vahetatavate elementide baasil. Kui klaster vajab uut Kubernetes'e versiooni, saab ta ka vastava CRI-O versiooni CoreOS-il. Kuna CRI-O versioon on otseselt seotud Kubernetes'ega, lihtsustab see oluliselt katsetamiseks, tõrkeotsinguks või toeks vajalike muudatuste tegemist. Lisaks võimaldab selline lähenemine vähendada lõppkasutajate ja Red Hati kulusid.

See on põhimõtteliselt uus lähenemine Kubernetes'e klastritele, mis loob aluse uute väga kasulike ja atraktiivsete funktsioonide kavandamiseks. CRI-O (Ava konteineri käituse liides – Open Container Initiative, lühendatult CRI-OCI) on osutunud parimaks valikuks massiliseks sõlmede loomiseks, mis on vajalik OpenShift'i jaoks. CRI-O asendab varasemalt kasutatud Docker'i mootorit, pakkudes OpenShift'i kasutajatele. majanduslik, stabiilne, lihtne ja igav – jah, te ei kuulnud valele – igav konteinerimootor, mis on loodud spetsiaalselt Kubernetes'e jaoks.

Ava konteinerite maailm

Maailm on juba pikka aega liikunud avatud konteinerite suunas. Olgu need Kubernetes'es või madalamal tasemel, konteineristandardite areng toob kaasa innovatsiooniekosüsteemi igas tasemes.

Kõik sai alguse Open Containers Initiative'i loomisest juunis 2015. Selle varajase töö etapis koostati konteineripildi ja käituse spetsifikatsioonid ja . See võimaldas tagada, et tööriistad saavad kasutada ühtset standarditkonteineripiltide jaoks. konteinerite kujundeid ja ühtne formaat nende tööks. Hiljem lisati spetsifikatsioonid distributsioonid (distribution), mis võimaldas kasutajatel hõlpsasti vahetada konteineripilte.

Seejärel töötas Kubernetes'i kogukond välja ühtse pluggable liidese, mille nimi oli Container Runtime Interface (CRI). Tänu sellele suudavad Kubernetes'i kasutajad lisada erinevaid mootoreid konteinerite töötlemiseks, sealhulgas Docker.

Red Hat'i ja Google'i insenerid nägid turul olemasolevat vajadust konteinerimootori järele, mis suudaks Kubelet'ilt CRI protokolli kaudu päringuid vastu võtta, ning esitasid konteinerid, mis olid kooskõlas ülalnimetatud OCI spetsifikatsioonidega. Nii ilmus OCID. Kuid oodake, me ütlesime, et see materjal on pühendatud CRI-O'le? Tegelikult on see tõsi, lihtsalt koos versiooni 1.0 tuli projektile uus nimi - CRI-O.

Joon. 1.

Innovatsioonid CRI-O ja CoreOS

Koos OpenShift 4 platvormi käivitamisega muudeti konteinerimootorit, mis on vaikimisi platvormis, ning Dockeri asemel tuli CRI-O, mis pakkus ökonoomset, stabiilset, lihtsat ja igavat konteinerite käitamise keskkonda, mis areneb koos Kubernetesega. See lihtsustab oluliselt klastrite hooldust ja seadistamist. Konteinerimootori ja hosti konfigureerimine ning haldamine muutub OpenShift 4 raames automatiseerituks.

Oota, kuidas nii?

Just nii, OpenShift 4 tulekuga pole enam vaja ühenduda eraldi hostidega ja installida konteinerimootorit, seadistada salvestusruumi, kohandada servereid otsinguks või seadistada võrku. OpenShift 4 platvorm on täielikult ümber kujundatud, et kasutada the Operator Framework mitte ainult lõppkasutajate rakenduste vaatenurgast, vaid ka platvormi tasandi põhitegevuste vaatenurgast, nagu piltide juurutamine, süsteemi seadistamine või värskenduste paigaldamine.

Kubernetes on alati võimaldanud kasutajatel hallata rakendusi, määratledes soovitud oleku ja kasutades kontrollerid (Controllers), et tagada, et tegelik olek vastab maksimaalselt määratud olekule. See lähenemine määratud oleku ja tegeliku oleku kasutamisega avab suuri võimalusi nii arenduse kui ka operatsioonide vaatepunktist. Arendajad saavad määratleda vajaliku oleku, edastada selle operaatorile YAML või JSON faili kujul ning seejärel saab operaator luua käituskeskkonnas vajaliku rakenduse instantsi, mille tööolek vastab täielikult määratud olekule.

Kasutades operaatorit (Operators) platvormil, toob OpenShift 4 selle uue paradigma (kasutades määratud ja tegeliku oleku kontseptsiooni) RHEL CoreOS ja CRI-O haldamisse. Operatsioonisüsteemi ja konteinerimootori konfiguratsiooni ja versioonihalduse ülesanded automatiseeritakse nn masinaklassi operaatori (Machine Config Operator, MCO) abil.. MCO lihtsustab oluliselt klastri administraatori töökoormat, automatiseerides sisuliselt viimased etapid paigaldamisest ja sellele järgnevate (teise päeva) toimingute tegemise. See kõik muudab OpenShift 4 tõeliseks pilveplatvormiks. Peatume sellel hiljem.

Konteinerite käivitamine

Kasutajatel oli võimalik kasutada CRI-O mootorit OpenShift platvormil alates versioonist 3.7 tehnilise eelvaate (Tech Preview) staatuses ja versioonist 3.9 üldise kättesaadavuse (Generally Available) staatuses. Lisaks sellele kasutab Red Hat ulatuslikult CRI-O tootmiskoormuste käivitamiseks OpenShift Online alates versioonist 3.10. See kõik on andnud CRI-O meeskonnale suure kogemuse konteinerite massiliseks käivitamiseks suurtes Kubernetes klastrites. Et saada põhiteadmisi, kuidas Kubernetes kasutab CRI-O-d, vaatame järgmist joonist, mis näitab arhitektuuri tööpõhimõtet.

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

CRI-O lihtsustab uute konteinerihostide loomist, sünkroniseerides kogu ülemise taseme uute sõlmede käivitamisel ja OpenShift'i platvormi uute versioonide väljalaskmisel. Kogu platvormi läbivaatamine võimaldab teha tehingupõhiseid värskendusi / tagasipöördeid ning takistab tsüklilisi lukustusi konteinerisaba, konteinerimootori, sõlmede (Kubeletid) ja Kubernetes Master'i vahel. Kõikide platvormi komponentide tsentraliseeritud haldamisega, versioonide jälgimise ja juhtimisega on alati võimalik jälgida selget teed seisundist A seisundisse B. See lihtsustab värskendamise protsessi, suurendab turvalisust, parandab tulemuslikkuse arvestust ja aitab vähendada värskenduste ja uute versioonide paigaldamise kulusid.

Vahetatavate elementide jõudude demonstreerimine

Nagu eespool mainitud, pakub Machine Config Operator konteinerite hostimise ja konteineri mootori haldamiseks OpenShift 4-s uut automatiseerimise taset, mis ei olnud varem Kubernetes platvormil võimalik. Uute võimaluste demonstreerimiseks näitame, kuidas te võiks teha muudatusi failis crio.conf. Terminoloogiaga mitte segadusse sattuda, püüdke keskenduda tulemustele.

Esmalt loome selle, mida nimetatakse konteineri käituskeskkonna konfiguratsiooniks – Container Runtime Config. Peate seda pidama teatud tüüpi Kubernetes ressurssideks, mis esindab CRI-O konfiguratsiooni. Tegelikult on see spetsialiseeritud versioon sellest, mida kutsutakse MachineConfig'iks, mis esindab igasugust konfiguratsiooni, mis on rakendatud RHEL CoreOS masinasse OpenShift klastris.

See kohandatud ressurss, mida nimetatakse ContainerRuntimeConfig-iks, on loodud selleks, et lihtsustada klastrihaldurite jaoks CRI-O seadistamist. See on piisavalt võimas tööriist, et seda saab rakendada ainult teatud sõlmedele, sõltuvalt MachineConfigPooli seadistustest. Pange see grupp masinad, mis teenivad sama eesmärki.

Pöörake tähelepanu kahte viimasele reale, mida me kavatseme muuta failis /etc/crio/crio.conf. Need kaks rida on väga sarnased ridadele failis crio.conf, need on:

vi ContainerRuntimeConfig.yaml

Väljund:

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 saatke see fail Kubernetes klastrisse ja kontrollime, kas see tõepoolest on loodud. Pange tähele, et töö toimib täpselt nagu mis tahes muu Kubernetes ressurss:

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

Väljund:

NAME              AGE
set-log-and-pid   22h

Pärast ContainerRuntimeConfig'i loomist peame muutma ühte MachineConfigPools'i, et anda Kubernetes'ile teada, et soovime seda konfiguratsiooni rakendada teatud masinagruppidele klastris. Sel juhul muudame master-nööride MachineConfigPool'i:

oc edit MachineConfigPool/master

Väljund (selguse huvides on jäetud põhimõtteline sisu):

...
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 alustab MCO uue faili crio.conf loomist klastrile. Valmis konfiguratsioonifaili saab vaadata Kubernetes API vahendite abil. Pidage meeles, et ContainerRuntimeConfig on vaid spetsialiseeritud versioon MachineConfigist, seega saame tulemuse näha, vaadates õigeid ridu MachineConfigs'is:

oc get MachineConfigs | grep rendered

Väljund:

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 master-sõlmede jaoks osutus uuemaks versiooniks kui algsed konfiguratsioonid. Selle vaatamiseks käivitage järgmine käsk. Samuti märkime, et see võib olla üks parimaid üherealisi 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

Väljund:

pids_limit = 2048

Nüüd veendume, et konfiguratsioon on rakendatud kõikidele master-sõlmedele. Esiteks saame nimekirja klastris olevatest sõlmedest:

oc get node | grep master

Väljund:

ip-10-0-135-153.us-east-2.compute.internal   Valmis master 23h v1.12.4+509916ce1

ip-10-0-154-0.us-east-2.compute.internal     Valmis master 23h v1.12.4+509916ce1

ip-10-0-166-79.us-east-2.compute.internal    Valmis master 23h v1.12.4+509916ce1

Vaata nüüd installitud faili. Näete, et fail on värskendatud uute väärtustega, mida määrasime ContainerRuntimeConfig ressursis. Kõik on elegantselt tehtud:

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

Väljund:

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

Kõik need muudatused klastris tehti isegi SSH käivitamata. Kõik töö tehti Kuberentesi peaõlule pöördumise kaudu. See tähendab, et need uued parameetrid konfigureeriti ainult peaõludel. Töötlusõlmed jäid selle juures muutumatuks, mis tõestab Kubernetes'i metodoloogia eeliseid, kasutades määratletud ja tegelikke olekuteavet konteinerite ja konteinerimootorite asendatavate komponentide suhtes.

Ülaltoodud näide illustreerib, kuidas saab teha muudatusi väikese OpenShift Container Platform 4 klastriga, kus on kolm töösõlme, või tohutu tootmisklastriga, kus on 3000 sõlme. Igal juhul on töö maht sama – ja üsnagi väike – piisab ContainerRuntimeConfig faili seadistamisest ja ühe sildi (label) muutmisest MachineConfigPoolis. Saate seda teha koos kõigi Kubernetes OpenShift Container Platform 4.X versioonidega kogu nende elutsükli vältel.

Tihti, tehnoloogia ettevõtted arenevad nii kiiresti, et me ei suuda selgitada, miks valime teatud tehnoloogiad põhikomponentide jaoks. Konteinerimootorid on ajalooliselt olnud komponent, millega kasutajad otseselt suhtlevad. Kuna konteinerite populaarsus kasvas koos konteinerimootorite ilmumisega, tunnevad kasutajad nende vastu sageli huvi. See on veel üks põhjus, miks Red Hat valis CRI-O. Konteinerid arenevad, keskendudes täna peamiselt orkestreerimisele, ja oleme jõudnud järeldusele, et CRI-O pakub parimat kogemust OpenShift 4 kasutamisel.

Allikas: habr.com