Foorumi
Ilmeinen ratkaisu oli käyttää Red Hat Enterprise Linux CoreOS:ää (Red Hat Enterprise Linuxin muunnos) ja CRI-O:ta standardina, ja tässä miksi...
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
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
Avointen konttien maailma
Maailma on siirtynyt kohti avoimia kontteja jo pitkään. Kubernetesissa tai alemmilla tasoilla,
Kaikki alkoi Open Containers Initiativen luomisesta
Kubernetes-yhteisö kehitti sitten yhden standardin kytkettävälle rajapinnalle, nimeltään
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
Kuva 1.
Innovaatioita CRI-O:n ja CoreOS:n kanssa
OpenShift 4 -alustan julkaisun myötä se muuttui
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
Kubernetes on aina sallinut käyttäjien hallita sovelluksia määrittämällä halutun tilan ja käyttämällä
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
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
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