{"id":55467,"date":"2020-01-21T00:00:00","date_gmt":"2020-01-20T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya"},"modified":"2020-02-18T14:03:35","modified_gmt":"2020-02-18T11:03:35","slug":"postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-marted\u00ec n. 5: \u00abPostgreSQL e Kubernetes. CI\/CD. Automazione dei test\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-marted\u00ec
\n
\nAlla fine dello scorso anno si \u00e8 svolta un'altra diretta della comunit\u00e0 russa di PostgreSQL #RuPostgres<\/a><\/noindex>, durante la quale il cofondatore Nikolai Samokhvalov ha conversato con il direttore tecnico di \"Flant\" Dmitry Stolyarov su questo DBMS nel contesto di Kubernetes.<\/p>\n

Pubbliciamo il verbale della parte principale di questa discussione, e su canale YouTube della comunit\u00e0<\/a><\/noindex> \u00e8 stata pubblicata la registrazione video completa:<\/a><\/noindex><\/p>\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Database e Kubernetes<\/h2>\n

\nNS<\/b>: Oggi non parleremo di VACUUM e CHECKPOINT, vogliamo parlare di Kubernetes. So che hai gi\u00e0 molti anni di esperienza. Ho guardato i tuoi video e alcuni li ho persino rivisti... Partiamo subito: perch\u00e9 Postgres o MySQL in K8s?<\/i><\/p>\n

DS<\/b>: Non c'\u00e8 una risposta definitiva a questa domanda. Ma in generale, si tratta di semplicit\u00e0 e comodit\u00e0... potenziali. A tutti piacciono i servizi gestiti.<\/p>\n

NS<\/b>: Come RDS<\/a><\/noindex>: solo che a casa tua?<\/i><\/p>\n

DS<\/b>: S\u00ec: come RDS, solo ovunque.<\/p>\n

NS<\/b>: \"Ovunque\" \u00e8 una buona osservazione. Nelle grandi aziende tutto \u00e8 situato in posti diversi. E allora perch\u00e9, se si tratta di una grande azienda, non prendere una soluzione pronta? Ad esempio, Nutanix ha i suoi sviluppi, altre aziende (VMware\u2026) hanno lo stesso \"RDS, solo a casa\".<\/i><\/p>\n

DS<\/b>: Ma stiamo parlando di una realizzazione specifica, che funzioner\u00e0 solo in determinate condizioni. E se parliamo di Kubernetes, qui c'\u00e8 una grande variet\u00e0 di infrastruttura (che pu\u00f2 essere in K8s). In sostanza \u00e8 uno standard per API verso il cloud...<\/p>\n

NS<\/b>: E anche gratuito!<\/i><\/p>\n

DS<\/b>: Non \u00e8 cos\u00ec importante. La gratuit\u00e0 \u00e8 importante per un segmento di mercato non molto grande. Ci\u00f2 che conta \u00e8 un'altra cosa... Probabilmente ti ricordi la relazione \"Database e Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

NS<\/b>: S\u00ec.<\/i><\/p>\n

DS<\/b>: Ho capito che \u00e8 stato percepito in modo molto ambiguo. Alcune persone hanno pensato che stessi dicendo: \"Ragazzi, andiamo con tutti i DB in Kubernetes!\", mentre altri hanno deciso che si trattava di biciclette ridicole. Ma volevo dire qualcos'altro: \"Guardate cosa sta succedendo, quali sono i problemi e come possono essere risolti. \u00c8 il momento di portare i database in Kubernetes? Nella produzione? Solo se vi piace... fare certe cose. Ma per lo sviluppo, posso dire che lo consiglio. Per lo sviluppo \u00e8 molto importante la dinamicit\u00e0 della creazione\/rimozione degli ambienti.\"<\/p>\n

NS: Per sviluppo intendi tutti gli ambienti che non sono in produzione? Staging, QA...<\/i><\/p>\n

DS<\/b>: Se parliamo di perf-stand, probabilmente no, perch\u00e9 i requisiti sono specifici. Se parliamo di casi particolari, dove su staging \u00e8 necessaria un'enorme DB, probabilmente no... Se si tratta di un ambiente statico, a lungo termine, quale beneficio c'\u00e8 nel fatto che il database si trovi in K8s?<\/p>\n

NS<\/b>: Nessuno. Ma dove vediamo ambienti statici? Gli ambienti statici sono gi\u00e0 obsoleti domani.<\/i><\/p>\n

DS<\/b>: Lo staging pu\u00f2 essere statico. Abbiamo clienti\u2026<\/p>\n

NS<\/b>: S\u00ec, ne ho anche io. \u00c8 un grosso problema avere un database di 10 TB, mentre lo staging \u00e8 di 200 GB\u2026<\/i><\/p>\n

