piattaforma consente di semplificare la creazione , anche nell'infrastruttura dei fornitori di servizi cloud, su piattaforme di virtualizzazione o in sistemi bare metal. Per creare una vera piattaforma basata sul cloud, abbiamo dovuto controllare rigorosamente tutti gli elementi utilizzati e aumentare così l'affidabilità di un processo di automazione complesso.
La soluzione ovvia era utilizzare Red Hat Enterprise Linux CoreOS (una variante di Red Hat Enterprise Linux) e CRI-O come standard, ed ecco perché...
Poiché il tema della navigazione è ottimo per trovare analogie quando si spiega il lavoro di Kubernetes e dei container, proviamo a parlare dei problemi aziendali che CoreOS e CRI-O risolvono, utilizzando un esempio . Nel 1803, Marc Brunel fu incaricato di produrre 100 blocchi di sartiame per le esigenze della crescente marina britannica. Un bozzello per sartiame è un tipo di sartiame utilizzato per fissare le corde alle vele. Fino all'inizio del XIX secolo, questi blocchi venivano realizzati a mano, ma Brunel riuscì ad automatizzare la produzione e iniziò a produrre blocchi standardizzati utilizzando macchine utensili. L'automazione di questo processo significava che i blocchi risultanti erano praticamente identici, potevano essere facilmente sostituiti in caso di rottura e potevano essere prodotti in grandi quantità.
Ora immagina se Brunel dovesse fare questo lavoro per 20 diversi modelli di navi (versioni Kubernetes) e per cinque diversi pianeti con correnti marine e venti completamente diversi (fornitori di servizi cloud). Inoltre, era richiesto che tutte le navi (cluster OpenShift), indipendentemente dai pianeti su cui viene effettuata la navigazione, dal punto di vista dei capitani (operatori che gestiscono il funzionamento dei cluster) si comportassero allo stesso modo. Per continuare l'analogia marittima, ai capitani delle navi non interessa affatto il tipo di bozzelli di sartiame (CRI-O) utilizzati sulle loro navi: la cosa principale per loro è che questi bozzelli siano resistenti e affidabili.
OpenShift 4, come piattaforma cloud, deve affrontare una sfida aziendale molto simile. I nuovi nodi devono essere creati al momento della creazione del cluster, in caso di guasto in uno dei nodi o durante il ridimensionamento del cluster. Quando un nuovo nodo viene creato e inizializzato, i componenti host critici, incluso CRI-O, devono essere configurati di conseguenza. Come in ogni altra produzione, le “materie prime” devono essere fornite all'inizio. Nel caso delle navi, le materie prime sono metallo e legno. Tuttavia, nel caso di creazione di un host per la distribuzione di contenitori in un cluster OpenShift 4, è necessario disporre di file di configurazione e server forniti da API come input. OpenShift fornirà quindi il livello di automazione richiesto durante l'intero ciclo di vita, offrendo il necessario supporto del prodotto agli utenti finali e recuperando così l'investimento nella piattaforma.
OpenShift 4 è stato creato in modo tale da fornire la possibilità di aggiornare comodamente il 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 fare ciò, i nodi devono essere creati sulla base di elementi intercambiabili. Quando un cluster richiede una nuova versione di Kubernetes, riceve anche la versione corrispondente di CRI-O su CoreOS. Poiché la versione CRI-O è collegata direttamente a Kubernetes, ciò semplifica notevolmente qualsiasi permutazione a fini di test, risoluzione dei problemi o supporto. Inoltre, questo approccio riduce i costi per gli utenti finali e per Red Hat.
Questo è un modo fondamentalmente nuovo di pensare ai cluster Kubernetes e getta le basi per pianificare alcune nuove funzionalità molto utili e interessanti. CRI-O (Container Runtime Interface - Open Container Initiative, abbreviato CRI-OCI) si è rivelata la scelta di maggior successo per la creazione di massa di nodi necessaria per lavorare con OpenShift. CRI-O sostituirà il motore Docker precedentemente utilizzato, offrendo agli utenti OpenShift – sì, hai sentito bene – un noioso motore container creato appositamente per lavorare con Kubernetes.
Il mondo dei contenitori aperti
Il mondo si sta muovendo da tempo verso i container aperti. Sia in Kubernetes, sia ai livelli inferiori, si traduce in un ecosistema di innovazione a tutti i livelli.
Tutto è iniziato con la creazione dell'iniziativa Open Containers . In questa fase iniziale del lavoro sono state formulate le specifiche del contenitore и . Ciò ha garantito che gli strumenti potessero utilizzare un unico standard e un formato unificato per lavorare con loro. Le specifiche sono state aggiunte successivamente , consentendo agli utenti di condividere facilmente .
La comunità Kubernetes ha quindi sviluppato un unico standard per un'interfaccia collegabile, chiamato . Grazie a ciò, gli utenti Kubernetes hanno potuto collegare diversi motori per lavorare con i container oltre a Docker.
Gli ingegneri di Red Hat e Google hanno notato la necessità del mercato di un motore di container in grado di accettare richieste Kubelet tramite il protocollo CRI e hanno introdotto contenitori compatibili con le specifiche OCI sopra menzionate. COSÌ . Ma scusatemi, non avevamo detto che questo materiale sarebbe stato dedicato al CRI-O? In realtà lo è, solo con il rilascio il progetto è stato ribattezzato CRI-O.
Fig. 1.
Innovazione con CRI-O e CoreOS
Con il lancio della piattaforma OpenShift 4, la situazione è cambiata , utilizzato per impostazione predefinita nella piattaforma, e Docker è stato sostituito da CRI-O, offrendo un ambiente conveniente, stabile, semplice e noioso per l'esecuzione di un contenitore che si sviluppa in parallelo con Kubernetes. Ciò semplifica notevolmente il supporto e la configurazione del cluster. La configurazione del motore del contenitore e dell'host, nonché la loro gestione, diventano automatizzate all'interno di OpenShift 4.
Aspetta, com'è questo?
Esatto, con l'avvento di OpenShift 4, non è più necessario connettersi a singoli host e installare un motore container, configurare lo storage, configurare server di ricerca o configurare una rete. La piattaforma OpenShift 4 è stata completamente riprogettata per utilizzare il non solo in termini di applicazioni per l'utente finale, ma anche in termini di operazioni di base a livello di piattaforma come la distribuzione di immagini, la configurazione del sistema o l'installazione di aggiornamenti.
Kubernetes da sempre consente agli utenti di gestire le applicazioni definendone lo stato e l'utilizzo desiderati , per garantire che lo stato effettivo corrisponda il più fedelmente possibile allo stato target. Questo apre grandi opportunità sia dal punto di vista dello sviluppo che delle operazioni. Gli sviluppatori possono definire lo stato richiesto tramite all'operatore sotto forma di file YAML o JSON, quindi l'operatore può creare l'istanza dell'applicazione richiesta nell'ambiente di produzione e lo stato operativo di questa istanza corrisponderà completamente a quello specificato.
Utilizzando gli operatori nella piattaforma, OpenShift 4 porta questo nuovo paradigma (utilizzando il concetto di stato impostato e stato attuale) nella gestione di RHEL CoreOS e CRI-O. Le attività di configurazione e gestione delle versioni del sistema operativo e del motore del contenitore sono automatizzate utilizzando il cosiddetto . MCO semplifica notevolmente il lavoro dell'amministratore del cluster, automatizzando sostanzialmente le ultime fasi dell'installazione, nonché le successive operazioni post-installazione (operazioni del secondo giorno). Tutto ciò rende OpenShift 4 una vera piattaforma cloud. Ne parleremo un po' più tardi.
Contenitori in esecuzione
Gli utenti hanno avuto l'opportunità di utilizzare il motore CRI-O nella piattaforma OpenShift dalla versione 3.7 nello stato Tech Preview e dalla versione 3.9 nello stato Generally Available (attualmente supportato). Inoltre, Red Hat utilizza in modo massiccio in OpenShift Online dalla versione 3.10. Tutto ciò ha permesso al team che lavora su CRI-O di acquisire una vasta esperienza nel lancio di massa di container su grandi cluster Kubernetes. Per avere una comprensione di base di come Kubernetes utilizza CRI-O, diamo un'occhiata alla seguente illustrazione, che mostra come funziona l'architettura.
Riso. 2. Come funzionano i contenitori in un cluster Kubernetes
CRI-O semplifica la creazione di nuovi host container sincronizzando l'intero livello superiore durante l'inizializzazione di nuovi nodi e quando si rilasciano nuove versioni della piattaforma OpenShift. La revisione dell'intera piattaforma consente aggiornamenti/rollback transazionali e previene anche blocchi nelle dipendenze tra il core di coda del contenitore, il motore del contenitore, i nodi (Kubelet) e il nodo Master Kubernetes. Gestendo centralmente tutti i componenti della piattaforma, con controllo e controllo delle versioni, c'è sempre un percorso chiaro dallo stato A allo stato B. Ciò semplifica il processo di aggiornamento, migliora la sicurezza, migliora il reporting sulle prestazioni e aiuta a ridurre il costo degli aggiornamenti e delle installazioni di nuove versioni .
Dimostrare la potenza degli elementi sostitutivi
Come accennato in precedenza, l'utilizzo di Machine Config Operator per gestire l'host del contenitore e il motore del contenitore in OpenShift 4 fornisce un nuovo livello di automazione che in precedenza non era possibile sulla piattaforma Kubernetes. Per dimostrare le nuove funzionalità, mostreremo come apportare modifiche al file crio.conf. Per evitare di confonderti con la terminologia, prova a concentrarti sui risultati.
Innanzitutto, creiamo quella che viene chiamata configurazione di runtime del contenitore: Container Runtime Config. Considerala come una risorsa Kubernetes che rappresenta la configurazione per CRI-O. In realtà, si tratta di una versione specializzata di qualcosa chiamato MachineConfig, ovvero qualsiasi configurazione distribuita su una macchina RHEL CoreOS come parte di un cluster OpenShift.
Questa risorsa personalizzata, denominata ContainerRuntimeConfig, è stata creata per semplificare la configurazione di CRI-O da parte degli amministratori del cluster. Questo strumento è sufficientemente potente da poter essere applicato solo a determinati nodi a seconda delle impostazioni di MachineConfigPool. Pensatelo come un gruppo di macchine che hanno lo stesso scopo.
Nota le ultime due righe che modificheremo nel file /etc/crio/crio.conf. Queste due righe sono molto simili alle righe nel file crio.conf, 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 inviamo questo file al cluster Kubernetes e controlliamo che sia stato effettivamente creato. Tieni presente che l'operazione è esattamente la stessa di qualsiasi altra risorsa Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Conclusione:
NAME AGE
set-log-and-pid 22h
Una volta creato ContainerRuntimeConfig, dobbiamo modificare uno dei MachineConfigPools per segnalare a Kubernetes che vogliamo applicare questa configurazione a un gruppo specifico di macchine nel cluster. In questo caso cambieremo il MachineConfigPool per i nodi master:
oc edit MachineConfigPool/master
Conclusione (per chiarezza, l'essenza principale è lasciata):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
A questo punto, MCO inizia a creare un nuovo file crio.conf per il cluster. In questo caso, il file di configurazione completamente finito può essere visualizzato utilizzando l'API Kubernetes. Ricorda, ContainerRuntimeConfig è solo una versione specializzata di MachineConfig, quindi possiamo vedere il risultato osservando le righe pertinenti 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
Tieni presente che il file di configurazione risultante per i nodi master era una versione più recente rispetto alle configurazioni originali. Per visualizzarlo, eseguire il comando seguente. Notiamo di sfuggita che questa è forse una delle migliori battute 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. Per prima cosa otteniamo un elenco di nodi nel 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
Ora diamo un'occhiata al file installato. Vedrai che il file è stato aggiornato con i nuovi valori per le direttive pid e debug che abbiamo specificato nella risorsa ContainerRuntimeConfig. L'eleganza stessa:
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 al cluster sono state apportate senza nemmeno eseguire SSH. Tutto il lavoro è stato svolto accedendo al nodo master Kuberentes. Cioè questi nuovi parametri sono stati configurati solo sui nodi master. I nodi di lavoro non sono cambiati, il che dimostra i vantaggi della metodologia Kubernetes nell'utilizzo di stati specificati ed effettivi in relazione agli host container e ai motori container con elementi intercambiabili.
L'esempio sopra mostra la possibilità di apportare modifiche a un piccolo cluster OpenShift Container Platform 4 con tre nodi di produzione o a un enorme cluster di produzione con 3000 nodi. In ogni caso, la quantità di lavoro sarà la stessa, e molto ridotta, basta configurare il file ContainerRuntimeConfig e modificare un'etichetta in MachineConfigPool. E puoi farlo con qualsiasi versione di OpenShift Container Platform 4.X che esegue Kubernetes durante tutto il suo ciclo di vita.
Spesso le aziende tecnologiche si evolvono così rapidamente che non siamo in grado di spiegare perché scegliamo determinate tecnologie per i componenti sottostanti. I motori dei contenitori sono stati storicamente il componente con cui gli utenti interagiscono direttamente. Poiché la popolarità dei container è iniziata naturalmente con l’avvento dei motori per container, gli utenti spesso mostrano interesse nei loro confronti. Questo è un altro motivo per cui Red Hat ha scelto CRI-O. I contenitori si stanno evolvendo concentrandosi ora sull'orchestrazione e abbiamo scoperto che CRI-O offre la migliore esperienza quando si lavora con OpenShift 4.
Fonte: habr.com