Red Hat OpenShift nell'edge computing: zero-touch provisioning

L'informatica sta subendo una notevole evoluzione e gli scenari di deployment e manutenzione cambiano da un giorno all'altro. L'elaborazione e la gestione dei dati e dei dispositivi nell'edge è sempre più necessaria, perciò le tecnologie devono adattarsi per supportare e incoraggiare l'adozione di tali strategie.

Red Hat OpenShift è in grado di soddisfare esigenze che vanno dalla gestione di una piattaforma applicativa indipendente dall'infrastruttura al deployment on premise o nel cloud, sia esso privato, pubblico o ibrido.

Tuttavia, la capacità di adattarsi a qualsiasi scenario si è evoluta enormemente nel tempo. L'utilizzo di configurazioni più leggere, come la modalità di deployment compatta a 3 nodi o la configurazione a nodo singolo, consente la stessa flessibilità e garantisce le stesse caratteristiche prestazionali, ma con un impatto ridotto. 

Questa flessibilità consente a OpenShift di adattarsi a deployment in scenari con ridotte capacità di elaborazione e vincoli di utilizzo dell'hardware, come le sedi remote, che si tratti di filiali o di singoli siti di calcolo ed elaborazione.

Immaginiamo di avere vari siti edge e di doverli raggiungere tutti con una tecnologia che garantisca capacità di elaborazione centralizzate e gestione dei carichi di lavoro. Siamo in grado di replicare e propagare configurazioni e impostazioni conformi alle policy predefinite e agli scenari relativi al sito e che, soprattutto, sono disponibili in breve tempo, riducendo la complessità e migliorando la replicabilità e l'affidabilità.

Questo scenario di utilizzo può essere affrontato con zero-touch provisioning (ZTP), grazie alla flessibilità di OpenShift Assisted Installer e alla versatilità e semplicità della gestione centralizzata di cluster e infrastruttura offerta da Red Hat Advanced Cluster Management for Kubernetes.

Zero-touch provisioning, come suggerisce il nome, è una modalità di provisioning dei cluster OpenShift su bare metal. Questo tipo di provisioning ci consente di creare più varianti di configurazioni di cluster in base alle esigenze dei siti remoti, senza interagire fisicamente con i nostri dispositivi. A tal fine, è necessario dichiarare le configurazioni desiderate per i nostri cluster su risorse specifiche, lasciando ai vari componenti di Red Hat Advanced Cluster Management il compito di tradurli in operazioni di provisioning, sia dei nodi dell'infrastruttura interfacciandosi con Baseboard Management Controller (BMC) sia dei cluster, sfruttando le funzioni OpenShift Assisted Installer.

Poiché tutte le risorse definite sono autonome, possono essere archiviate in un repository Git e applicate utilizzando l'operatore OpenShift GitOps (basato su ArgoCD), definendo i nostri siti e cluster come se fossero normali applicazioni.

Di seguito è riportato un diagramma di alcuni scenari di utilizzo, in cui si può notare che questa modalità di provisioning coinvolge un solo cluster, che fungerà da hub all'interno del data center centrale.

Le funzionalità di cui parleremo oggi sono disponibili nell'anteprima tecnica. Tuttavia, possiamo vedere come creare e adottare configurazioni ottimizzate su larga scala.

Scenario di utilizzo: OpenShift a nodo singolo nell'edge con ZTP

Diamo un'occhiata a ogni pezzo che compone il nostro puzzle e a come possiamo unire gli elementi per ottenere un quadro completo.

I principali componenti di Red Hat Advanced Cluster Management coinvolti nel processo sono:

• Operatore bare metal OpenShift
• Assisted Installer
• motore multicluster - Operatore Hive

Dal momento che affronteremo questioni relative ai dispositivi edge, il nostro ambito di riferimento è il bare metal. Qui, le modalità di configurazione sono già disponibili in base all'infrastruttura fornita dall'utente e alle installazioni nell'infrastruttura fornita dal programma di installazione, che sfrutteremo nelle varie fasi del deployment.

Ciascun dispositivo remoto è associato a un sito, che corrisponde alla definizione dei parametri fondamentali da considerare durante la fase di configurazione, che si traduce in una definizione delle risorse personalizzate (CRD) denominata SiteConfig.

CRD definirà:

• Dettagli sul BMC che utilizzeremo per gestire i nostri nodi
• Dettagli relativi ai cluster (nome cluster, dominio) 
• Configurazioni di rete (subnet per pod, servizi, macchine)
• Configurazioni dei nodi (impostazioni di rete, partizionamento, eventuale consolidamento necessario in base alle policy)

Queste informazioni vengono gestite e tradotte in risorse secondarie che sono gestite dai diversi componenti per orchestrare le diverse fasi dell'implementazione.

Per semplificare, il flusso logico di ZTP è il seguente:

Esaminiamo in dettaglio le diverse risorse menzionate e il loro ruolo.

BareMetalHost

BareMetalHost (BMH) gestisce le informazioni dal BMC, che vengono poi interpretate dall'operatore bare metal di OpenShift per creare il nodo bare metal all'interno di OpenShift per preparare e configurare il nodo remoto. Questo è il cuore pulsante del provisioning dei nodi, in quanto consente all'operatore di configurare da remoto i dispositivi di avvio in base alla configurazione da eseguire.

InfraEnv

InfraEnv definisce i dettagli della rete, i server NTP da utilizzare sui nodi che ospiterà, la chiave Secure Shell (SSH) che verrà utilizzata per accedere ai nodi che saranno collegati e le credenziali per accedere alle immagini del container necessarie per l'installazione. Insieme alla risorsa ClusterDeployment, si utilizza per creare l'ISO esplorativo per il programma di installazione assistita.

AgentClusterInstall

Contiene le informazioni che verranno utilizzate da Assisted Installer per generare l'immagine di avvio che verrà utilizzata dai nostri nodi per continuare l'installazione e la configurazione del cluster, inclusi la versione, il nome e le configurazioni di rete.

ClusterDeployment

Combina le informazioni definite in AgentClusterInstall e aggiunge altre informazioni necessarie per il corretto deployment del cluster, che verranno incorporate nell'ISO di avvio del nodo.

ManagedCluster e KlusterletAddonConfig

Queste risorse potrebbero già essere note agli utenti di Red Hat Advanced Cluster Management. Definiscono le informazioni sul cluster per consentirne l'importazione e la gestione all'interno dell'hub Red Hat Advanced Cluster Management, configurando i servizi necessari per la comunicazione.

Al termine del processo di provisioning e della configurazione del cluster tramite OpenShift Installer, il nostro hub mostrerà il nuovo nodo singolo OpenShift come installato e ancorato, pronto per essere utilizzato per il deployment dei carichi di lavoro.

Riepilogo

In questo articolo abbiamo introdotto il concetto di ZTP per OpenShift negli scenari edge e spiegato come può rendere il processo di provisioning della piattaforma più semplice, ripetibile e scalabile da un approccio Infrastructure as Code (IaC).

La tecnologia è in continua evoluzione e attualmente è abbastanza matura da permettere di sperimentare questo metodo innovativo per integrare una piattaforma applicativa completa in qualsiasi scenario.