Platforma leidžia supaprastinti kūrybą , įskaitant debesijos paslaugų teikėjų infrastruktūrą, virtualizacijos platformas ar be metalo sistemas. Norėdami sukurti tikrai debesimis pagrįstą platformą, turėjome griežtai kontroliuoti visus naudojamus elementus ir taip padidinti sudėtingo automatizavimo proceso patikimumą.
Akivaizdus sprendimas buvo naudoti Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux variantą) ir CRI-O kaip standartą, ir štai kodėl...
Kadangi buriavimo tema labai tinka ieškant analogijų aiškinant Kubernetes ir konteinerių darbą, pabandykime pakalbėti apie verslo problemas, kurias sprendžia CoreOS ir CRI-O, naudodamiesi pavyzdžiu. . 1803 m. Marcui Bruneliui buvo pavesta pagaminti 100 19 takelažo blokų augančio britų laivyno reikmėms. Takelažo blokas yra takelažas, naudojamas virvėms pritvirtinti prie burių. Iki pat XIX amžiaus pradžios šie blokeliai buvo gaminami rankomis, tačiau Brunel sugebėjo automatizuoti gamybą ir staklėmis pradėjo gaminti standartizuotus blokus. Šio proceso automatizavimas reiškė, kad gauti blokai iš esmės buvo identiški, juos buvo galima lengvai pakeisti, jei jie sulūžtų, ir gali būti gaminami dideliais kiekiais.
Dabar įsivaizduokite, jei Brunel turėtų atlikti šį darbą 20 skirtingų laivų modelių (Kubernetes versijos) ir penkių skirtingų planetų su visiškai skirtingomis jūros srovėmis ir vėjais (debesų tiekėjai). Be to, buvo reikalaujama, kad visi laivai (OpenShift klasteriai), nepriklausomai nuo planetų, kuriose vykdoma navigacija, kapitonų (operatorių, valdančių klasterių veiklą) požiūriu, elgtųsi vienodai. Tęsiant jūrinę analogiją, laivų kapitonams visiškai nesvarbu, kokie takelažo blokai (CRI-O) naudojami jų laivuose – jiems svarbiausia, kad šie blokai būtų tvirti ir patikimi.
„OpenShift 4“, kaip debesų platforma, susiduria su labai panašiu verslo iššūkiu. Nauji mazgai turi būti sukurti klasterio kūrimo metu, sugedus vienam iš mazgų arba keičiant klasterio mastelį. Kai sukuriamas ir inicijuojamas naujas mazgas, svarbūs pagrindinio kompiuterio komponentai, įskaitant CRI-O, turi būti atitinkamai sukonfigūruoti. Kaip ir bet kurioje kitoje gamyboje, „žaliavos“ turi būti tiekiamos pradžioje. Laivų atveju žaliavos yra metalas ir mediena. Tačiau jei sukuriate pagrindinį kompiuterį, skirtą konteineriams įdiegti „OpenShift 4“ klasteryje, kaip įvestį turite turėti konfigūracijos failus ir API teikiamus serverius. Tada „OpenShift“ užtikrins reikiamą automatizavimo lygį per visą gyvavimo ciklą, pasiūlys reikiamą produkto palaikymą galutiniams vartotojams ir taip susigrąžins investicijas į platformą.
OpenShift 4 buvo sukurtas taip, kad suteiktų galimybę patogiai atnaujinti sistemą per visą platformos gyvavimo ciklą (4.X versijoms) visiems pagrindiniams debesų kompiuterijos tiekėjams, virtualizacijos platformoms ir net pliko metalo sistemoms. Norėdami tai padaryti, mazgai turi būti sukurti keičiamų elementų pagrindu. Kai klasteriui reikalinga nauja Kubernetes versija, ji taip pat gauna atitinkamą CRI-O versiją CoreOS. Kadangi CRI-O versija yra tiesiogiai susieta su Kubernetes, tai labai supaprastina bet kokius testavimo, trikčių šalinimo ar palaikymo tikslus. Be to, šis metodas sumažina galutinių vartotojų ir „Red Hat“ išlaidas.
Tai iš esmės naujas mąstymo apie Kubernetes grupes būdas ir padeda planuoti kai kurias labai naudingas ir patrauklias naujas funkcijas. CRI-O (Container Runtime Interface - Open Container Initiative, sutrumpintai CRI-OCI) pasirodė esąs sėkmingiausias pasirinkimas masiniam mazgų, reikalingų darbui su OpenShift, kūrimu. CRI-O pakeis anksčiau naudotą „Docker“ variklį, siūlydamas „OpenShift“ vartotojams – Taip, teisingai išgirdote – nuobodus konteinerinis variklis, sukurtas specialiai darbui su Kubernetes.
Atvirų konteinerių pasaulis
Pasaulis jau seniai juda atvirų konteinerių link. Nesvarbu, ar Kubernetes, ar žemesniuose lygiuose, sukuria naujovių ekosistemą visais lygmenimis.
Viskas prasidėjo nuo Open Containers Initiative sukūrimo . Šiame ankstyvame darbo etape buvo suformuotos konteinerio specifikacijos и . Tai užtikrino, kad įrankiai galėtų naudoti vieną standartą ir vieningą darbo su jais formatą. Specifikacijos buvo pridėtos vėliau , todėl vartotojai gali lengvai bendrinti .
Tada Kubernetes bendruomenė sukūrė vieną standartą prijungiamai sąsajai, vadinamai . Dėl šios priežasties „Kubernetes“ vartotojai, be „Docker“, galėjo prijungti įvairius variklius, kad galėtų dirbti su konteineriais.
„Red Hat“ ir „Google“ inžinieriai pamatė, kad rinkai reikia konteinerio variklio, kuris galėtų priimti Kubelet užklausas per CRI protokolą, ir pristatė konteinerius, suderinamus su aukščiau paminėtomis OCI specifikacijomis. Taigi . Bet atleiskite, ar nesakėme, kad ši medžiaga bus skirta CRI-O? Tiesą sakant, tai tik su išleidimu projektas buvo pervadintas į CRI-O.
Pav. 1.
Naujovė su CRI-O ir CoreOS
Pradėjus naudoti „OpenShift 4“ platformą, ji buvo pakeista , platformoje naudojamas pagal numatytuosius nustatymus, o „Docker“ buvo pakeistas CRI-O, siūlančiu ekonomiškai efektyvią, stabilią, paprastą ir nuobodžią aplinką konteineriui, kuriamam lygiagrečiai su „Kubernetes“, paleisti. Tai labai supaprastina grupių palaikymą ir konfigūravimą. Konteinerio variklio ir pagrindinio kompiuterio konfigūravimas bei jų valdymas tampa automatizuoti naudojant „OpenShift 4“.
Palauk, kaip čia?
Tiesa, atsiradus „OpenShift 4“, nebereikia jungtis prie atskirų kompiuterių ir įdiegti konteinerio variklio, konfigūruoti saugyklą, konfigūruoti paieškos serverius ar konfigūruoti tinklą. „OpenShift 4“ platforma buvo visiškai pertvarkyta, kad būtų galima naudoti kalbant ne tik apie galutinio vartotojo programas, bet ir apie pagrindines platformos lygio operacijas, tokias kaip vaizdų diegimas, sistemos konfigūravimas ar naujinimų diegimas.
Kubernetes visada leido vartotojams valdyti programas apibrėžiant norimą būseną ir naudojant , kad tikroji būsena kuo labiau atitiktų tikslinę būseną. Tai atveria dideles galimybes tiek plėtros, tiek veiklos požiūriu. Kūrėjai gali apibrėžti reikiamą būseną operatoriui YAML arba JSON failo pavidalu, o tada operatorius gali sukurti reikiamą programos egzempliorių gamybinėje aplinkoje, o šio egzemplioriaus veikimo būsena visiškai atitiks nurodytą.
Platformoje naudojant operatorius, „OpenShift 4“ suteikia šią naują paradigmą (naudojant rinkinio ir faktinės būsenos sąvoką) RHEL CoreOS ir CRI-O valdymui. Operacinės sistemos ir konteinerio variklio versijų konfigūravimo ir valdymo užduotys automatizuojamos naudojant vadinamąjį . MCO labai supaprastina klasterio administratoriaus darbą, iš esmės automatizuodamas paskutinius diegimo etapus, taip pat vėlesnes operacijas po įdiegimo (antros dienos operacijos). Visa tai daro „OpenShift 4“ tikra debesų platforma. Į tai pakalbėsime šiek tiek vėliau.
Veikiantys konteineriai
Vartotojai turėjo galimybę naudoti CRI-O variklį „OpenShift“ platformoje nuo 3.7 versijos „Tech Preview“ būsenoje ir nuo 3.9 versijos – „Bendrai prieinama“ (šiuo metu palaikoma). Be to, „Red Hat“ masiškai naudoja „OpenShift Online“ nuo 3.10 versijos. Visa tai leido komandai, dirbančiai su CRI-O, įgyti didelę patirtį masiškai paleidžiant konteinerius dideliuose Kubernetes klasteriuose. Norėdami suprasti, kaip Kubernetes naudoja CRI-O, pažvelkime į šią iliustraciją, kurioje parodyta, kaip veikia architektūra.
Ryžiai. 2. Kaip konteineriai veikia Kubernetes klasteryje
CRI-O supaprastina naujų konteinerių prieglobų kūrimą sinchronizuodamas visą aukščiausią lygį inicijuojant naujus mazgus ir išleidžiant naujas OpenShift platformos versijas. Visos platformos peržiūra leidžia atnaujinti / grąžinti operacijas, taip pat apsaugo nuo priklausomybių tarp konteinerio uodegos šerdies, konteinerio variklio, mazgų (Kubelets) ir Kubernetes Master mazgo aklavietės. Centralizuotai valdant visus platformos komponentus, naudojant valdymą ir versijų nustatymą, visada yra aiškus kelias iš būsenos A į būseną B. Tai supaprastina atnaujinimo procesą, pagerina saugumą, pagerina našumo ataskaitas ir padeda sumažinti naujinimų ir naujų versijų diegimo išlaidas. .
Pakeičiamųjų elementų galios demonstravimas
Kaip minėta anksčiau, naudojant „Machine Config Operator“ konteinerio prieglobai ir konteinerio varikliui „OpenShift 4“ valdyti suteikiamas naujas automatizavimo lygis, kuris anksčiau nebuvo įmanomas „Kubernetes“ platformoje. Norėdami parodyti naujas funkcijas, parodysime, kaip galite pakeisti failą crio.conf. Kad nesusipainiotumėte dėl terminijos, pabandykite sutelkti dėmesį į rezultatus.
Pirmiausia sukurkime tai, kas vadinama konteinerio vykdymo konfigūracija – Container Runtime Config. Pagalvokite apie tai kaip apie Kubernetes šaltinį, kuris atspindi CRI-O konfigūraciją. Tiesą sakant, tai yra specializuota „MachineConfig“ versija, kuri yra bet kokia konfigūracija, kuri yra įdiegta „RHEL CoreOS“ įrenginyje kaip „OpenShift“ klasterio dalis.
Šis pasirinktinis išteklius, vadinamas ContainerRuntimeConfig, buvo sukurtas tam, kad klasterio administratoriams būtų lengviau konfigūruoti CRI-O. Šis įrankis yra pakankamai galingas, kad jį galima pritaikyti tik tam tikriems mazgams, atsižvelgiant į „MachineConfigPool“ nustatymus. Pagalvokite apie tai kaip apie mašinų grupę, kuri atlieka tą patį tikslą.
Atkreipkite dėmesį į paskutines dvi eilutes, kurias ketiname pakeisti faile /etc/crio/crio.conf. Šios dvi eilutės yra labai panašios į krio.conf failo eilutes, jos yra:
vi ContainerRuntimeConfig.yaml
Išvada:
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
Dabar perkelkime šį failą į Kubernetes klasterį ir patikrinkime, ar jis iš tikrųjų buvo sukurtas. Atkreipkite dėmesį, kad operacija yra lygiai tokia pati kaip ir su bet kuriuo kitu Kubernetes šaltiniu:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Išvada:
NAME AGE
set-log-and-pid 22h
Sukūrę „ContainerRuntimeConfig“, turime modifikuoti vieną iš „MachineConfigPools“, kad praneštume „Kubernetes“, kad norime pritaikyti šią konfigūraciją konkrečiai klasterio mašinų grupei. Tokiu atveju pakeisime pagrindinių mazgų MachineConfigPool:
oc edit MachineConfigPool/master
Išvada (aiškumo dėlei paliekama pagrindinė esmė):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Šiuo metu MCO pradeda kurti naują crio.conf failą klasteriui. Tokiu atveju visiškai užbaigtą konfigūracijos failą galima peržiūrėti naudojant Kubernetes API. Atminkite, kad „ContainerRuntimeConfig“ yra tik specializuota „MachineConfig“ versija, todėl rezultatą galime pamatyti žiūrėdami į atitinkamas „MachineConfigs“ eilutes:
oc get MachineConfigs | grep rendered
Išvada:
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
Atminkite, kad gautas pagrindinių mazgų konfigūracijos failas buvo naujesnės versijos nei pradinės konfigūracijos. Norėdami jį peržiūrėti, paleiskite šią komandą. Praeidami pažymime, kad tai turbūt vienas geriausių „Kubernetes“ istorijoje vieno pamušalo:
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
Išvada:
pids_limit = 2048
Dabar įsitikinkime, kad konfigūracija buvo pritaikyta visiems pagrindiniams mazgams. Pirmiausia gauname klasterio mazgų sąrašą:
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
Dabar pažiūrėkime į įdiegtą failą. Pamatysite, kad failas buvo atnaujintas naujomis pid ir derinimo direktyvų reikšmėmis, kurias nurodėme ContainerRuntimeConfig šaltinyje. Pati elegancija:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Išvada:
...
pids_limit = 2048
...
log_level = "debug"
...
Visi šie klasterio pakeitimai buvo atlikti net nepaleidus SSH. Visas darbas buvo atliktas prisijungus prie Kuberentes pagrindinio mazgo. Tai reiškia, kad šie nauji parametrai buvo sukonfigūruoti tik pagrindiniuose mazguose. Darbuotojų mazgai nepasikeitė, o tai parodo „Kubernetes“ metodologijos pranašumus naudojant nurodytas ir faktines būsenas, susijusias su konteinerių pagrindiniais kompiuteriais ir konteinerių varikliais su keičiamais elementais.
Aukščiau pateiktame pavyzdyje parodyta galimybė keisti mažą „OpenShift Container Platform 4“ klasterį su trimis gamybos mazgais arba didžiulę gamybos grupę su 3000 4 mazgų. Bet kokiu atveju darbo kiekis bus toks pat – ir labai mažas – tereikia sukonfigūruoti ContainerRuntimeConfig failą ir pakeisti vieną etiketę „MachineConfigPool“. Ir tai galite padaryti naudodami bet kurią „OpenShift Container Platform XNUMX.X“ versiją, kurioje veikia „Kubernetes“ per visą jos gyvavimo ciklą.
Dažnai technologijų įmonės vystosi taip greitai, kad negalime paaiškinti, kodėl renkamės tam tikras technologijas pagrindiniams komponentams. Konteinerių varikliai istoriškai buvo komponentas, su kuriuo vartotojai sąveikauja tiesiogiai. Kadangi konteinerių populiarumas natūraliai prasidėjo atsiradus konteinerių varikliams, vartotojai dažnai jais domisi. Tai dar viena priežastis, kodėl Red Hat pasirinko CRI-O. Sudėtiniai rodiniai tobulinami, daugiausia dėmesio skiriant orkestravimui, ir mes nustatėme, kad CRI-O suteikia geriausią patirtį dirbant su „OpenShift 4“.
Šaltinis: www.habr.com