Platvorm võimaldab loomist sujuvamaks muuta , sealhulgas pilveteenuste pakkujate infrastruktuuris, virtualiseerimisplatvormidel või paljasmetallisüsteemides. Tõeliselt pilvepõhise platvormi loomiseks pidime võtma range kontrolli kõigi kasutatavate elementide üle ja suurendama seeläbi keeruka automatiseerimisprotsessi töökindlust.
Ilmselge lahendus oli kasutada Red Hat Enterprise Linux CoreOS-i (Red Hat Enterprise Linuxi variant) ja CRI-O standardina ning siin on põhjus, miks...
Kuna purjetamise teema sobib väga hästi analoogide leidmiseks Kubernetese ja konteinerite töö selgitamisel, siis proovime näite varal rääkida äriprobleemidest, mida CoreOS ja CRI-O lahendavad. . 1803. aastal anti Marc Brunelile ülesandeks toota kasvava Briti mereväe vajadusteks 100 19 taglaseplokki. Taglaseplokk on taglase tüüp, mida kasutatakse purjede külge trosside kinnitamiseks. Kuni XNUMX. sajandi alguseni valmistati neid plokke käsitsi, kuid Brunel suutis tootmist automatiseerida ja hakkas tootma standardiseeritud plokke, kasutades tööpinke. Selle protsessi automatiseerimine tähendas, et saadud plokid olid sisuliselt identsed, purunemise korral kergesti asendatavad ja neid võis toota suurtes kogustes.
Kujutage nüüd ette, kui Brunel peaks seda tööd tegema 20 erineva laevamudeli (Kubernetes versioonid) ja viie erineva planeedi jaoks, millel on täiesti erinevad merehoovused ja tuuled (pilvepakkujad). Lisaks nõuti, et kõik laevad (OpenShift klastrid), olenemata planeetidest, millel navigeerimine toimub, käituvad kaptenite (klastrite tööd juhivad operaatorid) seisukohast ühtemoodi. Kui jätkata merenduslikku analoogiat, siis laevakaptenid ei hooli üldse sellest, missuguseid taglaseplokke (CRI-O) nende laevadel kasutatakse – nende jaoks on peamine, et need plokid oleksid tugevad ja töökindlad.
OpenShift 4 kui pilveplatvorm seisab silmitsi väga sarnase äriprobleemiga. Uued sõlmed tuleb luua klastri loomise ajal, mõne sõlme rikke korral või klastri skaleerimisel. Uue sõlme loomisel ja lähtestamisel tuleb kriitilised hostikomponendid, sealhulgas CRI-O, vastavalt konfigureerida. Nagu iga muu tootmise puhul, tuleb alguses tarnida “tooraine”. Laevade puhul on tooraineks metall ja puit. Kui aga loote hosti konteinerite juurutamiseks OpenShift 4 klastris, peavad teil olema sisendiks konfiguratsioonifailid ja API-ga serverid. OpenShift tagab seejärel vajalikul tasemel automatiseerituse kogu elutsükli jooksul, pakkudes lõppkasutajatele vajalikku tootetuge ja hüvitades seeläbi platvormi tehtud investeeringu.
OpenShift 4 loodi selliselt, et see võimaldaks süsteemi mugavalt uuendada kogu platvormi elutsükli jooksul (versioonidele 4.X) kõikidele suurematele pilvandmetöötluse pakkujatele, virtualiseerimisplatvormidele ja isegi paljasmetallisüsteemidele. Selleks tuleb luua sõlmed vahetatavate elementide baasil. Kui klaster nõuab Kubernetese uut versiooni, saab see ka CoreOS-is vastava CRI-O versiooni. Kuna CRI-O versioon on seotud otse Kubernetesiga, lihtsustab see oluliselt mis tahes permutatsioone testimise, tõrkeotsingu või tugieesmärkidel. Lisaks vähendab see lähenemine lõppkasutajate ja Red Hati kulusid.
See on põhimõtteliselt uus mõtteviis Kubernetese klastrite kohta ja paneb aluse mõne väga kasuliku ja mõjuva uue funktsiooni kavandamisele. CRI-O (Container Runtime Interface - Open Container Initiative, lühendatult CRI-OCI) osutus OpenShiftiga töötamiseks vajalike sõlmede massiliseks loomiseks kõige edukamaks valikuks. CRI-O asendab varem kasutatud Dockeri mootori, pakkudes OpenShifti kasutajatele – jah, kuulsite õigesti – igav konteinermootor, mis on loodud spetsiaalselt Kubernetesega töötamiseks.
Avatud konteinerite maailm
Maailm on juba pikka aega liikunud avatud konteinerite poole. Kas Kubernetesis või madalamal tasemel, tulemuseks on innovatsiooni ökosüsteem igal tasandil.
Kõik sai alguse Open Containers Initiative'i loomisest . Selles töö varases etapis koostati konteineri spetsifikatsioonid и . See tagas, et tööriistad said kasutada ühtset standardit ja ühtne formaat nendega töötamiseks. Spetsifikatsioonid lisati hiljem , mis võimaldab kasutajatel hõlpsasti jagada .
Seejärel töötas Kubernetese kogukond välja ühendatava liidese jaoks ühtse standardi, nn . Tänu sellele said Kubernetese kasutajad lisaks Dockerile ka konteineritega töötamiseks ühendada erinevaid mootoreid.
Red Hati ja Google'i insenerid nägid turul vajadust konteinermootori järele, mis suudaks Kubeleti taotlusi vastu võtta CRI protokolli kaudu, ja tutvustasid konteinereid, mis ühildusid ülalmainitud OCI spetsifikatsioonidega. Niisiis . Aga vabandust, kas me ei öelnud, et see materjal on pühendatud CRI-O-le? Tegelikult see on, just koos väljalaskmisega projekt sai nimeks CRI-O.
Joon. 1.
Innovatsioon CRI-O ja CoreOS-iga
OpenShift 4 platvormi käivitamisega seda muudeti , mida platvormis vaikimisi kasutatakse, ja Docker asendati CRI-O-ga, mis pakkus kuluefektiivset, stabiilset, lihtsat ja igavat keskkonda Kubernetesega paralleelselt areneva konteineri käitamiseks. See lihtsustab oluliselt klastri tuge ja konfigureerimist. Konteinermootori ja hosti konfigureerimine ning nende haldamine muutub OpenShift 4-s automatiseerituks.
Oot, kuidas see on?
See on õige, OpenShift 4 tulekuga pole enam vaja luua ühendust üksikute hostidega ja installida konteinermootorit, seadistada salvestusruumi, konfigureerida otsinguservereid ega konfigureerida võrku. OpenShift 4 platvorm on täielikult ümber kujundatud, et seda kasutada mitte ainult lõppkasutaja rakenduste, vaid ka platvormitaseme põhitoimingute osas, nagu piltide juurutamine, süsteemi konfigureerimine või värskenduste installimine.
Kubernetes on alati võimaldanud kasutajatel rakendusi hallata, määratledes soovitud oleku ja kasutades , tagamaks, et tegelik olek ühtiks võimalikult täpselt sihtolekuga. See avab suurepäraseid võimalusi nii arenduse kui ka tegutsemise vaatenurgast. Arendajad saavad vajaliku oleku määratleda operaatorile YAML- või JSON-faili kujul ja seejärel saab operaator luua tootmiskeskkonnas vajaliku rakenduse eksemplari ning selle eksemplari tööolek vastab täielikult määratletule.
Kasutades platvormis operaatoreid, toob OpenShift 4 selle uue paradigma (kasutades komplekti ja tegeliku oleku kontseptsiooni) RHEL CoreOS-i ja CRI-O haldamisse. Operatsioonisüsteemi ja konteinermootori versioonide seadistamise ja haldamise ülesanded automatiseeritakse nn . MCO lihtsustab oluliselt klastri administraatori tööd, automatiseerides sisuliselt nii viimased installietapid kui ka järgnevad installeerimisjärgsed toimingud (teise päeva toimingud). Kõik see teeb OpenShift 4-st tõelise pilveplatvormi. Me käsitleme seda veidi hiljem.
Jooksvad konteinerid
Kasutajatel on olnud võimalus kasutada CRI-O mootorit OpenShifti platvormil alates versioonist 3.7 tehnilise eelvaate olekus ja alates versioonist 3.9 olekus Üldkasutatav (praegu toetatud). Lisaks kasutab Red Hat massiliselt OpenShift Online'is alates versioonist 3.10. Kõik see võimaldas CRI-O kallal töötaval meeskonnal saada ulatuslikke kogemusi suurte Kubernetese klastrite konteinerite massilise käivitamise vallas. Põhiteadmiste saamiseks Kubernetesi CRI-O kasutamisest vaatame järgmist illustratsiooni, mis näitab, kuidas arhitektuur töötab.
Riis. 2. Kuidas konteinerid Kubernetese klastris töötavad
CRI-O lihtsustab uute konteineri hostide loomist, sünkroonides kogu tipptaseme uute sõlmede lähtestamisel ja OpenShifti platvormi uute versioonide väljastamisel. Kogu platvormi läbivaatamine võimaldab tehingute värskendamist / tagasipööramist ning hoiab ära ka ummikud konteineri saba tuuma, konteineri mootori, sõlmede (Kubelets) ja Kubernetes Masteri sõlme vahel. Kõiki platvormi komponente tsentraalselt hallates koos juhtimise ja versioonide loomisega, on alati selge tee olekust A olekusse B. See lihtsustab värskendusprotsessi, parandab turvalisust, parandab jõudluse aruandlust ning aitab vähendada värskenduste ja uute versioonide installimise kulusid. .
Asenduselementide võimsuse demonstreerimine
Nagu varem mainitud, pakub Machine Config Operatori kasutamine konteineri hosti ja konteinerimootori haldamiseks OpenShift 4-s uuel tasemel automatiseerimist, mis varem polnud Kubernetese platvormil võimalik. Uute funktsioonide demonstreerimiseks näitame, kuidas saate faili crio.conf muuta. Vältimaks terminoloogiaga segadust sattumist, proovige keskenduda tulemustele.
Esiteks loome nn konteineri käitusaja konfiguratsiooni – Container Runtime Config. Mõelge sellele kui Kubernetese ressursile, mis esindab CRI-O konfiguratsiooni. Tegelikkuses on see millegi MachineConfigi spetsialiseeritud versioon, mis on mis tahes konfiguratsioon, mis juurutatakse OpenShifti klastri osana RHEL CoreOS-i masinasse.
See kohandatud ressurss nimega ContainerRuntimeConfig loodi selleks, et hõlbustada klastri administraatoritel CRI-O konfigureerimist. See tööriist on piisavalt võimas, et seda saab rakendada ainult teatud sõlmedele, olenevalt MachineConfigPooli sätetest. Mõelge sellele kui masinate rühmale, mis teenivad sama eesmärki.
Pange tähele kahte viimast rida, mida me failis /etc/crio/crio.conf muudame. Need kaks rida on väga sarnased faili crio.conf ridadega, need on:
vi ContainerRuntimeConfig.yaml
Järeldus:
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 lükkame selle faili Kubernetese klastrisse ja kontrollime, kas see on tegelikult loodud. Pange tähele, et toiming on täpselt sama, mis kõigi teiste Kubernetese ressurssidega:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Järeldus:
NAME AGE
set-log-and-pid 22h
Kui oleme ContainerRuntimeConfigi loonud, peame muutma üht MachineConfigPoolsi, et anda Kubernetesile märku, et tahame seda konfiguratsiooni rakendada klastri konkreetsele masinarühmale. Sel juhul muudame peasõlmede jaoks MachineConfigPooli:
oc edit MachineConfigPool/master
Järeldus (selguse huvides jäetakse põhiolemus):
...
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 klastri jaoks looma uut faili crio.conf. Sel juhul saab täielikult valmis konfiguratsioonifaili vaadata Kubernetes API abil. Pidage meeles, et ContainerRuntimeConfig on lihtsalt MachineConfigi spetsiaalne versioon, nii et näeme tulemust, vaadates MachineConfigis vastavaid ridu:
oc get MachineConfigs | grep rendered
Järeldus:
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 põhisõlmede konfiguratsioonifail oli algsetest konfiguratsioonidest uuem versioon. Selle vaatamiseks käivitage järgmine käsk. Möödaminnes märgime, et see on võib-olla üks parimaid üherealisi Kubernetese 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
Järeldus:
pids_limit = 2048
Nüüd veendume, et konfiguratsioon on rakendatud kõikidele põhisõlmedele. Kõigepealt saame klastri sõlmede loendi:
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
Nüüd vaatame installitud faili. Näete, et faili on värskendatud ressursis ContainerRuntimeConfig määratletud pid- ja silumisdirektiivide uute väärtustega. Elegantsus ise:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Järeldus:
...
pids_limit = 2048
...
log_level = "debug"
...
Kõik need klastri muudatused tehti isegi SSH-d käivitamata. Kogu töö tehti Kuberentese põhisõlmele juurdepääsu kaudu. See tähendab, et need uued parameetrid konfigureeriti ainult põhisõlmedes. Töötajate sõlmed ei muutunud, mis näitab Kubernetese metoodika eeliseid määratud ja tegelike olekute kasutamisel seoses konteineri hostide ja vahetatavate elementidega konteinerimootoritega.
Ülaltoodud näide näitab võimalust teha muudatusi väikeses kolme tootmissõlmega OpenShift Container Platform 4 klastris või tohutus 3000 sõlmega tootmisklastris. Igal juhul on töömaht sama – ja väga väike –, konfigureerige lihtsalt fail ContainerRuntimeConfig ja muutke üks silt rakenduses MachineConfigPool. Ja saate seda teha OpenShift Container Platform 4.X mis tahes versiooniga, kus Kubernetes töötab kogu selle elutsükli jooksul.
Sageli arenevad tehnoloogiaettevõtted nii kiiresti, et me ei suuda selgitada, miks me valime aluseks olevate komponentide jaoks teatud tehnoloogiad. Konteinermootorid on ajalooliselt olnud komponent, millega kasutajad vahetult suhtlevad. Kuna konteinerite populaarsus sai loomulikult alguse konteinermootorite tulekust, näitavad kasutajad nende vastu sageli huvi. See on veel üks põhjus, miks Red Hat valis CRI-O. Konteinerid arenevad, keskendudes praegu orkestreerimisele, ja oleme leidnud, et CRI-O pakub OpenShift 4-ga töötamisel parimat kogemust.
Allikas: www.habr.com