Platform laat jou toe om die skepping te stroom , insluitend in die infrastruktuur van wolkdiensverskaffers, op virtualisasieplatforms of in kaalmetaalstelsels. Om 'n wolkplatform in die volle sin te skep, moes ons al die elemente wat gebruik word streng beheer neem en sodoende die betroubaarheid van 'n komplekse outomatiseringsproses verhoog.
Die voor die hand liggende oplossing was om Red Hat Enterprise Linux CoreOS (variëteite van Red Hat Enterprise Linux) en CRI-O as die standaard te gebruik, en dit is hoekom ...
Aangesien die onderwerp van navigasie baie goed is om analogieë te vind wanneer die werk van Kubernetes en houers verduidelik word, kom ons probeer om te praat oor die besigheidsprobleme wat CoreOS en CRI-O oplos, met behulp van 'n voorbeeld . In 1803 het Mark Brunel die taak gekry om 100 19 tuigblokke te maak vir die behoeftes van die groeiende Britse vloot. ’n Rigblok is ’n tipe tuig wat gebruik word om toue aan seile vas te maak. Tot aan die begin van die XNUMXde eeu is hierdie blokke met die hand gemaak, maar Brunel het daarin geslaag om produksie te outomatiseer en het gestandaardiseerde blokke met masjiengereedskap begin maak. Die outomatisering van hierdie proses het beteken dat die gevolg was dat al die blokke amper dieselfde was, maklik vervang kon word in die geval van 'n onklaarraking, en in groot hoeveelhede vervaardig kon word.
Stel jou nou voor of Brunel hierdie werk moes doen vir 20 verskillende skeepsmodelle (Kubernetes-weergawes) en vir vyf verskillende planete met heeltemal verskillende seestrome en winde (wolkverskaffers). Boonop is vereis dat alle skepe (OpenShift-klusters), ongeag die planete wat navigeer word, dieselfde optree vanuit die oogpunt van die kapteins (operateurs wat die werk van die trosse beheer). Om die mariene analogie voort te sit, gee skeepskapteins absoluut nie om watter tuigblokke (CRI-O) op hul skepe gebruik word nie - die belangrikste ding vir hulle is dat hierdie blokke sterk en betroubaar is.
OpenShift 4, as 'n wolkplatform, staar 'n baie soortgelyke besigheidsuitdaging in die gesig. Nuwe nodusse moet geskep word ten tyde van trosskepping, in geval van mislukking in een van die nodusse, of wanneer die tros skaal. Wanneer 'n nuwe nodus geskep en geïnisialiseer word, moet kritieke gasheerkomponente, insluitend CRI-O, dienooreenkomstig gekonfigureer word. Soos in enige ander produksie, is dit aan die begin nodig om "grondstowwe" in te dien. In die geval van skepe word metaal en hout as grondstowwe gebruik. In die geval van die skep van 'n gasheer vir die ontplooiing van houers in 'n OpenShift 4-kluster, moet u konfigurasielêers en bedieners hê wat deur die API as invoer verskaf word. Daarna sal OpenShift die regte vlak van outomatisering deur die hele lewensiklus bied, die nodige produkondersteuning vir eindgebruikers bied en sodoende die belegging in die platform verhaal.
OpenShift 4 is ontwerp om maklike stelselopgraderings regdeur die platform se lewensiklus (vir weergawes 4.X) vir alle groot wolkverskaffers, virtualisasieplatforms en selfs kaalmetaalstelsels te verskaf. Om dit te doen, moet nodusse geskep word op grond van verwisselbare elemente. Wanneer 'n groepering 'n nuwe weergawe van Kubernetes benodig, kry dit ook die ooreenstemmende weergawe van CRI-O op CoreOS. Aangesien die CRI-O-weergawe direk aan Kubernetes gekoppel is, vergemaklik dit enige omruilings vir toetsing, probleemoplossing of ondersteuning aansienlik. Boonop verminder hierdie benadering koste vir eindgebruikers en Red Hat.
Dit is 'n fundamenteel nuwe manier om na Kubernetes-klusters te kyk en lê die grondslag vir die beplanning van nuwe, uiters nuttige en aantreklike kenmerke. CRI-O (die Container Runtime Interface - Open Container Initiative, afgekort as CRI-OCI) het geblyk die beste keuse te wees vir die skepping van massanodus wat nodig is om met OpenShift te werk. CRI-O sal die voorheen gebruikte Docker-enjin vervang, wat gebruikers OpenShift bied - ja, jy lees reg - 'n vervelige houer-enjin wat spesifiek ontwerp is om met Kubernetes te werk.
Die wêreld van oop houers
Die wêreld beweeg al lank na oop houers. Of dit nou in Kubernetes is, of op laer vlakke, lei tot die ontstaan van 'n ekosisteem van innovasies op elke vlak.
Dit het alles begin met die skepping van die Open Containers Initiative . Op hierdie vroeë stadium van werk, die spesifikasies van die houer и . Dit het verseker dat die gereedskap 'n enkele standaard kon gebruik. en 'n enkele formaat om daarmee te werk. Spesifikasies later bygevoeg wat gebruikers toelaat om maklik te deel .
Die Kubernetes-gemeenskap het toe 'n enkele inpropbare koppelvlakstandaard genaamd ontwikkel . Danksy dit kon Kubernetes-gebruikers verskeie enjins koppel om met houers te werk, benewens Docker.
Red Hat- en Google-ingenieurs het die behoefte in die mark gesien vir 'n houer-enjin wat versoeke van Kubelet oor die CRI-protokol kan aanvaar en houers bekendgestel wat versoenbaar is met die OCI-spesifikasies hierbo genoem. Dus . Maar verskoon my, het ons gesê dat hierdie materiaal aan CRI-O gewy sal word? Eintlik is dit, net met die vrylating die projek is herdoop na CRI-O.
Fig. 1.
Innovasie met CRI-O en CoreOS
Met die bekendstelling van die OpenShift 4-platform, het die , wat by verstek deur die platform gebruik word, en Docker is vervang deur CRI-O, wat 'n koste-effektiewe, stabiele, eenvoudige en vervelige omgewing gebied het om 'n houer te bestuur wat parallel met Kubernetes ontwikkel. Dit vergemaklik die instandhouding en konfigurasie van groepe aansienlik. Houer-enjin en gasheerkonfigurasie en -bestuur word outomaties binne OpenShift 4.
Stop, hoe is dit?
Dit is reg, met die koms van OpenShift 4 is dit nie meer nodig om aan individuele gashere te koppel en 'n houer-enjin te installeer, berging op te stel, soekbedieners op te stel of 'n netwerk op te stel nie. Die OpenShift 4-platform is heeltemal herontwerp om die nie net in terme van eindgebruikertoepassings nie, maar ook in terme van basiese platformvlak-bewerkings soos die implementering van beelde, die opstel van die stelsel of die installering van opdaterings.
Kubernetes het altyd gebruikers toegelaat om toepassings te bestuur deur die verlangde toestand te definieer en te gebruik om te verseker dat die werklike toestand so na as moontlik aan die gespesifiseerde toestand is. Hierdie bied groot geleenthede in terme van ontwikkeling en in terme van bedrywighede. Ontwikkelaars kan die vereiste toestand definieer, operateur in die vorm van 'n YAML- of JSON-lêer, en dan kan die operateur die vereiste toepassingsinstansie in die produksie-omgewing skep, terwyl die werktoestand van hierdie instansie ten volle sal ooreenstem met die gespesifiseerde een.
Deur Operateurs in die platform te gebruik, bring OpenShift 4 hierdie nuwe paradigma (met die konsep van stel en werklike toestand) na die bestuur van RHEL CoreOS en CRI-O. Die take om weergawes van die bedryfstelsel en die houer-enjin op te stel en te bestuur word geoutomatiseer deur gebruik te maak van die sg. . MCO vereenvoudig die werk van die groepadministrateur aansienlik, en outomatiseer in wese die laaste stadiums van installasie, sowel as daaropvolgende bedrywighede na installasie (dag twee bedrywighede). Dit alles maak OpenShift 4 'n ware wolkplatform. Ons sal 'n bietjie later hieroor stilstaan.
Lopende houers
Gebruikers kon sedert weergawe 3.7 die CRI-O-enjin in die OpenShift-platform gebruik in Tech Preview-status en vanaf weergawe 3.9 in Algemeen Beskikbaar-status (tans ondersteun). Boonop maak Red Hat grootliks gebruik van in OpenShift Online sedert weergawe 3.10. Dit alles het die span wat aan CRI-O gewerk het, in staat gestel om groot ervaring op te doen in die massa-lansering van houers op groot Kubernetes-klusters. Om 'n basiese begrip te kry van hoe Kubernetes CRI-O gebruik, kom ons kyk na die volgende illustrasie, wat wys hoe die argitektuur werk.
Rys. 2. Hoe houers in 'n Kubernetes-kluster werk
CRI-O vereenvoudig die skepping van nuwe houergashere deur die hele boonste vlak te sinchroniseer wanneer nuwe nodusse geïnisialiseer word, en wanneer nuwe weergawes van die OpenShift-platform vrygestel word. Die hele platformhersiening maak voorsiening vir transaksionele opdaterings/terugbetalings en voorkom ook dooiepunte in afhanklikhede tussen die houerstertkern, houerenjin, nodusse (Kubelets) en die Kubernetes Master-nodus. Deur alle platformkomponente sentraal te bestuur, met weergawe en beheer, kan jy altyd 'n duidelike pad van toestand A na toestand B naspeur. Dit vereenvoudig die opgraderingsproses, verbeter sekuriteit, verbeter prestasieverslaggewing en help om die koste van opgraderings en nuwe weergawes te verminder.
Demonstrasie van die krag van verwisselbare elemente
Soos vroeër genoem, bied die gebruik van die Machine Config Operator om die houergasheer en houerenjin in OpenShift 4 te bestuur 'n nuwe vlak van outomatisering wat nie voorheen moontlik was op die Kubernetes-platform nie. Om die nuwe kenmerke te demonstreer, sal ons jou wys hoe jy veranderinge aan die crio.conf-lêer kan maak. Om nie verward te raak in die terminologie nie, probeer om op die resultate te konsentreer.
Kom ons skep eers wat 'n Container Runtime Config genoem word. Dink daaraan as 'n Kubernetes-hulpbron wat die konfigurasie vir CRI-O verteenwoordig. In werklikheid is dit 'n gespesialiseerde weergawe van wat MachineConfig genoem word, wat enige konfigurasie is wat op 'n RHEL CoreOS-masjien binne 'n OpenShift-groepering ontplooi word.
Hierdie pasgemaakte hulpbron, genaamd ContainerRuntimeConfig, is geskep om dit vir groepadministrateurs makliker te maak om CRI-O op te stel. Dit is 'n kragtige genoeg instrument dat dit slegs op sekere nodusse toegepas kan word, afhangende van die MachineConfigPool-instellings. Dink daaraan as 'n groep masjiene wat dieselfde doel dien.
Let op die laaste twee reëls wat ons in die /etc/crio/crio.conf-lêer gaan verander. Hierdie twee reëls is baie soortgelyk aan die lyne in die crio.conf-lêer, hulle is:
vi ContainerRuntimeConfig.yaml
Gevolgtrekking:
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
Kom ons stuur nou hierdie lêer na die Kubernetes-kluster en kyk of dit werklik geskep is. Neem asseblief kennis dat die werk op dieselfde manier uitgevoer word as met enige ander Kubernetes-hulpbron:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Gevolgtrekking:
NAME AGE
set-log-and-pid 22h
Sodra ons die ContainerRuntimeConfig geskep het, moet ons een van die MachineConfigPools wysig om Kubernetes te laat weet dat ons hierdie konfigurasie op 'n spesifieke groep masjiene in die groepie wil toepas. In hierdie geval sal ons die MachineConfigPool vir die meesternodusse verander:
oc edit MachineConfigPool/master
Gevolgtrekking (vir duidelikheid word die belangrikste essensie gelaat):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Op hierdie stadium begin MCO 'n nuwe crio.conf-lêer vir die groep skep. Terselfdertyd kan 'n volledig voltooide konfigurasielêer met die Kubernetes API bekyk word. Onthou, ContainerRuntimeConfig is net 'n gespesialiseerde weergawe van MachineConfig, so ons kan die resultaat sien deur na die relevante lyne in MachineConfigs te kyk:
oc get MachineConfigs | grep rendered
Gevolgtrekking:
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
Let daarop dat die gevolglike konfigurasielêer vir die masternodes 'n nuwer weergawe is as die oorspronklike konfigurasies. Om dit te sien, voer die volgende opdrag uit. In die verbygaan merk ons op dat dit waarskynlik een van die beste eenreël-skrifte in die geskiedenis van Kubernetes is:
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
Gevolgtrekking:
pids_limit = 2048
Kom ons maak nou seker dat die konfigurasie op alle meesternodusse toegepas is. Kry eers 'n lys nodusse in die groepering:
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
Kom ons kyk nou na die geïnstalleerde lêer. U sal sien dat die lêer opgedateer is met die nuwe waardes van die pid- en debug-aanwysings wat ons in die ContainerRuntimeConfig-hulpbron gespesifiseer het. Elegansie self:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Gevolgtrekking:
...
pids_limit = 2048
...
log_level = "debug"
...
Al hierdie veranderinge aan die groepering is gemaak selfs sonder om SSH te gebruik. Al die werk is gedoen deur die Kuberentes-meesternodus te bel. Dit wil sê, hierdie nuwe parameters is slegs op die meesternodusse gekonfigureer. Die werkernodusse het nie verander nie, wat die voordele van die Kubernetes-metodologie demonstreer deur gebruik te maak van vasgestelde en werklike toestande in verhouding tot leërskare van houers en houerenjins met verwisselbare elemente.
Die voorbeeld hierbo toon die vermoë om veranderinge aan te bring aan 'n klein OpenShift Container Platform 4-kluster met drie produksienodusse of 'n groot produksiekluster met 3000 nodusse. In elk geval, die hoeveelheid werk sal dieselfde wees - en baie klein - konfigureer net die ContainerRuntimeConfig-lêer, en verander een etiket (etiket) in die MachineConfigPool. En jy kan dit regdeur sy lewensiklus met enige weergawe van Kubernetes se OpenShift Container Platform 4.X doen.
Dikwels groei tegnologiemaatskappye so vinnig dat ons nie kan verduidelik hoekom ons sekere tegnologieë vir kernkomponente kies nie. Houer-enjins was histories die komponent waarmee gebruikers direk interaksie het. Aangesien die gewildheid van houers natuurlik begin het met die koms van houerenjins, toon gebruikers dikwels belangstelling daarin. Dit is nog 'n rede waarom Red Hat vir CRI-O gekies het. Houers ontwikkel met die fokus vandag op orkestrasie en ons het gevind dat CRI-O die beste ervaring bied wanneer jy met OpenShift 4 werk.
Bron: will.com