{"id":71858,"date":"2020-02-28T21:00:08","date_gmt":"2020-02-28T18:00:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/patterny-hraneniya-dannyh-v-kubernetes"},"modified":"2020-03-03T16:14:09","modified_gmt":"2020-03-03T13:14:09","slug":"patterny-hraneniya-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Pattern di archiviazione dei dati in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Pattern<\/a><\/noindex>
\nCiao, Habr!<\/p>\n

Ricordiamo che \u00e8 uscito un altro articolo estremamente interessante e utile libro<\/a><\/noindex> sui modelli Kubernetes. Tutto \u00e8 iniziato con \"Pattern<\/a><\/noindex>\" di Brendan Burns, e del resto, la nostra attivit\u00e0 in questo segmento \u00e8 in pieno svolgimento<\/a><\/noindex>. Oggi vi proponiamo di leggere un articolo del blog MinIO, che riassume le tendenze e le specificit\u00e0 dei pattern di archiviazione dei dati in Kubernetes.
\n<\/a><\/noindex><\/p>\n

Kubernetes ha cambiato radicalmente i tradizionali pattern di sviluppo e distribuzione delle applicazioni. Ora un team pu\u00f2 impiegare solo pochi giorni per sviluppare, testare e distribuire un'applicazione \u2013 in diversi ambienti, il tutto all'interno di cluster Kubernetes. Un lavoro simile con le tecnologie delle generazioni precedenti richiedeva solitamente settimane, se non mesi.<\/p>\n

Tale accelerazione \u00e8 stata possibile grazie all'astrazione fornita da Kubernetes, cio\u00e8 al fatto che Kubernetes gestisce da solo le interazioni con i dettagli a basso livello delle macchine fisiche o virtuali, permettendo agli utenti di dichiarare tra le altre variabili la CPU necessaria, la quantit\u00e0 di memoria e il numero di istanze di contenitori. Poich\u00e9 un enorme community si occupa del supporto di Kubernetes e gli ambiti di applicazione continuano ad espandersi, esso guida di gran lunga tutte le piattaforme di orchestrazione dei contenitori.<\/p>\n

Con l'aumentare dell'uso di Kubernetes, cresce anche la confusione riguardo ai pattern di archiviazione dei dati utilizzati.<\/b><\/i>.<\/p>\n

Nella generale concorrenza per una fetta della torta di Kubernetes (cio\u00e8, per lo storage dei dati), quando si discute di archiviazione dei dati, il segnale qui \u00e8 inghiottito da un forte rumore.
\nKubernetes incarna il modello moderno di sviluppo e distribuzione delle applicazioni, cos\u00ec come la loro gestione. Questo modello moderno scollega l'archiviazione dei dati dai calcoli. Per comprendere appieno tale scollegamento nel contesto di Kubernetes, \u00e8 necessario anche capire cosa siano le applicazioni con stato e senza stato, e come si integri l'archiviazione dei dati. \u00c8 proprio qui che l'approccio REST API, utilizzato da S3, ha chiari vantaggi rispetto all'approccio POSIX\/CSI, caratteristico di altre soluzioni.<\/p>\n

In questo articolo parleremo dei modelli di archiviazione dei dati in Kubernetes e affronteremo separatamente la questione delle applicazioni che operano con e senza stato, per comprendere appieno qual \u00e8 la differenza tra di esse e perch\u00e9 sia importante. In seguito, verranno esaminate le applicazioni e i modelli di archiviazione dei dati utilizzati in esse alla luce delle migliori pratiche per lavorare con i contenitori e Kubernetes.<\/p>\n

Contenitori senza stato<\/h4>\n

\nI contenitori sono, per loro natura, leggeri ed efimeri. Possono essere facilmente fermati, eliminati o distribuiti su un altro nodo - il tutto richiede solo pochi secondi. In un grande sistema di orchestrazione dei contenitori, queste operazioni avvengono continuamente, e gli utenti non notano nemmeno tali cambiamenti. Tuttavia, i trasferimenti sono possibili solo se il contenitore non ha alcuna dipendenza dal nodo su cui si trova. Di tali contenitori si dice che funzionano senza stato<\/i>.<\/p>\n

