Plataforma permet agilitzar la creació , fins i tot en la infraestructura dels proveïdors de serveis al núvol, en plataformes de virtualització o en sistemes de metall nu. Per crear una plataforma realment basada en núvol, hem hagut de prendre un control estricte de tots els elements utilitzats i així augmentar la fiabilitat d'un procés d'automatització complex.
La solució òbvia era utilitzar Red Hat Enterprise Linux CoreOS (una variant de Red Hat Enterprise Linux) i CRI-O com a estàndard, i aquí és per què...
Com que el tema de la vela és molt bo per trobar analogies a l'hora d'explicar el treball de Kubernetes i contenidors, intentem parlar dels problemes empresarials que solucionen CoreOS i CRI-O, fent servir un exemple. . El 1803, Marc Brunel va rebre l'encàrrec de produir 100 blocs d'aparell per a les necessitats de la creixent marina britànica. Un bloc d'aparell és un tipus d'aparell que s'utilitza per subjectar cordes a les veles. Fins a principis del segle XIX, aquests blocs es feien a mà, però Brunel va aconseguir automatitzar la producció i va començar a produir blocs estandarditzats amb màquines-eina. L'automatització d'aquest procés significava que els blocs resultants eren essencialment idèntics, es podien substituir fàcilment si es trenquen i es podien produir en grans quantitats.
Ara imagineu-vos si Brunel hagués de fer aquest treball per a 20 models de vaixells diferents (versions Kubernetes) i per a cinc planetes diferents amb corrents i vents marins completament diferents (proveïdors de núvols). A més, s'exigia que totes les naus (clústers OpenShift), independentment dels planetes on es faci la navegació, des del punt de vista dels capitans (operadors que gestionen el funcionament dels clústers) es comportin igual. Per continuar amb l'analogia marítima, als capitans dels vaixells no els importa gens quin tipus de blocs d'aparell (CRI-O) s'utilitzen als seus vaixells; el més important per a ells és que aquests blocs són forts i fiables.
OpenShift 4, com a plataforma al núvol, s'enfronta a un repte empresarial molt similar. S'han de crear nous nodes en el moment de la creació del clúster, en cas d'error en un dels nodes o quan s'escala el clúster. Quan es crea i inicialitza un nou node, els components crítics de l'amfitrió, inclòs el CRI-O, s'han de configurar en conseqüència. Com en qualsevol altra producció, cal subministrar “matèries primeres” al principi. En el cas dels vaixells, les matèries primeres són el metall i la fusta. Tanmateix, en el cas de crear un amfitrió per desplegar contenidors en un clúster OpenShift 4, cal que tingueu fitxers de configuració i servidors proporcionats per l'API com a entrada. Aleshores, OpenShift proporcionarà el nivell d'automatització requerit durant tot el cicle de vida, oferint el suport de producte necessari als usuaris finals i recuperant així la inversió a la plataforma.
OpenShift 4 es va crear de manera que ofereix la possibilitat d'actualitzar còmodament el sistema durant tot el cicle de vida de la plataforma (per a les versions 4.X) per a tots els principals proveïdors de computació en núvol, plataformes de virtualització i fins i tot sistemes de metall nu. Per fer-ho, s'han de crear nodes a partir d'elements intercanviables. Quan un clúster requereix una nova versió de Kubernetes, també rep la versió corresponent de CRI-O a CoreOS. Com que la versió CRI-O està lligada directament a Kubernetes, això simplifica enormement qualsevol permutació per a proves, resolució de problemes o assistència. A més, aquest enfocament redueix els costos per als usuaris finals i Red Hat.
Aquesta és una manera fonamentalment nova de pensar sobre els clústers de Kubernetes i posa les bases per planificar algunes funcions noves molt útils i atractives. CRI-O (Container Runtime Interface - Open Container Initiative, abreujat CRI-OCI) va resultar ser l'opció més exitosa per a la creació massiva de nodes que és necessària per treballar amb OpenShift. CRI-O substituirà el motor Docker utilitzat anteriorment, oferint als usuaris OpenShift – Sí, heu sentit bé – un motor de contenidors avorrit creat específicament per treballar amb Kubernetes.
El món dels contenidors oberts
El món fa temps que s'està movent cap als contenidors oberts. Ja sigui a Kubernetes o a nivells inferiors, resulta en un ecosistema d'innovació a tots els nivells.
Tot va començar amb la creació de l'Open Containers Initiative . En aquesta primera etapa del treball, es van formar les especificacions dels contenidors и . Això garanteix que les eines poguessin utilitzar un únic estàndard i un format unificat per treballar amb ells. Més tard es van afegir especificacions , que permet als usuaris compartir fàcilment .
Aleshores, la comunitat de Kubernetes va desenvolupar un estàndard únic per a una interfície connectable, anomenat . Gràcies a això, els usuaris de Kubernetes van poder connectar diversos motors per treballar amb contenidors a més de Docker.
Els enginyers de Red Hat i Google van veure la necessitat del mercat d'un motor de contenidors que pogués acceptar sol·licituds de Kubelet mitjançant el protocol CRI i van introduir contenidors compatibles amb les especificacions OCI esmentades anteriorment. Tan . Però disculpeu-me, no hem dit que aquest material es dedicaria a CRI-O? En realitat ho és, només amb el llançament el projecte va passar a anomenar-se CRI-O.
Fig. 1.
Innovació amb CRI-O i CoreOS
Amb el llançament de la plataforma OpenShift 4, es va canviar , utilitzat per defecte a la plataforma, i Docker va ser substituït per CRI-O, oferint un entorn rendible, estable, senzill i avorrit per executar un contenidor que es desenvolupa en paral·lel amb Kubernetes. Això simplifica molt el suport i la configuració del clúster. La configuració del motor de contenidors i l'amfitrió, així com la seva gestió, s'automatitza dins d'OpenShift 4.
Espera, com és això?
Així és, amb l'arribada d'OpenShift 4, ja no cal connectar-se a hosts individuals i instal·lar un motor de contenidors, configurar l'emmagatzematge, configurar servidors de cerca o configurar una xarxa. La plataforma OpenShift 4 ha estat completament redissenyada per utilitzar-la no només pel que fa a les aplicacions d'usuari final, sinó també pel que fa a les operacions bàsiques a nivell de plataforma, com ara desplegar imatges, configurar el sistema o instal·lar actualitzacions.
Kubernetes sempre ha permès als usuaris gestionar aplicacions definint l'estat desitjat i utilitzant-los , per garantir que l'estat real coincideixi amb l'estat objectiu el més a prop possible. Això obre grans oportunitats tant des del punt de vista de desenvolupament com d'operacions. Els desenvolupadors poden definir l'estat requerit per a l'operador en forma d'un fitxer YAML o JSON i, a continuació, l'operador pot crear la instància d'aplicació necessària a l'entorn de producció i l'estat de funcionament d'aquesta instància correspondrà completament a l'especificat.
Mitjançant l'ús d'operadors a la plataforma, OpenShift 4 aporta aquest nou paradigma (utilitzant el concepte de conjunt i estat real) a la gestió de RHEL CoreOS i CRI-O. Les tasques de configuració i gestió de versions del sistema operatiu i del motor de contenidors estan automatitzades mitjançant l'anomenat . MCO simplifica molt el treball de l'administrador del clúster, bàsicament automatitzant les últimes etapes d'instal·lació, així com les operacions posteriors a la instal·lació (operacions del segon dia). Tot això fa d'OpenShift 4 una veritable plataforma al núvol. Ens hi posarem una mica més tard.
Contenidors en funcionament
Els usuaris han tingut l'oportunitat d'utilitzar el motor CRI-O a la plataforma OpenShift des de la versió 3.7 a l'estat Tech Preview i des de la versió 3.9 a l'estat Generally Available (actualment compatible). A més, Red Hat utilitza massivament a OpenShift Online des de la versió 3.10. Tot això va permetre a l'equip que treballa a CRI-O adquirir una àmplia experiència en el llançament massiu de contenidors en grans clústers de Kubernetes. Per obtenir una comprensió bàsica de com Kubernetes utilitza CRI-O, mirem la il·lustració següent, que mostra com funciona l'arquitectura.
Arròs. 2. Com funcionen els contenidors en un clúster de Kubernetes
CRI-O simplifica la creació de nous amfitrions de contenidors sincronitzant tot el nivell superior en inicialitzar nous nodes i en llançar noves versions de la plataforma OpenShift. La revisió de tota la plataforma permet actualitzacions/retrocesos transaccionals i també evita els bloquejos en les dependències entre el nucli de la cua del contenidor, el motor del contenidor, els nodes (Kubelets) i el node mestre de Kubernetes. Mitjançant la gestió centralitzada de tots els components de la plataforma, amb control i control de versions, sempre hi ha un camí clar des de l'estat A fins a l'estat B. Això simplifica el procés d'actualització, millora la seguretat, millora els informes de rendiment i ajuda a reduir el cost de les actualitzacions i instal·lacions de les noves versions. .
Demostració del poder dels elements de substitució
Com s'ha esmentat anteriorment, utilitzar l'operador de configuració de la màquina per gestionar l'amfitrió del contenidor i el motor del contenidor a OpenShift 4 proporciona un nou nivell d'automatització que abans no era possible a la plataforma Kubernetes. Per demostrar les noves funcions, mostrarem com podeu fer canvis al fitxer crio.conf. Per evitar confondre's amb la terminologia, intenta centrar-te en els resultats.
Primer, creem el que s'anomena una configuració d'execució del contenidor: Config. d'execució del contenidor. Penseu-hi com un recurs de Kubernetes que representa la configuració de CRI-O. En realitat, és una versió especialitzada d'alguna cosa anomenada MachineConfig, que és qualsevol configuració que es desplega a una màquina RHEL CoreOS com a part d'un clúster OpenShift.
Aquest recurs personalitzat, anomenat ContainerRuntimeConfig, es va crear per facilitar als administradors del clúster configurar CRI-O. Aquesta eina és prou potent que només es pot aplicar a determinats nodes en funció de la configuració de MachineConfigPool. Penseu en això com un grup de màquines que serveixen per a la mateixa finalitat.
Observeu les dues últimes línies que canviarem al fitxer /etc/crio/crio.conf. Aquestes dues línies són molt semblants a les línies del fitxer crio.conf, són:
vi ContainerRuntimeConfig.yaml
Conclusió:
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
Ara enviem aquest fitxer al clúster de Kubernetes i comprovem que s'ha creat realment. Tingueu en compte que l'operació és exactament la mateixa que amb qualsevol altre recurs de Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Conclusió:
NAME AGE
set-log-and-pid 22h
Un cop hàgim creat el ContainerRuntimeConfig, hem de modificar un dels MachineConfigPools per indicar a Kubernetes que volem aplicar aquesta configuració a un grup específic de màquines del clúster. En aquest cas canviarem el MachineConfigPool per als nodes mestres:
oc edit MachineConfigPool/master
Conclusió (per a més claredat, es deixa l'essència principal):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
En aquest punt, MCO comença a crear un nou fitxer crio.conf per al clúster. En aquest cas, el fitxer de configuració completament acabat es pot veure mitjançant l'API de Kubernetes. Recordeu que ContainerRuntimeConfig és només una versió especialitzada de MachineConfig, de manera que podem veure el resultat mirant les línies rellevants a MachineConfigs:
oc get MachineConfigs | grep rendered
Conclusió:
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
Tingueu en compte que el fitxer de configuració resultant per als nodes mestres era una versió més recent que les configuracions originals. Per veure'l, executeu l'ordre següent. De passada, observem que aquesta és potser una de les millors línies de la història de Kubernetes:
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
Conclusió:
pids_limit = 2048
Ara ens assegurem que la configuració s'ha aplicat a tots els nodes mestres. Primer obtenim una llista de nodes del clúster:
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
Ara mirem el fitxer instal·lat. Veureu que el fitxer s'ha actualitzat amb els nous valors per a les directives pid i debug que hem especificat al recurs ContainerRuntimeConfig. Elegància mateixa:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Conclusió:
...
pids_limit = 2048
...
log_level = "debug"
...
Tots aquests canvis al clúster es van fer sense tan sols executar SSH. Tot el treball es va fer accedint al node mestre Kuberentes. És a dir, aquests nous paràmetres es van configurar només als nodes mestres. Els nodes de treball no van canviar, cosa que demostra els avantatges de la metodologia Kubernetes d'utilitzar estats especificats i reals en relació amb amfitrions de contenidors i motors de contenidors amb elements intercanviables.
L'exemple anterior mostra la capacitat de fer canvis a un petit clúster OpenShift Container Platform 4 amb tres nodes de producció o un gran clúster de producció amb 3000 nodes. En qualsevol cas, la quantitat de treball serà la mateixa, i molt petita, només cal que configureu el fitxer ContainerRuntimeConfig i canvieu una etiqueta a MachineConfigPool. I ho podeu fer amb qualsevol versió de l'OpenShift Container Platform 4.X amb Kubernetes al llarg del seu cicle de vida.
Sovint, les empreses tecnològiques evolucionen tan ràpidament que no podem explicar per què triem certes tecnologies per als components subjacents. Els motors de contenidors han estat històricament el component amb el qual els usuaris interactuen directament. Com que la popularitat dels contenidors va començar naturalment amb l'arribada dels motors de contenidors, els usuaris sovint mostren interès per ells. Aquesta és una altra raó per la qual Red Hat va triar CRI-O. Els contenidors estan evolucionant centrant-se ara en l'orquestració, i hem descobert que CRI-O ofereix la millor experiència quan es treballa amb OpenShift 4.
Font: www.habr.com