Cluster all'edge
Dispositivi di tutti i tipi: dispositivi audio, dispositivi video, dispositivi IoT e vari sensori e attuatori. Questo post parlerà dei container distribuiti su edge cluster di piccole dimensioni che fungono da nodi edge, ovvero eseguono cluster Kubernetes su macchine di classe Raspberry Pi o in fattori di forma ridotti come Intel NUC con storage ed elaborazioni sufficienti. In particolare, i cluster che eseguono una distribuzione downstream basata su Kubernetes, come K3S o MicroK8s, o una Red Hat OpenShift Container Platform (OCP) ridotta a tre nodi su un piccolo cluster, come un nodo edge in un ambiente on-premise, lontano da un data center.
Le applicazioni ad alta intensità di calcolo richiedono un'elevata capacità di calcolo per il trattamento dei dati e lo storage che i dispositivi IoT non sono in grado di soddisfare, dato che spesso hanno un limite di risorse. Pertanto, le aziende possono utilizzare cluster all'edge come ambienti dinamici e robusti in cui i team delle operazioni possono soddisfare lo storage richiesto, il calcolo, la bassa latenza, le alte prestazioni e l'elevata larghezza di banda. Inoltre, alcuni servizi condivisi on-premise ad alta disponibilità potrebbero richiedere la scalabilità che i cluster Kubernetes sono progettati per fornire, come le distribuzione di cloud edge.
Un cluster edge può spesso essere un limite logico di risorse per un'azienda. Anche gli investimenti nei dispositivi edge di fascia alta sono costosi per le aziende. Numerosi dispositivi legacy a funzione fissa o dedicati potrebbero essere già stati implementati e preventivati. La tecnologia dei cluster edge offre alle aziende un modo per modernizzare e rendere a prova di futuro le proprie applicazioni utilizzando un approccio edge-native. Ciò avviene collegando tali dispositivi a un cluster di piccole dimensioni con impronta edge che esegue una soluzione di gestione dei dispositivi o di piattaforma IoT. Il cluster edge verrebbe quindi gestito e utilizzato come un dispositivo edge.
I cluster edge offrono i seguenti vantaggi fondamentali:
- Scalabilità: offrono ai clienti la facilità e la capacità di aggiungere capacità aggiuntiva al cluster in base alla domanda. Può essere impostato per la scalabilità automatica, riducendo così il tempo e gli sforzi del team delle operazioni.
- Distribuzione: insight e azioni più rapide man mano che una maggiore quantità di dati viene elaborata e analizzata dal cluster edge, evitando così le spese e il tempo per l'invio dei dati al cloud.
- Conformità: l'elaborazione dei dati nel cluster edge aiuta anche a soddisfare le esigenze di conformità normativa, la residenza dei dati e l'isolamento dei dati.
- Sicurezza: comunicazione sicura tra tutti i server delle app ospitati nel cluster.
- Alta disponibilità: una maggiore affidabilità è fornita dalle opzioni di failback sul cluster e dalla possibilità di creare nuovi nodi in base alla necessità per le operazioni dell'applicazione.
Facciamo un esempio nel settore retail. Un rivenditore desidera ritirare un prodotto specifico dallo scaffale del negozio o renderlo comunque non disponibile all'acquisto a causa di un richiamo del prodotto per motivi di sicurezza. Dovrebbe aggiornare il suo sistema di inventario centrale e far sì che tale aggiornamento abbia effetto in più punti vendita.
Un edge cluster nel negozio, abbinato a dispositivi IoT, telecamere e sensori, è la soluzione ideale per supportare questo scenario. Mentre il sistema di inventario contrassegna il particolare SKU (Stock Keeping Unit) come ritirato, il responsabile del punto vendita riceve la notifica di ritirare i prodotti fisici dagli scaffali. Contemporaneamente, il sistema Point of Sale (POS) viene aggiornato per invalidare quel particolare codice a barre del prodotto. Una soluzione edge cluster ben progettata consentirebbe un'azione rapida, su larga scala, senza costosi ritardi o errori umani.
La Figura 1 mostra il cluster implementato in un tipico punto vendita con layout a griglia, con telecamere di sicurezza e inventario, sistemi point of sale (POS), un sensore di ingresso e sensori di temperatura nei congelatori:
Diamo un'occhiata a un altro esempio, questa volta nel settore dei trasporti. Una nave da carico con connettività limitata alla rete trasporta centinaia di reefer. I container refrigerati (reefer) sono, in poche parole, grandi frigoriferi trasportati dalle portacontainer per movimentare merci sensibili alla temperatura, come carne, verdura e prodotti farmaceutici, senza che si deteriorino. Il contenuto determina la temperatura da mantenere all'interno di questi reefer.
I container refrigerati non solo devono mantenere una temperatura stabile all'interno, ma anche controllare l'umidità e promuovere un flusso d'aria adeguato. Il monitoraggio e la gestione dei termostati, delle ventole e di altri componenti vitali del reefer sono eseguiti meglio da un cluster edge, anche nello scenario di connettività limitata a bordo della nave. Questa configurazione consentirà anche il monitoraggio e l'invio di avvisi a bordo senza richiedere un'infrastruttura basata su cloud. Quando la nave raggiunge un porto, il cluster edge si riconnette all'hub edge sul molo di spedizione o nel cloud. La gestione di questi reefer e altri dispositivi su larga scala, con un intervento umano minimo o nullo, è possibile solo tramite una soluzione di cluster edge ben progettata.
Un edge cluster può essere abbastanza piccolo da stare su uno scaffale in uno spazio ristretto, come un QSR (ristorante con servizio rapido), un treno, un'ambulanza, un chiosco, negozi, magazzini e reparti di produzione. Possiamo implementare workload pertinenti per questi ambienti. Potrebbero essere applicazioni di rilevamento video, applicazioni di rilevamento della temperatura, applicazioni di biglietteria, servizi vocali mission-critical o persino applicazioni AR/VR.
Come esempio rappresentativo di una modesta installazione del cluster Kubernetes per gli scenari precedenti, ecco alcuni dettagli su come implementarla utilizzando K3s. Ricorda che potresti anche utilizzare distribuzioni Kubernetes simili, come minikube o microk8s. Il seguente elenco mostra una configurazione di cluster di base, con 1 master e 2 worker (https://k3s.io/). Mostriamo il set minimo di comandi che è necessario eseguire su ciascun componente. La topologia a 3 nodi è illustrata nella seguente tabella:
K3S_URL è l'indirizzo IP del nodo master insieme alla porta, dove 6443 è la porta di ascolto HTTPS. Si noti che, per impostazione predefinita, K3s utilizza i container containerd e non Docker.
Master
$export K3S_URL="https://192.168.0.248:6443" $curl -sfL https://get.k3s.io | sh - $sudo cat /var/lib/rancher/k3s/server/node-token K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd
Worker 1
$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd"
Worker 2
$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d585
Dal punto di vista di IBM Edge Application Manager (IEAM), un cluster edge è simile a un dispositivo edge perché su entrambi è installato un agente edge. La figura 2 mostra i componenti di alto livello di un cluster edge:
I cluster edge sono fondamentalmente nodi edge basati su cluster Kubernetes. Quindi, qual è la logica alla base della configurazione di un piccolo cluster come nodo edge? Ogni nodo edge, in questo caso, il cluster edge, è registrato presso l'exchange nell'organizzazione del proprietario del cluster edge. La registrazione è composta da un ID e un token di sicurezza che si applicano solo a quel cluster edge. Un processo di agente autonomo viene eseguito su quel cluster edge e applica le politiche stabilite dal proprietario del cluster edge. Contemporaneamente, ai bot di accordo autonomi (o agbot) vengono assegnate politiche di distribuzione per implementare servizi in questi cluster edge.
Quanto sopra descrive i passaggi del prodotto IBM Edge Application Manager, che consente la distribuzione di servizi edge su un cluster edge, tramite un operatore Kubernetes, abilitando così gli stessi meccanismi di distribuzione autonomi utilizzati con i dispositivi edge. Questo significa che tutta la potenza di Kubernetes come piattaforma di gestione dei container è disponibile per i servizi edge.
Questo link nel knowledge center del prodotto descrive i passaggi per installare un edge agent su un edge cluster. Dopodiché, le applicazioni pertinenti possono essere installate su quell'edge cluster. Come avrai intuito, IEAM supporta Kubernetes, K3s, miniKube, microK8s e Red Hat OpenShift.
Questo blog ha descritto il valore aziendale unico fornito dall'implementazione dei cluster all'edge, non necessariamente al far edge, ma comunque su nodi all'edge in sedi on-premise remote. Come detto in precedenza, le funzionalità di clustering dei nodi edge aiutano a gestire e implementare i workload da un cluster di hub di gestione a istanze remote di OCP o altri cluster basati su Kubernetes.
Un cluster edge consente casi d'uso all'edge che richiedono la co-locazione del calcolo con le operazioni aziendali o che richiedono più scalabilità, disponibilità e capacità di calcolo rispetto a quelle che possono essere supportate da un dispositivo edge. Inoltre, non è raro che i cluster forniscono servizi di applicazione necessari per supportare i servizi in esecuzione su dispositivi edge a causa della loro vicinanza a tali dispositivi.
Esiste un nuovo strumento di gestione dei container open source per lo sviluppo, la gestione e l'esecuzione di container Open Container Initiative (OCI). Chiamato Podman (abbreviazione di Pod Manager), è un'opzione molto adatta per cluster edge. Podman viene fornito come parte della libreria libpod e può essere utilizzato per creare e gestire container. Sebbene possa eseguire container Docker, attualmente funziona solo su sistemi operativi basati su Linux. Puoi scoprire di più su Podman qui.
L'IBM Cloud Architecture Center offre numerose architetture di riferimento, ibride e multicloud.
Puoi anche visualizzare la recente architettura di riferimento per l'edge nell'automotive.
Un ringraziamento speciale a Joe Pearson e David Booz per la revisione dell'articolo.
Assicurati di dare un'occhiata agli altri articoli di questa serie di post sul blog sull'edge computing:
- Parte 3: “Architettura all'edge”
- Parte 4: “DevOps all’edge”
- Parte 7: “Sicurezza all'edge”
- Parte 8: "Analytics all'edge"
- Parte 9: "5G all'edge"
- Parte 10: “Cluster all'edge”
- Parte 11: “Automazione all'edge”
- Parte 12: "Network slicing all'edge"
- Parte 13: "Dati all'edge"
- Parte 14: "Decisioni architettoniche all'edge"
- Parte 15: “GitOps all'edge”
- Parte 17: "Servizi di storage all'edge"
- Parte 18: "Cloud service all'edge"
- Parte 20: "Sovranità dei dati all'edge"
- Parte 22: "Prodotti connessi all'edge"
- Parte 23: “Foundation model all'edge”