Contenitori con stato<\/h4>\n

\nSe un contenitore conserva dati su dispositivi collegati localmente (o su uno storage a blocchi), il volume di archiviazione su cui si trova dovr\u00e0 essere trasferito su un nuovo nodo insieme al contenitore stesso - in caso di guasto. Questo \u00e8 importante, poich\u00e9 altrimenti l'applicazione in esecuzione nel contenitore non potr\u00e0 funzionare correttamente, poich\u00e9 deve accedere ai dati memorizzati sui supporti locali. Di tali contenitori si dice che funzionano con stato<\/i>.<\/p>\n

Da un punto di vista puramente tecnico, anche i contenitori con stato possono essere spostati su altri nodi. Di solito, ci\u00f2 \u00e8 garantito attraverso l'uso di file system distribuiti o di archiviazioni di dati a blocchi in rete, attaccate a tutti i nodi su cui funzionano i contenitori. In questo modo, i contenitori ottengono accesso ai volumi per l'archiviazione persistente dei dati, e le informazioni vengono memorizzate su dischi situati in tutta la rete. Questo metodo lo chiamer\u00f2 \"approccio del contenitore con stato<\/i>\" e nel resto dell'articolo mi riferir\u00f2 a esso in questo modo per coerenza.<\/p>\n

\"Pattern
\n
\nCon un approccio tipico ai contenitori con stato, tutti i pod delle applicazioni sono collegati a un unico sistema di file distribuiti: si crea un tipo di archiviazione condivisa, dove si trovano tutti i dati delle applicazioni. Pur essendo possibili alcune variazioni, questo \u00e8 un approccio ad alto livello.<\/p>\n

Ora vediamo perch\u00e9 l'approccio ai contenitori con stato nel mondo orientato al cloud \u00e8 considerato un antipattern.<\/p>\n

Progettazione di applicazioni orientate al cloud<\/h4>\n

\nTradizionalmente, le applicazioni utilizzavano database per la memorizzazione strutturata delle informazioni e dischi locali o sistemi di file distribuiti, dove venivano scaricati tutti i dati non strutturati o semi-strutturati. Con l'aumento dei volumi di dati non strutturati, gli sviluppatori si resero conto che POSIX era troppo 'chiacchierone', comportava costi significativi e, alla fine, ostacolava il funzionamento dell'applicazione quando si passava a scale veramente grandi.<\/p>\n

Questo ha principalmente contribuito alla nascita di un nuovo standard di archiviazione dei dati, ovvero i sistemi di archiviazione orientati al cloud, che operano principalmente basati su REST API e liberano l'applicazione dal gravoso compito della gestione di archiviazioni locali. In questo caso, l'applicazione passa effettivamente a una modalit\u00e0 di funzionamento senza stato (poich\u00e9 lo stato \u00e8 in un'archiviazione remota). Le applicazioni moderne vengono costruite fin dall'inizio tenendo conto di questo fattore. Di solito, qualsiasi applicazione moderna che gestisce dati di vario tipo (log, metadati, blob, ecc.) \u00e8 costruita secondo la paradigamma orientata al cloud, dove lo stato viene trasferito a un sistema software dedicato per la sua archiviazione. <\/p>\n

L'approccio ai contenitori con stato costringe l'intera paradigamma a tornare esattamente all'origine da cui era partita! <\/b><\/i><\/p>\n

Utilizzando le interfacce POSIX per l'archiviazione dei dati, le applicazioni funzionano come se stessero conservando lo stato, e per questo si allontanano dai postulati pi\u00f9 importanti del design orientato al cloud, ovvero la possibilit\u00e0 di variare le dimensioni dei flussi di lavoro dell'applicazione in base al carico in ingresso, spostarsi su un nuovo nodo non appena quello attuale fallisce, e cos\u00ec via.<\/p>\n

Osservando questa situazione pi\u00f9 da vicino, scopriamo che nella scelta dello storage dei dati ci troviamo di nuovo di fronte al dilemma 'POSIX contro REST API', MA con un'ulteriore aggravante riguardo ai problemi di POSIX, dovuta alla natura distribuita degli ambienti Kubernetes. In particolare,<\/p>\n