Piattaforma consente di mettere in produzione la creazione , inclusi quelli nell'infrastruttura dei fornitori di servizi cloud, su piattaforme di virtualizzazione o in sistemi bare-metal. Per creare una vera piattaforma cloud, abbiamo dovuto controllare rigorosamente tutti gli elementi utilizzati e così aumentare l'affidabilità di un processo complesso di automazione.
La soluzione ovvia è stata utilizzare come standard Red Hat Enterprise Linux CoreOS (una variante di Red Hat Enterprise Linux) e CRI-O, ecco perché…
Poiché il tema della navigazione è piuttosto efficace per trovare analogie nell'esplorazione del funzionamento di Kubernetes e dei container, cerchiamo di illustrare i problemi aziendali che CoreOS e CRI-O risolvono, usando come esempio . Nel 1803, Mark Brunel ricevette l'incarico di produrre 100.000 blocchi di rigging per le esigenze della crescente flotta marittima britannica. Un blocco di rigging è un tipo di attrezzatura utilizzata per fissare le corde alle vele. Fino all'inizio del 19° secolo, questi blocchi venivano prodotti a mano, ma Brunel riuscì ad automatizzare il processo e a iniziare a produrre blocchi standardizzati usando macchinari. L'automazione di questo processo significava che tutti i blocchi risultavano praticamente identici, potevano essere facilmente sostituiti in caso di guasto e potevano essere prodotti in grandi quantità.
E ora immaginate che Brunel dovesse svolgere questo lavoro per 20 modelli diversi di navi (versioni di Kubernetes) e per cinque pianeti diversi con correnti e venti marini completamente diversi (fornitori di cloud). Inoltre, era necessario che tutte le navi (cluster OpenShift), indipendentemente dai pianeti su cui navigano, si comportassero allo stesso modo, secondo i capitani (operatori che gestiscono il lavoro dei cluster). Continuando con l'analogia marittima, ai capitani delle navi non importa affatto quali blocchi di rigging (CRI-O) vengono utilizzati sulle loro navi: ciò che conta per loro è che questi blocchi siano robusti e affidabili.
Prima di OpenShift 4, come piattaforma cloud, c'è un compito aziendale molto simile. I nuovi nodi devono essere creati al momento della creazione del cluster, in caso di guasto di uno dei nodi o durante la scalabilità del cluster. Durante la creazione e l'inizializzazione di un nuovo nodo, devono essere configurati anche i componenti critici dell'host, incluso CRI-O. Come in qualsiasi altra produzione, è necessario fornire prima 'materie prime'. Nel caso delle navi, le materie prime sono metallo e legno. Tuttavia, nel caso della creazione di un host per il dispiegamento di container nel cluster OpenShift 4, è necessario avere file di configurazione e server API forniti. Dopodiché, OpenShift garantirà il livello necessario di automazione durante l'intero ciclo di vita, offrendo il supporto prodotto necessario per gli utenti finali e recuperando così gli investimenti nella piattaforma.
OpenShift 4 è stato creato in modo tale da garantire la possibilità di aggiornamenti semplici del sistema lungo tutto il ciclo di vita della piattaforma (per le versioni 4.X) per tutti i principali provider di cloud computing, piattaforme di virtualizzazione e persino sistemi bare metal. Per questo, i nodi devono essere creati sulla base di elementi intercambiabili. Quando il cluster richiede una nuova versione di Kubernetes, riceve anche la corrispondente versione di CRI-O su CoreOS. Poiché la versione di CRI-O è direttamente legata a Kubernetes, tutto ciò semplifica notevolmente qualsiasi riorganizzazione per testare, risolvere problemi o supportare. Inoltre, un approccio simile permette di ridurre i costi per gli utenti finali e per Red Hat.
Questo è un nuovo approccio ai cluster Kubernetes, che getta le basi per pianificare nuove funzionalità molto utili e interessanti. CRI-O (progetto interfaccia di runtime del contenitore dell'iniziativa Open Container, abbreviato in CRI-OCI) si è rivelato la scelta più adatta per la creazione massiva di nodi necessaria per lavorare con OpenShift. CRI-O sostituirà il motore Docker utilizzato in precedenza, offrendo agli utenti di OpenShift – sì, non hai sentito male – un motore di contenitori noioso, creato appositamente per lavorare con Kubernetes.
Il mondo dei contenitori aperti
Il mondo si sta già da tempo muovendo verso i contenitori aperti. Che si tratti di Kubernetes o di livelli più bassi, porta alla nascita di un ecosistema di innovazione a ogni livello.
Tutto è iniziato con la creazione dell'iniziativa Open Containers Initiative . In questa fase iniziale sono state formulate specifiche per l' e . Ciò ha consentito di garantire che gli strumenti possano utilizzarsi conforme a uno standard unico e un formato unico per lavorarci. Successivamente sono state aggiunte specifiche , che hanno permesso agli utenti di scambiarsi facilmente .
Successivamente, la comunità di Kubernetes ha sviluppato uno standard unico per l'interfaccia pluggable, denominato . Grazie a ciò, gli utenti di Kubernetes possono connettere diversi motori per la gestione dei contenitori oltre a Docker.
Gli ingegneri di Red Hat e Google hanno notato l'esistenza di una domanda di mercato per un motore di contenitori in grado di ricevere richieste da Kubelet tramite il protocollo CRI e hanno presentato contenitori compatibili con le specifiche OCI menzionate. Così . Ma aspetta, abbiamo detto che questo materiale sarà dedicato a CRI-O? In realtà è così, semplicemente con il rilascio il progetto è stato rinominato in CRI-O.
Fig. 1.
Innovazioni con CRI-O e CoreOS
Con il lancio della piattaforma OpenShift 4, è stato cambiato , utilizzato nella piattaforma per impostazione predefinita, e al posto di Docker è arrivato CRI-O, che offre un ambiente economico, stabile, semplice e noioso per l'esecuzione dei contenitori, che si sviluppa parallelamente a Kubernetes. Ciò semplifica notevolmente la manutenzione e la configurazione del cluster. La configurazione del motore dei contenitori e dell'host, così come la loro gestione, diventa automatizzata nell'ambito di OpenShift 4.
Aspetta, come è possibile?
Proprio così, con l'arrivo di OpenShift 4, non è più necessario connettersi a host separati e installare un motore di contenitori, configurare lo storage, impostare server per la ricerca o configurare la rete. La piattaforma OpenShift 4 è stata completamente riprogettata per utilizzare l' non solo dal punto di vista delle applicazioni degli utenti finali, ma anche dal punto di vista delle operazioni di base a livello di piattaforma, come il deployment di immagini, la configurazione del sistema o l'installazione degli aggiornamenti.
Kubernetes ha sempre consentito agli utenti di gestire le applicazioni, definendo lo stato desiderato e utilizzando , per garantire che lo stato effettivo corrisponda il più possibile allo stato impostato. Questo apre grandi opportunità sia dal punto di vista dello sviluppo che delle operazioni. Gli sviluppatori possono definire lo stato richiesto, all'operatore in formato YAML o JSON, e poi l'operatore può creare nell'ambiente di produzione l'istanza necessaria dell'applicazione, garantendo che lo stato di funzionamento di questa istanza corrisponda completamente a quello impostato.
Utilizzando gli operatori (Operators) sulla piattaforma, OpenShift 4 porta questa nuova forma (utilizzando il concetto di stato impostato e stato effettivo) nella gestione di RHEL CoreOS e CRI-O. Le attività di configurazione e gestione delle versioni del sistema operativo e del motore dei container vengono automatizzate tramite il cosiddetto . Il MCO semplifica notevolmente il lavoro dell'amministratore del cluster, automatizzando sostanzialmente le ultime fasi dell'installazione, così come le operazioni successive all'installazione (day two operations). Tutto ciò rende OpenShift 4 una vera piattaforma cloud. Ne parleremo più avanti.
Avvio dei container
Gli utenti hanno potuto utilizzare il motore CRI-O sulla piattaforma OpenShift a partire dalla versione 3.7 in stato di Tech Preview e dalla versione 3.9 in stato di Generally Available (attualmente supportato). Inoltre, Red Hat utilizza ampiamente in OpenShift Online dalla versione 3.10. Tutto ciò ha permesso al team che lavora su CRI-O di acquisire una grande esperienza nel lancio massiccio di container su grandi cluster Kubernetes. Per ottenere una comprensione fondamentale di come Kubernetes utilizza CRI-O, diamo un'occhiata alla seguente illustrazione, che mostra il funzionamento dell'architettura.
Fig. 2. Come funzionano i container in un cluster Kubernetes
CRI-O semplifica la creazione di nuovi host container grazie alla sincronizzazione di tutto il livello superiore durante l'inizializzazione di nuove nodi e con il rilascio di nuove versioni della piattaforma OpenShift. La revisione dell'intera piattaforma consente di eseguire aggiornamenti/transazioni inversi, nonché di prevenire i blocchi reciproci nelle dipendenze tra il nucleo dell'host container, il motore container, le nodi (Kubelet) e la master node Kubernetes Master. Con la gestione centralizzata di tutti i componenti della piattaforma, con controllo e gestione delle versioni, è sempre possibile tracciare un percorso chiaro dallo stato A allo stato B. Ciò semplifica il processo di aggiornamento, aumenta la sicurezza, migliora la rendicontazione delle performance e aiuta a ridurre i costi per aggiornamenti e installazione di nuove versioni.
Dimostrazione della potenza degli elementi sostituibili
Come già accennato, l'utilizzo del Machine Config Operator per la gestione dell'host container e del motore container in OpenShift 4 offre un nuovo livello di automazione che non era possibile sulla piattaforma Kubernetes in precedenza. Per dimostrare le nuove funzionalità, mostreremo come potresti apportare modifiche al file crio.conf. Per non confonderti con la terminologia, cerca di concentrarti sui risultati.
Innanzitutto, creiamo quello che viene chiamato il Container Runtime Config. Consideralo come una risorsa Kubernetes che rappresenta la configurazione per CRI-O. In realtà, è una versione specializzata di ciò che viene chiamato MachineConfig, che rappresenta qualsiasi configurazione distribuita sulla macchina RHEL CoreOS all'interno di un cluster OpenShift.
Questa risorsa personalizzata, chiamata ContainerRuntimeConfig, è stata concepita per facilitare agli amministratori del cluster la configurazione di CRI-O. È uno strumento abbastanza potente, tanto che può essere applicato solo a nodi specifici a seconda delle impostazioni di MachineConfigPool. Considerala come un gruppo di macchine che servono allo stesso scopo.
Fai attenzione alle ultime due righe che stiamo per modificare nel file /etc/crio/crio.conf. Queste due righe sono molto simili alle righe nel file crio.conf, esse sono:
vi ContainerRuntimeConfig.yaml
Conclusione:
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
Ora invieremo questo file al cluster Kubernetes e verificheremo che sia stato effettivamente creato. Nota che il lavoro viene svolto esattamente come con qualsiasi altra risorsa Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Conclusione:
NOME ETÀ
set-log-and-pid 22h
Dopo aver creato il ContainerRuntimeConfig, dobbiamo modificare uno dei MachineConfigPools per far sapere a Kubernetes che vogliamo applicare questa configurazione a un determinato gruppo di macchine nel cluster. In questo caso, modificheremo il MachineConfigPool per i nodi master:
oc edit MachineConfigPool/master
Output (per chiarezza si lascia la sostanza principale):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
In questo momento, l'MCO inizia a creare un nuovo file crio.conf per il cluster. Tuttavia, è possibile visualizzare il file di configurazione completamente pronto tramite l'API di Kubernetes. Ricorda, ContainerRuntimeConfig è solo una versione specializzata di MachineConfig, quindi possiamo vedere il risultato esaminando le righe necessarie in MachineConfigs:
oc get MachineConfigs | grep rendered
Conclusione:
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
Nota che il file di configurazione ottenuto per i nodi master è risultato essere una versione più recente rispetto alle configurazioni originali. Per visualizzarlo, esegui il seguente comando. A proposito, facciamo notare che questo è forse uno degli script a riga singola migliori nella storia di 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
Conclusione:
pids_limit = 2048
Ora assicuriamoci che la configurazione sia stata applicata a tutti i nodi master. Prima otteniamo l'elenco dei nodi nel cluster:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Pronto master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Pronto master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Pronto master 23h v1.12.4+509916ce1
Ora esaminiamo il file impostato. Vedrai che il file è stato aggiornato con i nuovi valori delle direttive pid e debug che abbiamo specificato nella risorsa ContainerRuntimeConfig. La pura eleganza:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Conclusione:
...pids_limit = 2048
...
log_level = "debug"
...
Tutte queste modifiche nel cluster sono state apportate senza avviare SSH. Tutto il lavoro è stato svolto facendo riferimento al nodo master di Kubernetes. Ciò significa che questi nuovi parametri sono stati configurati solo sui nodi master. I nodi di lavoro, nel frattempo, non sono stati modificati, il che dimostra i vantaggi della metodologia Kubernetes utilizzando stati desiderati e attuali in relazione agli host dei container e ai motori di container con elementi intercambiabili.
L'esempio sopra riportato dimostra la possibilità di apportare modifiche a un piccolo cluster OpenShift Container Platform 4 con tre nodi di lavoro o a un enorme cluster produttivo con 3000 nodi. In entrambi i casi, l'entità del lavoro sarà la stessa – e molto ridotta – è sufficiente configurare il file ContainerRuntimeConfig e modificare un'etichetta (label) in MachineConfigPool. E puoi farlo con qualsiasi versione della piattaforma OpenShift Container Platform 4.X utilizzata in Kubernetes per tutto il suo ciclo di vita.
Spesso le aziende tecnologiche si sviluppano così rapidamente che non siamo in grado di spiegare perché scegliamo determinate tecnologie per i componenti di base. I motori di container sono storicamente stati quel componente con cui gli utenti interagiscono direttamente. Poiché la popolarità dei container è logicamente iniziata con l'emergere dei motori di container, gli utenti dimostrano spesso interesse nei loro confronti. Questa è un'altra ragione per cui Red Hat ha scelto CRI-O. I container si evolvono, mentre oggi l'attenzione principale è sull'orchestrazione, e abbiamo concluso che CRI-O offre la migliore esperienza lavorando con OpenShift 4.
Fonte: habr.com
