Lo stato attuale di Kubernetes: stateful e stateless

Non ci posso credere che, ancora nel 2024, sento spesso gli operatori delle piattaforme dire che Kubernetes è solo per i carichi di lavoro stateless o che non richiede la protezione dei dati in quanto “tutte le nostre app sono stateless”. In questo articolo fornirò informazioni di base sulla presenza degli stati nelle nostre applicazioni, sull’ascesa del mito “Kubernetes = stateless” e parlerò delle esigenze di protezione dei dati in tutti gli ambienti Kubernetes.

Stateful vs. Stateless — Nozioni di base

Per stateless si intende un carico di lavoro che non richiede la persistenza con stato, ad esempio se il riavvio o la ridistribuzione del carico di lavoro comporta la scomparsa di tutti i dati raccolti o delle impostazioni modificate. Rispetto ai predecessori di macchine virtuali (VM) stateful, i contenitori sono intrinsecamente stateless. Riavviando un contenitore, un utente sa che il carico di lavoro sta eseguendo se stesso, quello previsto nel momento in cui l’immagine del contenitore è stata inizialmente creata.

Secondo la logica, un carico di lavoro stateful è tipo di carico che conserva i dati in modo che sia possibile accedervi tra un riavvio e l’altro. I carichi di lavoro stateful più comuni includono database come PostgreSQL, MySQL o MongoDB.

E quindi, cos’è un’applicazione stateless ?

In genere, le applicazioni sono costituite da più carichi di lavoro. Anche le applicazioni monolitiche basate su VM sono generalmente costituite da front-end, logica di business e carichi di lavoro di database separati. Le applicazioni cloud native e basate su microservizi saranno in genere costituite da molti più carichi di lavoro separati, ognuno con la propria funzione specifica, con l’obiettivo di consentire alle organizzazioni di fornire nuove funzionalità e servizi più velocemente che mai.

Ciò significa che, nella stragrande maggioranza dei casi, le applicazioni stateless non esistono.

La tua app preferita per ordinare cibo, un’app “di cose da fare” sul telefono, un modulo che compili per prenotare un appuntamento dal medico: tutto questo sarebbe effettivamente inutile se non ci fossero alcuni carichi di lavoro stateful responsabili della persistenza dei dati critici associati a ciascuno di questi casi d’uso.

Con Kubernetes, è fondamentale capire dove risiedono i dati o lo stato dell’applicazione, all’interno o all’esterno del cluster.

Come siamo arrivati a questo punto: Kubernetes = Stateless?

Nella prima metà degli anni 2010, quando Docker è diventata de facto una piattaforma di contenitori per il software di imballaggio, disporre di una soluzione per orchestrare gruppi di contenitori su larga scala è stato fondamentale per estrarre il pieno valore operativo dal passaggio ai microservizi, e Kubernetes lo ha fatto. Le implementazioni dichiarative, la disponibilità elevata e la scalabilità automatizzata sono stati vantaggi significativi per i carichi di lavoro stateless che potevano essere arrestati, riavviati e clonati con facilità. Questi carichi di lavoro, che spesso forniscono più elaborazione front-end o server applicazioni, potrebbero essere connessi ai servizi dati in esecuzione all’esterno del cluster. La soluzione è stata salutata da molti come un successo. Kubernetes era chiaramente una soluzione progettata per i carichi di lavoro Stateless, giusto?

Eppure, già in Kubernetes v1.0, accanto a tutte queste straordinarie funzionalità per i carichi di lavoro stateless, c’era già Persistent Volumes, un meccanismo nativo di Kubernetes per collegare lo storage persistente ai pod effimeri. Chiaramente, l’intenzione di supportare i carichi di lavoro stateful è stata presa in considerazione fin dall’inizio, con diversi miglioramenti degni di nota lungo il percorso:

