Container – i pipeline: CRI-O är nu som standard i OpenShift Container Platform 4

Plattform Red Hat OpenShift Container Platform 4 möjliggör att strömlinjeforma skapandet av värdar för distribution av containrar, inklusive i infrastruktur från molnleverantörer, på virtualisering plattformar eller i bare-metal system. För att skapa en verkligt molnbaserad plattform var vi tvungna att ha strikt kontroll över alla använda komponenter och på så sätt öka tillförlitligheten i den komplexa automatiseringsprocessen.

En uppenbar lösning 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 sjöfartstema är en mycket lyckad analogi för att förklara hur Kubernetes och containrar fungerar, låt oss illustrera de affärsproblem som CoreOS och CRI-O löser med hjälp av Brunels uppfinning för produktion av riggbockar. År 1803 ställdes Mark Brunel inför uppgiften att tillverka 100 000 riggbockar för behovet hos Storbritanniens växande flotta. En riggbock är en typ av utrustning som används för att fästa rep vid segel. Fram till början av 1800-talet tillverkades dessa block för hand, men Brunel lyckades automatisera produktionen och börja tillverka standardiserade block med hjälp av maskiner. Automatiseringen av denna process innebar att alla block fick en nästan identisk utformning, kunde enkelt bytas ut vid skada och kunde produceras i stora mängder.

Och nu, föreställ dig att Brunel skulle behöva utföra detta arbete för 20 olika modeller av fartyg (versioner av Kubernetes) och för fem olika planeter med helt olika havsströmmar och vindar (molnleverantörer). Dessutom var det nödvändigt att alla fartyg (OpenShift-kluster), oavsett vilka planeter de navigerade i, uppförde sig likadant ur kaptenernas (operatörer som styr kluster) perspektiv. Fortsätter vi med sjöanalogin, så spelar det ingen roll för kaptenerna vilka riggbockar (CRI-O) som används på deras fartyg – det som verkligen räknas är att dessa block är hållbara och pålitliga.

Inför OpenShift 4 står en mycket liknande affärsutmaning. Nya noder måste skapas vid klusterets skapande, vid ett fel på en av noderna, eller vid skalning av klustret. Vid skapande och initiering av en ny nod måste även värdens kritiska komponenter konfigureras, inklusive CRI-O. Precis som i vilken annan produktion som helst måste "råvaror" tillhandahållas i början. I fallet med fartyg utgör metall och trä råvarorna. Men vid skapandet av en värd för distribuerade containrar i OpenShift 4 måste konfigurationsfiler och tillgängliga API-servrar finnas som input. Därefter kommer OpenShift att säkerställa rätt nivå av automatisering under hela livscykeln, erbjuda nödvändigt produktstöd för slutanvändare och på så sätt återbetala investeringarna i plattformen.

OpenShift 4 skapades för att möjliggöra smidiga systemuppdateringar under hela plattformens livscykel (för versioner 4.X) för alla större leverantörer av molntjänster, virtualiseringsplattformar och till och med bare metal-system. För detta behöver noder skapas baserat på utbytbara enheter. När klustret kräver en ny version av Kubernetes får det också den motsvarande versionen av CRI-O på CoreOS. Eftersom versionen av CRI-O är direkt kopplad till Kubernetes förenklar detta i hög grad alla omarrangemang för testande, felsökning eller support. Dessutom möjliggör ett sådant tillvägagångssätt att sänka kostnaderna för slutanvändarna och Red Hat.

Detta är en principiellt ny syn på Kubernetes-kluster, vilket lägger grunden för planering av nya mycket användbara och attraktiva funktioner. CRI-O (Container Runtime Interface - Open Container Initiative, förkortat CRI-OCI) har visat sig vara det mest lyckade valet för massproduktion av noder som behövs för att arbeta med OpenShift. CRI-O ersätter den tidigare använda Docker-motorn och erbjuder OpenShift-användare en kostnadseffektiv, stabil, enkel och tråkig – ja, ni hörde rätt – en tråkig container-motor, skapad specifikt för att fungera med Kubernetes.

Världen av öppna containrar

Världen har länge rört sig mot öppna containrar. Oavsett om det är i Kubernetes eller på lägre nivåer, utvecklingen av containernormer leder till en innovationsekosystem på varje nivå.

Allt började med skapandet av Open Containers Initiative i juni 2015. Under denna tidiga fas formades specifikationer för containern bild (image) och körmiljö (runtime). Detta säkerställde att verktygen kunde använda en gemensam standard för containrar och ett enhetligt format för att arbeta med dem. Senare lades specifikationerna för distribution (distribution), vilket gjorde det möjligt för användare att enkelt dela containrar.

