3 motivi per portare applicazioni stateful su Kubernetes

3 motivi per portare applicazioni stateful su Kubernetes


 

Ci sono i puristi del cloud-native che credono che le applicazioni stateful non siano adatte ai containers. Le applicazioni stateful conservano dati persistenti da transazione a transazione ed infrangono la legge delle applicazioni a 12 fattori. Questa legge afferma che le app devono essere eseguite come “uno o più processi stateless”, comportando il refactoring di molte applicazioni per trasferire la responsabilità di ricordare le informazioni al client. Ad esempio, un e-commerce shopping cart app può utilizzare i cookie di sessione per memorizzare gli acquisti di un acquirente fino al momento della transazione.

Tuttavia, il framework a 12 fattori afferma anche che “tutti i dati che devono persistere necessitano di essere archiviati in un stateful backing service, in genere un database”. Quindi, quando questa shopping cart app deve verificare l’inventario prima di procedere, deve estrarre quei dati da un database.

Anche se i contenitori non erano originariamente progettati per i database, ora, componenti applicativi stateful come applicazioni per analisi ed elaborazione dei dati, possono essere distribuiti in ambienti Kubernetes.

E, sebbene sia ancora più probabile che i contenitori ospitino app stateless, ci sono tre ragioni principali per cui assistiamo ad un aumento delle app stateful nei contenitori.

1. Tutti traggono vantaggio da agilità e portabilità

Gli sviluppatori di software sono stati il ​​primo gruppo ad adottare rapidamente i contenitori, come un modo per accelerare lo sviluppo di microservizi applicativi. La possibilità di impacchettare microservizi in contenitori ha semplificato il lavoro sulle applicazioni in un ambiente locale e l’iterazione rapida del codice. A differenza delle applicazioni legacy monolitiche del passato, gli sviluppatori sono in grado di modificare il codice più frequentemente e fornire di conseguenza più funzionalità, senza lunghi ritardi per la compilazione e la creazione di applicazioni. Con l’aggiunta di Kubernetes come strumento di orchestrazione standard, gli sviluppatori potrebbero anche distribuire tali applicazioni in ambienti diversi, senza preoccuparsi di problemi di compatibilità e differenze nell’infrastruttura.

Oggi, container e progetti Kubernetes vengono utilizzati sia dagli sviluppatori che dai team operativi IT. Oltre all’agilità concessa agli sviluppatori, i team operativi e SRE riconoscono i vantaggi di Kubernetes, tra cui:

  • Maggiore resilienza: le applicazioni containerizzate possono essere riavviate rapidamente per risolvere i problemi. In caso di errori software o hardware che interessano un nodo, le applicazioni vengono semplicemente riavviate su un nodo diverso.
  • Tempi di risoluzione dei problemi ridotti: l’immutabilità delle applicazioni containerizzate semplifica l’applicazione di patch e l’aggiornamento o il ripristino di una versione funzionante precedente.
  • Automazione migliorata: Kubernetes supporta un modello dichiarativo, che gli consente di scalare in modo più efficace con risultati riproducibili. Le interfacce di riparazione automatica integrate e basate su API consentono una più facile implementazione delle distribuzioni Blue-Green.
  • Maggiore portabilità: poiché Kubernetes è uno standard ampiamente adottato, le applicazioni sono veramente portabili su diverse infrastrutture; fornendo un set comune di API tra cloud e ambienti locali.

Sebbene i microservizi stateless costituissero la maggior parte dei primi progetti Kubernetes, tutti i vantaggi sopra elencati sono preziosi per tutti i tipi di applicazioni. Gli sviluppatori devono ancora iterare sui designs dei database e i team operativi desiderano modi semplici per aggiornare e ripristinare le applicazioni di elaborazione dati e  rimediare rapidamente ai problemi. Di conseguenza, nell’ultimo anno, abbiamo assistito a un rapido aumento di strumenti e soluzioni per supportare le applicazioni stateful su Kubernetes, il quale ha anche incoraggiato le aziende a containerizzare le loro applicazioni stateful. In effetti, un recente sondaggio condotto da 451 Research ha mostrato che la maggioranza delle imprese (55%) concorda sul fatto che le applicazioni stateful costituiscono più della metà di tutte le applicazioni containerizzate. Si prevede che ciò aumenterà ulteriormente man mano che vengono containerizzate sempre più applicazioni stateful.

2. Lo storage in Kubernetes sta migliorando