• Dicembre 2017 (v1.9) Disponibilità al pubblico di StatefulSets: persistenza dei tratti di identità dei pod e delle operazioni ordinate
• Dicembre 2018 (v1.13) Disponibilità generale di Container Storage Interface (CSI), uno standard che consente a qualsiasi produttore di storage di creare i propri plugin per fornire storage ai carichi di lavoro Kubernetes
• Maggio 2018 Introduzione di Operator Framework, un Software Development Kit (SDK) per semplificare l’implementazione e la gestione di carichi di lavoro avanzati, come i database, su Kubernetes
• Dicembre 2020 (v1.20) Disponibilità generale degli snapshot del volume all’interno della specifica CSI — fornendo un’interfaccia standardizzata per l’esecuzione delle operazioni di snapshot dello storage all’interno di Kubernetes

Questi miglioramenti, combinati con l’impegno di molti fornitori e collaboratori di progetti diversi, hanno creato un ricco ecosistema che offre agli utenti la libertà di scegliere quali servizi dati forniranno lo stato della loro applicazione e dove verranno eseguiti i carichi di lavoro.

L’ascesa di GitOps

Durante questo periodo, la community di Kubernetes ha visto nascere un’altra idea per migliorare l’orchestrazione dei container: GitOps. Il concetto è semplice: usare il controllo versione come fonte di verità, archiviando tutto il necessario per implementare un’applicazione, inclusi il codice e le risorse Kubernetes. Ogni volta che il codice viene unito al repository per apportare una modifica, un controller aggiorna l’implementazione in modo che rifletta lo stato desiderato descritto in Git. Le implementazioni GitOps possono fornire un meccanismo per il controllo delle modifiche, la possibilità di ridistribuire un intero ambiente con un solo clic e un modo per annullare le modifiche, a volte.

Il fatto che Kubernetes sia in grado di eseguire carichi di lavoro stateful significa che dovresti?

Incaricato di creare un’applicazione proof-of-concept, uno sviluppatore può spesso optare per un database gestito ospitato nel cloud, o DBaaS, per ospitare i dati persistenti all’esterno del cluster Kubernetes. Le soluzioni DBaaS offrono API di facile utilizzo per gli sviluppatori e un rapido time-to-value per gli utenti, indipendentemente dal livello di competenza nell’amministrazione del database. Tuttavia, come spesso accade, la via più facile non è sempre la migliore. Esploriamo i motivi per prendere in considerazione l’esecuzione di carichi di lavoro stateful all’interno o all’esterno del cluster:

• Latenza : la co-locazione dei servizi dati insieme ad altri carichi di lavoro containerizzati aiuta a garantire una connettività a bassa latenza ai dati per offrire un’esperienza utente coerente.
• Mobilità: Kubernetes fornisce un solido livello di astrazione che consente di spostare lo stesso carico di lavoro tra cloud diversi. Ciò consente alle organizzazioni di soddisfare le esigenze di controllo completo dei dati o semplicemente di trarre vantaggio da condizioni di prezzo migliori. Tuttavia, se i tuoi servizi dati sono legati a un DBaaS specifico per il cloud, la migrazione tra ambienti diventa molto più complicata. Le automazioni e le policy create per un DBaaS dovranno essere ricreate per il database gestito equivalente nel cloud di destinazione, presumendo che esista e soddisfi i requisiti. Saranno necessari strumenti ed elaborazioni separati per ridistribuire i carichi di lavoro Kubernetes dai servizi dati esterni.
• Gestione dei dati delle copie: gli sviluppatori devono testare l’applicazione con dati recenti e pertinenti, richiedendo processi separati per gestire e connettere questi servizi dati quando vengono eseguiti all’esterno del cluster. Nell’ambito di una soluzione completamente dichiarativa che esegue carichi di lavoro sia stateless che stateful all’interno del cluster, gli utenti possono semplicemente ripristinare i backup completi delle applicazioni come cloni utilizzando un’interfaccia nativa di Kubernetes come “kubectl”.
• Persistenza Poliglotta: un modo elegante per dire “il servizio dati giusto per il caso d’uso giusto”. Man mano che le applicazioni legacy vengono ricostruite utilizzando un’architettura basata su microservizi, gli sviluppatori possono scegliere su Kubernetes di implementare il servizio dati ideale per ogni esigenza, con un’implementazione semplificata e una gestione continua a carico degli operatori. Le organizzazioni che gestiscono servizi dati al di fuori di Kubernetes potrebbero non essere in grado di scalare per soddisfare i complessi requisiti operativi per supportare ciascuna delle selezioni di servizi dati ideali effettuate dagli sviluppatori.
• Costo: con le soluzioni DBaaS, paghi per la comodità. Tuttavia, partner come EnterpriseDB hanno dimostrato come l’hosting dei propri servizi dati su Kubernetes offra un costo totale di gestione (TCO) inferiore senza sacrificare in modo significativo l’esperienza dell’utente.

