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:

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:

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:

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.

Exit mobile version