La versione iniziale di Kubernetes aveva un supporto limitato per applicazioni stateful complesse, ma la comunità Kubernetes ha rapidamente innovato quest’area. Diamo uno sguardo ad alcune delle innovazioni chiave che hanno reso possibili applicazioni stateful, sia all’interno del framework Kubernetes che tramite estensioni di Kubernetes.

PersistentVolumes (PV)

Fin dall’inizio, Kubernetes ha supportato i volumi persistenti tramite le API PersistentVolume (PV) e PersistentVolumeClaim (PVC).

Un PersistentVolume (PV) è un volume di archiviazione che ha un ciclo di vita indipendente da ogni singolo Pod che utilizza il PV. Questi volumi vengono creati da un amministratore del sistema e possono essere supportati da una varietà di sistemi di storage, inclusi Amazon EBS, NFS o Ceph. Un PersistentVolumeClaim (PVC) è la richiesta di archiviazione da parte dell’utente. La richiesta include la dimensione del volume e le modalità di accesso richieste: lettura-scrittura su un singolo nodo montato, lettura-scrittura su molti nodi o sola lettura da molti nodi.

 


Volume Plugin

Ogni PV è supportato da un sistema di accumulo. Agli albori di Kubernetes, l’interfaccia per le diverse infrastrutture di archiviazione veniva gestita tramite volume plugin. Sono stati creati plugin per volumi diversi per supportare diverse soluzioni di archiviazione, inclusi ciascuno dei principali cloud pubblici, iSCSI e NFS. Ma l’architettura originale di questi plugin richiedeva di ricontrollare il codice nel progetto principale Kubernetes, ognuno con i propri requisiti unici. Nel 2015 Diamanti ha contribuito con il plug-in FlexVolume, che ha consentito ai provider di archiviazione di terze parti di presentare i volumi a Kubernetes in modo coerente. Ciò ha influenzato la creazione della Container Storage Interface (CSI), consentendo l’ingresso sul mercato di nuove soluzioni di storage di diversi fornitori.

StorageClass

Nella maggior parte degli ambienti aziendali, applicazioni diverse richiedono caratteristiche di archiviazione diverse per motivi di prezzo e prestazioni. Nel 2017, Kubernetes ha aggiunto l’oggetto StorageClass. Una StorageClass fornisce agli amministratori un modo per descrivere le “classi” di archiviazione che offrono e presentare diverse opzioni agli sviluppatori. Insieme a questo concetto è nata l’idea del provisioning dinamico, in cui il sistema attende le richieste di un particolare tipo di volume persistente e abbina il PVC ai PV disponibili. Ciò ha fornito maggiore flessibilità agli utenti per allineare le applicazioni al tipo di archiviazione più adatto.

StatefulSets

All’inizio, sebbene i volumi potessero essere persistenti indipendentemente dai pod, era ancora piuttosto difficile ricollegare i volumi di archiviazione ai pod quando venivano riavviati su diversi nodi del cluster. Nel 2016, abbiamo visto per la prima volta il concetto alfa di “PetSet”, che poi è diventato StatefulSets quando è stato rilasciato nel 2017. StatefulSets è un workload API object che mantiene un’identità adesiva per ciascun pod con i volumi persistenti, in modo che tu possa ricollegare un volume ad un Pod che è stato riavviato su un nodo diverso. Questa innovazione è molto importante per mantenere intatto lo stato di un cluster, poiché un’applicazione come un database ora può sopravvivere alla morte di un pod.

Container Storage Interface (CSI)

Come discusso in precedenza, i volume plugin non erano scalabili per un ecosistema di archiviazione in crescita, per questo motivo è stato creato CSI, che fornisce un’interfaccia comune in Kubernetes. CSI è diventato disponibile a dicembre 2018, offrendo ai provider di archiviazione di terze parti la possibilità di scrivere plugin che interagiscono con Kubernetes, senza dover toccare il codice principale. Ciò ha avviato l’ultima ondata di innovazione, poiché i commercial vendors sono in grado di introdurre funzionalità più avanzate nel mercato per supportare le implementazioni di produzione.

3. Le applicazioni stateful in Kubernetes sono ora pronte per la produzione

Le applicazioni stateless e stateful hanno requisiti molto diversi per la “production readiness”, il più importante è il modo in cui sia lo stato che i dati vengono protetti e conservati.