La scelta di consolidare i carichi di lavoro stateless e stateful in Kubernetes può aumentare la flessibilità della posizione in cui possono essere eseguite le applicazioni. Può anche fornire un self-service aggiuntivo per DevOps, ridurre i costi e semplificare strumenti e processi. In questo modo è possibile applicare la metodologia GitOps a tutte le parti di un’applicazione. Non dovrebbe sorprendere quindi, secondo il più recente rapporto di Datadog sull’uso dei container nel mondo reale, che i database continuino a essere la categoria più popolare di carichi di lavoro containerizzati.

Mantenere protetti i dati di Kubernetes

Team Stateful

Se sei già convinto che i carichi di lavoro stateful su Kubernetes siano la strada da seguire, probabilmente saprai già che fornire backup e disaster recovery per queste applicazioni richiede uno strumento appositamente progettato. Ogni applicazione è composta da molte risorse Kubernetes diverse (ConfigMaps, Secrets, Deployments e così via) insieme a dati di volume persistenti. E soprattutto, tutti questi elementi devono essere correttamente individuati, sottoposti a snapshot ed esportati in una posizione sicura off-cluster.

Ecco Veeam Kasten for Kubernetes, una soluzione di protezione dei dati e mobilità delle applicazioni nativa di Kubernetes. Kasten offre alle organizzazioni un modo facile da usare, scalabile e sicuro per creare backup immutabili e ripristinare intere applicazioni in modo rapido e affidabile.

Poiché Kasten fornisce un’API dichiarativa nativa di Kubernetes per la definizione di policy, l’esecuzione di azioni e altro ancora, la protezione dei dati può essere strettamente integrata in qualsiasi implementazione GitOps. Questo è vero in una vasta gamma di casi d’uso, dalla distribuzione e configurazione di Kasten su un nuovo cluster, fino al miglioramento di GitOps automatizzando i backup prima di implementare gli aggiornamenti del codice. Di per sé, GitOps offre la possibilità di eseguire il rollback delle modifiche alla configurazione di una risorsa Kubernetes; Tuttavia, se una di queste modifiche anomale altera i dati su un volume persistente (ad esempio, una modifica errata dello schema o l’eliminazione di una tabella), sarà necessario un backup recente che possa essere ripristinato rapidamente.

Team Stateless

Non sei ancora pronto a scambiare il tuo DBaaS preferito con un database nuovo di zecca gestito da un operatore in hosting su Kubernetes? Kasten è sempre al tuo fianco. Vediamo perché la protezione dei dati nativa di Kubernetes è ancora necessaria:

