perron giver dig mulighed for at strømline skabelsen , herunder i infrastrukturen hos cloud-tjenesteudbydere, på virtualiseringsplatforme eller i bare-metal-systemer. For at skabe en virkelig cloud-baseret platform var vi nødt til at tage streng kontrol over alle de anvendte elementer og dermed øge pålideligheden af en kompleks automatiseringsproces.
Den oplagte løsning var at bruge Red Hat Enterprise Linux CoreOS (en variant af Red Hat Enterprise Linux) og CRI-O som standard, og her er hvorfor...
Da emnet sejlads er et meget godt emne til at finde analogier, når vi forklarer arbejdet med Kubernetes og containere, lad os prøve at tale om de forretningsproblemer, som CoreOS og CRI-O løser ved at bruge et eksempel . I 1803 fik Marc Brunel til opgave at producere 100 riggeblokke til den voksende britiske flådes behov. En riggblok er en form for rigning, der bruges til at fastgøre reb til sejl. Indtil begyndelsen af det 19. århundrede blev disse blokke fremstillet i hånden, men Brunel formåede at automatisere produktionen og begyndte at producere standardiserede blokke ved hjælp af værktøjsmaskiner. Automatisering af denne proces betød, at de resulterende blokke i det væsentlige var identiske, let kunne udskiftes, hvis de gik i stykker, og kunne produceres i store mængder.
Forestil dig nu, hvis Brunel skulle udføre dette arbejde for 20 forskellige skibsmodeller (Kubernetes-versioner) og for fem forskellige planeter med helt forskellige havstrømme og vinde (skyudbydere). Derudover krævedes det, at alle skibe (OpenShift-klynger), uanset de planeter, hvorpå der sejles, set fra kaptajnernes synspunkt (operatører, der styrer driften af klyngerne) opfører sig ens. For at fortsætte den maritime analogi er skibskaptajner overhovedet ligeglade med, hvilken slags riggeblokke (CRI-O) der bruges på deres skibe - det vigtigste for dem er, at disse blokke er stærke og pålidelige.
OpenShift 4, som en cloud-platform, står over for en meget lignende forretningsudfordring. Nye noder skal oprettes på tidspunktet for oprettelse af klynge, i tilfælde af fejl i en af noderne, eller ved skalering af klyngen. Når en ny node oprettes og initialiseres, skal kritiske værtskomponenter, inklusive CRI-O, konfigureres i overensstemmelse hermed. Som i enhver anden produktion skal der tilføres "råvarer" i begyndelsen. For skibe er råvarerne metal og træ. Men i tilfælde af at oprette en vært til at implementere containere i en OpenShift 4-klynge, skal du have konfigurationsfiler og API-leverede servere som input. OpenShift vil derefter levere det nødvendige niveau af automatisering gennem hele livscyklussen, tilbyde den nødvendige produktsupport til slutbrugere og dermed tjene på investeringen i platformen.
OpenShift 4 blev skabt på en sådan måde, at det giver mulighed for bekvemt at opdatere systemet gennem hele platformens livscyklus (for version 4.X) for alle større cloud computing-udbydere, virtualiseringsplatforme og endda bare metal-systemer. For at gøre dette skal noder oprettes på basis af udskiftelige elementer. Når en klynge kræver en ny version af Kubernetes, modtager den også den tilsvarende version af CRI-O på CoreOS. Da CRI-O-versionen er knyttet direkte til Kubernetes, forenkler dette i høj grad alle permutationer til test, fejlfinding eller supportformål. Derudover reducerer denne tilgang omkostninger for slutbrugere og Red Hat.
Dette er en fundamentalt ny måde at tænke på Kubernetes-klynger og lægger grundlaget for planlægning af nogle meget nyttige og overbevisende nye funktioner. CRI-O (Container Runtime Interface - Open Container Initiative, forkortet CRI-OCI) viste sig at være det mest succesrige valg til masseoprettelse af noder, der er nødvendige for at arbejde med OpenShift. CRI-O vil erstatte den tidligere brugte Docker-motor, der tilbyder OpenShift-brugere – ja, du hørte rigtigt – en kedelig containermotor skabt specielt til at arbejde med Kubernetes.
En verden af åbne containere
Verden har i lang tid bevæget sig mod åbne containere. Uanset om det er i Kubernetes eller på lavere niveauer, resulterer i et økosystem af innovation på alle niveauer.
Det hele startede med oprettelsen af Open Containers Initiative . På dette tidlige stadie af arbejdet blev containerspecifikationer dannet и . Dette sikrede, at værktøjerne kunne bruge en enkelt standard og et samlet format til at arbejde med dem. Specifikationer blev senere tilføjet , så brugerne nemt kan dele .
Kubernetes-fællesskabet udviklede derefter en enkelt standard for en pluggbar grænseflade, kaldet . Takket være dette var Kubernetes-brugere i stand til at forbinde forskellige motorer til at arbejde med containere ud over Docker.
Ingeniører hos Red Hat og Google så et markedsbehov for en containermotor, der kunne acceptere Kubelet-anmodninger over CRI-protokollen, og introducerede containere, der var kompatible med OCI-specifikationerne nævnt ovenfor. Så . Men undskyld mig, sagde vi ikke, at dette materiale ville være dedikeret til CRI-O? Faktisk er det, bare med udgivelsen projektet blev omdøbt til CRI-O.
Fig. 1.
Innovation med CRI-O og CoreOS
Med lanceringen af OpenShift 4-platformen blev det ændret , brugt som standard i platformen, og Docker blev erstattet af CRI-O, der tilbyder et omkostningseffektivt, stabilt, enkelt og kedeligt miljø til at køre en container, der udvikler sig parallelt med Kubernetes. Dette forenkler i høj grad cluster support og konfiguration. Konfiguration af containermotoren og værten, såvel som deres styring, bliver automatiseret i OpenShift 4.
Vent, hvordan er det her?
Det er rigtigt, med fremkomsten af OpenShift 4 er der ikke længere behov for at oprette forbindelse til individuelle værter og installere en containermotor, konfigurere lager, konfigurere søgeservere eller konfigurere et netværk. OpenShift 4-platformen er blevet fuldstændig redesignet til at bruge ikke kun med hensyn til slutbrugerapplikationer, men også med hensyn til grundlæggende handlinger på platformsniveau, såsom implementering af billeder, konfiguration af systemet eller installation af opdateringer.
Kubernetes har altid tilladt brugere at administrere applikationer ved at definere den ønskede tilstand og bruge , for at sikre, at den faktiske tilstand matcher måltilstanden så tæt som muligt. Det her åbner op for store muligheder fra både et udviklings- og driftsperspektiv. Udviklere kan definere den påkrævede tilstand ved til operatøren i form af en YAML- eller JSON-fil, og så kan operatøren oprette den påkrævede applikationsinstans i produktionsmiljøet, og driftstilstanden for denne instans vil fuldt ud svare til den angivne.
Ved at bruge Operators i platformen bringer OpenShift 4 dette nye paradigme (ved hjælp af konceptet set og faktisk tilstand) til styringen af RHEL CoreOS og CRI-O. Opgaverne med at konfigurere og administrere versioner af operativsystemet og containermotoren automatiseres ved hjælp af den såkaldte . MCO forenkler i høj grad klyngeadministratorens arbejde, idet det i det væsentlige automatiserer de sidste faser af installationen såvel som efterfølgende operationer efter installationen (dag to operationer). Alt dette gør OpenShift 4 til en ægte cloud-platform. Vi kommer ind på dette lidt senere.
Kørende containere
Brugere har haft mulighed for at bruge CRI-O-motoren i OpenShift-platformen siden version 3.7 i Tech Preview-status og fra version 3.9 i Generally Available-status (understøttet i øjeblikket). Derudover bruger Red Hat massivt i OpenShift Online siden version 3.10. Alt dette gjorde det muligt for teamet, der arbejdede på CRI-O, at få omfattende erfaring med masseopsendelse af containere på store Kubernetes-klynger. For at få en grundlæggende forståelse af, hvordan Kubernetes bruger CRI-O, lad os se på følgende illustration, som viser, hvordan arkitekturen fungerer.
Ris. 2. Hvordan containere fungerer i en Kubernetes-klynge
CRI-O forenkler oprettelsen af nye containerværter ved at synkronisere hele topniveauet ved initialisering af nye noder og ved frigivelse af nye versioner af OpenShift-platformen. Revision af hele platformen giver mulighed for transaktionsopdateringer/tilbageføringer og forhindrer også dødvande i afhængigheder mellem containerhalekernen, containermotoren, noderne (Kubelets) og Kubernetes Master-knuden. Ved central styring af alle platformskomponenter, med kontrol og versionering, er der altid en klar vej fra tilstand A til tilstand B. Dette forenkler opdateringsprocessen, forbedrer sikkerheden, forbedrer ydeevnerapportering og hjælper med at reducere omkostningerne ved opdateringer og installationer af nye versioner .
Demonstration af udskiftningselementers kraft
Som tidligere nævnt giver brug af Machine Config Operator til at administrere containerværten og containermotoren i OpenShift 4 et nyt niveau af automatisering, som ikke tidligere var muligt på Kubernetes-platformen. For at demonstrere de nye funktioner viser vi, hvordan du kan foretage ændringer i filen crio.conf. For at undgå at blive forvirret af terminologi, prøv at fokusere på resultaterne.
Lad os først oprette det, der kaldes en container runtime-konfiguration - Container Runtime Config. Tænk på det som en Kubernetes-ressource, der repræsenterer konfigurationen for CRI-O. I virkeligheden er det en specialiseret version af noget kaldet MachineConfig, som er enhver konfiguration, der er implementeret til en RHEL CoreOS-maskine som en del af en OpenShift-klynge.
Denne brugerdefinerede ressource, kaldet ContainerRuntimeConfig, blev oprettet for at gøre det nemmere for klyngeadministratorer at konfigurere CRI-O. Dette værktøj er kraftfuldt nok til, at det kun kan anvendes på visse noder afhængigt af MachineConfigPool-indstillingerne. Tænk på det som en gruppe af maskiner, der tjener samme formål.
Bemærk de sidste to linjer, som vi vil ændre i filen /etc/crio/crio.conf. Disse to linjer ligner meget linjerne i filen crio.conf, de er:
vi ContainerRuntimeConfig.yaml
Konklusion:
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
Lad os nu skubbe denne fil til Kubernetes-klyngen og kontrollere, at den faktisk blev oprettet. Bemærk venligst, at handlingen er nøjagtig den samme som med enhver anden Kubernetes-ressource:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Konklusion:
NAME AGE
set-log-and-pid 22h
Når vi har oprettet ContainerRuntimeConfig, skal vi ændre en af MachineConfigPools for at signalere til Kubernetes, at vi ønsker at anvende denne konfiguration på en specifik gruppe af maskiner i klyngen. I dette tilfælde vil vi ændre MachineConfigPool for masterknuderne:
oc edit MachineConfigPool/master
Konklusion (for klarhedens skyld er hovedessensen tilbage):
...
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 tidspunkt begynder MCO at oprette en ny crio.conf-fil til klyngen. I dette tilfælde kan den fuldstændigt færdige konfigurationsfil ses ved hjælp af Kubernetes API. Husk, ContainerRuntimeConfig er kun en specialiseret version af MachineConfig, så vi kan se resultatet ved at se på de relevante linjer i MachineConfigs:
oc get MachineConfigs | grep rendered
Konklusion:
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
Bemærk venligst, at den resulterende konfigurationsfil for masterknuderne var en nyere version end de originale konfigurationer. For at se den skal du køre følgende kommando. I forbifarten bemærker vi, at dette måske er en af de bedste 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
Konklusion:
pids_limit = 2048
Lad os nu sikre os, at konfigurationen er blevet anvendt på alle masterknudepunkter. 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
Lad os nu se på den installerede fil. Du vil se, at filen er blevet opdateret med de nye værdier for pid- og debug-direktiverne, som vi specificerede i ContainerRuntimeConfig-ressourcen. Selve elegancen:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Konklusion:
...
pids_limit = 2048
...
log_level = "debug"
...
Alle disse ændringer i klyngen blev foretaget uden selv at køre SSH. Alt arbejde blev udført ved at få adgang til Kuberentes master node. Det vil sige, at disse nye parametre kun blev konfigureret på masterknudepunkter. Arbejdernoderne ændrede sig ikke, hvilket demonstrerer fordelene ved Kubernetes-metoden ved at bruge specificerede og faktiske tilstande i forhold til containerværter og containermotorer med udskiftelige elementer.
Eksemplet ovenfor viser muligheden for at foretage ændringer i en lille OpenShift Container Platform 4-klynge med tre produktionsnoder eller en enorm produktionsklynge med 3000 noder. Under alle omstændigheder vil mængden af arbejde være den samme - og meget lille - bare konfigurer ContainerRuntimeConfig-filen, og skift en etiket i MachineConfigPool. Og du kan gøre dette med enhver version af OpenShift Container Platform 4.X, der kører Kubernetes gennem hele dens livscyklus.
Ofte udvikler teknologivirksomheder sig så hurtigt, at vi ikke er i stand til at forklare, hvorfor vi vælger bestemte teknologier til de underliggende komponenter. Containermotorer har historisk set været den komponent, som brugerne interagerer direkte med. Da containernes popularitet naturligt begyndte med fremkomsten af containermotorer, viser brugerne ofte interesse for dem. Dette er endnu en grund til, at Red Hat valgte CRI-O. Containere udvikler sig med fokus nu på orkestrering, og vi har fundet ud af, at CRI-O giver den bedste oplevelse, når du arbejder med OpenShift 4.
Kilde: www.habr.com