DS<\/b>: Ho un caso clamoroso! In staging c'\u00e8 un database di produzione che subisce modifiche. Ed \u00e8 prevista una funzione: \"rilascialo in produzione\". Queste modifiche - le delte - vengono aggiunte (sembra che si sincronizzino semplicemente tramite API) in produzione. \u00c8 un'opzione molto esotica.<\/p>\n

NS<\/b>: Ho visto startup nella Valle che sono ancora in RDS o addirittura in Heroku - storie di 2-3 anni fa - che scaricano un dump sui loro laptop. Perch\u00e9 il database \u00e8 solo di 80 GB e c'\u00e8 spazio nel laptop. Poi comprano dischi per tutti, in modo da avere 3 database e gestire sviluppi diversi. Anche questo succede. Ho anche visto che non hanno paura di copiare da produzione a staging - molto dipende dall'azienda. Ma ho visto anche che hanno paura, e che spesso manca tempo e mani. Ma prima di passare a questo argomento, voglio sentire parlare di Kubernetes. Ho capito bene che in produzione non ce l'ha ancora nessuno?<\/i><\/p>\n

DS<\/b>: Abbiamo piccoli database in produzione. Si parla di volumi di decine di gigabyte e servizi non critici, per i quali \u00e8 stata una seccatura fare repliche (e non c'era nemmeno necessit\u00e0). E a condizione che sotto Kubernetes ci sia un buon storage. Questo database funzionava in una macchina virtuale - diciamo in VMware, sopra un SAN. L'abbiamo messo in PV<\/a><\/noindex> e ora possiamo spostarlo da una macchina all'altra.<\/p>\n

NS<\/b>: Database di questa dimensione, fino a 100 GB, su buoni dischi e con una buona rete possono essere distribuiti in pochi minuti, giusto? Una velocit\u00e0 di 1 GB al secondo non \u00e8 pi\u00f9 esotica.<\/i><\/p>\n

DS<\/b>: S\u00ec, per un'operazione lineare non \u00e8 un problema.<\/p>\n

NS<\/b>: Ok, per prod dobbiamo solo pensarci. E se consideriamo Kubernetes per ambienti non di produzione \u2014 come procedere? Vedo che in Zalando fanno un operatore<\/a><\/noindex>, in Crunchy stanno sviluppando<\/a><\/noindex>, e ci sono anche altre opzioni. E c'\u00e8 OnGres<\/a><\/noindex> \u2014 \u00e8 il nostro buon amico Alvaro dalla Spagna: in sostanza fanno non solo operatore<\/a><\/noindex>, ma un'intera distribuzione (StackGres<\/a><\/noindex>), in cui oltre a Postgres abbiamo deciso di mettere anche un backup, un proxy Envoy...<\/i><\/p>\n

DS<\/b>: A cosa serve Envoy? Per il bilanciamento del traffico di Postgres?<\/p>\n

NS<\/b>: S\u00ec. Cio\u00e8, lo vedono cos\u00ec: se prendiamo una distribuzione di Linux e il suo kernel, l'ordinario PostgreSQL \u00e8 il kernel, mentre loro vogliono creare una distribuzione che sia amichevole con il cloud e possa girare in Kubernetes. Stanno integrando componenti (backup, ecc.) e affinando affinch\u00e9 funzionino bene.<\/i><\/p>\n

DS<\/b>: Molto interessante! In sostanza, \u00e8 un software per creare il proprio Postgres gestito.<\/p>\n

NS<\/b>: Le distribuzioni Linux hanno sempre problemi: come fare i driver affinch\u00e9 l'intero hardware venga supportato. E la loro idea \u00e8 che funzioneranno in Kubernetes. So che nell'operatore Zalando abbiamo recentemente visto un'integrazione con AWS e questo non \u00e8 molto positivo. Non dovrebbe esserci un'integrazione con un'infrastruttura specifica \u2014 qual \u00e8 allora il senso?<\/i><\/p>\n

DS<\/b>: Non so in quale situazione specifica si sia legato Zalando, ma attualmente in Kubernetes lo storage \u00e8 fatto in modo tale che non \u00e8 possibile effettuare un backup su disco in modo generico. Recentemente, nello standard \u2014 nell'ultima versione della specifica CSI<\/a><\/noindex> \u2014 \u00e8 stata introdotta la possibilit\u00e0 di snapshot, ma dove \u00e8 stata implementata? Onestamente, \u00e8 tutto ancora cos\u00ec grezzo\u2026 Stiamo provando CSI su AWS, GCE, Azure, vSphere, ma appena inizi a utilizzarlo, diventa evidente che non \u00e8 ancora pronto.<\/p>\n

NS<\/b>: Per questo a volte \u00e8 necessario legarsi all'infrastruttura. Penso che sia ancora una fase iniziale \u2014 i problemi di crescita. Domanda: cosa consiglieresti ai neofiti che vogliono provare PgSQL in K8s? Quale operatore, magari?<\/i><\/p>\n

DS<\/b>: Il problema \u00e8 che per noi Postgres rappresenta solo il 3%. Abbiamo una lunga lista di vari software su Kubernetes, non voglio nemmeno elencarli tutti. Ad esempio, Elasticsearch. Ci sono molti operatori: alcuni si sviluppano attivamente, altri no. Abbiamo stabilito dei requisiti su cosa deve avere un operatore affinch\u00e9 lo prendiamo sul serio. L'operatore specifico per Kubernetes \u2014 non in \u00abun operatore per fare qualcosa in Amazon\u00bb\u2026 Infatti utilizziamo in modo abbastanza massiccio (= quasi tutti i clienti) un unico operatore \u2014 per Redis<\/a><\/noindex> (presto pubblicheremo un articolo anche su di lui)<\/i>.<\/p>\n

NS<\/b>: E per MySQL non esiste nemmeno? So che Percona\u2026 dato che ora si occupano di MySQL, MongoDB e Postgres, dovrebbero creare qualcosa di universale: per tutti i database, per tutti i fornitori di cloud.<\/i><\/p>\n

DS<\/b>: Non abbiamo avuto tempo di esaminare gli operatori per MySQL. Per noi questo non \u00e8 attualmente il focus principale. MySQL funziona bene in modalit\u00e0 standalone. A cosa serve un operatore, se puoi semplicemente avviare il database\u2026 Puoi avviare un container Docker con Postgres, oppure farlo in modo semplice.<\/p>\n

NS<\/b>: C'era anche questa domanda. Davvero senza operatore?<\/i><\/p>\n

DS<\/b>: S\u00ec, siamo al 100% con PostgreSQL avviato senza operatore. Per ora \u00e8 cos\u00ec. Utilizziamo attivamente l'operatore per Prometheus, per Redis. Abbiamo in programma di trovare un operatore per Elasticsearch, poich\u00e9 \u00e8 quello che ha maggiore urgenza, perch\u00e9 vogliamo installarlo nel 100% dei casi in Kubernetes. Allo stesso modo, vogliamo arrivare a installare sempre MongoDB in Kubernetes. Qui si presentano delle esigenze specifiche: c'\u00e8 la sensazione che in questi casi si possa fare qualcosa. Per quanto riguarda Postgres, non abbiamo nemmeno guardato. Certo, sappiamo dell'esistenza di varie opzioni, ma di fatto abbiamo standalone.<\/p>\n

Database per test in Kubernetes<\/h2>\n

\nNS<\/b>: Passiamo al tema del testing. Come distribuire le modifiche nel database \u2014 dal punto di vista della prospettiva DevOps. Ci sono microservizi, molti database, c'\u00e8 sempre qualcosa che cambia. Come garantire un buon CI\/CD affinch\u00e9 dal punto di vista del DBMS sia tutto a posto? Qual \u00e8 il tuo approccio?<\/i><\/p>\n

DS<\/b>: Non pu\u00f2 esserci una risposta unica. Ci sono diversi parametri. Il primo \u00e8 la dimensione del database che vogliamo distribuire. Hai accennato al fatto che nelle aziende si hanno approcci diversi riguardo al fatto che la copia del database di produzione sia presente su dev e stage.<\/p>\n

NS<\/b>: E in contesti di GDPR, penso che siano sempre pi\u00f9 cauti\u2026 Posso dire che in Europa hanno gi\u00e0 iniziato a multare.<\/i><\/p>\n

DS<\/b>: Ma spesso \u00e8 possibile scrivere un software che effettua un dump dal production e lo offusca. Si ottengono dati di produzione (snapshot, dump, copia binaria\u2026), ma sono anonimizzati. In alternativa, possono esserci script di generazione: possono essere fixture o semplicemente uno script che genera un ampio database. Qual \u00e8 il problema: quanto tempo occorre per creare l'immagine di base? E quanto tempo ci vuole per distribuirla nell'ambiente richiesto?<\/p>\n

Siamo arrivati a uno schema: se il cliente ha un insieme di dati fixture (versione minima del database), allora di default utilizziamo quelli. Se si tratta di ambienti di review, quando abbiamo creato un branch, si \u00e8 avviato un'istanza dell'applicazione \u2014 l\u00ec distribuiamo un piccolo database. Ma \u00e8 andata bene anche. una versione<\/a><\/noindex>, quando dal production, una volta al giorno (di notte), facciamo un dump e realizziamo un contenitore Docker con PostgreSQL e MySQL con questi dati caricati. Se da quest'immagine bisogna distribuire il database 50 volte, si fa abbastanza facilmente e velocemente.<\/p>\n

NS<\/b>: Con una semplice copia?<\/i><\/p>\n

DS<\/b>: I dati sono memorizzati direttamente nell'immagine Docker. Cio\u00e8, abbiamo un'immagine pronta, magari di 100 GB. Grazie ai layer in Docker possiamo distribuire rapidamente questa immagine il numero necessario di volte. \u00c8 un metodo semplice, ma funziona piuttosto bene.<\/p>\n

NS<\/b>: Inoltre, quando testate, cambia direttamente all'interno di Docker, giusto? Copy-on-write all'interno di Docker \u2014 scartiamo e ricominciamo, tutto ok. Fantastico! E lo state gi\u00e0 utilizzando ampiamente?<\/i><\/p>\n

DS<\/b>: Da un po'.<\/p>\n

NS<\/b>: Noi ci occupiamo di cose molto simili. Solo che non utilizziamo il copy-on-write di Docker, ma qualche altro.<\/i><\/p>\n

DS<\/b>: Non \u00e8 generico. Mentre quello di Docker funziona ovunque.<\/p>\n

NS<\/b>: In teoria, s\u00ec. Ma anche noi abbiamo dei moduli, possiamo fare vari moduli e lavorare con diversi filesystem. Qui c'\u00e8 un aspetto. Noi guardiamo tutto questo da una prospettiva di Postgres. Ora ho guardato dalla prospettiva di Docker e ho visto che tutto funziona. Ma se il database \u00e8 enorme, ad esempio, 1 TB, allora tutto \u00e8 gi\u00e0 lungo: sia le operazioni notturne, sia metterlo tutto in Docker\u2026 E se devo mettere 5 TB in Docker\u2026 O va tutto bene?<\/i><\/p>\n

DS<\/b>: Che differenza fa: sono solo blob, semplicemente bit e byte.<\/p>\n

NS<\/b>: La differenza \u00e8: lo fate tramite dump e restore?<\/i><\/p>\n

DS<\/b>: Assolutamente no. I metodi di generazione di questa immagine possono essere diversi.<\/p>\n

NS<\/b>: Per alcuni clienti, abbiamo fatto in modo che invece di generare regolarmente un'immagine di base, la manteniamo costantemente aggiornata. Essa \u00e8 fondamentalmente una replica, ma i dati non vengono ricevuti direttamente dal master, bens\u00ec tramite un archivio. Un archivio binario, dove i WAL vengono applicati ogni giorno, e qui vengono effettuati anche i backup... Questi WAL poi arrivano \u2014 con un leggero ritardo (letteralmente 1-2 secondi) \u2014 all'immagine di base. Da l\u00ec possiamo clonare in qualsiasi modo \u2014 attualmente usiamo di default ZFS.<\/i><\/p>\n

DS<\/b>: Ma con ZFS sei limitato a un singolo nodo.<\/p>\n

NS<\/b>: S\u00ec. Ma ZFS ha anche un magico send<\/a><\/noindex>: con cui puoi inviare uno snapshot e anche (questo non l'ho ancora testato molto, ma...) puoi inviare una delta tra due PGDATA<\/code>. In realt\u00e0, abbiamo anche un altro strumento che non abbiamo considerato molto per tali attivit\u00e0. In PostgreSQL c'\u00e8 pg_rewind<\/a><\/noindex>, che funge da \u00absmart\u00bb rsync, saltando gran parte di ci\u00f2 che non vale la pena vedere, perch\u00e9 non \u00e8 cambiato. Possiamo effettuare una rapida sincronizzazione tra due server e tornare indietro allo stesso modo.<\/i><\/p>\n

Quindi, stiamo cercando di creare uno strumento da questa prospettiva pi\u00f9 da DBA, che consenta di fare ci\u00f2 di cui parlavi: abbiamo un database, ma vogliamo testare qualcosa 50 volte, quasi contemporaneamente.<\/i><\/p>\n

DS<\/b>: 50 volte significa che devi richiedere 50 istanze Spot.<\/p>\n

NS<\/b>: No, facciamo tutto su un'unica macchina.<\/i><\/p>\n

DS<\/b>: Ma come puoi distribuire 50 volte, se questo unico database \u00e8, diciamo, di un terabyte? Probabilmente ha bisogno di circa 256 GB di RAM?<\/p>\n

NS<\/b>: S\u00ec, a volte occorre molta memoria \u2014 \u00e8 normale. Ma ecco un esempio dalla vita reale. Su una macchina di produzione ci sono 96 core e 600 GB. Di questi, 32 core vengono utilizzati per il DB (anche se a volte bastano 16 core) e la memoria \u00e8 di 100-120 GB.<\/i><\/p>\n

DS<\/b>: E ci stanno 50 copie?<\/p>\n

NS<\/b>: Quindi la copia \u00e8 una, ma poi funziona il copy-on-write (ZFS)... Ti spiegher\u00f2 meglio.<\/i><\/p>\n

Abbiamo, ad esempio, un database di 10 TB. Abbiamo creato un disco per esso e ZFS ha gi\u00e0 ridotto le dimensioni del 30-40%. Poich\u00e9 non facciamo test di carico, il tempo di risposta esatto non \u00e8 importante: pu\u00f2 essere fino a 2 volte pi\u00f9 lento \u2014 va bene.<\/i><\/p>\n

Diamo la possibilit\u00e0 a programmatori, QA, DBA, ecc. di eseguire test in 1-2 flussi. Ad esempio, possono avviare una migrazione. Non richiede immediatamente 10 core \u2014 le serve 1 backend di Postgres, 1 core. La migrazione si avvier\u00e0 \u2014 pu\u00f2 darsi che autovacuum<\/a><\/noindex> pu\u00f2 anche avviarsi di nuovo, a quel punto sar\u00e0 attivato il secondo core. Abbiamo dedicato 16-32 core, cos\u00ec 10 persone possono lavorare contemporaneamente, senza problemi.<\/i><\/p>\n

Poich\u00e9 fisicamente PGDATA<\/code> sia uguale, si arriva a imbrogliare Postgres in realt\u00e0. Il trucco \u00e8: ad esempio, vengono avviati 10 Postgres contemporaneamente. Qual \u00e8 di solito il problema? Si impostano shared_buffers<\/a><\/noindex>, diciamo, al 25%. Di conseguenza, si tratta di 200 GB. Non puoi avviare pi\u00f9 di tre di questi, perch\u00e9 la memoria finisce.<\/i><\/p>\n

Ma a un certo punto abbiamo capito che non era necessario: impostiamo shared_buffers a 2 GB. PostgreSQL ha effective_cache_size<\/a><\/noindex>, e in realt\u00e0 \u00e8 solo lui a influenzare i piani<\/a><\/noindex>. Lo impostiamo a 0,5 TB. E non importa nemmeno che in realt\u00e0 non ci siano: costruisce piani come se ci fossero.<\/i><\/p>\n

Di conseguenza, quando testiamo una migrazione, possiamo raccogliere tutti i piani \u2014 vedremo come si svolger\u00e0 in produzione. I secondi saranno diversi (pi\u00f9 lent), ma i dati che leggiamo effettivamente, e i piani stessi (quali JOIN ci sono, ecc.) risultano esattamente gli stessi di quelli in produzione. E parallelamente \u00e8 possibile avviare un gran numero di tali controlli su una macchina.<\/i><\/p>\n

DS<\/b>: Non pensi che ci siano alcuni problemi? Il primo \u00e8 che questa soluzione funziona solo con PostgreSQL. Questo approccio \u00e8 molto specifico e non generico. Il secondo \u00e8 che Kubernetes (e tutto ci\u00f2 su cui si basano ora le tecnologie cloud) prevede numerosi nodi, e questi nodi sono effimeri. Nel tuo caso, invece, si tratta di un nodo stateful e persistente. Questi aspetti suscitano delle contraddizioni in me.<\/p>\n

NS<\/b>: Primo \u2014 concordo, \u00e8 una storia puramente Postgres. Penso che, se abbiamo qualche direct IO e un buffer pool praticamente su tutta la memoria, questo approccio non funzioner\u00e0 \u2014 i piani saranno diversi. Ma per ora lavoriamo solo con Postgres e non pensiamo ad altri.<\/i><\/p>\n

Riguardo a Kubernetes. Dici sempre che il nostro database \u00e8 persistente. Se un'istanza si guasta, l'importante \u00e8 salvare il disco. Anche la nostra piattaforma \u00e8 in Kubernetes, con il componente PostgreSQL separato (anche se un giorno sar\u00e0 integrato). Pertanto, \u00e8 cos\u00ec: l'istanza \u00e8 caduta, ma abbiamo salvato il suo PV e semplicemente lo abbiamo collegato a un'altra (nuova) istanza, come se non fosse successo nulla.<\/i><\/p>\n

DS<\/b>: Dal mio punto di vista, stiamo creando pod in Kubernetes. K8s \u00e8 elastico: i nodi vengono ordinati automaticamente secondo necessit\u00e0. Il compito \u00e8 semplicemente creare un pod e dire che ha bisogno di X risorse, e poi K8s si occupa del resto. Ma il supporto per lo storage in Kubernetes \u00e8 ancora instabile: in 1.16<\/a><\/noindex>, in 1.17<\/a><\/noindex> (questa versione \u00e8 stata rilasciata settimane<\/i> fa) queste funzionalit\u00e0 diventano solo una beta.<\/p>\n

Dopo sei mesi o un anno, diventer\u00e0 pi\u00f9 o meno stabile, o almeno sar\u00e0 dichiarato tale. A quel punto, la possibilit\u00e0 di snapshot e resizing risolver\u00e0 completamente la tua esigenza. Perch\u00e9 hai una base. S\u00ec, potrebbe non essere molto veloce, ma la velocit\u00e0 dipende da cosa c'\u00e8 \"sotto il cofano\", perch\u00e9 alcune implementazioni sono capaci di copia e copy-on-write a livello del sottosistema di archiviazione.<\/p>\n

NS<\/b>: Qui ci vuole anche che tutti i motori (Amazon, Google...) inizino a supportare questa versione \u2014 anche questo richiede tempo.<\/i><\/p>\n

DS<\/b>: Al momento non li usiamo. Usiamo il nostro.<\/p>\n

Sviluppo locale su Kubernetes<\/h2>\n

\nNS<\/b>: Ti \u00e8 mai capitato di avere questa necessit\u00e0 di avviare tutti i pod su una sola macchina e fare un piccolo test? Per ottenere rapidamente una prova di concetto, vedere se l'applicazione funziona in Kubernetes, senza dover allocare un sacco di macchine. Esiste Minikube, giusto?<\/i><\/p>\n

DS<\/b>: Mi sembra che questo caso \u2014 l'esecuzione su un nodo \u2014 riguardi esclusivamente lo sviluppo locale. O qualche manifestazione di un tale schema. C'\u00e8 Minikube<\/a><\/noindex>, c'\u00e8 k3s<\/a><\/noindex>, (Kubernetes IN Docker) e<\/a><\/noindex>. Stiamo andando verso l'utilizzo di Kubernetes IN Docker. Abbiamo appena iniziato a lavorare su di esso per i test.<\/p>\n

NS<\/b>: Pensavo fosse un tentativo di racchiudere tutti i pod in un'unica immagine Docker. Ma si \u00e8 rivelato essere qualcosa di completamente diverso. Ci sono comunque contenitori separati, pod separati \u2014 semplicemente in Docker.<\/i><\/p>\n

DS<\/b>: S\u00ec. E l\u00ec \u00e8 stata realizzata un'imitazione piuttosto divertente, ma il senso \u00e8 questo... Abbiamo uno strumento per il deployment \u2014 werf<\/a><\/noindex>. Vogliamo fare una modalit\u00e0 in essa \u2014 diciamo werf up<\/code>: \u00abAlzami un Kubernetes locale\u00bb. E poi avviare l\u00ec un werf follow<\/code>. Allora lo sviluppatore potr\u00e0 modificare nell'IDE, mentre nel sistema \u00e8 in esecuzione un processo che rileva le modifiche e ricompila le immagini, ridistribuendole nel K8s locale. In questo modo vogliamo cercare di risolvere il problema dello sviluppo locale.<\/p>\n

Snapshot e clonazione del DB nella realt\u00e0 K8s<\/h2>\n

\nNS<\/b>: Tornando al copy-on-write. Ho notato che anche i servizi cloud hanno snapshot. Funzionano in modo diverso. Ad esempio, in GCP: hai un'istanza di diversi terabyte sulla costa est degli Stati Uniti. Fai snapshot periodici. Sollevi una copia del disco dallo snapshot sulla costa ovest \u2014 dopo qualche minuto \u00e8 gi\u00e0 tutto pronto, funziona molto velocemente, bisogna solo riempire la cache in memoria. Ma questi cloni (snapshot) servono per \"provisionare\" un nuovo volume. \u00c8 fantastico quando hai bisogno di creare molte istanze.<\/i><\/p>\n

Per quanto riguarda i test, i snapshot di cui parli in Docker o di cui parlo io in ZFS, btrfs e persino LVM... \u2014 permettono, a mio avviso, di non generare realmente nuovi dati su una sola macchina. Nel cloud, pagherai per loro ogni volta e dovrai aspettare non secondi, ma minuti (e nel caso del lazy loading<\/a><\/noindex>, forse, anche ore).<\/i><\/p>\n

Invece, puoi ottenere questi dati in un secondo o due, eseguire il test e scartare. Questi snapshot risolvono diverse esigenze. Nel primo caso \u2014 per scalare e ottenere nuove repliche, mentre nel secondo \u2014 per i test.<\/i><\/p>\n

DS<\/b>: Non sono d'accordo. Eseguire un clone corretto dei volumi \u00e8 compito del cloud. Non ho visto la loro implementazione, ma so come lo facciamo noi sull'hardware. Abbiamo Ceph, in cui si pu\u00f2 dire a qualsiasi volume fisico (RBD<\/a><\/noindex>) clone<\/i> e ottenere, in pochi millisecondi, un secondo volume con le stesse caratteristiche, IOPS<\/a><\/noindex>e cos\u00ec via. Bisogna comprendere che all'interno c'\u00e8 un astuto copy-on-write. Perch\u00e9 il cloud non dovrebbe fare lo stesso? Sono certo che in un modo o nell'altro stiano cercando di farlo.<\/p>\n

NS<\/b>: Ma avranno comunque bisogno di secondi, decine di secondi, per avviare l'istanza, portare l\u00ec Docker, ecc.<\/i><\/p>\n

DS<\/b>: Perch\u00e9 \u00e8 necessario avviare un'intera istanza? Abbiamo gi\u00e0 un'istanza con 32 core, 16... e in essa entra un certo numero di volumi - ad esempio, quattro. Quando richiediamo il quinto, si avvia un'istanza, che poi verr\u00e0 eliminata.<\/p>\n

NS<\/b>: Gi\u00e0, interessante, in Kubernetes si ha una storia diversa. La nostra Borsa dati non \u00e8 in K8s, e c'\u00e8 un'unica istanza. Tuttavia, ci vogliono non pi\u00f9 di due secondi per clonare un database di diversi terabyte.<\/i><\/p>\n

DS<\/b>: \u00c8 fantastico. Ma la mia idea originaria \u00e8 che questa non \u00e8 una soluzione generica. S\u00ec, \u00e8 fantastica, ma \u00e8 adatta solo per Postgres e solo su un nodo.<\/p>\n

NS<\/b>: Non \u00e8 adatta solo per Postgres: questi piani, come ho descritto, funzioneranno solo in esso. Ma se non ci si preoccupa dei piani e abbiamo solo bisogno di tutti i dati per test funzionali, allora andr\u00e0 bene per qualsiasi DBMS.<\/i><\/p>\n

DS<\/b>: Molti anni fa abbiamo realizzato qualcosa di simile con gli snapshot LVM. \u00c8 un classico. Questo approccio \u00e8 stato utilizzato molto attivamente. Solo che i nodi stateful sono un dolore. Perch\u00e9 non si possono far cadere, bisogna sempre tenerli a mente...<\/p>\n

NS<\/b>: Non vedi qui una certa possibilit\u00e0 di un ibrido? Supponiamo che lo stateful sia un pod, e opera con pi\u00f9 persone (molti tester). Abbiamo un solo volume, ma grazie al file system i cloni sono locali. Se il pod cade, il disco rimane - il pod si riavvier\u00e0, recuperer\u00e0 informazioni su tutti i cloni, riavvier\u00e0 tutto e dir\u00e0: \u00abEcco i vostri cloni su queste porte, continuate a lavorare con loro\u00bb.<\/i><\/p>\n

DS<\/b>: Tecnicamente significa che all'interno di Kubernetes si tratta di un pod, all'interno del quale eseguiamo molti Postgres.<\/p>\n

NS<\/b>: Gi\u00e0. Ha un limite: supponiamo che simultaneamente non ci lavorino pi\u00f9 di 10 persone. Se ne servono 20, avviamo un secondo pod di questo tipo. Possiamo clonarlo completamente, ottenendo un secondo volume completo, e avr\u00e0 altre 10 \u00abclone snelli\u00bb. Non vedi questa possibilit\u00e0?<\/i><\/p>\n

DS<\/b>: \u00c8 necessario aggiungere qui domande sulla sicurezza. Questa organizzazione implica che questo pod abbia privilegi elevati (capabilities), poich\u00e9 pu\u00f2 eseguire operazioni non standard sul filesystem... Ma ripeto: credo che nel medio termine Kubernetes risolver\u00e0 il problema dello storage e nei cloud sistemeranno tutta la storia dei volumi \u2014 tutto funzioner\u00e0 'soltanto'. Ci sar\u00e0 il resize, la clonazione... Esiste un volume \u2014 diciamo: 'Crea un nuovo volume basato su questo', \u2014 e dopo un secondo e mezzo otteniamo ci\u00f2 di cui abbiamo bisogno.<\/p>\n

NS<\/b>: Non credo che ci vogliano un secondo e mezzo per molti terabyte. Su Ceph lo fai tu, ma parli dei cloud. Vai sul cloud, su EC2 clona un volume EBS di diversi terabyte e guarda quale sar\u00e0 la performance. Non ci vorranno pochi secondi. Sono molto curioso di sapere quando arriveranno a tale valore. Capisco di cosa stai parlando, ma mi permetto di dissentire.<\/i><\/p>\n

DS<\/b>: Va bene, ma ho detto che a medio termine, non a breve termine. Nel giro di alcuni anni.<\/p>\n

Riguardo all'operatore per PostgreSQL di Zalando<\/h2>\n

\nA met\u00e0 di questo incontro si \u00e8 unito anche Alexey Klyukin, ex sviluppatore di Zalando, che ha raccontato la storia dell'operatore PostgreSQL:<\/p>\n

\u00c8 fantastico che si parli di questo argomento: sia Postgres che Kubernetes. Quando abbiamo iniziato a lavorare su di esso in Zalando nel 2017, era un argomento che tutti volevano trattare, ma nessuno lo faceva. Tutti avevano gi\u00e0 Kubernetes, ma quando si chiedeva come gestire i database, anche persone come Kelsey Hightower<\/a><\/noindex>, che predicavano K8s, dicevano pi\u00f9 o meno quanto segue:<\/p>\n

\u00abAndate verso i servizi gestiti e utilizzateli, non avviate database in Kubernetes. Altrimenti, il vostro K8s decider\u00e0, per esempio, di fare un aggiornamento, spegner\u00e0 tutti i nodi e i vostri dati voleranno lontano lontano\u00bb.<\/i><\/p>\n

Abbiamo deciso di creare un operatore che, contrario a questo consiglio, avviasse il database Postgres in Kubernetes. E avevamo una buona base - Patroni<\/a><\/noindex>. Questo \u00e8 un failover automatico per PostgreSQL, fatto correttamente, cio\u00e8 utilizzando etcd, consul o ZooKeeper come archivio di informazioni sul cluster. Un archivio che fornisce a tutti quelli che chiedono, ad esempio, chi \u00e8 l'attuale leader, la stessa informazione \u2014 nonostante il nostro sistema distribuito, \u2014 per evitare situazioni di split brain. Inoltre, avevamo Docker image<\/a><\/noindex> per esso.<\/p>\n

In effetti, la necessit\u00e0 di un auto failover per l'azienda \u00e8 emersa dopo la migrazione da un data center interno a un cloud. Il cloud era basato su una soluzione PaaS (Platform-as-a-Service) proprietaria. Era open source, ma per implementarlo era necessario lavorare sodo. Si chiamava STUPS<\/a><\/noindex>.<\/p>\n

Inizialmente non c'era alcun Kubernetes. O meglio, quando \u00e8 stata implementata la soluzione proprietaria, K8s era gi\u00e0 presente, ma cos\u00ec acerbo che non era adatto per la produzione. Era, secondo me, il 2015 o il 2016. Entro il 2017 Kubernetes era diventato pi\u00f9 o meno maturo \u2014 c'era bisogno di una migrazione l\u00ec.<\/p>\n

E avevamo gi\u00e0 un container Docker. C'era PaaS che utilizzava Docker. Perch\u00e9 non provare K8s? Perch\u00e9 non scrivere il proprio operatore? Murat Kabilov, che \u00e8 arrivato da noi da Avito, ha iniziato questo come progetto di iniziativa personale - \u201cgiocare\u201d, - e il progetto ha \u201cdecollato\u201d.<\/p>\n

Ma in realt\u00e0 volevo parlare di AWS. Perch\u00e9 storicamente c'era codice legato ad AWS...<\/p>\n

Quando si avvia qualcosa in Kubernetes, bisogna capire che K8s \u00e8 un work in progress. Si evolve continuamente, si migliora e a volte si rompe. \u00c8 necessario prestare attenzione a tutte le modifiche in Kubernetes e essere pronti, se necessario, a immergersi in esso e capire come funziona nei dettagli - probabilmente pi\u00f9 di quanto si vorrebbe. Questo \u00e8 un aspetto comune a qualsiasi piattaforma su cui si eseguono i propri database...<\/p>\n

Quindi, quando abbiamo creato l'operatore, avevamo Postgres che lavorava con un volume esterno (in questo caso - EBS, poich\u00e9 lavoravamo in AWS). Il database cresceva e, a un certo punto, si \u00e8 reso necessario un resize: ad esempio, la dimensione iniziale di EBS era di 100 TB, il database ha raggiunto quella dimensione, ora vogliamo aumentare EBS a 200 TB. Come? Supponiamo di poter fare un dump\/restore su una nuova istanza, ma \u00e8 lungo e comporta un downtime.<\/p>\n

Pertanto, desideravamo un resize che aumentasse la partizione EBS e poi dicesse al filesystem di utilizzare il nuovo spazio. E lo abbiamo fatto, ma in quel periodo Kubernetes non aveva alcuna API per l'operazione di resize. Poich\u00e9 stavamo lavorando su AWS, abbiamo scritto il codice per la sua API.<\/p>\n

Nessuno impedisce di fare lo stesso per altre piattaforme. Nell'operatore non c'\u00e8 alcun vincolo che possa essere eseguito solo su AWS; funzioner\u00e0 anche su altre piattaforme. In fin dei conti, questo \u00e8 un progetto Open Source: se qualcuno desidera accelerare l'uso di una nuova API - \u00e8 il benvenuto. C'\u00e8 GitHub<\/a><\/noindex>, pull-request \u2014 il team di Zalando cerca di rispondere abbastanza rapidamente e supportare l'operatore. Per quanto ne so, il progetto ha partecipato<\/a><\/noindex> a Google Summer of Code e ad altre iniziative simili. Zalando sta lavorando attivamente su di esso.\n<\/p><\/blockquote>\n

<\/p>\n

P.S. Bonus!<\/h2>\n

\nSe siete interessati all'argomento PostgreSQL e Kubernetes, vi informiamo anche che la settimana scorsa si \u00e8 svolto il seguente Postgres-Marted\u00ec, durante il quale Nicola ha parlato con Alexander Kukushkin di Zalando<\/b>. Il video \u00e8 disponibile qui<\/a><\/noindex>.<\/p>\n

P.P.S.<\/h2>\n

\nLeggi anche nel nostro blog:<\/p>\n