Kubernetes per l'industria e l'IoT

Kubernetes nell'industria

Negli ultimi anni ho visto crescere molto le richieste di adozione e implementazione di Kubernetes in ambito industriale, sia nelle startup sia nelle aziende consolidate. La scelta di Kubernetes risponde all'esigenza di automatizzare i rilasci e il ciclo di vita delle applicazioni, gestire l'alta affidabilità e adeguarsi ai requisiti delle applicazioni di mercato che ormai girano su Kubernetes.

Le richieste sono di due tipi: progetti in datacenter e in cloud, e software da rilasciare e gestire direttamente negli impianti, all'edge.

Datacenter e cloud: spesso la prima architettura cloud native

Il primo tipo riguarda progetti nuovi o di modernizzazione. La differenza rispetto ad altri settori è che le tecnologie cloud native sono ancora poco adottate. In ambito fintech, ad esempio, si arriva quasi sempre dopo anni di cloud native, con piattaforme già in piedi e abitudini già formate, non sempre buone. In ambito industriale l'adozione è recente, e spesso Kubernetes è la prima architettura di questo tipo.

È un'occasione: si può partire con le pratiche giuste fin dall'inizio, invece di correggere abitudini consolidate.

Edge e impianti: hardware e connettività

Rilasciare e gestire software negli impianti industriali pone sfide diverse, e non solo a livello di infrastruttura.

Cambia l'hardware, che spinge verso distribuzioni snelle e con meno complessità di gestione, come k3s o MicroK8s.

E cambia soprattutto la connettività. Un sito remoto può avere una linea altalenante, non ridondata, a volte assente per ore. Un'architettura pensata per il datacenter dà per scontata una connessione molto buona. Negli impianti invece bisogna ragionare non solo a livello infrastrutturale, ma soprattutto a livello applicativo, con tutte le problematiche proprie dei sistemi distribuiti. Non si può, ad esempio, dare per scontato che i dati prodotti sull'edge arrivino in tempi certi a un database centralizzato.

Un solo nodo per sito?

In molti impianti il cluster è una macchina sola. Non è una scorciatoia: spesso è la scelta giusta, perché costa poco, si gestisce con facilità e con una distribuzione leggera fa tutto quello che serve. Ma va valutata con chiarezza, sito per sito.

Un cluster a nodo singolo non ha ridondanza: se la macchina si ferma, si ferma tutto quello che gira sul sito finché non viene sostituita. Prima di sceglierlo bisogna quindi rispondere a qualche domanda. Cosa succede alla produzione se il nodo è giù per un giorno? Quanto in fretta si può sostituire l'hardware e ripristinare lo stato del cluster, e c'è un backup da cui farlo? Ci sono applicazioni che devono restare disponibili comunque?

Dove la risposta è che un fermo è tollerabile e il ripristino è rapido e provato, un nodo solo basta. Dove non lo è, si passa a più nodi, o si tiene l'applicazione critica fuori dal cluster. La decisione fa parte del progetto, non arriva dopo il primo guasto.

Un caso: data ingestion per una startup IoT

Per una startup IoT post-seed ho costruito un'infrastruttura in parte cloud e in parte bare metal, con cui l'onboarding di oltre 10 provider di sensori industriali è diventato automatico, tenendo sotto controllo i costi operativi. Una volta in piedi, la piattaforma è passata al team interno, che ha continuato a svilupparla.

Come lavoro

Come in ogni adozione di Kubernetes, il primo passo è capire se nel vostro caso ha senso, e in che forma. Solo dopo si decide il modello: quanti cluster, quanti nodi per sito, quali distribuzioni, cosa resta in datacenter e cosa finisce negli impianti. Ne parlo più in dettaglio nella pagina sulla consulenza Kubernetes.

L'obiettivo non cambia: un team interno capace di gestire la piattaforma da solo. Ci si arriva con l'affiancamento e, dove serve, con un corso Kubernetes che dia a tutti una base comune.