Därefter utvecklade Kubernetes-gemenskapen en enhetlig pluggbar gränssnitt (pluggable interface) som fick namnet Container Runtime Interface (CRI). Tack vare detta kunde användare av Kubernetes ansluta olika motorer för att arbeta med containrar utöver Docker.

Ingenjörer från Red Hat och Google såg en befintlig marknadsbehov för en containermotor som kunde ta emot begärningar från Kubelet via CRI-protokollet och presenterade containrar som var kompatibla med de nämnda OCI-specifikationerna. Så fanns OCID. Men vänta, vi sa ju att detta material skulle handla om CRI-O? Faktum är att det är sant, bara att med lanseringen av version 1.0 projektet döptes om till CRI-O.

Fig. 1.

Innovationer med CRI-O och CoreOS

Med lanseringen av OpenShift 4 ändrades den containermotor, som användes som standard i plattformen, och CRI-O ersatte Docker, vilket erbjöd en kostnadseffektiv, stabil, enkel och tråkig miljö för att köra containrar som utvecklas parallellt med Kubernetes. Detta förenklar tydligt underhåll och konfiguration av klustret. Konfiguration av containermotorer och värdar, samt hantering av dem, blir automatiserat inom OpenShift 4.

Vänta, hur går det till?

Precis så, med anloningen av OpenShift 4, finns det ingen anledning att längre ansluta till separata värdar och installera containermotorer, konfigurera lagringslösningar, ställa in servrar för att söka eller konfigurera nätverk. OpenShift 4-plattformen har helt omarbetats för att använda den Operator Framework inte bara ur perspektivet av slutanvändarapplikationer, utan också ur perspektivet av grundläggande operationer på plattformnivå, såsom distribution av bilder, systemkonfiguration eller installation av uppdateringar.

Kubernetes har alltid tillåtit användare att hantera applikationer genom att definiera det önskade tillståndet och använda kontroller (Controllers), för att säkerställa att det faktiska tillståndet så mycket som möjligt motsvarar det angivna tillståndet. Denna metod med att använda det angivna tillståndet och det faktiska tillståndet öppnar stora möjligheter både ur utvecklings- och driftsynpunkt. Utvecklare kan definiera det önskade tillståndet, överlämna det 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, med det arbetsmässiga tillståndet av den instansen fullständigt överensstämmande med det angivna.

Genom att använda operatörer (Operators) i plattformen, inför OpenShift 4 denna nya paradigm (med användning av begreppet angivet och faktiskt tillstånd) i hanteringen av RHEL CoreOS och CRI-O. Uppgifter som konfiguration och versionshantering av operativsystemet och containermotorn automatiseras med hjälp av den så kallade maskinkonfigurationsoperatören (Machine Config Operator, MCO). MCO förenklar betydligt arbetet för klusteradministratören, genom att i praktiken automatisera de sista stegen av installationen, samt efterföljande operationer efter installationen (day two operations). Allt detta gör OpenShift 4 till en riktig molnplattform. Vi kommer att gå djupare in på detta senare.

Körning av containrar

Användare har haft möjlighet att använda CRI-O-motorn i OpenShift-plattformen sedan version 3.7 i statusen Tech Preview och sedan version 3.9 i statusen Generally Available (för närvarande stöds). Dessutom använder Red Hat i stor utsträckning CRI-O för att köra produktionsarbetsbelastningar i OpenShift Online sedan version 3.10. Allt detta har gett teamet som arbetar med CRI-O enorm erfarenhet av massiv körning 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 ta en titt på följande illustration som visar hur arkitekturen fungerar.

Fig. 2. Hur containrar fungerar i ett Kubernetes-kluster

CRI-O förenklar skapandet av nya behållarhostar genom att synkronisera hela den övre nivån vid initiering av nya noder, samt vid lansering av nya versioner av OpenShift-plattformen. En granskning av hela plattformen tillåter transaktionella uppdateringar / återställningar och förhindrar ömsesidig blockering i beroenden mellan kärnan i behållarhosten, behållarmotorn, noderna (Kubelets) och Kubernetes masternod. Genom centraliserad hantering av alla komponenter i plattformen, med kontroll och hantering av versioner, kan man alltid spåra en tydlig väg från tillstånd A till tillstånd B. Detta förenklar uppdateringsprocessen, ökar säkerheten, förbättrar rapporteringen om prestanda och hjälper till att minska kostnaderna för uppdateringar och installation av nya versioner.

