Foorumi voit virtaviivaistaa luomista , mukaan lukien pilvipalveluntarjoajien infrastruktuurissa, virtualisointialustoilla tai paljasmetallijärjestelmissä. Aidosti pilvipohjaisen alustan luomiseksi meidän piti ottaa tiukasti hallintaan kaikki käytetyt elementit ja siten lisätä monimutkaisen automaatioprosessin luotettavuutta.
Ilmeinen ratkaisu oli käyttää Red Hat Enterprisea standardina. Linux CoreOS (Red Hat Enterprise -versiot) Linux) ja CRI-O, ja tässä on syy...
Koska purjehduksen aihe on erittäin hyvä tapa löytää analogioita selitettäessä Kubernetesin ja konttien toimintaa, yritetään puhua esimerkin avulla CoreOS:n ja CRI-O:n ratkaisemista liiketoimintaongelmista . Vuonna 1803 Marc Brunel sai tehtäväkseen valmistaa 100 19 takilaa kasvavan Britannian laivaston tarpeisiin. Takila on eräänlainen takila, jota käytetään köysien kiinnittämiseen purjeisiin. XNUMX-luvun alkuun asti nämä lohkot valmistettiin käsin, mutta Brunel onnistui automatisoimaan tuotannon ja alkoi valmistaa standardoituja lohkoja työstökoneilla. Tämän prosessin automatisointi tarkoitti sitä, että tuloksena saadut lohkot olivat olennaisesti identtisiä, ne voitiin helposti vaihtaa rikkoutuessaan ja niitä voitiin valmistaa suuria määriä.
Kuvittele nyt, jos Brunelin täytyisi tehdä tämä työ 20 eri laivamallille (Kubernetes-versiot) ja viidelle eri planeetalle, joilla on täysin erilaiset merivirrat ja tuulet (pilvien tarjoajat). Lisäksi edellytettiin, että kaikki alukset (OpenShift-klusterit), riippumatta siitä, millä planeetoilla navigointi tapahtuu, kapteenien (klusterien toimintaa ohjaavat operaattorit) kannalta katsottuna käyttäytyvät samalla tavalla. Merenkulun analogiaa jatketakseni todettakoon, että laivakapteenit eivät välitä ollenkaan siitä, millaisia takiloja (CRI-O) heidän laivoissaan käytetään - heille pääasia, että nämä lohkot ovat vahvoja ja luotettavia.
OpenShift 4 pilvialustana kohtaa hyvin samanlaisen liiketoimintahaasteen. Uudet solmut on luotava klusterin luomisen yhteydessä, jos jossakin solmussa ilmenee vika tai klusteria skaalattaessa. Kun uusi solmu luodaan ja alustetaan, tärkeät isäntäkomponentit, mukaan lukien CRI-O, on määritettävä vastaavasti. Kuten missä tahansa muussa tuotannossa, "raaka-aineet" on toimitettava alussa. Laivojen raaka-aineina ovat metalli ja puu. Jos kuitenkin luodaan isäntä säiliöiden käyttöönottoa varten OpenShift 4 -klusterissa, syötteenä on oltava määritystiedostoja ja API:n tarjoamia palvelimia. OpenShift tarjoaa sitten vaaditun automaation tason koko elinkaaren ajan, tarjoten loppukäyttäjille tarvittavan tuotetuen ja siten takaisin alustaan tehdyn investoinnin.
OpenShift 4 luotiin siten, että se mahdollistaa järjestelmän kätevän päivittämisen alustan koko elinkaaren ajan (versioille 4.X) kaikille tärkeimmille pilvipalveluntarjoajille, virtualisointialustoille ja jopa paljasmetallijärjestelmille. Tätä varten solmut on luotava vaihdettavien elementtien pohjalta. Kun klusteri vaatii uuden Kubernetes-version, se vastaanottaa myös vastaavan version CRI-O:sta CoreOS:ssä. Koska CRI-O-versio on sidottu suoraan Kubernetesiin, tämä yksinkertaistaa huomattavasti mahdollisia permutaatioita testausta, vianetsintää tai tukea varten. Lisäksi tämä lähestymistapa vähentää loppukäyttäjien ja Red Hatin kustannuksia.
Tämä on pohjimmiltaan uusi tapa ajatella Kubernetes-klustereita ja luo perustan erittäin hyödyllisten ja kiinnostavien uusien ominaisuuksien suunnittelulle. CRI-O (Container Runtime Interface - Open Container Initiative, lyhennettynä CRI-OCI) osoittautui menestyksekkäimmäksi valinnaksi solmujen massaluonnissa, joka on välttämätön OpenShift-työskentelyyn. CRI-O korvaa aiemmin käytetyn Docker-moottorin ja tarjoaa OpenShift-käyttäjille – kyllä, kuulit oikein – tylsä konttimoottori, joka on luotu erityisesti Kubernetesin kanssa työskentelemiseen.
Avointen konttien maailma
Maailma on siirtynyt kohti avoimia kontteja jo pitkään. Kubernetesissa tai alemmilla tasoilla, tuloksena on innovaatioekosysteemi kaikilla tasoilla.
Kaikki alkoi Open Containers Initiativen luomisesta . Tässä varhaisessa työvaiheessa muodostettiin konttimääritykset и . Tämä varmisti, että työkalut saattoivat käyttää yhtä standardia ja yhtenäinen muoto heidän kanssaan työskentelemiseen. Tekniset tiedot lisättiin myöhemmin , jolloin käyttäjät voivat jakaa helposti .
Kubernetes-yhteisö kehitti sitten yhden standardin kytkettävälle rajapinnalle, nimeltään . Tämän ansiosta Kubernetes-käyttäjät pystyivät kytkemään erilaisia moottoreita toimimaan konttien kanssa Dockerin lisäksi.
Red Hatin ja Googlen insinöörit näkivät markkinoiden tarpeen konttimoottorille, joka voisi hyväksyä Kubelet-pyynnöt CRI-protokollan kautta, ja esittelivät kontit, jotka olivat yhteensopivia yllä mainittujen OCI-määritysten kanssa. Niin . Mutta anteeksi, emmekö sanoneet, että tämä materiaali olisi omistettu CRI-O:lle? Itse asiassa se on, vain julkaisun myötä Projekti nimettiin uudelleen CRI-O:ksi.
Kuva 1.
Innovaatioita CRI-O:n ja CoreOS:n kanssa
OpenShift 4 -alustan julkaisun myötä se muuttui , jota käytetään oletuksena alustassa, ja Docker korvattiin CRI-O:lla, joka tarjosi kustannustehokkaan, vakaan, yksinkertaisen ja tylsän ympäristön Kubernetesin rinnalla kehittyvän kontin käyttämiseen. Tämä yksinkertaistaa huomattavasti klusterin tukea ja konfigurointia. Säiliömoottorin ja isännän määritykset sekä niiden hallinta automatisoituvat OpenShift 4:ssä.
Odota, miten tämä on?
Aivan oikein, OpenShift 4:n myötä ei enää tarvitse muodostaa yhteyttä yksittäisiin isäntiin ja asentaa konttimoottoria, määrittää tallennustilaa, määrittää hakupalvelimia tai määrittää verkkoa. OpenShift 4 -alusta on suunniteltu kokonaan uudelleen käyttämään ei vain loppukäyttäjäsovellusten, vaan myös alustatason perustoimintojen, kuten kuvien käyttöönotto, järjestelmän määrittäminen tai päivitysten asentaminen, kannalta.
Kubernetes on aina sallinut käyttäjien hallita sovelluksia määrittämällä halutun tilan ja käyttämällä , jotta varmistetaan, että todellinen tila vastaa mahdollisimman tarkasti kohdetilaa. Tämä avaa suuria mahdollisuuksia sekä kehityksen että toiminnan näkökulmasta. Kehittäjät voivat määrittää vaaditun tilan operaattorille YAML- tai JSON-tiedostona, ja sitten operaattori voi luoda tarvittavan sovellusesiintymän tuotantoympäristöön ja tämän ilmentymän toimintatila vastaa täysin määritettyä.
Käyttämällä alustassa Operaattoreita OpenShift 4 tuo tämän uuden paradigman (käyttäen joukon ja todellisen tilan käsitettä) RHEL CoreOS:n ja CRI-O:n hallintaan. Käyttöjärjestelmän ja konttimoottorin versioiden konfigurointi- ja hallintatehtävät automatisoidaan ns . MCO yksinkertaistaa huomattavasti klusterin ylläpitäjän työtä ja automatisoi olennaisesti asennuksen viimeiset vaiheet sekä myöhemmät asennuksen jälkeiset toiminnot (toisen päivän toiminnot). Kaikki tämä tekee OpenShift 4:stä todellisen pilvialustan. Palataan asiaan hieman myöhemmin.
Käynnissä olevat kontit
Käyttäjillä on ollut mahdollisuus käyttää CRI-O-moottoria OpenShift-alustalla versiosta 3.7 alkaen Tech Preview -tilassa ja versiosta 3.9 alkaen Yleisesti saatavilla -tilassa (tällä hetkellä tuettu). Lisäksi Red Hat käyttää massiivisesti OpenShift Onlinessa versiosta 3.10 lähtien. Kaiken tämän ansiosta CRI-O:n parissa työskentelevä tiimi sai laajan kokemuksen suurten Kubernetes-klustereiden konttien massalaukaisusta. Saadaksesi perusymmärryksen siitä, kuinka Kubernetes käyttää CRI-O:ta, katsotaan seuraavaa kuvaa, joka näyttää kuinka arkkitehtuuri toimii.
Riisi. 2. Kuinka säilöt toimivat Kubernetes-klusterissa
CRI-O yksinkertaistaa uusien konttiisäntien luomista synkronoimalla koko huipputason uusia solmuja alustettaessa ja OpenShift-alustan uusia versioita julkaistaessa. Koko alustan versio mahdollistaa tapahtumien päivitykset/palautukset ja estää myös riippuvuuksien lukkiutumisen säiliön ytimen, konttimoottorin, solmujen (Kubelets) ja Kubernetes Master -solmun välillä. Hallitsemalla kaikkia alustan osia keskitetysti ohjauksella ja versioinnilla, on aina selkeä tie tilasta A tilaan B. Tämä yksinkertaistaa päivitysprosessia, parantaa turvallisuutta, parantaa suorituskykyraportointia ja auttaa vähentämään päivitysten ja uusien versioiden asennuskustannuksia. .
Korvaavien elementtien tehon osoittaminen
Kuten aiemmin mainittiin, Machine Config Operatorin käyttö konttiisännän ja konttimoottorin hallintaan OpenShift 4:ssä tarjoaa uuden tason automaatiota, joka ei ollut aiemmin mahdollista Kubernetes-alustalla. Esittelemme uusia ominaisuuksia näyttämällä, kuinka voit tehdä muutoksia crio.conf-tiedostoon. Yritä keskittyä tuloksiin, jotta et joutuisi sekaannukseen terminologiasta.
Luodaan ensin niin sanottu säilön ajonaikainen määritys - Container Runtime Config. Ajattele sitä Kubernetes-resurssina, joka edustaa CRI-O:n kokoonpanoa. Todellisuudessa se on erikoisversio jostakin nimeltä MachineConfig, joka on mikä tahansa kokoonpano, joka on otettu käyttöön RHEL CoreOS -koneeseen osana OpenShift-klusteria.
Tämä mukautettu resurssi, nimeltään ContainerRuntimeConfig, luotiin helpottamaan klusterin järjestelmänvalvojien CRI-O:n määrittämistä. Tämä työkalu on tarpeeksi tehokas, jotta sitä voidaan käyttää vain tiettyihin solmuihin MachineConfigPool-asetuksista riippuen. Ajattele sitä ryhmänä koneita, jotka palvelevat samaa tarkoitusta.
Huomaa kaksi viimeistä riviä, joita aiomme muuttaa /etc/crio/crio.conf-tiedostossa. Nämä kaksi riviä ovat hyvin samankaltaisia kuin crio.conf-tiedoston rivit, ne ovat:
vi ContainerRuntimeConfig.yaml
Johtopäätös:
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
Työnnetään nyt tämä tiedosto Kubernetes-klusteriin ja tarkistetaan, että se todella luotiin. Huomaa, että toiminto on täsmälleen sama kuin minkä tahansa muun Kubernetes-resurssin kanssa:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Johtopäätös:
NAME AGE
set-log-and-pid 22h
Kun olemme luoneet ContainerRuntimeConfigin, meidän on muokattava yhtä MachineConfigPooleista ilmoittamaan Kubernetesille, että haluamme käyttää tätä kokoonpanoa klusterin tiettyyn koneryhmään. Tässä tapauksessa muutamme pääsolmujen MachineConfigPoolia:
oc edit MachineConfigPool/master
Johtopäätös (selvyyden vuoksi pääolemus jätetään):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Tässä vaiheessa MCO alkaa luoda uutta crio.conf-tiedostoa klusteriin. Tässä tapauksessa täysin valmis määritystiedosto voidaan tarkastella Kubernetes API:lla. Muista, että ContainerRuntimeConfig on vain MachineConfigin erikoisversio, joten voimme nähdä tuloksen tarkastelemalla asiaankuuluvia rivejä MachineConfigissa:
oc get MachineConfigs | grep rendered
Johtopäätös:
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
Huomaa, että tuloksena saatu pääsolmujen määritystiedosto oli uudempi versio kuin alkuperäiset kokoonpanot. Voit tarkastella sitä suorittamalla seuraavan komennon. Ohittaen huomautamme, että tämä on ehkä yksi parhaista yksikerroksisista Kubernetesin historiasta:
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
Johtopäätös:
pids_limit = 2048
Varmistetaan nyt, että kokoonpano on otettu käyttöön kaikissa pääsolmuissa. Ensin saamme luettelon klusterin solmuista:
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
Katsotaanpa nyt asennettua tiedostoa. Näet, että tiedosto on päivitetty uusilla arvoilla pid- ja debug-ohjeille, jotka määritimme ContainerRuntimeConfig-resurssissa. Itse eleganssi:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Johtopäätös:
...
pids_limit = 2048
...
log_level = "debug"
...
Kaikki nämä muutokset klusteriin tehtiin edes suorittamatta SSH:ta. Kaikki työ tehtiin käyttämällä Kuberentes-pääsolmua. Toisin sanoen nämä uudet parametrit määritettiin vain pääsolmuissa. Työntekijäsolmut eivät muuttuneet, mikä osoittaa Kubernetes-metodologian edut määritettyjen ja todellisten tilojen käyttämisessä suhteessa konttiisäntään ja konttimoottoreihin, joissa on vaihdettavia elementtejä.
Yllä oleva esimerkki näyttää mahdollisuuden tehdä muutoksia pieneen OpenShift Container Platform 4 -klusteriin, jossa on kolme tuotantosolmua, tai valtavaan tuotantoklusteriin, jossa on 3000 4 solmua. Joka tapauksessa työn määrä on sama - ja hyvin pieni - vain määritä ContainerRuntimeConfig-tiedosto ja vaihda yksi nimike MachineConfigPoolissa. Ja voit tehdä tämän millä tahansa OpenShift Container Platform XNUMX.X -versiolla, jossa Kubernetes on käytössä koko sen elinkaaren ajan.
Usein teknologiayritykset kehittyvät niin nopeasti, ettemme pysty selittämään, miksi valitsemme tiettyjä teknologioita taustalla oleville komponenteille. Säiliömoottorit ovat historiallisesti olleet osa, jonka kanssa käyttäjät ovat vuorovaikutuksessa suoraan. Koska konttien suosio alkoi luonnollisesti konttimoottoreiden myötä, käyttäjät osoittavat usein kiinnostusta niitä kohtaan. Tämä on toinen syy miksi Red Hat valitsi CRI-O:n. Kontit kehittyvät keskittyen nyt orkestrointiin, ja olemme havainneet, että CRI-O tarjoaa parhaan kokemuksen OpenShift 4:n kanssa työskennellessä.
Lähde: will.com
