Platform Hiermee kunt u de creatie stroomlijnen , ook in de infrastructuur van cloudserviceproviders, op virtualisatieplatforms of in bare-metal-systemen. Om een echt cloudgebaseerd platform te creëren, moesten we alle gebruikte elementen strikt onder controle houden en zo de betrouwbaarheid van een complex automatiseringsproces vergroten.
De voor de hand liggende oplossing was om Red Hat Enterprise Linux CoreOS (een variant van Red Hat Enterprise Linux) en CRI-O als standaard te gebruiken, en dit is waarom...
Omdat het onderwerp zeilen een zeer goed onderwerp is om analogieën te vinden bij het uitleggen van het werk van Kubernetes en containers, laten we proberen te praten over de zakelijke problemen die CoreOS en CRI-O oplossen, aan de hand van een voorbeeld . In 1803 kreeg Marc Brunel de opdracht om 100 tuigageblokken te produceren voor de behoeften van de groeiende Britse marine. Een tuigageblok is een soort tuigage dat wordt gebruikt om touwen aan zeilen te bevestigen. Tot het begin van de 19e eeuw werden deze blokken met de hand gemaakt, maar Brunel slaagde erin de productie te automatiseren en begon gestandaardiseerde blokken te produceren met behulp van werktuigmachines. Automatisering van dit proces betekende dat de resulterende blokken in wezen identiek waren, gemakkelijk konden worden vervangen als ze kapot waren, en in grote hoeveelheden konden worden geproduceerd.
Stel je nu voor dat Brunel dit werk zou moeten doen voor twintig verschillende scheepsmodellen (Kubernetes-versies) en voor vijf verschillende planeten met totaal verschillende zeestromingen en winden (cloudproviders). Bovendien was het vereist dat alle schepen (OpenShift-clusters), ongeacht de planeten waarop de navigatie wordt uitgevoerd, vanuit het oogpunt van de kapiteins (operatoren die de werking van de clusters beheren) zich hetzelfde gedroegen. Om de maritieme analogie voort te zetten: het maakt kapiteins van schepen helemaal niet uit wat voor soort tuigageblokken (CRI-O) op hun schepen worden gebruikt - het belangrijkste voor hen is dat deze blokken sterk en betrouwbaar zijn.
OpenShift 4 staat als cloudplatform voor een zeer vergelijkbare zakelijke uitdaging. Nieuwe knooppunten moeten worden gemaakt op het moment dat het cluster wordt gemaakt, in het geval van een storing in een van de knooppunten of bij het schalen van het cluster. Wanneer een nieuw knooppunt wordt gemaakt en geïnitialiseerd, moeten kritieke hostcomponenten, inclusief CRI-O, dienovereenkomstig worden geconfigureerd. Zoals bij elke andere productie moeten er in het begin “grondstoffen” worden aangevoerd. Bij schepen zijn de grondstoffen metaal en hout. Als u echter een host maakt voor het inzetten van containers in een OpenShift 4-cluster, heeft u configuratiebestanden en door API's geleverde servers als invoer nodig. OpenShift zorgt vervolgens gedurende de gehele levenscyclus voor het benodigde automatiseringsniveau, biedt de benodigde productondersteuning aan eindgebruikers en verdient zo de investering in het platform terug.
OpenShift 4 is zo gemaakt dat het de mogelijkheid biedt om het systeem gemakkelijk te updaten gedurende de gehele levenscyclus van het platform (voor versies 4.X) voor alle grote cloud computing-providers, virtualisatieplatforms en zelfs bare metal-systemen. Om dit te doen, moeten knooppunten worden gemaakt op basis van uitwisselbare elementen. Wanneer een cluster een nieuwe versie van Kubernetes nodig heeft, ontvangt het ook de bijbehorende versie van CRI-O op CoreOS. Omdat de CRI-O-versie rechtstreeks aan Kubernetes is gekoppeld, vereenvoudigt dit de permutaties voor test-, probleemoplossings- of ondersteuningsdoeleinden aanzienlijk. Bovendien verlaagt deze aanpak de kosten voor eindgebruikers en Red Hat.
Dit is een fundamenteel nieuwe manier van denken over Kubernetes-clusters en legt de basis voor het plannen van een aantal zeer nuttige en aantrekkelijke nieuwe functies. CRI-O (Container Runtime Interface - Open Container Initiative, afgekort CRI-OCI) bleek de meest succesvolle keuze voor het massaal creëren van knooppunten die nodig zijn om met OpenShift te werken. CRI-O zal de eerder gebruikte Docker-engine vervangen en OpenShift-gebruikers aanbieden – ja, je hebt het goed gehoord – een saaie containerengine die speciaal is gemaakt om met Kubernetes te werken.
De wereld van open containers
De wereld beweegt zich al lange tijd richting open containers. Of het nu in Kubernetes is, of op lagere niveaus, resulteert in een ecosysteem van innovatie op elk niveau.
Het begon allemaal met de oprichting van het Open Containers Initiative . In dit vroege stadium van het werk werden de containerspecificaties opgesteld и . Dit zorgde ervoor dat de tools één standaard konden gebruiken en een uniform formaat om ermee te werken. Specificaties zijn later toegevoegd , waardoor gebruikers gemakkelijk kunnen delen .
De Kubernetes-gemeenschap ontwikkelde vervolgens één standaard voor een plug-in interface, genaamd . Hierdoor konden Kubernetes-gebruikers verschillende motoren aansluiten om naast Docker met containers te werken.
Ingenieurs van Red Hat en Google zagen in de markt behoefte aan een containerengine die Kubelet-verzoeken via het CRI-protocol kon accepteren en introduceerden containers die compatibel waren met de hierboven genoemde OCI-specificaties. Dus . Maar excuseer mij, zeiden we niet dat dit materiaal gewijd zou zijn aan CRI-O? Eigenlijk is dat zo, alleen met de release het project werd omgedoopt tot CRI-O.
Fig. 1.
Innovatie met CRI-O en CoreOS
Met de lancering van het OpenShift 4-platform werd dit veranderd , standaard gebruikt in het platform, en Docker werd vervangen door CRI-O, wat een kosteneffectieve, stabiele, eenvoudige en saaie omgeving biedt voor het draaien van een container die zich parallel met Kubernetes ontwikkelt. Dit vereenvoudigt de clusterondersteuning en -configuratie aanzienlijk. De configuratie van de containerengine en host, evenals het beheer ervan, wordt geautomatiseerd binnen OpenShift 4.
Wacht, hoe is dit?
Dat klopt, met de komst van OpenShift 4 is het niet langer nodig om verbinding te maken met individuele hosts en een containerengine te installeren, opslag te configureren, zoekservers te configureren of een netwerk te configureren. Het OpenShift 4-platform is volledig opnieuw ontworpen om de niet alleen in termen van eindgebruikersapplicaties, maar ook in termen van basisbewerkingen op platformniveau, zoals het implementeren van images, het configureren van het systeem of het installeren van updates.
Kubernetes heeft gebruikers altijd de mogelijkheid gegeven om applicaties te beheren door de gewenste status te definiëren en te gebruiken , om ervoor te zorgen dat de werkelijke toestand zo goed mogelijk overeenkomt met de doeltoestand. Dit biedt geweldige kansen vanuit zowel ontwikkelings- als operationeel perspectief. Ontwikkelaars kunnen de vereiste status definiëren door aan de operator in de vorm van een YAML- of JSON-bestand, waarna de operator het vereiste applicatie-exemplaar in de productieomgeving kan maken, en de operationele status van dit exemplaar zal volledig overeenkomen met de gespecificeerde.
Door Operators in het platform te gebruiken, brengt OpenShift 4 dit nieuwe paradigma (met behulp van het concept van de ingestelde en feitelijke status) naar het beheer van RHEL CoreOS en CRI-O. De taken van het configureren en beheren van versies van het besturingssysteem en de containerengine worden geautomatiseerd met behulp van de zogenaamde . MCO vereenvoudigt het werk van de clusterbeheerder aanzienlijk, waarbij in wezen de laatste fasen van de installatie worden geautomatiseerd, evenals de daaropvolgende bewerkingen na de installatie (bewerkingen op dag twee). Dit alles maakt OpenShift 4 tot een echt cloudplatform. We zullen hier wat later op ingaan.
Rennende containers
Gebruikers hebben de mogelijkheid gehad om de CRI-O-engine in het OpenShift-platform te gebruiken sinds versie 3.7 in de Tech Preview-status en vanaf versie 3.9 in de algemeen beschikbare status (momenteel ondersteund). Bovendien maakt Red Hat massaal gebruik van in OpenShift Online sinds versie 3.10. Hierdoor kon het team dat aan CRI-O werkte uitgebreide ervaring opdoen met het massaal lanceren van containers op grote Kubernetes-clusters. Laten we, om een basiskennis te krijgen van hoe Kubernetes CRI-O gebruikt, naar de volgende illustratie kijken, die laat zien hoe de architectuur werkt.
Rijst. 2. Hoe containers werken in een Kubernetes-cluster
CRI-O vereenvoudigt het maken van nieuwe containerhosts door het volledige topniveau te synchroniseren bij het initialiseren van nieuwe knooppunten en bij het uitbrengen van nieuwe versies van het OpenShift-platform. Revisie van het gehele platform maakt transactionele updates/rollbacks mogelijk en voorkomt ook impasses in de afhankelijkheden tussen de containerstaartkern, de containerengine, knooppunten (Kubelets) en het Kubernetes Master-knooppunt. Door alle platformcomponenten centraal te beheren, met controle en versiebeheer, is er altijd een duidelijk pad van status A naar status B. Dit vereenvoudigt het updateproces, verbetert de beveiliging, verbetert de prestatierapportage en helpt de kosten van updates en installaties van nieuwe versies te verlagen .
De kracht van vervangende elementen demonstreren
Zoals eerder vermeld biedt het gebruik van de Machine Config Operator voor het beheren van de containerhost en containerengine in OpenShift 4 een nieuw niveau van automatisering dat voorheen niet mogelijk was op het Kubernetes-platform. Om de nieuwe functies te demonstreren, laten we zien hoe u wijzigingen kunt aanbrengen in het bestand crio.conf. Om te voorkomen dat u door de terminologie in de war raakt, kunt u zich op de resultaten concentreren.
Laten we eerst een zogenaamde containerruntimeconfiguratie maken: Container Runtime Config. Zie het als een Kubernetes-bron die de configuratie voor CRI-O vertegenwoordigt. In werkelijkheid is het een gespecialiseerde versie van iets dat MachineConfig heet, wat elke configuratie is die wordt geïmplementeerd op een RHEL CoreOS-machine als onderdeel van een OpenShift-cluster.
Deze aangepaste bron, genaamd ContainerRuntimeConfig, is gemaakt om het voor clusterbeheerders eenvoudiger te maken CRI-O te configureren. Deze tool is krachtig genoeg om alleen op bepaalde knooppunten te kunnen worden toegepast, afhankelijk van de MachineConfigPool-instellingen. Zie het als een groep machines die hetzelfde doel dienen.
Let op de laatste twee regels die we gaan veranderen in het bestand /etc/crio/crio.conf. Deze twee regels lijken erg op de regels in het crio.conf-bestand, ze zijn:
vi ContainerRuntimeConfig.yaml
Conclusie:
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
Laten we dit bestand nu naar het Kubernetes-cluster pushen en controleren of het daadwerkelijk is gemaakt. Houd er rekening mee dat de werking precies hetzelfde is als bij elke andere Kubernetes-bron:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Conclusie:
NAME AGE
set-log-and-pid 22h
Nadat we de ContainerRuntimeConfig hebben gemaakt, moeten we een van de MachineConfigPools aanpassen om aan Kubernetes te laten weten dat we deze configuratie willen toepassen op een specifieke groep machines in het cluster. In dit geval zullen we de MachineConfigPool voor de masterknooppunten wijzigen:
oc edit MachineConfigPool/master
Conclusie (voor de duidelijkheid blijft de essentie over):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Op dit punt begint MCO een nieuw crio.conf-bestand voor het cluster te maken. In dit geval kan het volledig voltooide configuratiebestand worden bekeken met behulp van de Kubernetes API. Houd er rekening mee dat ContainerRuntimeConfig slechts een gespecialiseerde versie van MachineConfig is, dus we kunnen het resultaat zien door naar de relevante regels in MachineConfigs te kijken:
oc get MachineConfigs | grep rendered
Conclusie:
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
Houd er rekening mee dat het resulterende configuratiebestand voor de hoofdknooppunten een nieuwere versie was dan de originele configuraties. Om het te bekijken, voert u de volgende opdracht uit. Terloops merken we op dat dit wellicht één van de beste oneliners uit de geschiedenis van Kubernetes is:
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
Conclusie:
pids_limit = 2048
Laten we er nu voor zorgen dat de configuratie op alle hoofdknooppunten is toegepast. Eerst krijgen we een lijst met knooppunten in het cluster:
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
Laten we nu naar het geïnstalleerde bestand kijken. U zult zien dat het bestand is bijgewerkt met de nieuwe waarden voor de pid- en debug-richtlijnen die we hebben opgegeven in de ContainerRuntimeConfig-bron. Elegantie zelf:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Conclusie:
...
pids_limit = 2048
...
log_level = "debug"
...
Al deze wijzigingen in het cluster zijn aangebracht zonder zelfs maar SSH uit te voeren. Al het werk werd gedaan door toegang te krijgen tot het Kuberentes-masterknooppunt. Dat wil zeggen dat deze nieuwe parameters alleen op hoofdknooppunten zijn geconfigureerd. De werkknooppunten zijn niet veranderd, wat de voordelen aantoont van de Kubernetes-methodologie van het gebruik van gespecificeerde en feitelijke statussen in relatie tot containerhosts en containermotoren met verwisselbare elementen.
Het bovenstaande voorbeeld toont de mogelijkheid om wijzigingen aan te brengen in een klein OpenShift Container Platform 4-cluster met drie productieknooppunten of een enorm productiecluster met 3000 knooppunten. In ieder geval zal de hoeveelheid werk hetzelfde zijn (en zeer klein) door gewoon het ContainerRuntimeConfig-bestand te configureren en één label te wijzigen in MachineConfigPool. En u kunt dit doen met elke versie van het OpenShift Container Platform 4.X waarop Kubernetes draait gedurende de gehele levenscyclus.
Vaak evolueren technologiebedrijven zo snel dat we niet kunnen verklaren waarom we bepaalde technologieën kiezen voor de onderliggende componenten. Containermotoren zijn van oudsher het onderdeel waarmee gebruikers rechtstreeks communiceren. Omdat de populariteit van containers natuurlijk begon met de komst van containermotoren, tonen gebruikers er vaak interesse in. Dit is nog een reden waarom Red Hat voor CRI-O heeft gekozen. Containers evolueren nu met de focus op orkestratie, en we hebben ontdekt dat CRI-O de beste ervaring biedt bij het werken met OpenShift 4.
Bron: www.habr.com