Platfoarm lit jo de skepping streamlynje , ynklusyf yn 'e ynfrastruktuer fan wolktsjinstferlieners, op virtualisaasjeplatfoarms of yn bleatemetaalsystemen. Om in wirklik wolkbasearre platfoarm te meitsjen, moasten wy strikte kontrôle nimme fan alle brûkte eleminten en sadwaande de betrouberens fan in kompleks automatisearringsproses ferheegje.
De foar de hân lizzende oplossing wie om Red Hat Enterprise Linux CoreOS (in fariant fan Red Hat Enterprise Linux) en CRI-O as de standert te brûken, en hjir is wêrom ...
Sûnt it ûnderwerp fan silen in heul goed is foar it finen fan analogy's by it ferklearjen fan it wurk fan Kubernetes en konteners, litte wy besykje te praten oer de saaklike problemen dy't CoreOS en CRI-O oplosse, mei in foarbyld . Yn 1803 krige Marc Brunel de opdracht om 100 riggingblokken te meitsjen foar de behoeften fan 'e groeiende Britske marine. In riggingblok is in soarte fan rigging dat brûkt wurdt om touwen oan seilen te befestigjen. Oant it begjin fan 'e 19e ieu waarden dizze blokken mei de hân makke, mar Brunel wist de produksje te automatisearjen en begon te produsearjen fan standerdisearre blokken mei help fan masines. Automatisearring fan dit proses betsjutte dat de resultearjende blokken wiene frijwol identyk, koe wurde maklik ferfongen as brutsen, en koe wurde produsearre yn grutte hoemannichten.
Stel jo no foar as Brunel dit wurk moast dwaan foar 20 ferskillende skipmodellen (Kubernetes-ferzjes) en foar fiif ferskillende planeten mei folslein oare seestreamen en wynen (wolkproviders). Dêrneist wie it fereaske dat alle skippen (OpenShift-klusters), nettsjinsteande de planeten dêr't navigearre wurdt, út it eachpunt fan 'e kapteins (operators dy't de wurking fan 'e klusters beheare) itselde gedrage. Om fierder te gean mei de maritime analogy, skipkapiteins net skele oer wat soarte fan rigging blokken (CRI-O) wurde brûkt op harren skippen - it wichtichste ding foar harren is dat dizze blokken binne sterk en betrouber.
OpenShift 4, as wolkplatfoarm, stiet foar in heul ferlykbere saaklike útdaging. Nije knopen moatte oanmakke wurde op it momint fan kluster oanmeitsjen, yn it gefal fan in mislearring yn ien fan de knopen, of by it skaalfergrutting fan it kluster. As in nij knooppunt wurdt oanmakke en inisjalisearre, moatte krityske hostkomponinten, ynklusyf CRI-O, dêrmei konfigureare wurde. Lykas yn elke oare produksje moatte "grûnstoffen" oan it begjin levere wurde. By skippen binne de grûnstoffen metaal en hout. Yn it gefal fan it meitsjen fan in host foar it ynsetten fan konteners yn in OpenShift 4-kluster, moatte jo konfiguraasjebestannen en API-levere servers hawwe as ynfier. OpenShift sil dan it fereaske nivo fan automatisearring yn 'e heule libbenssyklus leverje, de nedige produktstipe oanbiede oan ein brûkers en sadwaande de ynvestearring yn it platfoarm weromhelje.
OpenShift 4 is makke op sa'n manier om de mooglikheid te leverjen om it systeem maklik te aktualisearjen yn 'e heule libbenssyklus fan it platfoarm (foar ferzjes 4.X) foar alle grutte providers fan cloud computing, virtualisaasjeplatfoarms en sels bleate metalen systemen. Om dit te dwaan, moatte knopen makke wurde op basis fan wikselbere eleminten. As in kluster in nije ferzje fan Kubernetes fereasket, ûntfangt it ek de oerienkommende ferzje fan CRI-O op CoreOS. Sûnt de CRI-O-ferzje is direkt bûn oan Kubernetes, simplifies dit alle permutaasjes foar testen, probleemoplossing of stipedoelen sterk. Dêrneist ferleget dizze oanpak kosten foar ein brûkers en Red Hat.
Dit is in fûneminteel nije manier fan tinken oer Kubernetes-klusters en leit de basis foar it plannen fan wat heul nuttige en twingende nije funksjes. CRI-O (Container Runtime Interface - Open Container Initiative, ôfkoarte CRI-OCI) blykte de meast súksesfolle kar te wêzen foar de massale skepping fan knopen dy't nedich binne om te wurkjen mei OpenShift. CRI-O sil de earder brûkte Docker-motor ferfange, en biedt OpenShift-brûkers - ja, jo hawwe gelyk heard - in saaie kontenermotor dy't spesjaal makke is foar wurkjen mei Kubernetes.
De wrâld fan iepen konteners
De wrâld beweecht al lang nei iepen konteners. Oft yn Kubernetes, of op legere nivo's, resultearret yn in ekosysteem fan ynnovaasje op elk nivo.
It begûn allegear mei de oprjochting fan it Open Containers Initiative . Op dit iere stadium fan wurk waarden kontenerspesifikaasjes foarme и . Dit soarge derfoar dat de ark ien standert brûke koe en in unifoarme opmaak om mei har te wurkjen. Spesifikaasjes waarden letter tafoege , wêrtroch brûkers maklik diele kinne .
De Kubernetes-mienskip ûntwikkele doe in inkele standert foar in pluggable ynterface, neamd . Hjirmei koene Kubernetes-brûkers ferskate motoren ferbine om te wurkjen mei konteners neist Docker.
Yngenieurs by Red Hat en Google seagen in merkferlet foar in kontenermotor dy't Kubelet-oanfragen koe akseptearje oer it CRI-protokol en yntrodusearre konteners dy't kompatibel wiene mei de hjirboppe neamde OCI-spesifikaasjes. Sa . Mar ekskús my, hawwe wy net sein dat dit materiaal soe wêze wijd oan CRI-O? Eins is it, krekt mei de frijlitting it projekt waard omdoopt ta CRI-O.
Fig. 1.
Ynnovaasje mei CRI-O en CoreOS
Mei de lansearring fan it OpenShift 4-platfoarm waard it feroare , Standert brûkt yn it platfoarm, en Docker waard ferfongen troch CRI-O, en biedt in kosten-effektive, stabile, ienfâldige en saaie omjouwing foar it útfieren fan in kontener dy't parallel mei Kubernetes ûntwikkelet. Dit simplifies gâns kluster stipe en konfiguraasje. Konfiguraasje fan 'e kontenermotor en host, lykas har behear, wurdt automatisearre binnen OpenShift 4.
Wachtsje, hoe is dit?
Dat is krekt, mei de komst fan OpenShift 4 is d'r net langer in ferlet om te ferbinen mei yndividuele hosts en in kontenermotor te ynstallearjen, opslach te konfigurearjen, syktsjinners te konfigurearjen of in netwurk te konfigurearjen. It OpenShift 4-platfoarm is folslein opnij ûntwurpen om de net allinich yn termen fan ein-brûkersapplikaasjes, mar ek yn termen fan basale operaasjes op platfoarmnivo, lykas it ynsetten fan ôfbyldings, it konfigurearjen fan it systeem, of it ynstallearjen fan updates.
Kubernetes hat brûkers altyd tastien om applikaasjes te behearjen troch de winske steat te definiearjen en te brûken , om te soargjen dat de eigentlike steat sa nau mooglik oerienkomt mei de doelsteat. Dit iepenet grutte kânsen út sawol in ûntwikkeling as operaasjes perspektyf. Ûntwikkelers kinne definiearje de fereaske steat troch oan de operator yn 'e foarm fan in YAML- of JSON-bestân, en dan kin de operator de fereaske applikaasje-eksimplaar oanmeitsje yn' e produksjeomjouwing, en de bestjoeringsstatus fan dit eksimplaar sil folslein oerienkomme mei de spesifisearre.
Troch it brûken fan Operators yn it platfoarm bringt OpenShift 4 dit nije paradigma (mei it konsept fan set en werklike steat) nei it behear fan RHEL CoreOS en CRI-O. De taken fan it konfigurearjen en beheare ferzjes fan it bestjoeringssysteem en container motor wurde automatisearre mei help fan de saneamde . MCO simplifies it wurk fan 'e klusterbehearder sterk, en automatisearret yn essinsje de lêste stadia fan ynstallaasje, lykas ek folgjende post-ynstallaasje operaasjes (dei twa operaasjes). Dit alles makket OpenShift 4 in wirklik wolkplatfoarm. Wy komme hjir efkes letter op yn.
Running containers
Brûkers hawwe de kâns hân om de CRI-O-motor te brûken yn it OpenShift-platfoarm sûnt ferzje 3.7 yn 'e Tech Preview-status en fan ferzje 3.9 yn' e Algemien Beskikbere status (op it stuit stipe). Dêrneist Red Hat massaal brûkt yn OpenShift Online sûnt ferzje 3.10. Dit alles koe it team wurkje oan CRI-O om wiidweidige ûnderfining op te heljen yn massale lansearring fan konteners op grutte Kubernetes-klusters. Om in basisbegryp te krijen fan hoe't Kubernetes CRI-O brûkt, litte wy nei de folgjende yllustraasje sjen, dy't sjen lit hoe't de arsjitektuer wurket.
Rys. 2. Hoe konteners wurkje yn in Kubernetes kluster
CRI-O simplifies it oanmeitsjen fan nije kontenerhosts troch it syngronisearjen fan it heule topnivo by it inisjalisearjen fan nije knopen, en by it frijjaan fan nije ferzjes fan it OpenShift-platfoarm. Ferzje fan it hiele platfoarm soarget foar transaksje-updates / weromdraaien, en foarkomt ek deadlocks yn ôfhinklikens tusken de kontenersturtkearn, kontenermotor, knopen (Kubelets) en de Kubernetes Master-knooppunt. Troch sintraal beheare fan alle platfoarm komponinten, mei kontrôle en ferzje, der is altyd in dúdlik paad fan steat A nei steat B. Dit simplifies it update proses, ferbetteret feiligens, ferbetteret prestaasjes rapportaazje, en helpt ferminderjen de kosten fan fernijings en ynstallaasjes fan nije ferzjes .
Demonstrearje de krêft fan ferfangende eleminten
Lykas earder neamd, it brûken fan de Machine Config Operator om de kontenerhost en kontenermotor te behearjen yn OpenShift 4 biedt in nij nivo fan automatisearring dat net earder mooglik wie op it Kubernetes-platfoarm. Om de nije funksjes te demonstrearjen, sille wy sjen litte hoe't jo wizigingen kinne meitsje oan it crio.conf-bestân. Om foar te kommen dat jo betize wurde troch terminology, besykje te fokusjen op 'e resultaten.
Litte wy earst meitsje wat in kontener-runtime-konfiguraasje hjit - Container Runtime Config. Tink oan it as in Kubernetes-boarne dy't de konfiguraasje foar CRI-O fertsjintwurdiget. Yn 'e realiteit is it in spesjalisearre ferzje fan wat MachineConfig hjit, dat is elke konfiguraasje dy't wurdt ynset op in RHEL CoreOS-masine as ûnderdiel fan in OpenShift-kluster.
Dizze oanpaste boarne, neamd ContainerRuntimeConfig, is makke om it makliker te meitsjen foar klusterbehearders om CRI-O te konfigurearjen. Dit ark is krêftich genôch dat it allinich kin wurde tapast op bepaalde knopen ôfhinklik fan 'e ynstellings fan MachineConfigPool. Tink oan it as in groep masines dy't tsjinje itselde doel.
Notysje de lêste twa rigels dy't wy sille feroarje yn it /etc/crio/crio.conf-bestân. Dizze twa rigels binne tige ferlykber mei de rigels yn it crio.conf-bestân, se binne:
vi ContainerRuntimeConfig.yaml
Fermelding:
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
Litte wy no dit bestân nei it Kubernetes-kluster triuwe en kontrolearje dat it eins makke is. Tink derom dat de operaasje krekt itselde is as mei elke oare Kubernetes-boarne:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Fermelding:
NAME AGE
set-log-and-pid 22h
As wy ienris de ContainerRuntimeConfig hawwe makke, moatte wy ien fan 'e MachineConfigPools wizigje om oan Kubernetes te sinjalearjen dat wy dizze konfiguraasje tapasse wolle op in spesifike groep masines yn it kluster. Yn dit gefal sille wy de MachineConfigPool feroarje foar de masterknooppunten:
oc edit MachineConfigPool/master
Konklúzje (foar dúdlikens, de wichtichste essinsje is oerbleaun):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Op dit punt begjint MCO in nij crio.conf-bestân te meitsjen foar it kluster. Yn dit gefal kin it folslein foltôge konfiguraasjebestân besjoen wurde mei de Kubernetes API. Unthâld, ContainerRuntimeConfig is gewoan in spesjalisearre ferzje fan MachineConfig, sadat wy it resultaat kinne sjen troch te sjen nei de relevante rigels yn MachineConfigs:
oc get MachineConfigs | grep rendered
Fermelding:
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
Tink derom dat it resultearjende konfiguraasjetriem foar de masterknooppunten in nijere ferzje wie dan de orizjinele konfiguraasjes. Om it te besjen, útfiere it folgjende kommando. Yn it foarbygean konstatearje wy dat dit miskien ien fan 'e bêste one-liners is yn' e skiednis fan Kubernetes:
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
Fermelding:
pids_limit = 2048
Litte wy no derfoar soargje dat de konfiguraasje is tapast op alle masterknooppunten. Earst krije wy in list mei knopen yn it kluster:
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
Litte wy no sjen nei it ynstalleare bestân. Jo sille sjen dat it bestân is bywurke mei de nije wearden foar de pid- en debug-rjochtlinen dy't wy spesifisearre hawwe yn 'e ContainerRuntimeConfig-boarne. Elegânsje sels:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Fermelding:
...
pids_limit = 2048
...
log_level = "debug"
...
Al dizze wizigingen oan it kluster waarden makke sûnder sels SSH út te fieren. Alle wurk waard dien troch tagong te krijen ta de Kuberentes-masterknooppunt. Dat is, dizze nije parameters waarden konfigurearre allinnich op master knopen. De arbeidersknooppunten binne net feroare, wat de foardielen fan 'e Kubernetes-metoade toant foar it brûken fan spesifisearre en aktuele steaten yn relaasje ta kontenerhosts en kontenermotoren mei útwikselbere eleminten.
It hjirboppe foarbyld toant de mooglikheid om wizigingen te meitsjen oan in lyts OpenShift Container Platform 4-kluster mei trije produksjeknooppunten as in enoarme produksjekluster mei 3000 knopen. Yn alle gefallen sil de hoemannichte wurk itselde wêze - en heul lyts - konfigurearje gewoan it ContainerRuntimeConfig-bestân, en feroarje ien label yn MachineConfigPool. En jo kinne dit dwaan mei elke ferzje fan it OpenShift Container Platform 4.X dy't Kubernetes yn har hiele libbenssyklus draait.
Faak ûntwikkelje technologybedriuwen sa fluch dat wy net kinne útlizze wêrom't wy bepaalde technologyen kieze foar de ûnderlizzende komponinten. Containermotoren hawwe histoarysk it komponint west wêrmei brûkers direkt ynteraksje. Sûnt de populariteit fan konteners natuerlik begon mei de komst fan kontenermotoren, litte brûkers faak ynteresse yn har sjen. Dit is in oare reden wêrom Red Hat keas CRI-O. Containers evoluearje mei de fokus no op orkestraasje, en wy hawwe fûn dat CRI-O de bêste ûnderfining leveret by it wurkjen mei OpenShift 4.
Boarne: www.habr.com