Demonstration av kraften i utbytbara komponenter

Som nämnts tidigare ger användningen av Machine Config Operator för att hantera behållarhosten och behållar motorn i OpenShift 4 en ny nivå av automatisering som inte var möjlig tidigare på Kubernetes-plattformen. För att visa de nya möjligheterna kommer vi att visa hur du kan göra ändringar i filen crio.conf. För att undvika förvirring i terminologin, försök att fokusera på resultaten.

Först, låt oss skapa det som kallas Container Runtime Config. Tänk på det som en typ av Kubernetes-resurs som representerar konfigurationen för CRI-O. I verkligheten är detta en specialiserad version av det som kallas MachineConfig, som representerar vilken konfiguration som helst som distribueras på RHEL CoreOS-maskinen i ett OpenShift-kluster.

Denna anpassade resurs, kallad ContainerRuntimeConfig, har utformats för att underlätta för klusteradministratörer att ställa in CRI-O. Det är ett tillräckligt kraftfullt verktyg för att det kan tillämpas endast på specifika noder beroende på inställningarna för MachineConfigPool. Tänk på det som en grupp av maskiner som tjänar samma syfte.

Observera de två sista raderna som vi kommer att ändra i filen /etc/crio/crio.conf. Dessa två rader liknar väldigt mycket 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

Nu skickar vi den här filen till Kubernetes-klustret och kontrollerar att den verkligen har skapats. Observera att arbetet sker på exakt samma sätt som med alla andra Kubernetes-resurser:

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

Slutsats:

NAMN              ÅLDER
set-log-and-pid   22h

När vi har skapat ContainerRuntimeConfig behöver vi ändra en av MachineConfigPools för att informera Kubernetes om att vi vill tillämpa denna konfiguration på en viss grupp maskiner i klustret. I det här fallet kommer vi att ändra MachineConfigPool för master-noder:

oc edit MachineConfigPool/master

Utdata (för tydlighet har vi lämnat huvudpunkten):

...
metadata:
 creationTimestamp: 2019-04-10T23:42:28Z
 generation: 1
 labels:
   debug-crio: config-log-and-pid
   operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...

Vid det här laget börjar MCO skapa en ny fil crio.conf för klustret. Den fullständiga konfigurationsfilen kan ses via Kubernetes API. Kom ihåg, ContainerRuntimeConfig är bara 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 erhållna konfigurationsfilen för master-noder var en nyare version än de ursprungliga konfigurationerna. För att visa den, kör följande kommando. Låt oss också notera att detta kan vara ett av de bästa enradiga skripten 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

Nu ska vi bekräfta att konfigurationen har tillämpats på alla master-noder. Först får vi en lista över noder i klustret:

oc get node | grep master

Utdata:

ip-10-0-135-153.us-east-2.compute.internal   Klar master 23h v1.12.4+509916ce1

ip-10-0-154-0.us-east-2.compute.internal     Klar master 23h v1.12.4+509916ce1

ip-10-0-166-79.us-east-2.compute.internal    Klar master 23h v1.12.4+509916ce1

Nu ska vi granska den installerade filen. Du kommer att se att filen har uppdaterats med de nya värdena för direktiven pid och debug 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 köra SSH. Hela arbetet utfördes genom att kontakta Kubernetes master-noden. Det vill säga, dessa nya parametrar konfigurerades endast på master-noderna. Arbetsnoderna ändrades inte, vilket visar fördelarna med Kubernetes-metodologin med hjälp av specificerade och aktuella tillstånd i förhållande till containerhosts och containermotorer med utbytbara komponenter.

Exemplet ovan visar möjligheten att göra ändringar i ett litet OpenShift Container Platform 4-kluster med tre arbetsnoder eller i ett stort produktionskluster med 3000 noder. I båda fallen kommer arbetsinsatsen att vara densamma – och ganska liten – det räcker att konfigurera filen ContainerRuntimeConfig och ändra en etikett i MachineConfigPool. Och du kan göra detta med vilken version av Kubernetes-plattformen OpenShift Container Platform 4.X som helst 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 grundkomponenterna. Containermotorer har historiskt varit den komponent som användare interagerar direkt med. Eftersom populariteten av containrar historiskt sett började med framväxten av containermotorer, visar användare ofta intresse för dem. Det är ännu en anledning till varför Red Hat valde CRI-O. Containrar utvecklas, och idag är fokus på orkestrering, och vi har kommit fram till att CRI-O ger den bästa upplevelsen med OpenShift 4.

Källa: habr.com