Applicazioni Stateful vs Stateless su Kubernetes

Criteri importanti da considerare prima di eseguire una nuova applicazione, in produzione, è l'architettura sottostante dell'app. Un termine spesso utilizzato in questo contesto è che l'applicazione è "apolida" o che l'applicazione è "statale". Entrambi i tipi hanno i loro pro e contro. Averemo un cluster Kubernetes nella parte posteriore della nostra mente quando parliamo di un'applicazione o di un servizio in esecuzione in produzione. Puoi installare un cluster Kubernetes tutto tuo sul cloud oppure puoi farlo funzionare come un singolo nodo sul tuo PC per fare una pratica con esso.

Cominciamo con una definizione ingenua di "apolide" e poi passiamo lentamente a una visione più rigorosa e reale.

Un'applicazione apolide è una che dipende da nessuna memoria persistente. L'unica cosa che il tuo cluster è responsabile è il codice e altri contenuti statici, che vengono ospitati su di esso. Questo è tutto, nessun database che cambia, nessuna scrittura e nessun file rimasto quando il pod viene eliminato.

Un'applicazione statale, d'altra parte, ha diversi altri parametri che dovrebbe occuparsi nel cluster. Esistono database dinamici che, anche quando l'app è offline o eliminata, persistono sul disco. Su un sistema distribuito, come Kubernetes, questo solleva diversi problemi. Li guarderemo in dettaglio, ma prima chiariamo alcune idee sbagliate.

I servizi apolidi non sono in realtà "apolidi"

Cosa significa quando diciamo lo stato di un sistema? Bene, consideriamo il seguente semplice esempio di porta automatica.

La porta si apre quando il sensore rileva qualcuno che si avvicina e si chiude una volta che il sensore non ottiene input pertinente.

In pratica, la tua app apolida è simile a questo meccanismo sopra. Può avere molti più stati che semplicemente chiusi o aperti, e molti diversi tipi di input, rendendolo anche più complesso, ma essenzialmente lo stesso.

Può risolvere problemi complicati semplicemente ricevendo un input ed eseguendo azioni che dipendono sia dall'input, sia dallo "stato" in cui si trova. Il numero di possibili stati sono predefiniti.

Quindi apolanza è un errore.

Le applicazioni apolide, in pratica, possono anche imbrogliare salvando i dettagli su, diciamo, le sessioni del cliente sul cliente stesso (i cookie HTTP sono un ottimo esempio) e hanno ancora una bella apolide che li farebbe funzionare perfettamente sul cluster.

Ad esempio, i dettagli della sessione di un cliente come quali prodotti sono stati salvati nel carrello e non il check out possono essere archiviati sul cliente e la prossima sessione inizia a ricordare questi dettagli pertinenti.

Su un cluster di Kubernetes, un'applicazione apolida non ha archiviazione o volume persistente ad esso associata. Dal punto di vista operativo, questa è una grande notizia. Diversi pod in tutto il cluster possono funzionare in modo indipendente con più richieste che si presentano contemporaneamente. Se qualcosa va storto, puoi semplicemente riavviare l'applicazione e tornerà allo stato iniziale con pochi tempi di inattività.

Servizi statali e teorema del cappuccio

I servizi statali, d'altra parte, dovranno preoccuparsi di un sacco di casi di bordo e strani problemi. Un pod è accompagnato da almeno un volume e se i dati in quel volume sono corrotti, quindi persiste anche se l'intero cluster viene riavviato.

Ad esempio, se si esegue un database su un cluster Kubernetes, tutti i pod devono avere un volume locale per la memorizzazione del database. Tutti i dati devono essere in perfetta sincronizzazione.

Quindi, se qualcuno modifica una voce nel database, e ciò è stato fatto su POD A e una richiesta di lettura è disponibile su Pod B per vedere quei dati modificati, il POD B deve mostrare che i dati più recenti o ti vengono forniti un messaggio di errore. Questo è noto come coerenza.

Consistenza, Nel contesto di un cluster Kubernetes, significa Ogni lettura riceve la scrittura più recente o un messaggio di errore.

Ma questo si taglia contro disponibilità, uno dei motivi più importanti per avere un sistema distribuito. Disponibilità implica che l'applicazione funziona il più vicino alla perfezione come possibile, tutto il giorno, con il minor errore possibile.

Si potrebbe sostenere che puoi evitare tutto questo se hai un solo database centralizzato che è responsabile della gestione di tutte le esigenze di archiviazione persistenti. Ora siamo tornati ad avere un singolo punto di fallimento, che è un altro problema che un cluster di Kubernetes dovrebbe risolvere in primo luogo.

Devi avere un modo decentralizzato di archiviare dati persistenti in un cluster. Comunemente indicato come partizionamento della rete. Inoltre, il cluster deve essere in grado di sopravvivere al fallimento di nodi che eseguono l'applicazione statale. Questo è noto come tolleranza alla partizione.

Qualsiasi servizio statale (o applicazione), eseguito su un cluster di Kubernetes, deve avere un equilibrio tra questi tre parametri. Nel settore, è noto come teorema del limite in cui i compromessi tra coerenza e disponibilità sono considerati in presenza di partizionamento della rete.

Ulteriori riferimenti

Per ulteriori informazioni sul teorema del cappuccio potresti voler vedere questo eccellente discorso tenuto da Bryan Cantrill, che guarda molto più da vicino ai sistemi distribuiti nella produzione.