plattform lar deg strømlinjeforme skapelsen , inkludert i infrastrukturen til skytjenesteleverandører, på virtualiseringsplattformer eller i bare-metal-systemer. For å lage en virkelig skybasert plattform, måtte vi ta streng kontroll over alle elementene som ble brukt og dermed øke påliteligheten til en kompleks automatiseringsprosess.
Den åpenbare løsningen var å bruke Red Hat Enterprise Linux CoreOS (en variant av Red Hat Enterprise Linux) og CRI-O som standard, og her er hvorfor...
Siden temaet seiling er veldig bra for å finne analogier når vi forklarer arbeidet til Kubernetes og containere, la oss prøve å snakke om forretningsproblemene som CoreOS og CRI-O løser, ved å bruke et eksempel . I 1803 fikk Marc Brunel i oppgave å produsere 100 19 riggeblokker for behovene til den voksende britiske marinen. En riggblokk er en type rigg som brukes til å feste tau til seil. Helt til begynnelsen av XNUMX-tallet ble disse blokkene laget for hånd, men Brunel klarte å automatisere produksjonen og begynte å produsere standardiserte blokker ved hjelp av maskinverktøy. Automatisering av denne prosessen betydde at de resulterende blokkene var i hovedsak identiske, kunne enkelt erstattes hvis de ble ødelagt, og kunne produseres i store mengder.
Tenk nå om Brunel måtte gjøre dette arbeidet for 20 forskjellige skipsmodeller (Kubernetes-versjoner) og for fem forskjellige planeter med helt forskjellige havstrømmer og vinder (skyleverandører). I tillegg ble det påkrevd at alle skip (OpenShift-klynger), uavhengig av planetene det navigeres på, sett fra kapteinenes (operatører som styrer driften av klyngene) oppfører seg likt. For å fortsette den maritime analogien, bryr ikke skipskapteiner seg i det hele tatt hva slags riggeblokker (CRI-O) som brukes på skipene deres - det viktigste for dem er at disse blokkene er sterke og pålitelige.
OpenShift 4, som en skyplattform, står overfor en veldig lignende forretningsutfordring. Nye noder må opprettes ved opprettelse av klynge, ved feil i en av nodene, eller ved skalering av klyngen. Når en ny node opprettes og initialiseres, må kritiske vertskomponenter, inkludert CRI-O, konfigureres tilsvarende. Som i all annen produksjon må «råvarer» tilføres i begynnelsen. Når det gjelder skip er råvarene metall og tre. Men i tilfelle du oppretter en vert for å distribuere containere i en OpenShift 4-klynge, må du ha konfigurasjonsfiler og API-leverte servere som input. OpenShift vil da gi det nødvendige automatiseringsnivået gjennom hele livssyklusen, tilby nødvendig produktstøtte til sluttbrukere og dermed tjene tilbake investeringen i plattformen.
OpenShift 4 ble opprettet på en slik måte at det gir muligheten til å enkelt oppdatere systemet gjennom hele livssyklusen til plattformen (for versjon 4.X) for alle store cloud computing-leverandører, virtualiseringsplattformer og til og med bare metal-systemer. For å gjøre dette må noder opprettes på grunnlag av utskiftbare elementer. Når en klynge krever en ny versjon av Kubernetes, mottar den også den tilsvarende versjonen av CRI-O på CoreOS. Siden CRI-O-versjonen er knyttet direkte til Kubernetes, forenkler dette i stor grad alle permutasjoner for testing, feilsøking eller støtteformål. I tillegg reduserer denne tilnærmingen kostnadene for sluttbrukere og Red Hat.
Dette er en fundamentalt ny måte å tenke på Kubernetes-klynger og legger grunnlaget for planlegging av noen svært nyttige og overbevisende nye funksjoner. CRI-O (Container Runtime Interface - Open Container Initiative, forkortet CRI-OCI) viste seg å være det mest vellykkede valget for masseoppretting av noder som er nødvendig for å jobbe med OpenShift. CRI-O vil erstatte den tidligere brukte Docker-motoren, som tilbyr OpenShift-brukere – ja, du hørte rett – en kjedelig containermotor laget spesielt for å jobbe med Kubernetes.
En verden av åpne containere
Verden har beveget seg mot åpne containere i lang tid. Enten i Kubernetes, eller på lavere nivåer, resulterer i et økosystem av innovasjon på alle nivåer.
Det hele startet med opprettelsen av Open Containers Initiative . På dette tidlige stadiet av arbeidet ble containerspesifikasjoner dannet и . Dette sikret at verktøyene kunne bruke en enkelt standard og et enhetlig format for å jobbe med dem. Spesifikasjoner ble senere lagt til , slik at brukerne enkelt kan dele .
Kubernetes-fellesskapet utviklet deretter en enkelt standard for et pluggbart grensesnitt, kalt . Takket være dette kunne Kubernetes-brukere koble til ulike motorer for å jobbe med containere i tillegg til Docker.
Ingeniører hos Red Hat og Google så et markedsbehov for en containermotor som kunne akseptere Kubelet-forespørsler over CRI-protokollen og introduserte containere som var kompatible med OCI-spesifikasjonene nevnt ovenfor. Så . Men unnskyld meg, sa vi ikke at dette materialet ville være dedikert til CRI-O? Faktisk er det, bare med utgivelsen prosjektet ble omdøpt til CRI-O.
Fig. 1.
Innovasjon med CRI-O og CoreOS
Med lanseringen av OpenShift 4-plattformen ble den endret , brukt som standard i plattformen, og Docker ble erstattet av CRI-O, og tilbyr et kostnadseffektivt, stabilt, enkelt og kjedelig miljø for å kjøre en container som utvikler seg parallelt med Kubernetes. Dette forenkler klyngestøtte og konfigurasjon betraktelig. Konfigurasjon av containermotoren og verten, så vel som deres administrasjon, blir automatisert i OpenShift 4.
Vent, hvordan er dette?
Det er riktig, med bruken av OpenShift 4 er det ikke lenger behov for å koble til individuelle verter og installere en containermotor, konfigurere lagring, konfigurere søkeservere eller konfigurere et nettverk. OpenShift 4-plattformen har blitt fullstendig redesignet for å bruke ikke bare når det gjelder sluttbrukerapplikasjoner, men også når det gjelder grunnleggende operasjoner på plattformnivå som å distribuere bilder, konfigurere systemet eller installere oppdateringer.
Kubernetes har alltid tillatt brukere å administrere applikasjoner ved å definere ønsket tilstand og bruke , for å sikre at den faktiske tilstanden samsvarer så godt med måltilstanden som mulig. Dette åpner for store muligheter både fra et utviklings- og driftsperspektiv. Utviklere kan definere den nødvendige tilstanden ved til operatøren i form av en YAML- eller JSON-fil, og deretter kan operatøren opprette den nødvendige applikasjonsforekomsten i produksjonsmiljøet, og driftstilstanden til denne forekomsten vil fullt ut samsvare med den spesifiserte.
Ved å bruke Operators i plattformen, bringer OpenShift 4 dette nye paradigmet (ved å bruke konseptet sett og faktisk tilstand) til administrasjonen av RHEL CoreOS og CRI-O. Oppgavene med å konfigurere og administrere versjoner av operativsystemet og containermotoren er automatisert ved hjelp av den såkalte . MCO forenkler arbeidet til klyngeadministratoren betydelig, og automatiserer i hovedsak de siste stadiene av installasjonen, samt påfølgende operasjoner etter installasjon (dag to operasjoner). Alt dette gjør OpenShift 4 til en ekte skyplattform. Vi kommer inn på dette litt senere.
Kjøre containere
Brukere har hatt muligheten til å bruke CRI-O-motoren i OpenShift-plattformen siden versjon 3.7 i Tech Preview-status og fra versjon 3.9 i Generally Available-status (støttes for øyeblikket). I tillegg bruker Red Hat massivt i OpenShift Online siden versjon 3.10. Alt dette gjorde at teamet som jobbet med CRI-O fikk omfattende erfaring med masseutskyting av containere på store Kubernetes-klynger. For å få en grunnleggende forståelse av hvordan Kubernetes bruker CRI-O, la oss se på følgende illustrasjon, som viser hvordan arkitekturen fungerer.
Ris. 2. Hvordan containere fungerer i en Kubernetes-klynge
CRI-O forenkler opprettelsen av nye containerverter ved å synkronisere hele toppnivået ved initialisering av nye noder, og ved utgivelse av nye versjoner av OpenShift-plattformen. Revisjon av hele plattformen gir mulighet for transaksjonsoppdateringer/tilbakeføringer, og forhindrer også dødlåser i avhengigheter mellom containerhalekjernen, containermotoren, nodene (Kubelets) og Kubernetes Master-noden. Ved sentral administrasjon av alle plattformkomponenter, med kontroll og versjonering, er det alltid en klar vei fra tilstand A til tilstand B. Dette forenkler oppdateringsprosessen, forbedrer sikkerheten, forbedrer ytelsesrapporteringen og bidrar til å redusere kostnadene for oppdateringer og installasjoner av nye versjoner .
Demonstrere kraften til erstatningselementer
Som nevnt tidligere, gir bruk av Machine Config Operator til å administrere containerverten og containermotoren i OpenShift 4 et nytt automatiseringsnivå som ikke tidligere var mulig på Kubernetes-plattformen. For å demonstrere de nye funksjonene, viser vi hvordan du kan gjøre endringer i filen crio.conf. For å unngå å bli forvirret av terminologi, prøv å fokusere på resultatene.
Først, la oss lage det som kalles en container kjøretidskonfigurasjon - Container Runtime Config. Tenk på det som en Kubernetes-ressurs som representerer konfigurasjonen for CRI-O. I virkeligheten er det en spesialisert versjon av noe som heter MachineConfig, som er enhver konfigurasjon som er distribuert til en RHEL CoreOS-maskin som en del av en OpenShift-klynge.
Denne tilpassede ressursen, kalt ContainerRuntimeConfig, ble opprettet for å gjøre det enklere for klyngeadministratorer å konfigurere CRI-O. Dette verktøyet er kraftig nok til at det bare kan brukes på visse noder avhengig av MachineConfigPool-innstillingene. Tenk på det som en gruppe maskiner som tjener samme formål.
Legg merke til de to siste linjene som vi skal endre i filen /etc/crio/crio.conf. Disse to linjene er veldig like linjene i crio.conf-filen, de er:
vi ContainerRuntimeConfig.yaml
Konklusjon:
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
La oss nå skyve denne filen til Kubernetes-klyngen og sjekke at den faktisk ble opprettet. Vær oppmerksom på at operasjonen er nøyaktig den samme som med alle andre Kubernetes-ressurser:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Konklusjon:
NAME AGE
set-log-and-pid 22h
Når vi har opprettet ContainerRuntimeConfig, må vi modifisere en av MachineConfigPools for å signalisere til Kubernetes at vi ønsker å bruke denne konfigurasjonen til en bestemt gruppe maskiner i klyngen. I dette tilfellet vil vi endre MachineConfigPool for masternodene:
oc edit MachineConfigPool/master
Konklusjon (for klarhetens skyld er hovedessensen igjen):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
På dette tidspunktet begynner MCO å lage en ny crio.conf-fil for klyngen. I dette tilfellet kan den fullstendig ferdige konfigurasjonsfilen vises ved hjelp av Kubernetes API. Husk at ContainerRuntimeConfig bare er en spesialisert versjon av MachineConfig, så vi kan se resultatet ved å se på de relevante linjene i MachineConfigs:
oc get MachineConfigs | grep rendered
Konklusjon:
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
Vær oppmerksom på at den resulterende konfigurasjonsfilen for masternodene var en nyere versjon enn de opprinnelige konfigurasjonene. For å se den, kjør følgende kommando. I forbifarten bemerker vi at dette kanskje er en av de beste one-liners i Kubernetes historie:
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
Konklusjon:
pids_limit = 2048
La oss nå sørge for at konfigurasjonen er brukt på alle masternoder. Først får vi en liste over noder i klyngen:
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
La oss nå se på den installerte filen. Du vil se at filen har blitt oppdatert med de nye verdiene for pid- og debug-direktivene som vi spesifiserte i ContainerRuntimeConfig-ressursen. Selve elegansen:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Konklusjon:
...
pids_limit = 2048
...
log_level = "debug"
...
Alle disse endringene i klyngen ble gjort uten engang å kjøre SSH. Alt arbeid ble utført ved å få tilgang til Kuberentes-hovednoden. Det vil si at disse nye parameterne ble konfigurert bare på masternoder. Arbeidsnodene endret seg ikke, noe som viser fordelene med Kubernetes-metodikken ved å bruke spesifiserte og faktiske tilstander i forhold til containerverter og containermotorer med utskiftbare elementer.
Eksemplet ovenfor viser muligheten til å gjøre endringer i en liten OpenShift Container Platform 4-klynge med tre produksjonsnoder eller en enorm produksjonsklynge med 3000 noder. Uansett vil mengden arbeid være den samme - og veldig liten - bare konfigurer ContainerRuntimeConfig-filen, og endre en etikett i MachineConfigPool. Og du kan gjøre dette med hvilken som helst versjon av OpenShift Container Platform 4.X som kjører Kubernetes gjennom hele livssyklusen.
Ofte utvikler teknologiselskaper seg så raskt at vi ikke klarer å forklare hvorfor vi velger visse teknologier for de underliggende komponentene. Containermotorer har historisk vært komponenten som brukere samhandler direkte med. Siden populariteten til containere naturlig begynte med bruken av containermotorer, viser brukerne ofte interesse for dem. Dette er en annen grunn til at Red Hat valgte CRI-O. Containere utvikler seg med fokus nå på orkestrering, og vi har funnet ut at CRI-O gir den beste opplevelsen når du arbeider med OpenShift 4.
Kilde: www.habr.com