Phenquestions
Iniziamo con una definizione ingenua di "apolidia" e poi passiamo lentamente a una visione più rigorosa e reale.
Un'applicazione stateless è una che non dipende da un'archiviazione persistente. L'unica cosa di cui è responsabile il tuo cluster è il codice e altri contenuti statici ospitati su di esso. Questo è tutto, nessun database di modifica, nessuna scrittura e nessun file rimasto quando il pod viene eliminato.
Un'applicazione stateful, d'altra parte, ha molti altri parametri di cui 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 esamineremo nel dettaglio, ma prima chiariamo alcune idee sbagliate.
I servizi senza stato non sono in realtà "apolidi"
Cosa significa quando diciamo lo stato di un sistema? Bene, consideriamo il seguente semplice esempio di una porta automatica.
La porta si apre quando il sensore rileva qualcuno che si avvicina e si chiude quando il sensore non riceve alcun input rilevante.
In pratica, la tua app stateless è simile a questo meccanismo sopra. Può avere molti più stati che solo chiuso o aperto e molti diversi tipi di input, oltre a renderlo 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 è predefinito.
Quindi l'apolidia è un termine improprio.
Le applicazioni stateless, in pratica, possono anche imbrogliare un po' salvando i dettagli, ad esempio, delle sessioni client sul client stesso (i cookie HTTP sono un ottimo esempio) e hanno ancora una bella apolidia che le farebbe funzionare perfettamente sul cluster.
Ad esempio, i dettagli della sessione di un cliente come quali prodotti sono stati salvati nel carrello e non estratti possono essere tutti memorizzati sul cliente e la volta successiva che inizia una sessione, anche questi dettagli rilevanti vengono raccolti.
Su un cluster Kubernetes, un'applicazione senza stato non ha spazio di archiviazione persistente o volume ad essa associato. Dal punto di vista delle operazioni, questa è un'ottima notizia. Diversi pod in tutto il cluster possono funzionare in modo indipendente con più richieste che arrivano a loro contemporaneamente. Se qualcosa va storto, puoi semplicemente riavviare l'applicazione e tornerà allo stato iniziale con poco tempo di inattività.
Servizi con stato e teorema della CAP
I servizi stateful, d'altra parte, dovranno preoccuparsi di molti, molti casi limite e problemi strani. Un pod è accompagnato da almeno un volume e se i dati in quel volume sono danneggiati, ciò persiste anche se l'intero cluster viene riavviato.
Ad esempio, se stai eseguendo un database su un cluster Kubernetes, tutti i pod devono avere un volume locale per l'archiviazione del database. Tutti i dati devono essere in perfetta sincronia.
Quindi, se qualcuno modifica una voce nel database, e questo è stato fatto sul pod A, e arriva una richiesta di lettura sul pod B per vedere i dati modificati, allora il pod B deve mostrare i dati più recenti o darti un messaggio di errore. Questa è nota come coerenza.
Consistenza, nel contesto di un cluster Kubernetes, significa ogni lettura riceve la scrittura più recente o un messaggio di errore.
Ma questo va contro disponibilità, uno dei motivi più importanti per avere un sistema distribuito. La disponibilità implica che la tua applicazione funzioni il più vicino possibile alla perfezione, 24 ore su 24, con il minor errore possibile.
Si potrebbe obiettare che è possibile evitare tutto questo se si dispone di un solo database centralizzato responsabile della gestione di tutte le esigenze di archiviazione persistenti. Ora siamo tornati ad avere un singolo punto di errore, che è un altro problema che un cluster Kubernetes dovrebbe risolvere in primo luogo.
È necessario disporre di un modo decentralizzato per archiviare i dati persistenti in un cluster. Comunemente indicato come partizionamento di rete. Inoltre, il tuo cluster deve essere in grado di sopravvivere al fallimento dei nodi che eseguono l'applicazione stateful. Questo è noto come tolleranza di partizione.
Qualsiasi servizio stateful (o applicazione), in esecuzione su un cluster Kubernetes, deve avere un equilibrio tra questi tre parametri. Nell'industria, è noto come teorema CAP dove si considerano i compromessi tra Consistenza e Disponibilità in presenza di Partizionamento di rete.
Ulteriori riferimenti
Per ulteriori informazioni sul teorema CAP potresti voler vedere questo eccellente discorso tenuto da Bryan Cantrill, che esamina molto più da vicino l'esecuzione di sistemi distribuiti in produzione.