Nel caso di applicazioni stateless, qualsiasi problema si verifichi, indipendentemente dal fatto che sia correlato al nodo, al pod, alla rete o persino a un guasto hardware, Kubernetes interromperà semplicemente l’applicazione e la riavvierà da qualche altra parte. Ciò risolve un gran numero di problemi comuni che si presentano. Questo è possibile perché tutte le applicazioni containerizzate sono supportate da file immagine immutabili e file YAML dichiarativi che vengono generalmente archiviati in un repository di artefatti come Docker Hub, Artifactory o Harbor. Finché questi file sono intatti, la stessa applicazione può essere riavviata semplicemente su diversi nodi del cluster. Poiché applicazioni come questa non hanno stato, possono essere avviate anche in un cluster completamente diverso in una posizione diversa, a condizione che anche il nuovo cluster abbia accesso a questi file. Non si basano su dati preesistenti. Questo è un vantaggio molto potente di Kubernetes, che consente alle applicazioni stateless di essere altamente resilienti e portabili su diversi cluster e diverse infrastrutture.

Tuttavia, se si considerano applicazioni stateful come database o applicazioni AI/ML, tutto ciò diventa molto più complicato. Oltre a garantire che il repository di artefatti sia intatto, bisogna anche garantire che i dati stessi siano altamente disponibili e resilienti. Ciò richiede di pensare a tutti i diversi tipi di errore che possono verificarsi e di disporre un set completo di servizi per affrontare ogni tipo di errore.

Come gli ambienti dei data center tradizionali, queste applicazioni necessitano di funzionalità integrate di backup e ripristino, nonché di snapshot dei volumi, per sopravvivere a guasti occasionali del disco o del nodo. Tuttavia, molte organizzazioni vogliono anche proteggersi da un guasto del rack, quindi la capacità di estendere i cluster tra diverse zone di disponibilità è importante. Ciò può essere ottenuto tramite il mirroring sincrono, per cui i dati vengono replicati automaticamente tra i nodi di un singolo cluster esteso. Infine, aziende come banche e strutture mediche vogliono anche avere la resilienza del sito, il che significa avere la possibilità di inviare dati anche ad un’altra posizione, attraverso servizi di replica asincrona e ripristino di emergenza.

Molte delle complesse applicazioni stateful distribuite su Kubernetes sono anche ad uso intensivo di I/O. Applicazioni di elaborazione dati come Splunk o Elasticsearch, applicazioni di messaggistica come Kafka e i suddetti database e workload AI/ML, esercitano un’enorme pressione sul sistema. Per fornire prestazioni di production-level a queste applicazioni, le aziende devono anche considerare le prestazioni del sistema di storage scelto. Lo storage a bassa latenza con qualità del servizio garantita può spesso migliorare le prestazioni delle applicazioni e persino ridurre i costi essendo più efficiente. Ad esempio, i clienti Splunk possono importare più dati e raccogliere più informazioni in tempo reale con un sistema di archiviazione più efficiente.

CSI e altri sviluppi dell’ecosistema di archiviazione Kubernetes hanno visto un recente periodo di rinascita, poiché vengono introdotte soluzioni di archiviazione cloud-native più avanzate per fornire queste funzionalità. Fornendo soluzioni comparabili per la protezione dei dati e la resilienza dei dati comuni agli ambienti virtualizzati odierni o offrendo opzioni di archiviazione ad alte prestazioni e bassa latenza che possono essere sfruttate in modo nativo su Kubernetes, le scelte disponibili per le aziende oggi rendono possibile supportare anche le più complesse applicazioni stateful su Kubernetes, con le stesse prestazioni e resilienza che hanno negli ambienti tradizionali, ma con i vantaggi aggiuntivi di agilità e portabilità.

La prossima sfida per le applicazioni stateful

Quindi questo significa che il lavoro è finito? Le applicazioni stateful sono alla pari con le applicazioni stateless su Kubernetes? Non ancora, ma il divario si sta riducendo.

Come accennato in precedenza, un’applicazione stateless può essere riavviata molto facilmente in un cluster diverso, può anche essere eseguita in un cloud diverso, purché gli artefatti siano disponibili. Questa è ancora una sfida per le applicazioni stateful, in cui anche i dati nel volume dovrebbero essere portati su un cluster diverso. Diamanti sta affrontando questa sfida con Diamanti Spektra 3.0, che consente di replicare i dati su altri cluster Kubernetes, inclusi i cloud-based cluster.

È un momento entusiasmante per chi opera in questo ambiente e ci sono, oggi più che mai, sempre meno ragioni per trattenersi dal containerizzare applicazioni stateful.

Kubernetes non è più solo per i puristi.