Alla fine dello scorso anno ha avuto luogo un'altra trasmissione in diretta della comunità russa PostgreSQL , durante il quale il suo cofondatore Nikolai Samokhvalov ha parlato con il direttore tecnico di Flant Dmitry Stolyarov di questo DBMS nel contesto di Kubernetes.
Stiamo pubblicando una trascrizione della parte principale di questa discussione, e in Video completo pubblicato:
Database e Kubernetes
NA: Oggi non parleremo di VACUUM e CHECKPOINT. Vogliamo parlare di Kubernetes. So che hai molti anni di esperienza. Ho guardato i tuoi video e ne ho anche rivisto alcuni... Andiamo dritti al punto: perché Postgres o MySQL in K8s?
DS: Non c'è e non può esserci una risposta definitiva a questa domanda. Ma in generale, questa è semplicità e comodità... potenziale. Tutti vogliono servizi gestiti.
NA: A come , solo a casa?
DS: Sì: come RDS, ovunque.
NA: “Ovunque” è un buon punto. Nelle grandi aziende tutto si trova in posti diversi. Perché allora, se si tratta di una grande azienda, non adottare una soluzione già pronta? Nutanix, ad esempio, ha i propri sviluppi, altre aziende (VMware...) hanno lo stesso “RDS, solo in casa”.
DS: Ma stiamo parlando di un'implementazione separata che funzionerà solo a determinate condizioni. E se parliamo di Kubernetes, allora esiste un'enorme varietà di infrastrutture (che possono trovarsi in K8). Essenzialmente questo è uno standard per le API nel cloud...
NA: È anche gratis!
DS: Non è così importante. La libertà è importante per un segmento non molto ampio del mercato. Qualcos'altro è importante... Probabilmente ricorderete il rapporto “"?
NASì
DS: Mi sono reso conto che è stato ricevuto in modo molto ambiguo. Alcuni pensavano che stessi dicendo: “Ragazzi, mettiamo tutti i database in Kubernetes!”, mentre altri pensavano che fossero tutte biciclette terribili. Ma volevo dire qualcosa di completamente diverso: “Guarda cosa sta succedendo, quali problemi ci sono e come possono essere risolti. Dovremmo usare i database Kubernetes adesso? Produzione? Beh, solo se ti piace... fare certe cose. Ma per uno sviluppatore, posso dire che lo consiglio. Per uno sviluppatore, il dinamismo della creazione/eliminazione degli ambienti è molto importante."
NS: Per dev intendi tutti gli ambienti che non sono prod? Messa in scena, QA...
DS: Se parliamo di supporti perfetti, probabilmente no, perché i requisiti sono specifici. Se parliamo di casi speciali in cui è necessario un database molto grande per lo staging, probabilmente no... Se si tratta di un ambiente statico e di lunga durata, qual è il vantaggio di avere il database posizionato in K8?
NA: Nessuno. Ma dove vediamo gli ambienti statici? Un ambiente statico diventerà obsoleto domani.
DS: La messa in scena può essere statica. Abbiamo clienti...
NA: Sì, ne ho uno anch'io. È un grosso problema se hai un database da 10 TB e uno staging da 200 GB...
DS: Ho un caso davvero interessante! Nello staging è presente un database dei prodotti al quale vengono apportate le modifiche. E c'è un pulsante: "implementazione in produzione". Queste modifiche - delta - vengono aggiunte (sembra che siano semplicemente sincronizzate tramite l'API) in produzione. Questa è un'opzione molto esotica.
NA: Ho visto startup nella Valley che si trovano in RDS o anche in Heroku - queste sono storie di 2-3 anni fa - e scaricano il dump sul loro laptop. Perché il database è ancora di soli 80 GB e c'è spazio sul laptop. Quindi acquistano dischi aggiuntivi per tutti in modo da avere 3 database per eseguire sviluppi diversi. Succede anche così. Ho anche visto che non hanno paura di copiare la produzione nello stage: dipende molto dalla compagnia. Ma ho visto anche che hanno molta paura, e che spesso non hanno abbastanza tempo e mani. Ma prima di passare a questo argomento, voglio sentire parlare di Kubernetes. Ho capito bene che nessuno è ancora in produzione?
DS: Abbiamo piccoli database in prod. Stiamo parlando di volumi di decine di gigabyte e di servizi non critici per i quali eravamo troppo pigri per realizzare repliche (e non ce n'è bisogno). E a condizione che sia disponibile spazio di archiviazione normale in Kubernetes. Questo database funzionava in una macchina virtuale, condizionatamente in VMware, sopra il sistema di archiviazione. L'abbiamo inserito e ora possiamo trasferirlo da una macchina all'altra.
NA: Database di queste dimensioni, fino a 100 GB, possono essere implementati in pochi minuti su buoni dischi e una buona rete, giusto? Una velocità di 1 GB al secondo non è più esotica.
DS: Sì, per il funzionamento lineare questo non è un problema.
NA: Ok, dobbiamo solo pensare alla produzione. E se stiamo considerando Kubernetes per ambienti non produttivi, cosa dovremmo fare? Lo vedo su Zalando , in Croccante , ci sono alcune altre opzioni. E c'è - questo è il nostro buon amico Alvaro dalla Spagna: quello che fanno essenzialmente non è giusto , e l'intera distribuzione (), nel quale, oltre a Postgres stesso, hanno deciso di inserire anche un backup, il proxy Envoy...
DS: Inviato per cosa? Bilanciare il traffico Postgres in modo specifico?
NA: SÌ. Cioè, lo vedono come: se prendi una distribuzione Linux e un kernel, allora PostgreSQL normale è il kernel e vogliono creare una distribuzione che sia compatibile con il cloud e funzioni su Kubernetes. Mettono insieme i componenti (backup, ecc.) e ne eseguono il debug in modo che funzionino bene.
DS: Molto bello! Essenzialmente si tratta di un software per creare il tuo Postgres gestito.
NA: Le distribuzioni Linux hanno problemi eterni: come creare driver in modo che tutto l'hardware sia supportato. E hanno l'idea che lavoreranno in Kubernetes. So che nell'operatore Zalando abbiamo recentemente visto una connessione ad AWS e questo non è più molto buono. Non dovrebbe esserci un legame con un’infrastruttura specifica: qual è il punto allora?
DS: Non so esattamente in quale situazione si sia trovato Zalando, ma in Kubernetes lo storage è ormai fatto in modo tale che è impossibile eseguire un backup del disco utilizzando un metodo generico. Recentemente in standard - nell'ultima versione - abbiamo reso possibili le istantanee, ma dove vengono implementate? Onestamente, è ancora tutto così grezzo... Stiamo provando CSI su AWS, GCE, Azure, vSphere, ma non appena inizi a usarlo, puoi vedere che non è ancora pronto.
NA: Ecco perché a volte dobbiamo fare affidamento sulle infrastrutture. Penso che questa sia ancora una fase iniziale: dolori della crescita. Domanda: che consiglio daresti ai neofiti che vogliono provare PgSQL in K8? Che operatore magari?
DS: Il problema è che Postgres per noi vale il 3%. Abbiamo anche un elenco molto ampio di diversi software in Kubernetes, non elencherò nemmeno tutto. Ad esempio, Elasticsearch. Ci sono molti operatori: alcuni si stanno sviluppando attivamente, altri no. Abbiamo elaborato per noi stessi i requisiti su cosa dovrebbe essere presente nell'operatore in modo da prenderlo sul serio. In un operatore specifico per Kubernetes - non in un "operatore che fa qualcosa alle condizioni di Amazon"... In effetti, utilizziamo abbastanza ampiamente (= quasi tutti i clienti) un singolo operatore - (a breve pubblicheremo un articolo su di lui).
NA: E nemmeno per MySQL? So che Percona... dato che ora stanno lavorando su MySQL, MongoDB e Postgres, dovranno creare una sorta di soluzione universale: per tutti i database, per tutti i fornitori di servizi cloud.
DS: Non abbiamo avuto il tempo di esaminare gli operatori per MySQL. Questo non è il nostro obiettivo principale in questo momento. MySQL funziona bene in modalità standalone. Perché usare un operatore se puoi semplicemente avviare un database... Puoi avviare un contenitore Docker con Postrges oppure puoi avviarlo in modo semplice.
NA: C'era una domanda anche su questo. Nessun operatore?
DS: Sì, il 100% di noi ha PostgreSQL in esecuzione senza operatore. Finora tutto. Utilizziamo attivamente l'operatore per Prometheus e Redis. Abbiamo in programma di trovare un operatore per Elasticsearch: è quello più “in fiamme”, perché vogliamo installarlo in Kubernetes nel 100% dei casi. Così come vogliamo garantire che MongoDB sia sempre installato anche in Kubernetes. Qui compaiono alcuni desideri: si ha la sensazione che in questi casi si possa fare qualcosa. E non abbiamo nemmeno guardato Postgres. Naturalmente sappiamo che ci sono diverse opzioni, ma in realtà ne abbiamo una standalone.
DB per i test in Kubernetes
NA: Passiamo al tema dei test. Come implementare le modifiche al database, dal punto di vista DevOps. Esistono microservizi, molti database, qualcosa cambia continuamente da qualche parte. Come garantire CI/CD normale in modo che tutto sia in ordine dal punto di vista del DBMS. Qual è il tuo approccio?
DS: Non può esserci una risposta. Ci sono diverse opzioni. Il primo è la dimensione della base che vogliamo stendere. Tu stesso hai affermato che le aziende hanno atteggiamenti diversi nei confronti dell'avere una copia del database dei prodotti in fase di sviluppo e in scena.
NA: E alle condizioni del GDPR, penso che siano sempre più attenti... posso dire che in Europa hanno già cominciato a imporre multe.
DS: Ma spesso puoi scrivere software che prende un dump dalla produzione e lo offusca. Vengono ottenuti i dati di produzione (istantanea, dump, copia binaria...), ma sono resi anonimi. Possono invece esserci script di generazione: questi possono essere dispositivi o semplicemente uno script che genera un database di grandi dimensioni. Il problema è: quanto tempo ci vuole per creare un'immagine di base? E quanto tempo ci vuole per distribuirlo nell'ambiente desiderato?
Siamo arrivati a uno schema: se il cliente ha un set di dati fisso (versione minima del database), li utilizziamo per impostazione predefinita. Se parliamo di ambienti di revisione, quando abbiamo creato un ramo, abbiamo distribuito un'istanza dell'applicazione: lì implementiamo un piccolo database. Ma è andata bene , quando eseguiamo un dump dalla produzione una volta al giorno (di notte) e creiamo un contenitore Docker con PostgreSQL e MySQL con questi dati caricati in base ad esso. Se è necessario espandere il database 50 volte da questa immagine, ciò viene fatto in modo abbastanza semplice e rapido.
NA: Con la semplice copia?
DS: i dati vengono archiviati direttamente nell'immagine Docker. Quelli. Abbiamo un'immagine già pronta, anche se 100 GB. Grazie ai livelli in Docker, possiamo distribuire rapidamente questa immagine tutte le volte che ne abbiamo bisogno. Il metodo è stupido, ma funziona bene.
NA: Quindi, quando esegui il test, cambia direttamente all'interno di Docker, giusto? Copia su scrittura all'interno di Docker: buttalo via e riprova, va tutto bene. Classe! E tu lo stai già utilizzando al meglio?
DS: Per molto tempo.
NA: Facciamo cose molto simili. Solo che non utilizziamo il copy-on-write di Docker, ma qualche altro.
DS: Non è generico. E Docker funziona ovunque.
NA: In teoria sì. Ma abbiamo anche dei moduli lì, puoi creare moduli diversi e lavorare con file system diversi. Che momento qui. Dal lato di Postgres, guardiamo tutto questo in modo diverso. Ora ho guardato dal lato Docker e ho visto che tutto funziona per te. Ma se il database è enorme, ad esempio 1 TB, allora tutto ciò richiede molto tempo: operazioni notturne e inserimento di tutto in Docker... E se 5 TB vengono inseriti in Docker... O va tutto bene?
DS: Qual è la differenza: questi sono blob, solo bit e byte.
NA: La differenza è questa: lo fai tramite dump e ripristino?
DS: Per niente necessario. I metodi per generare questa immagine possono essere diversi.
NA: Per alcuni clienti abbiamo fatto in modo che invece di generare regolarmente un'immagine di base, la manteniamo costantemente aggiornata. È essenzialmente una replica, ma riceve i dati non direttamente dal master, ma attraverso un archivio. Un archivio binario dove ogni giorno vengono scaricati i WAL, dove vengono fatti i backup... Questi WAL raggiungono poi l'immagine di base con un leggero ritardo (letteralmente 1-2 secondi). Lo cloniamo in qualsiasi modo: ora abbiamo ZFS per impostazione predefinita.
DS: Ma con ZFS sei limitato a un nodo.
NA: SÌ. Ma ZFS ha anche una magia : con esso puoi inviare uno snapshot e anche (non l'ho ancora testato, ma...) puoi inviare un delta tra due PGDATA. In effetti, abbiamo un altro strumento che non abbiamo realmente considerato per tali compiti. PostgreSQL ha , che funziona come un rsync "intelligente", saltando gran parte di ciò che non devi guardare, perché lì non è cambiato nulla. Possiamo eseguire una rapida sincronizzazione tra i due server e riavvolgere allo stesso modo.
Quindi, da questo lato più DBA, stiamo cercando di creare uno strumento che ci permetta di fare la stessa cosa che hai detto: abbiamo un database, ma vogliamo testare qualcosa 50 volte, quasi contemporaneamente.
DS: 50 volte significa che devi ordinare 50 istanze Spot.
NA: No, facciamo tutto su una macchina.
DS: Ma come puoi espanderti 50 volte se questo database è, diciamo, terabyte. Molto probabilmente ha bisogno di 256 GB di RAM condizionali?
NA: Sì, a volte hai bisogno di molta memoria: è normale. Ma questo è un esempio dalla vita. La macchina di produzione ha 96 core e 600 GB. Allo stesso tempo, per il database vengono utilizzati 32 core (a volte anche 16 core) e 100-120 GB di memoria.
DS: E ci stanno 50 copie?
NA: Quindi c'è una sola copia, quindi funziona il copy-on-write (ZFS)... te lo dirò più in dettaglio.
Ad esempio, abbiamo un database da 10 TB. Hanno creato un disco per questo, ZFS ha anche compresso le sue dimensioni del 30-40%. Poiché non eseguiamo test di carico, il tempo di risposta esatto non è importante per noi: lascia che sia fino a 2 volte più lento, va bene.
Diamo l'opportunità a programmatori, QA, DBA, ecc. eseguire il test in 1-2 thread. Ad esempio, potrebbero eseguire una sorta di migrazione. Non richiede 10 core contemporaneamente: necessita di 1 backend Postgres, 1 core. La migrazione inizierà, forse verrà comunque avviato, verrà utilizzato il secondo core. Abbiamo 16-32 core allocati, quindi 10 persone possono lavorare contemporaneamente, senza problemi.
Perché fisicamente PGDATA lo stesso, si scopre che in realtà stiamo ingannando Postgres. Il trucco è questo: ad esempio, vengono lanciati 10 Postgre contemporaneamente. Qual è il problema di solito? Loro mettono , diciamo il 25%. Di conseguenza, si tratta di 200 GB. Non potrai avviarne più di tre, perché la memoria si esaurirà.
Ma ad un certo punto ci siamo resi conto che ciò non era necessario: abbiamo impostato shared_buffers su 2 GB. PostgreSQL ha , e in realtà è l'unico che influenza . Lo impostiamo su 0,5 TB. E non importa nemmeno che in realtà non esistano: fa progetti come se esistessero.
Di conseguenza, quando testiamo una sorta di migrazione, possiamo raccogliere tutti i piani: vedremo come avverrà in produzione. I secondi saranno diversi (più lenti), ma i dati che leggiamo effettivamente e i piani stessi (quali JOIN ci sono, ecc.) Risultano esattamente gli stessi della produzione. E puoi eseguire molti di questi controlli in parallelo su una macchina.
DS: Non pensi che ci siano qualche problema qui? La prima è una soluzione che funziona solo su PostgreSQL. Questo approccio è molto privato, non è generico. Il secondo è che Kubernetes (e tutto ciò che le tecnologie cloud faranno ora) coinvolge molti nodi e questi nodi sono effimeri. E nel tuo caso è un nodo con stato e persistente. Queste cose mi mettono in conflitto.
NA: Innanzitutto, sono d'accordo, questa è una storia puramente Postgres. Penso che se disponiamo di una sorta di I/O diretto e di un pool di buffer per quasi tutta la memoria, questo approccio non funzionerà: i piani saranno diversi. Ma per ora lavoriamo solo con Postgres, non pensiamo ad altri.
Informazioni su Kubernetes. Tu stesso ci dici ovunque che abbiamo un database persistente. Se l'istanza fallisce, l'importante è salvare il disco. Anche qui abbiamo l'intera piattaforma in Kubernetes, e la componente con Postgres è separata (anche se un giorno ci sarà). Pertanto, è tutto così: l'istanza è caduta, ma abbiamo salvato il suo PV e l'abbiamo semplicemente collegata a un'altra (nuova) istanza, come se nulla fosse successo.
DS: Dal mio punto di vista, creiamo pod in Kubernetes. K8s - elastico: i nodi vengono ordinati secondo necessità. Il compito è semplicemente creare un pod e dire che ha bisogno di una quantità X di risorse, quindi K8 lo capirà da solo. Ma il supporto dello storage in Kubernetes è ancora instabile: In (questa versione è stata rilasciata settimane fa) queste funzionalità diventano solo beta.
Passeranno da sei mesi a un anno: diventerà più o meno stabile, o almeno sarà dichiarato tale. Quindi la possibilità di istantanee e ridimensionamenti risolve completamente il tuo problema. Perché hai una base. Sì, potrebbe non essere molto veloce, ma la velocità dipende da cosa c'è "sotto il cofano", perché alcune implementazioni possono copiare e copiare su scrittura a livello del sottosistema del disco.
NA: È inoltre necessario che tutti i motori (Amazon, Google...) inizino a supportare questa versione - anche questo richiede del tempo.
DS: Non li usiamo ancora. Usiamo il nostro.
Sviluppo locale per Kubernetes
NA: Ti sei imbattuto in un simile desiderio quando hai bisogno di installare tutti i pod su una macchina ed eseguire un test così piccolo. Per ottenere rapidamente una prova di concetto, verifica che l'applicazione venga eseguita in Kubernetes, senza dedicarle un gruppo di macchine. C'è Minikube, vero?
DS: Mi sembra che questo caso - distribuito su un nodo - riguardi esclusivamente lo sviluppo locale. O alcune manifestazioni di un tale modello. Mangiare Ci , . Ci stiamo muovendo verso l'utilizzo di Kubernetes IN Docker. Ora abbiamo iniziato a lavorarci per i test.
NA: Pensavo che questo fosse un tentativo di racchiudere tutti i pod in un'unica immagine Docker. Ma si è scoperto che si tratta di qualcosa di completamente diverso. Ad ogni modo, ci sono contenitori separati, pod separati, solo in Docker.
DS: SÌ. Ed è stata fatta un'imitazione piuttosto divertente, ma il significato è questo... Abbiamo un'utilità per la distribuzione - . Vogliamo renderlo una modalità condizionale werf up: "Procurami Kubernetes locale." E poi usa il condizionale lì werf follow. Quindi lo sviluppatore sarà in grado di modificare l'IDE e nel sistema verrà avviato un processo che rileva le modifiche e ricostruisce le immagini, ridistribuendole sui K8 locali. Vogliamo provare a risolvere così il problema dello sviluppo locale.
Istantanee e clonazione di database nella realtà di K8
NA: Se torniamo al copy-on-write. Ho notato che anche le nuvole hanno delle istantanee. Funzionano diversamente. Ad esempio, in GCP: hai un'istanza di più terabyte sulla costa orientale degli Stati Uniti. Scatti periodicamente istantanee. Prendi una copia del disco sulla costa occidentale da un'istantanea: in pochi minuti tutto è pronto, funziona molto velocemente, devi solo riempire la cache in memoria. Ma questi cloni (istantanee) servono per "fornire" un nuovo volume. Questo è utile quando devi creare molte istanze.
Ma per i test, mi sembra che le istantanee, di cui parli in Docker o di cui parlo in ZFS, btrfs e persino LVM... - ti consentono di non creare dati veramente nuovi su una macchina. Nel cloud, li pagherai comunque ogni volta e aspetterai non secondi, ma minuti (e nel caso , forse un orologio).
Invece, puoi ottenere questi dati in un secondo o due, eseguire il test e buttarli via. Queste istantanee risolvono diversi problemi. Nel primo caso - per ampliare e ottenere nuove repliche, e nel secondo - per i test.
DS: Non sono d'accordo. Far funzionare correttamente la clonazione del volume è il compito del cloud. Non ho esaminato la loro implementazione, ma so come lo facciamo sull'hardware. Abbiamo Ceph, consente qualsiasi volume fisico () Dire clonare ed ottenere un secondo volume con le stesse caratteristiche in decine di millisecondi, 'ami, ecc. Devi capire che all'interno c'è una complicata copia su scrittura. Perché il cloud non dovrebbe fare lo stesso? Sono sicuro che stanno cercando di farlo in un modo o nell'altro.
NA: Ma ci vorranno comunque secondi, decine di secondi per generare un'istanza, portare lì Docker, ecc.
DS: Perché è necessario generare un'intera istanza? Abbiamo un'istanza con 32 core, 16... e può adattarsi, ad esempio quattro. Quando ordiniamo la quinta, l'istanza sarà già sollevata e poi verrà cancellata.
NA: Sì, interessante, Kubernetes risulta essere una storia diversa. Il nostro database non è in K8 e abbiamo un'istanza. Ma la clonazione di un database da più terabyte non richiede più di due secondi.
DS: Questo è fantastico. Ma il mio punto iniziale è che questa non è una soluzione generica. Sì, è bello, ma è adatto solo per Postgres e solo su un nodo.
NA: È adatto non solo per Postgres: questi piani, come ho descritto, funzioneranno solo con esso. Ma se non ci preoccupiamo dei piani e abbiamo solo bisogno di tutti i dati per i test funzionali, allora questo è adatto a qualsiasi DBMS.
DS: Molti anni fa abbiamo fatto qualcosa di simile sugli snapshot LVM. Questo è un classico. Questo approccio è stato utilizzato molto attivamente. I nodi con stato sono solo una seccatura. Perché non dovresti lasciarli cadere, dovresti ricordarli sempre...
NA: Vedete qualche possibilità di un ibrido qui? Diciamo che stateful è una specie di pod, funziona per più persone (molti tester). Abbiamo un volume, ma grazie al file system i cloni sono locali. Se il pod cade, ma il disco rimane, il pod si solleverà, conterà le informazioni su tutti i cloni, raccoglierà di nuovo tutto e dirà: "Ecco i tuoi cloni in esecuzione su queste porte, continua a lavorare con loro".
DS: Tecnicamente questo significa che all'interno di Kubernetes è un pod all'interno del quale eseguiamo molti Postgres.
NA: SÌ. Ha un limite: diciamo che con lui lavorano non più di 10 persone contemporaneamente. Se ne avrai bisogno di 20, lanceremo un secondo pod di questo tipo. Lo cloneremo completamente, avendo ricevuto il secondo volume completo, avrà gli stessi 10 cloni “sottili”. Non vedi questa opportunità?
DS: Dobbiamo aggiungere qui i problemi di sicurezza. Questo tipo di organizzazione implica che questo pod abbia privilegi (capacità) elevati, perché può eseguire operazioni non standard sul file system... Ma ripeto: credo che a medio termine sistemeranno lo storage in Kubernetes, e in le nuvole fisseranno l'intera storia con i volumi: tutto “funzionerà e basta”. Ci sarà il ridimensionamento, la clonazione... C'è un volume: diciamo: "Creane uno nuovo in base a quello" e dopo un secondo e mezzo otteniamo ciò di cui abbiamo bisogno.
NA: Non credo in un secondo e mezzo per molti terabyte. Su Ceph lo fai da solo, ma parli delle nuvole. Vai sul cloud, crea un clone di un volume EBS multi-terabyte su EC2 e guarda quali saranno le prestazioni. Non ci vorranno pochi secondi. Sono molto interessato a quando raggiungeranno questo livello. Capisco quello che dici, ma mi permetto di dissentire.
DS: Ok, ma ho detto a medio termine, non a breve termine. Per molti anni.
Informazioni sull'operatore per PostgreSQL di Zalando
Nel mezzo di questo incontro si è unito anche Alexey Klyukin, un ex sviluppatore di Zalando, che ha parlato della storia dell'operatore PostgreSQL:
È fantastico che questo argomento venga toccato in generale: sia Postgres che Kubernetes. Quando abbiamo iniziato a farlo su Zalando nel 2017, era un argomento che tutti volevano affrontare, ma nessuno lo faceva. Tutti avevano già Kubernetes, ma quando chiedevano cosa fare con i database, anche alla gente piaceva , che predicava il K8, disse qualcosa del genere:
“Vai ai servizi gestiti e usali, non eseguire il database in Kubernetes. Altrimenti i tuoi K8 decideranno, ad esempio, di fare un upgrade, spegneranno tutti i nodi, e i tuoi dati voleranno lontano, molto lontano.”
Abbiamo deciso di creare un operatore che, contrariamente a questo consiglio, lancerà un database Postgres in Kubernetes. E avevamo una buona ragione - . Questo è un failover automatico per PostgreSQL, eseguito correttamente, ad es. utilizzando etcd, console o ZooKeeper come archivio di informazioni sul cluster. Un tale archivio che fornirà a chiunque chieda, ad esempio, quale sia l'attuale leader, le stesse informazioni - nonostante abbiamo tutto distribuito - in modo che non vi siano divisioni cerebrali. Inoltre abbiamo avuto per lui.
In generale, la necessità dell'azienda di failover automatico è emersa dopo la migrazione da un data center hardware interno al cloud. Il cloud era basato su una soluzione proprietaria PaaS (Platform-as-a-Service). È Open Source, ma c'è voluto molto lavoro per renderlo operativo. Era chiamato .
Inizialmente non esisteva Kubernetes. Più precisamente, quando è stata adottata la nostra soluzione, il K8 esisteva già, ma era così rozzo da non essere adatto alla produzione. Era, secondo me, il 2015 o il 2016. Nel 2017 Kubernetes era diventato più o meno maturo: era necessario migrare lì.
E avevamo già un container Docker. C'era un PaaS che utilizzava Docker. Perché non provare i K8? Perché non scrivere il tuo operatore? Murat Kabilov, arrivato da noi da Avito, ha avviato questo progetto di sua iniziativa - "per giocare" - e il progetto "è decollato".
Ma in generale volevo parlare di AWS. Perché esisteva un codice storico relativo ad AWS...
Quando esegui qualcosa in Kubernetes, devi capire che K8s è un work in progress. Si sviluppa costantemente, migliora e persino si rompe di volta in volta. Devi tenere d'occhio tutti i cambiamenti in Kubernetes, devi essere pronto a tuffarti se succede qualcosa e imparare come funziona in dettaglio, forse più di quanto vorresti. Questo, in linea di principio, si applica a qualsiasi piattaforma su cui esegui i tuoi database...
Quindi, quando abbiamo fatto la dichiarazione, avevamo Postgres in esecuzione su un volume esterno (EBS in questo caso, poiché stavamo lavorando su AWS). Il database è cresciuto, ad un certo punto è stato necessario ridimensionarlo: ad esempio, la dimensione iniziale di EBS era 100 TB, il database è cresciuto fino a raggiungere, ora vogliamo rendere EBS 200 TB. Come? Supponiamo che tu possa eseguire un dump/ripristino su una nuova istanza, ma ciò richiederà molto tempo e comporterà tempi di inattività.
Pertanto, volevo un ridimensionamento che allargasse la partizione EBS e quindi indicasse al file system di utilizzare il nuovo spazio. E lo abbiamo fatto, ma a quel tempo Kubernetes non disponeva di alcuna API per l'operazione di ridimensionamento. Dato che abbiamo lavorato su AWS, abbiamo scritto il codice per la sua API.
Nessuno ti impedisce di fare lo stesso per altre piattaforme. Non vi è alcun accenno nella dichiarazione che possa essere eseguito solo su AWS e non funzionerà su tutto il resto. In generale si tratta di un progetto Open Source: se qualcuno vuole accelerare la diffusione dell'utilizzo delle nuove API, è il benvenuto. Mangiare , pull request: il team di Zalando cerca di rispondere abbastanza rapidamente e di promuovere l'operatore. Per quanto ne so, il progetto al Google Summer of Code e ad alcune altre iniziative simili. Zalando ci sta lavorando molto attivamente.
Bonus PS!
Se sei interessato all'argomento PostgreSQL e Kubernetes, tieni presente anche che la settimana scorsa si è svolto il prossimo Postgres Tuesday, dove ho parlato con Nikolai Alexander Kukushkin di Zalando. Il video da esso è disponibile .
PPS
Leggi anche sul nostro blog:
- «";
- «";
- «";
- «'.
Fonte: habr.com