Plattform låter dig effektivisera skapandet , inklusive i molntjänstleverantörers infrastruktur, på virtualiseringsplattformar eller i barmetallsystem. För att skapa en riktigt molnbaserad plattform var vi tvungna att ta strikt kontroll över alla element som användes och därmed öka tillförlitligheten i en komplex automatiseringsprocess.
Den uppenbara lösningen var att använda Red Hat Enterprise Linux CoreOS (en variant av Red Hat Enterprise Linux) och CRI-O som standard, och här är varför...
Eftersom temat segling är mycket bra för att hitta analogier när man förklarar arbetet med Kubernetes och containrar, låt oss försöka prata om affärsproblemen som CoreOS och CRI-O löser med ett exempel . 1803 fick Marc Brunel uppdraget att tillverka 100 19 riggblock för den växande brittiska flottans behov. Ett riggblock är en typ av rigg som används för att fästa rep på segel. Fram till början av XNUMX-talet tillverkades dessa block för hand, men Brunel lyckades automatisera produktionen och började tillverka standardiserade block med hjälp av verktygsmaskiner. Automatisering av denna process innebar att de resulterande blocken var i huvudsak identiska, kunde lätt bytas ut om de gick sönder och kunde tillverkas i stora mängder.
Föreställ dig nu om Brunel var tvungen att göra detta arbete för 20 olika fartygsmodeller (Kubernetes-versioner) och för fem olika planeter med helt olika havsströmmar och vindar (molnleverantörer). Dessutom krävdes att alla fartyg (OpenShift-kluster), oavsett på vilka planeter navigering utförs, ur befälhavarnas (operatörer som sköter driften av klustren) uppför sig likadant. För att fortsätta den maritima analogin bryr sig fartygskaptenerna inte alls vilken typ av riggblock (CRI-O) som används på deras fartyg - det viktigaste för dem är att dessa block är starka och pålitliga.
OpenShift 4, som en molnplattform, står inför en mycket liknande affärsutmaning. Nya noder måste skapas när klustret skapas, i händelse av ett fel i någon av noderna eller vid skalning av klustret. När en ny nod skapas och initieras måste kritiska värdkomponenter, inklusive CRI-O, konfigureras därefter. Som i all annan produktion måste ”råvaror” tillföras i början. När det gäller fartyg är råvarorna metall och trä. Men i fallet med att skapa en värd för att distribuera behållare i ett OpenShift 4-kluster måste du ha konfigurationsfiler och API-försedda servrar som indata. OpenShift kommer då att tillhandahålla den erforderliga nivån av automatisering genom hela livscykeln, erbjuda det nödvändiga produktstödet till slutanvändarna och på så sätt få tillbaka investeringen i plattformen.
OpenShift 4 skapades på ett sådant sätt att det ger möjligheten att bekvämt uppdatera systemet under hela plattformens livscykel (för version 4.X) för alla större molnbaserade leverantörer, virtualiseringsplattformar och till och med blankmetallsystem. För att göra detta måste noder skapas på basis av utbytbara element. När ett kluster kräver en ny version av Kubernetes, får det också motsvarande version av CRI-O på CoreOS. Eftersom CRI-O-versionen är kopplad direkt till Kubernetes, förenklar detta avsevärt alla permutationer för test-, felsöknings- eller supportändamål. Dessutom minskar detta tillvägagångssätt kostnaderna för slutanvändare och Red Hat.
Detta är ett fundamentalt nytt sätt att tänka på Kubernetes-kluster och lägger grunden för planering av några mycket användbara och övertygande nya funktioner. CRI-O (Container Runtime Interface - Open Container Initiative, förkortat CRI-OCI) visade sig vara det mest framgångsrika valet för massskapandet av noder som är nödvändigt för att arbeta med OpenShift. CRI-O kommer att ersätta den tidigare använda Docker-motorn, som erbjuder OpenShift-användare – ja, du hörde rätt – en tråkig containermotor skapad speciellt för att arbeta med Kubernetes.
En värld av öppna containrar
Världen har gått mot öppna containrar under lång tid. Oavsett om det är i Kubernetes eller på lägre nivåer, resulterar i ett ekosystem av innovation på alla nivåer.
Allt började med skapandet av Open Containers Initiative . I detta tidiga skede av arbetet utformades containerspecifikationer и . Detta säkerställde att verktygen kunde använda en enda standard och ett enhetligt format för att arbeta med dem. Specifikationer har senare lagts till , så att användare enkelt kan dela .
Kubernetes-communityt utvecklade sedan en enda standard för ett pluggbart gränssnitt, kallad . Tack vare detta kunde Kubernetes-användare ansluta olika motorer för att arbeta med containrar förutom Docker.
Ingenjörer på Red Hat och Google såg ett marknadsbehov av en containermotor som kunde acceptera Kubelet-förfrågningar över CRI-protokollet och introducerade containrar som var kompatibla med OCI-specifikationerna ovan. Så . Men ursäkta mig, sa vi inte att detta material skulle tillägnas CRI-O? Egentligen är det så, bara med releasen projektet döptes om till CRI-O.
FIG. 1.
Innovation med CRI-O och CoreOS
I och med lanseringen av OpenShift 4-plattformen ändrades det , som används som standard i plattformen, och Docker ersattes av CRI-O, vilket erbjuder en kostnadseffektiv, stabil, enkel och tråkig miljö för att köra en container som utvecklas parallellt med Kubernetes. Detta förenklar avsevärt klusterstöd och konfiguration. Konfigurationen av containermotorn och värden, såväl som deras hantering, blir automatiserad inom OpenShift 4.
Vänta, hur är det här?
Det stämmer, med tillkomsten av OpenShift 4 finns det inte längre ett behov av att ansluta till enskilda värdar och installera en containermotor, konfigurera lagring, konfigurera sökservrar eller konfigurera ett nätverk. OpenShift 4-plattformen har gjorts om helt för att använda inte bara när det gäller slutanvändarapplikationer, utan också när det gäller grundläggande operationer på plattformsnivå som att distribuera bilder, konfigurera systemet eller installera uppdateringar.
Kubernetes har alltid tillåtit användare att hantera applikationer genom att definiera önskat tillstånd och använda , för att säkerställa att det faktiska tillståndet matchar måltillståndet så nära som möjligt. Detta öppnar stora möjligheter ur både ett utvecklings- och verksamhetsperspektiv. Utvecklare kan definiera önskat tillstånd med till operatören i form av en YAML- eller JSON-fil, och sedan kan operatören skapa den nödvändiga applikationsinstansen i produktionsmiljön, och drifttillståndet för denna instans kommer helt att motsvara den angivna.
Genom att använda Operatörer i plattformen, ger OpenShift 4 detta nya paradigm (med konceptet set och faktisk tillstånd) till hanteringen av RHEL CoreOS och CRI-O. Uppgifterna att konfigurera och hantera versioner av operativsystemet och containermotorn automatiseras med hjälp av den sk . MCO förenklar arbetet för klusteradministratören avsevärt, och automatiserar i huvudsak de sista stegen av installationen, såväl som efterföljande operationer efter installationen (dag två operationer). Allt detta gör OpenShift 4 till en riktig molnplattform. Vi kommer in på det här lite senare.
Körande containrar
Användare har haft möjlighet att använda CRI-O-motorn i OpenShift-plattformen sedan version 3.7 i Tech Preview-status och från version 3.9 i General Available-status (stöds för närvarande). Dessutom använder Red Hat massivt i OpenShift Online sedan version 3.10. Allt detta gjorde det möjligt för teamet som arbetade på CRI-O att skaffa sig omfattande erfarenhet av massuppskjutning av containrar på stora Kubernetes-kluster. För att få en grundläggande förståelse för hur Kubernetes använder CRI-O, låt oss titta på följande illustration, som visar hur arkitekturen fungerar.
Ris. 2. Hur behållare fungerar i ett Kubernetes-kluster
CRI-O förenklar skapandet av nya containervärdar genom att synkronisera hela toppnivån vid initialisering av nya noder och när nya versioner av OpenShift-plattformen släpps. Revidering av hela plattformen möjliggör transaktionsuppdateringar/återställningar och förhindrar även dödlägen i beroenden mellan containerns bakkärna, containermotorn, noderna (Kubelets) och Kubernetes Master-noden. Genom att centralt hantera alla plattformskomponenter, med kontroll och versionshantering, finns det alltid en tydlig väg från tillstånd A till tillstånd B. Detta förenklar uppdateringsprocessen, förbättrar säkerheten, förbättrar prestandarapporteringen och hjälper till att minska kostnaderna för uppdateringar och installationer av nya versioner .
Demonstrera kraften hos ersättningselement
Som tidigare nämnts, att använda Machine Config Operator för att hantera containervärden och containermotorn i OpenShift 4 ger en ny nivå av automatisering som tidigare inte var möjlig på Kubernetes-plattformen. För att demonstrera de nya funktionerna kommer vi att visa hur du kan göra ändringar i filen crio.conf. För att undvika att bli förvirrad av terminologi, försök att fokusera på resultaten.
Låt oss först skapa vad som kallas en containerruntime-konfiguration - Container Runtime Config. Se det som en Kubernetes-resurs som representerar konfigurationen för CRI-O. I verkligheten är det en specialiserad version av något som kallas MachineConfig, vilket är vilken konfiguration som helst som distribueras till en RHEL CoreOS-maskin som en del av ett OpenShift-kluster.
Denna anpassade resurs, kallad ContainerRuntimeConfig, skapades för att göra det enklare för klusteradministratörer att konfigurera CRI-O. Det här verktyget är tillräckligt kraftfullt för att det bara kan tillämpas på vissa noder beroende på MachineConfigPool-inställningarna. Se det som en grupp maskiner som tjänar samma syfte.
Lägg märke till de två sista raderna som vi kommer att ändra i filen /etc/crio/crio.conf. Dessa två rader är mycket lika raderna i filen crio.conf, de är:
vi ContainerRuntimeConfig.yaml
Slutsats:
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
Låt oss nu skicka den här filen till Kubernetes-klustret och kontrollera att den faktiskt skapades. Observera att operationen är exakt densamma som med alla andra Kubernetes-resurser:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Slutsats:
NAME AGE
set-log-and-pid 22h
När vi väl har skapat ContainerRuntimeConfig måste vi modifiera en av MachineConfigPools för att signalera till Kubernetes att vi vill tillämpa denna konfiguration på en specifik grupp av maskiner i klustret. I det här fallet kommer vi att ändra MachineConfigPool för masternoderna:
oc edit MachineConfigPool/master
Slutsats (för tydlighetens skull är huvudessensen kvar):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Vid denna tidpunkt börjar MCO skapa en ny crio.conf-fil för klustret. I det här fallet kan den helt färdiga konfigurationsfilen ses med hjälp av Kubernetes API. Kom ihåg att ContainerRuntimeConfig bara är en specialiserad version av MachineConfig, så vi kan se resultatet genom att titta på de relevanta raderna i MachineConfigs:
oc get MachineConfigs | grep rendered
Slutsats:
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
Observera att den resulterande konfigurationsfilen för masternoderna var en nyare version än de ursprungliga konfigurationerna. För att se det, kör följande kommando. I förbigående noterar vi att detta kanske är en av de bästa one-liners i Kubernetes historia:
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
Slutsats:
pids_limit = 2048
Låt oss nu se till att konfigurationen har tillämpats på alla masternoder. Först får vi en lista över noder i klustret:
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
Låt oss nu titta på den installerade filen. Du kommer att se att filen har uppdaterats med de nya värdena för pid- och debug-direktiven som vi angav i ContainerRuntimeConfig-resursen. Själva elegansen:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Slutsats:
...
pids_limit = 2048
...
log_level = "debug"
...
Alla dessa ändringar i klustret gjordes utan att ens köra SSH. Allt arbete gjordes genom att komma åt Kuberentes huvudnod. Det vill säga, dessa nya parametrar konfigurerades endast på masternoder. Arbetarnoderna ändrades inte, vilket visar fördelarna med Kubernetes-metoden att använda specificerade och faktiska tillstånd i förhållande till containervärdar och containermotorer med utbytbara element.
Exemplet ovan visar möjligheten att göra ändringar i ett litet OpenShift Container Platform 4-kluster med tre produktionsnoder eller ett enormt produktionskluster med 3000 4 noder. Hur som helst kommer mängden arbete att vara densamma - och mycket liten - bara konfigurera ContainerRuntimeConfig-filen och ändra en etikett i MachineConfigPool. Och du kan göra detta med vilken version av OpenShift Container Platform XNUMX.X som helst som kör Kubernetes under hela dess livscykel.
Ofta utvecklas teknikföretag så snabbt att vi inte kan förklara varför vi väljer vissa teknologier för de underliggande komponenterna. Containermotorer har historiskt sett varit den komponent som användare interagerar med direkt. Eftersom containers popularitet naturligtvis började med tillkomsten av containermotorer, visar användarna ofta intresse för dem. Detta är ytterligare en anledning till att Red Hat valde CRI-O. Containers utvecklas med fokus nu på orkestrering, och vi har funnit att CRI-O ger den bästa upplevelsen när du arbetar med OpenShift 4.
Källa: will.com