• Lo stato deve risiedere da qualche parte : ovunque i dati risiedano al di fuori del cluster, rimane fondamentale essere in grado di riprodurre implementazioni a un certo point-in-time delle applicazioni, tipicamente per motivi di DR o conformità. Fondamentalmente, Kasten è un motore di orchestrazione progettato per le operazioni di protezione dei dati. Le funzionalità blueprint di Kasten consentono solidi controlli per mettere in pausa i servizi dati sul cluster, ma possono essere sfruttate anche per orchestrare snapshot e backup di servizi dati esterni. Ciò può includere l’orchestrazione di dump logici di un database o l’integrazione diretta con le API DBaaS.
• GitOps non è infallibile : molti amministratori e ingegneri hanno sperimentato una qualche forma di “testato in produzione”. Ciò significa che sono state apportate delle modifiche a un’istanza di produzione che <insert important reason here> ha aggirato il processo di gestione delle modifiche accettato. Pertanto, l’unica fonte di verità di ciò che è stato distribuito proviene dal cluster stesso in fase di esecuzione. L’esecuzione di backup regolari dei manifesti associati a ciascuna applicazione distribuita garantisce che tutte queste discrepanze vengano catturate, consentendo riproduzioni fedeli dell’ambiente originale per supportare il DR e/o eventuali requisiti normativi.
• Protezione delle immagini  dei container— Kasten si integra con molte delle funzionalità avanzate fornite da Red Hat OpenShift, incluso il supporto per la protezione e il ripristino delle immagini dei container ImageStream. I flussi di immagini aggiungono una vasta gamma di funzionalità per la creazione e la distribuzione di immagini di container rispetto a Kubernetes upstream. Le fonti potenzialmente trascurate di uno stato del cluster sono le immagini del contenitore ImageStream che, per impostazione predefinita, vengono inserite nel registro del contenitore interno del cluster. La ricostruzione dall’origine non garantisce che le immagini risultanti siano le stesse. Ancora una volta, essere in grado di riprodurre completamente un ambiente o di eseguire un ripristino dalla perdita di un cluster richiede backup affidabili.
• Macchine virtuali su Kubernetes — Grazie al progetto KubeVirt e ai suoi collaboratori, è ora possibile eseguire le VM fianco a fianco con carichi di lavoro containerizzati su Kubernetes. Ciò consente alle organizzazioni di semplificare strumenti ed elaborazioni relative a Kubernetes, fornendo al contempo una semplice rampa di accesso ai carichi di lavoro che non sono ancora stati, o semplicemente non saranno, trasformati in applicazioni completamente native per il cloud. Anche su Kubernetes, le VM sono intrinsecamente stateful, ma non possono essere protette con i tradizionali strumenti di backup delle VM. Kasten V7.0 offre il supporto migliore della categoria per il backup e il ripristino delle VM su Kubernetes che eseguono OpenShift Virtualization.

Il team Protezione dei dati di Kubernetes

Kubernetes si è evoluto per supportare tutti i tipi di carichi di lavoro, indipendentemente dalla persistente convinzione che Kubernetes sia adatto solo a carichi di lavoro stateless. Mentre le organizzazioni si impegnano per estrarre il massimo valore dagli investimenti nativi su cloud, è inevitabile un continuo spostamento verso l’esecuzione di carichi di lavoro stateful. Prestazioni e mobilità migliorate, gestione semplificata dei dati di copia, persistenza poliglotta e risparmi sui costi sono tutti vantaggi che attendono di essere realizzati.

Che si tratti di eseguire carichi di lavoro stateful o stateless, la protezione dei dati rimane fondamentale. Veeam Kasten for Kubernetes offre una soluzione nativa di Kubernetes per il backup di dati e applicazioni, il disaster recovery, la mobilità delle applicazioni e la protezione dal ransomware. Inoltre, le metodologie GitOps possono essere migliorate integrando la protezione dei dati nelle distribuzioni delle applicazioni. In definitiva, l’adozione di carichi di lavoro con stato su Kubernetes può non solo sbloccare opportunità di fatturato, ma anche portare maggiore flessibilità, self-service, economicità e operazioni ottimizzate alle organizzazioni.

Prova la nostra soluzione Veeam Kasten Free o la versione di prova Enterprise per iniziare subito.