Piattaforma consente di automatizzare la creazione , inclusi nelle infrastrutture dei fornitori di servizi cloud, su piattaforme di virtualizzazione o in sistemi bare-metal. Per creare una vera e propria piattaforma cloud, abbiamo dovuto esercitare un rigoroso controllo su tutti gli elementi utilizzati, aumentando così l'affidabilità di un processo di automazione complesso.
La scelta ovvia è stata adottare come standard Red Hat Enterprise Linux CoreOS (una variante di Red Hat Enterprise Linux) e CRI-O, ecco perché…
Poiché il tema della navigazione è molto efficace per trovare analogie nella spiegazione di come funzionano Kubernetes e i container, cercheremo di illustrare i problemi aziendali che risolvono CoreOS e CRI-O attraverso l'esempio . Nel 1803, a Marc Brunel venne affidato il compito di produrre 100.000 pulegge per le esigenze della crescente marina britannica. Una puleggia è un tipo di attrezzatura usata per fissare le corde alle vele. Fino all'inizio del XIX secolo, queste pulegge venivano realizzate a mano, ma Brunel riuscì a automatizzare il processo di produzione e a iniziare a fabbricare pulegge standardizzate tramite macchinari. L'automazione di questo processo significava che tutte le pulegge risultavano praticamente identiche, potevano essere facilmente sostituite in caso di guasto e potevano essere prodotte in grandi quantità.
E ora immaginate che Brunello debba fare questo lavoro per 20 diversi modelli di navi (versioni di Kubernetes) e per cinque pianeti differenti con correnti e venti marini completamente diversi (fornitori cloud). Inoltre, era necessario che tutte le navi (cluster OpenShift), indipendentemente dai pianeti su cui navigano, si comportassero allo stesso modo dal punto di vista dei capitani (operatori che gestiscono il funzionamento dei cluster). Continuando nell'analogia marina, ai capitani delle navi non importa affatto quali blocchi di attrezzatura (CRI-O) siano utilizzati sulle loro navi – ciò che conta per loro è che questi blocchi siano solidi e affidabili.
Prima di OpenShift 4, come piattaforma cloud, c'è un compito aziendale molto simile. Le nuove nodi devono essere create al momento della creazione del cluster, in caso di guasto di uno dei nodi, o durante il ridimensionamento del cluster. Durante la creazione e l'inizializzazione di un nuovo nodo, i componenti critici dell'host devono essere configurati di conseguenza, inclusi CRI-O. Come in qualsiasi altro processo produttivo, è necessario fornire inizialmente la "materia prima". Nel caso delle navi, le materie prime sono metallo e legno. Tuttavia, quando si crea un host per il deployment di container nel cluster OpenShift 4, è necessario avere a disposizione file di configurazione e server API forniti. Dopodiché, OpenShift garantirà il livello di automazione richiesto durante l'intero ciclo di vita, offrendo il supporto necessario per gli utenti finali e, in tal modo, recuperando l'investimento nella piattaforma.
OpenShift 4 è stato progettato per garantire aggiornamenti semplici del sistema durante l'intero ciclo di vita della piattaforma (per le versioni 4.X) per tutti i principali fornitori di cloud computing, piattaforme di virtualizzazione e persino sistemi bare metal. Per questo, i nodi devono essere creati sulla base di elementi intercambiabili. Quando un 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, questo semplifica notevolmente qualsiasi riorganizzazione per scopi di test, risoluzione dei problemi o supporto. Inoltre, questo approccio consente di ridurre i costi per gli utenti finali e Red Hat.
Una nuova prospettiva sui cluster Kubernetes, che getta le basi per la pianificazione di funzionalità nuove, utili e attraenti. CRI-O (progetto dell'Open Container Initiative - Container Runtime Interface, abbreviato in CRI-OCI) si è rivelato la scelta migliore per la creazione massiccia dei nodi necessari per lavorare con OpenShift. CRI-O sostituirà il motore Docker precedentemente utilizzato, offrendo agli utenti di OpenShift – sì, non hai frainteso – un motore di container noioso, progettato specificamente per lavorare con Kubernetes.
Il mondo dei container aperti
Il mondo si sta muovendo verso i container aperti da tempo. Sia in Kubernetes, sia a livelli inferiori, porta a un ecosistema di innovazione a ogni livello.
Tutto è iniziato con la creazione dell'Open Containers Initiative . In questa fase iniziale, sono state definite le specifiche per l' e . Questo ha garantito che gli strumenti potessero utilizzare uno standard uniforme e un formato unico per lavorare con essi. In seguito sono state aggiunte le specifiche , permettendo agli utenti di scambiare facilmente .
Successivamente, la comunità di Kubernetes ha sviluppato uno standard unico per le interfacce pluggable, chiamato . Grazie a ciò, gli utenti di Kubernetes hanno potuto collegare vari motori per lavorare con i container, oltre a Docker.
Gli ingegneri di Red Hat e Google hanno riconosciuto l'esistenza di una domanda di mercato per un motore di container in grado di ricevere richieste da Kubelet tramite il protocollo CRI, e hanno presentato container compatibili con le specifiche OCI sopra menzionate. Così . Ma aspetta, abbiamo detto che questo materiale sarà dedicato a CRI-O? In effetti, è così, semplicemente con il rilascio della il progetto è stato rinominato in CRI-O.
Fig. 1.
Innovazioni con CRI-O e CoreOS
Con il lancio della piattaforma OpenShift 4, è stato modificato , utilizzato nella piattaforma per impostazione predefinita, e Docker è stato sostituito da CRI-O, che offre un ambiente economico, stabile, semplice e noioso per l'esecuzione dei contenitori, sviluppandosi parallelamente a Kubernetes. Questo semplifica notevolmente il supporto e la configurazione del cluster. La configurazione e la gestione del motore dei contenitori e dell'host diventano automatizzate all'interno di OpenShift 4.
Fermati, come così?
Esattamente, con l'arrivo di OpenShift 4, non è più necessario connettersi a host separati e installare il motore dei contenitori, configurare lo storage, impostare i server per la ricerca o configurare la rete. La piattaforma OpenShift 4 è stata completamente riprogettata per utilizzare the 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 delle immagini, la configurazione del sistema o l'installazione degli aggiornamenti.
Kubernetes ha sempre permesso agli utenti di gestire le applicazioni definendo lo stato desiderato e utilizzando , per garantire che lo stato reale corrisponda al massimo allo stato desiderato. Questo apre grandi opportunità sia dal punto di vista dello sviluppo che delle operazioni. Gli sviluppatori possono definire lo stato richiesto, all'operatore sotto forma di file YAML o JSON, e poi l'operatore può creare nell'ambiente operativo l'istanza necessaria dell'applicazione, il cui stato operativo sarà completamente allineato con quello desiderato.
Utilizzando gli operatori (Operators) nella piattaforma, OpenShift 4 introduce questa nuova paridigma (attraverso il concetto di stato desiderato e stato reale) 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 . MCO semplifica notevolmente il lavoro dell'amministratore del cluster, automatizzando in pratica le ultime fasi dell'installazione e le operazioni successive (operazioni del giorno due). Questo rende OpenShift 4 una vera piattaforma cloud. Affronteremo questo argomento più avanti.
Avvio dei contenitori
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 supportata). Inoltre, Red Hat utilizza ampiamente in OpenShift Online a partire dalla versione 3.10. Tutto ciò ha permesso al team di CRI-O di acquisire una grande esperienza nell'avvio massivo di contenitori su grandi cluster Kubernetes. Per avere una comprensione di base su come Kubernetes utilizza CRI-O, esaminiamo l'illustrazione seguente che mostra il principio di funzionamento dell'architettura.
Fig. 2. Come funzionano i contenitori nel cluster Kubernetes
CRI-O semplifica la creazione di nuovi host per contenitori sincronizzando l'intero livello superiore durante l'inizializzazione di nuovi nodi e durante il rilascio di nuove versioni della piattaforma OpenShift. La revisione completa della piattaforma consente aggiornamenti/arretramenti transazionali e previene i blocchi reciproci nelle dipendenze tra il nucleo del contenitore, il motore del contenitore, i nodi (Kubelet) e il nodo master di Kubernetes. Con la gestione centralizzata di tutti i componenti della piattaforma, con controllo e gestione delle versioni, è sempre possibile tracciare un chiaro percorso dallo stato A allo stato B. Questo semplifica il processo di aggiornamento, aumenta la sicurezza, migliora la reportistica sulle prestazioni e aiuta a ridurre i costi per aggiornamenti e installazioni di nuove versioni.
Dimostrazione della potenza degli elementi sostituibili
Come accennato in precedenza, l'uso di Machine Config Operator per gestire l'host del contenitore e il motore del contenitore in OpenShift 4 offre un nuovo livello di automazione, precedentemente non possibile sulla piattaforma Kubernetes. Per dimostrare queste nuove funzionalità, mostreremo come è possibile apportare modifiche al file crio.conf. Per non confonderci con la terminologia, cercate di concentrarvi sui risultati.
Iniziamo creando quella che chiamiamo configurazione dell'ambiente di runtime del contenitore – Container Runtime Config. Pensate a questo come a una sorta di risorsa Kubernetes che rappresenta la configurazione per CRI-O. In realtà, è una versione specializzata di ciò che chiamiamo MachineConfig, che rappresenta qualsiasi configurazione distribuita su una macchina RHEL CoreOS all'interno di un cluster OpenShift.
Questa risorsa personalizzata, chiamata ContainerRuntimeConfig, è stata concepita per semplificare per gli amministratori di 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. Pensate a questo come a un gruppo di macchine che servono lo stesso scopo.
Presta attenzione alle ultime due righe che intendiamo modificare nel file /etc/crio/crio.conf. Queste due righe sono molto simili a quelle nel file crio.conf, ovvero:
vi ContainerRuntimeConfig.yaml
Risultato:
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 inviamo questo file al cluster Kubernetes e verifichiamo che sia stato effettivamente creato. Nota che l'operazione avviene esattamente come per qualsiasi altra risorsa Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Risultato:
NOME ETÀ
set-log-and-pid 22h
Dopo aver creato il ContainerRuntimeConfig, è necessario modificare uno dei MachineConfigPools per informare Kubernetes che desideriamo 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
Uscita (per maggiore chiarezza è stata mantenuta l'essenza 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, MCO inizia a creare un nuovo file crio.conf per il cluster. Il file di configurazione completamente pronto può essere visualizzato tramite le API di Kubernetes. Ricordate che ContainerRuntimeConfig è semplicemente una versione specializzata di MachineConfig, quindi possiamo vedere il risultato guardando le righe necessarie nei MachineConfigs:
oc get MachineConfigs | grep rendered
Risultato:
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
Si noti che il file di configurazione ottenuto per i nodi master è risultata una versione più recente rispetto alle configurazioni originali. Per visualizzarlo, eseguite il seguente comando. Si noti, inoltre, che questo è probabilmente uno dei migliori script in una riga 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
Risultato:
pids_limit = 2048
Ora assicuriamoci che la configurazione sia stata applicata a tutti i nodi master. Prima di tutto, 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 visualizziamo il file installato. Vedrete che il file è stato aggiornato con i nuovi valori delle direttive pid e debug che abbiamo specificato nella risorsa ContainerRuntimeConfig. La vera eleganza:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Risultato:
...
pids_limit = 2048
...
log_level = "debug"
...
Tutte queste modifiche nel cluster sono state apportate senza l'avvio di SSH. Tutto il lavoro è stato svolto contattando il nodo master di Kubernetes. Ciò significa che questi nuovi parametri sono stati configurati solo sui nodi master. I nodi di lavoro, invece, 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 dei container con componenti intercambiabili.
L'esempio sopra mostra la possibilità di apportare modifiche a un piccolo cluster OpenShift Container Platform 4 con tre nodi di lavoro o a un enorme cluster di produzione con 3000 nodi. In entrambi i casi il lavoro richiesto sarà lo stesso — e abbastanza limitato — è sufficiente configurare il file ContainerRuntimeConfig e modificare un'etichetta (label) nel MachineConfigPool. E puoi farlo con qualsiasi versione della piattaforma Kubernetes OpenShift Container Platform 4.X durante tutto il suo ciclo di vita.
Spesso, le aziende tecnologiche si sviluppano così rapidamente che non riusciamo a spiegare perché scegliamo determinate tecnologie per i componenti di base. I motori dei container sono storicamente stati l'elemento con cui gli utenti interagiscono direttamente. Poiché la popolarità dei container è iniziata con l'emergere dei motori dei container, gli utenti mostrano spesso un certo interesse nei loro confronti. Questo è un ulteriore motivo per cui Red Hat ha scelto CRI-O. I container continuano ad evolversi, mentre oggi l'attenzione principale è sull'orchestrazione, e siamo giunti alla conclusione che CRI-O offre la migliore esperienza con OpenShift 4.
Fonte: habr.com
