A finals de l'any passat, va tenir lloc una altra transmissió en directe de la comunitat russa de PostgreSQL , durant la qual el seu cofundador Nikolai Samokhvalov va parlar amb el director tècnic de Flant, Dmitry Stolyarov, sobre aquest SGBD en el context de Kubernetes.
Estem publicant una transcripció de la part principal d'aquesta discussió, i a Vídeo complet publicat:
Bases de dades i Kubernetes
NS: Avui no parlarem de BUIT i CHECKPOINTs. Volem parlar de Kubernetes. Sé que tens molts anys d'experiència. Vaig mirar els teus vídeos i fins i tot n'he tornat a mirar alguns... Anem directament al punt: per què Postgres o MySQL a K8s?
DS: No hi ha ni pot haver-hi una resposta definitiva a aquesta pregunta. Però, en general, això és senzillesa i comoditat... potencial. Tothom vol serveis gestionats.
NS: a com , només a casa?
DS: Sí: com RDS, a qualsevol lloc.
NS: "A qualsevol lloc" és un bon punt. A les grans empreses, tot està situat en llocs diferents. Aleshores, per què, si es tracta d'una gran empresa, no prendre una solució ja feta? Per exemple, Nutanix té els seus propis desenvolupaments, altres empreses (VMware...) tenen el mateix "RDS, només a casa".
DS: Però estem parlant d'una implementació independent que només funcionarà sota determinades condicions. I si estem parlant de Kubernetes, hi ha una gran varietat d'infraestructures (que poden estar en K8). Essencialment, aquest és un estàndard per a les API al núvol...
NS: També és gratuït!
DS: No és tan important. La llibertat és important per a un segment no molt gran del mercat. Una altra cosa és important... Segurament recordeu l'informe “"?
NS: Sí.
DS: Em vaig adonar que es va rebre de manera molt ambigua. Algunes persones pensaven que deia: "Nois, posem totes les bases de dades a Kubernetes!", mentre que altres van decidir que totes eren bicicletes terribles. Però volia dir una cosa completament diferent: “Mireu què passa, quins problemes hi ha i com es poden resoldre. Hem d'utilitzar les bases de dades de Kubernetes ara? Producció? Bé, només si t'agrada... fer certes coses. Però per a un desenvolupador, puc dir que el recomano. Per a un desenvolupador, el dinamisme de crear/suprimir entorns és molt important".
NS: Per desenvolupador, vols dir tots els entorns que no són prod? Escenificació, control de qualitat...
DS: Si estem parlant de suports de perfeccionament, probablement no, perquè els requisits són específics. Si estem parlant de casos especials on es necessita una base de dades molt gran per a la posada en escena, probablement no... Si es tracta d'un entorn estàtic i de llarga vida, quin avantatge té tenir la base de dades ubicada al K8s?
NS: Cap. Però on veiem entorns estàtics? Un entorn estàtic quedarà obsolet demà.
DS: La posada en escena pot ser estàtica. Tenim clients...
NS: Sí, jo també en tinc un. És un gran problema si teniu una base de dades de 10 TB i 200 GB d'estadi...
DS: Tinc un cas molt xulo! A la posada en escena hi ha una base de dades de productes a la qual es fan canvis. I hi ha un botó: "desplegar a producció". Aquests canvis -deltes- s'afegeixen (sembla que simplement es sincronitzen mitjançant l'API) en producció. Aquesta és una opció molt exòtica.
NS: He vist startups a la vall que estan assegudes a RDS o fins i tot a Heroku (són històries de fa 2 o 3 anys) i descarreguen l'abocador al seu ordinador portàtil. Perquè la base de dades encara només té 80 GB i hi ha espai a l'ordinador portàtil. Després compren discs addicionals per a tothom perquè tinguin 3 bases de dades per realitzar diferents desenvolupaments. Així també passa. També vaig veure que no tenen por de copiar el producte a la posada en escena: depèn molt de l'empresa. Però també vaig veure que tenen molta por, i que sovint no tenen prou temps i mans. Però abans de passar a aquest tema, vull saber sobre Kubernetes. Entenc bé que ningú encara està en prod?
DS: Tenim petites bases de dades en prod. Estem parlant de volums de desenes de gigabytes i serveis no crítics per als quals ens feia mandra fer rèpliques (i no hi ha cap necessitat). I sempre que hi hagi emmagatzematge normal a Kubernetes. Aquesta base de dades funcionava en una màquina virtual, condicionalment a VMware, a la part superior del sistema d'emmagatzematge. L'hem col·locat i ara el podem transferir de màquina en màquina.
NS: Les bases de dades d'aquesta mida, de fins a 100 GB, es poden desplegar en pocs minuts en bons discs i una bona xarxa, oi? Una velocitat d'1 GB per segon ja no és exòtica.
DS: Sí, per al funcionament lineal això no és un problema.
NS: D'acord, només hem de pensar en prod. I si estem considerant Kubernetes per a entorns que no són de producte, què hem de fer? Ho veig a Zalando , a Cruixent , hi ha altres opcions. I n'hi ha - aquest és el nostre bon amic Alvaro d'Espanya: el que fan no és essencialment just , i tota la distribució (), a la qual, a més del mateix Postgres, també van decidir emplenar una còpia de seguretat, el proxy Envoy...
DS: Enviat per a què? Equilibrar el trànsit de Postgres específicament?
NS: Sí. És a dir, ho veuen com: si agafeu una distribució i un nucli de Linux, llavors PostgreSQL normal és el nucli i volen fer una distribució que sigui compatible amb el núvol i que s'executi a Kubernetes. Ajunten components (còpies de seguretat, etc.) i els depuren perquè funcionin bé.
DS: Molt guai! Essencialment, aquest és un programari per crear el vostre propi Postgres gestionat.
NS: Les distribucions de Linux tenen problemes eterns: com fer controladors perquè tot el maquinari sigui compatible. I tenen la idea que treballaran a Kubernetes. Sé que a l'operador de Zalando fa poc hem vist una connexió amb AWS i això ja no és molt bo. No hi hauria d'haver un vincle amb una infraestructura específica; de què serveix llavors?
DS: No sé exactament en quina situació es va trobar Zalando, però a Kubernetes l'emmagatzematge es fa de tal manera que és impossible fer una còpia de seguretat del disc mitjançant un mètode genèric. Recentment en estàndard - en l'última versió — vam fer possibles les instantànies, però on s'implementa? Sincerament, tot segueix tan cru... Estem provant CSI a sobre d'AWS, GCE, Azure, vSphere, però tan bon punt comenceu a utilitzar-lo, podeu veure que encara no està llest.
NS: Per això de vegades hem de confiar en la infraestructura. Crec que encara és una etapa primerenca: dolors de creixement. Pregunta: Quins consells donaríeu als novells que vulguin provar PgSQL a K8s? Quin operador potser?
DS: El problema és que Postgres és un 3% per a nosaltres. També tenim una llista molt gran de programari diferent a Kubernetes, ni tan sols ho enumeraré tot. Per exemple, Elasticsearch. Hi ha molts operadors: alguns es desenvolupen activament, altres no. Ens hem elaborat els requisits sobre què hauria de tenir un operador per tal que ens ho prenguem seriosament. En un operador específicament per a Kubernetes, no en un "operador per fer alguna cosa en les condicions d'Amazon"... De fet, de manera bastant àmplia (= gairebé tots els clients) fem servir un únic operador - (en breu publicarem un article sobre ell).
NS: I tampoc per a MySQL? Sé que Percona... com que ara treballen en MySQL, MongoDB i Postgres, hauran de crear algun tipus de solució universal: per a totes les bases de dades, per a tots els proveïdors de núvol.
DS: No vam tenir temps de mirar els operadors de MySQL. Aquest no és el nostre objectiu principal ara mateix. MySQL funciona bé de manera independent. Per què utilitzar un operador si només podeu llançar una base de dades... Podeu llançar un contenidor Docker amb Postrges, o podeu llançar-lo d'una manera senzilla.
NS: També hi havia una pregunta sobre això. No hi ha cap operador?
DS: Sí, el 100% de nosaltres tenim PostgreSQL funcionant sense un operador. Fins aquí. Utilitzem activament l'operador per a Prometheus i Redis. Tenim previst trobar un operador per a Elasticsearch: és el que està més "en flames", perquè volem instal·lar-lo a Kubernetes en el 100% dels casos. De la mateixa manera que volem assegurar-nos que MongoDB també estigui sempre instal·lat a Kubernetes. Aquí apareixen certs desitjos: hi ha la sensació que en aquests casos es pot fer alguna cosa. I ni tan sols vam mirar a Postgres. Per descomptat, sabem que hi ha diferents opcions, però de fet en tenim una autònoma.
Base de dades per provar a Kubernetes
NS: Passem al tema de les proves. Com implementar canvis a la base de dades, des d'una perspectiva DevOps. Hi ha microserveis, moltes bases de dades, alguna cosa està canviant en algun lloc tot el temps. Com garantir CI/CD normal perquè tot estigui en ordre des de la perspectiva del SGBD. Quin és el teu enfocament?
DS: No hi pot haver una sola resposta. Hi ha diverses opcions. El primer és la mida de la base que volem desplegar. Vostè mateix va esmentar que les empreses tenen actituds diferents a l'hora de tenir una còpia de la base de dades de productes al desenvolupament i a l'escenari.
NS: I en les condicions del GDPR, crec que cada cop tenen més cura... Puc dir que a Europa ja han començat a imposar multes.
DS: Però sovint podeu escriure programari que treu un abocador de la producció i l'ofosqui. S'obtenen dades de producte (snapshot, dump, binary copy...), però són anònimes. En canvi, hi pot haver scripts de generació: poden ser accessoris o només un script que genera una gran base de dades. El problema és: quant de temps es triga a crear una imatge base? I quant de temps triga a desplegar-lo a l'entorn desitjat?
Hem arribat a un esquema: si el client té un conjunt de dades fix (versió mínima de la base de dades), les fem servir per defecte. Si estem parlant d'entorns de revisió, quan vam crear una branca, vam desplegar una instància de l'aplicació: hi despleguem una petita base de dades. Però va sortir bé , quan fem un abocament de la producció un cop al dia (a la nit) i construïm un contenidor Docker amb PostgreSQL i MySQL amb aquestes dades carregades basades en això. Si necessiteu ampliar la base de dades 50 vegades a partir d'aquesta imatge, això es fa de manera senzilla i ràpida.
NS: Per simple còpia?
DS: Les dades s'emmagatzemen directament a la imatge de Docker. Aquells. Tenim una imatge ja feta, encara que de 100 GB. Gràcies a les capes de Docker, podem desplegar ràpidament aquesta imatge tantes vegades com necessitem. El mètode és estúpid, però funciona bé.
NS: Aleshores, quan feu la prova, canvia just dins de Docker, oi? Còpia sobre escriptura dins de Docker: llenceu-lo i torneu-ho, tot està bé. Classe! I ja l'estàs utilitzant al màxim?
DS: Durant molt de temps.
NS: Fem coses molt semblants. Només que no utilitzem el copy-on-write de Docker, sinó un altre.
DS: No és genèric. I Docker funciona a tot arreu.
NS: En teoria, sí. Però també hi tenim mòduls, pots fer diferents mòduls i treballar amb diferents sistemes de fitxers. Quin moment aquí. Des del costat de Postgres, mirem tot això de manera diferent. Ara vaig mirar des del costat de Docker i vaig veure que tot funciona per a tu. Però si la base de dades és enorme, per exemple, 1 TB, llavors tot això porta molt de temps: operacions a la nit, i embotir-ho tot a Docker... I si s'inclouen 5 TB a Docker... O està tot bé?
DS: Quina diferència hi ha: són blobs, només bits i bytes.
NS: La diferència és aquesta: ho feu mitjançant l'abocament i la restauració?
DS: No és gens necessari. Els mètodes per generar aquesta imatge poden ser diferents.
NS: Per a alguns clients, hem fet que en comptes de generar regularment una imatge de base, la mantenim constantment actualitzada. Bàsicament és una rèplica, però rep dades no directament del mestre, sinó a través d'un arxiu. Un arxiu binari on es descarreguen WAL cada dia, on es fan còpies de seguretat... Aquests WAL arriben llavors a la imatge base amb un lleuger retard (literalment 1-2 segons). En clonem de qualsevol manera: ara tenim ZFS per defecte.
DS: Però amb ZFS esteu limitat a un node.
NS: Sí. Però ZFS també té una màgia : amb ell podeu enviar una instantània i fins i tot (encara no ho he provat realment, però...) podeu enviar un delta entre dos PGDATA. De fet, tenim una altra eina que realment no hem considerat per a aquestes tasques. PostgreSQL té , que funciona com un rsync "intel·ligent", saltant-se molt del que no cal veure, perquè no hi ha canviat res. Podem fer una sincronització ràpida entre els dos servidors i rebobinar de la mateixa manera.
Per tant, a partir d'aquest, més costat de DBA, estem intentant crear una eina que ens permeti fer el mateix que vau dir: tenim una base de dades, però volem provar alguna cosa 50 vegades, gairebé simultàniament.
DS: 50 vegades significa que heu de demanar 50 instàncies Spot.
NS: No, ho fem tot en una màquina.
DS: Però com s'ampliarà 50 vegades si aquesta base de dades és, per exemple, terabyte. El més probable és que necessiti un condicional de 256 GB de RAM?
NS: Sí, de vegades necessites molta memòria, això és normal. Però aquest és un exemple de la vida. La màquina de producció té 96 nuclis i 600 GB. Al mateix temps, s'utilitzen 32 nuclis (fins i tot 16 nuclis ara de vegades) i 100-120 GB de memòria per a la base de dades.
DS: I hi caben 50 còpies?
NS: Per tant, només hi ha una còpia, després la còpia sobre escriptura (ZFS) funciona... Us ho explicaré amb més detall.
Per exemple, tenim una base de dades de 10 TB. Van fer-hi un disc, ZFS també va comprimir la seva mida entre un 30 i un 40 per cent. Com que no fem proves de càrrega, el temps de resposta exacte no és important per a nosaltres: deixeu que sigui fins a 2 vegades més lent, això està bé.
Donem l'oportunitat a programadors, QA, DBA, etc. realitzar proves en 1-2 fils. Per exemple, poden executar algun tipus de migració. No requereix 10 nuclis alhora: necessita 1 backend Postgres, 1 nucli. La migració començarà, potser encara començarà, llavors s'utilitzarà el segon nucli. Tenim 16-32 nuclis assignats, de manera que 10 persones poden treballar al mateix temps, sense cap problema.
Perquè físicament PGDATA el mateix, resulta que en realitat estem enganyant a Postgres. El truc és aquest: per exemple, s'inicien 10 Postgres simultàniament. Quin és el problema habitualment? Ells posen , diguem un 25%. En conseqüència, això són 200 GB. No podreu llançar més de tres d'aquests, perquè la memòria s'esgotarà.
Però en algun moment ens vam adonar que això no era necessari: vam establir shared_buffers a 2 GB. PostgreSQL té , i en realitat és l'únic que influeix . Ho vam establir a 0,5 TB. I ni tan sols importa que en realitat no existeixin: fa plans com si existissin.
En conseqüència, quan provem algun tipus de migració, podem recollir tots els plans; veurem com passarà en producció. Els segons seran diferents (més lents), però les dades que llegim realment i els mateixos plans (quins JOIN hi ha, etc.) resulten exactament iguals que a la producció. I podeu executar moltes comprovacions d'aquest tipus en paral·lel en una màquina.
DS: No creus que hi ha alguns problemes aquí? La primera és una solució que només funciona a PostgreSQL. Aquest enfocament és molt privat, no és genèric. La segona és que Kubernetes (i tot el que faran les tecnologies del núvol ara) implica molts nodes, i aquests nodes són efímers. I en el vostre cas és un node persistent i amb estat. Aquestes coses em posen en conflicte.
NS: En primer lloc, estic d'acord, aquesta és una història purament de Postgres. Crec que si tenim algun tipus d'IO directa i un grup de memòria intermèdia per a gairebé tota la memòria, aquest enfocament no funcionarà: els plans seran diferents. Però de moment només treballem amb Postgres, no pensem en els altres.
Sobre Kubernetes. Tu mateix ens dius a tot arreu que tenim una base de dades persistent. Si la instància falla, el més important és desar el disc. Aquí també tenim tota la plataforma a Kubernetes, i el component amb Postgres està separat (tot i que algun dia hi serà). Per tant, tot és així: la instància ha caigut, però hem desat el seu PV i simplement l'hem connectat a una altra (nova) instància, com si no hagués passat res.
DS: Des del meu punt de vista, creem pods a Kubernetes. K8s - elàstic: els nusos s'ordenen segons calgui. La tasca és simplement crear una beina i dir que necessita X quantitat de recursos, i després K8s ho descobrirà per si mateix. Però el suport d'emmagatzematge a Kubernetes encara és inestable: a (aquest llançament es va publicar недели fa) aquestes funcions només es converteixen en beta.
Passaran de sis mesos a un any: es tornarà més o menys estable, o almenys es declararà com a tal. Aleshores, la possibilitat de fer instantànies i canviar la mida resol el vostre problema completament. Perquè tens una base. Sí, pot ser que no sigui molt ràpid, però la velocitat depèn del que hi ha "sota el capó", perquè algunes implementacions poden copiar i copiar-en-escriptura a nivell de subsistema de disc.
NS: També és necessari que tots els motors (Amazon, Google...) comencin a donar suport a aquesta versió; això també porta una mica de temps.
DS: Encara no els fem servir. Utilitzem la nostra.
Desenvolupament local per a Kubernetes
NS: us heu trobat amb aquest desig quan necessiteu instal·lar tots els pods en una màquina i fer una prova tan petita. Per obtenir ràpidament una prova de concepte, comproveu que l'aplicació s'executa a Kubernetes, sense dedicar-hi un munt de màquines. Hi ha Minikube, oi?
DS: Em sembla que aquest cas, desplegat en un node, tracta exclusivament de desenvolupament local. O algunes manifestacions d'aquest patró. Menja , hi ha , . Estem avançant cap a l'ús de Kubernetes IN Docker. Ara hem començat a treballar-hi per fer proves.
NS: solia pensar que era un intent d'embolicar tots els pods en una imatge de Docker. Però va resultar que es tracta d'una cosa completament diferent. De totes maneres, hi ha contenidors separats, beines separades, només a Docker.
DS: Sí. I es fa una imitació força divertida, però el significat és aquest... Tenim una utilitat per al desplegament - . Volem que sigui un mode condicional werf up: "Aconsegueix-me Kubernetes local". I després executa el condicional allà werf follow. Aleshores, el desenvolupador podrà editar l'IDE i s'iniciarà un procés al sistema que veurà els canvis i reconstruirà les imatges, tornant a desplegar-les als K8 locals. Així és com volem intentar resoldre el problema del desenvolupament local.
Instantània i clonació de bases de dades a la realitat K8s
NS: Si tornem a còpia sobre escriptura. Em vaig adonar que els núvols també tenen instantànies. Funcionen de manera diferent. Per exemple, a GCP: teniu una instància de diversos terabytes a la costa est dels Estats Units. Feu instantànies periòdicament. Agafeu una còpia del disc a la costa oest d'una instantània: en pocs minuts tot està a punt, funciona molt ràpidament, només cal omplir la memòria cau a la memòria. Però aquests clons (snapshots) són per "provisionar" un nou volum. Això és fantàstic quan necessiteu crear moltes instàncies.
Però per a les proves, em sembla que les instantànies, de les quals parleu a Docker o jo parlo a ZFS, btrfs i fins i tot LVM..., us permeten no crear dades realment noves en una màquina. Al núvol, encara pagareu per ells cada vegada i esperareu no segons, sinó minuts (i en el cas , possiblement un rellotge).
En canvi, podeu obtenir aquestes dades en un segon o dos, executar la prova i llençar-les. Aquestes instantànies resolen diferents problemes. En el primer cas, per ampliar i obtenir noves rèpliques, i en el segon, per a proves.
DS: No estic d'acord. Fer que la clonació de volums funcioni correctament és la tasca del núvol. No he mirat la seva implementació, però sé com ho fem amb el maquinari. Tenim Ceph, permet qualsevol volum físic () dir clonar i obteniu un segon volum amb les mateixes característiques en desenes de mil·lisegons, 'ami, etc. Heu d'entendre que hi ha una còpia en escriptura complicada dins. Per què el núvol no hauria de fer el mateix? Estic segur que estan intentant fer-ho d'una manera o altra.
NS: Però encara trigaran segons, desenes de segons a plantejar una instància, portar-hi Docker, etc.
DS: Per què cal plantejar una instància sencera? Tenim una instància amb 32 nuclis, 16... i hi pot cabre, per exemple, quatre. Quan ordenem el cinquè, la instància ja s'aixecarà, i després s'eliminarà.
NS: Sí, interessant, Kubernetes resulta ser una història diferent. La nostra base de dades no es troba a K8s i tenim una instància. Però clonar una base de dades de diversos terabytes no triga més de dos segons.
DS: Això es fantàstic. Però el meu punt inicial és que aquesta no és una solució genèrica. Sí, és fantàstic, però només és adequat per a Postgres i només en un node.
NS: És adequat no només per a Postgres: aquests plans, com he descrit, només funcionaran en ell. Però si no ens preocupem pels plans i només necessitem totes les dades per a proves funcionals, això és adequat per a qualsevol SGBD.
DS: Fa molts anys vam fer alguna cosa semblant a les instantànies de LVM. Això és un clàssic. Aquest enfocament es va utilitzar molt activament. Els nodes amb estat són només un dolor. Com que no els has de deixar caure, els has de recordar sempre...
NS: Veieu alguna possibilitat d'un híbrid aquí? Diguem que stateful és una mena de pod, funciona per a diverses persones (molts provadors). Tenim un volum, però gràcies al sistema de fitxers, els clons són locals. Si la càpsula cau, però el disc es manté, la càpsula s'aixecarà, comptarà informació sobre tots els clons, tornarà a agafar-ho tot i dirà: "Aquí teniu els vostres clons que s'executen en aquests ports, continueu treballant amb ells".
DS: Tècnicament, això vol dir que dins de Kubernetes és un pod dins del qual executem molts Postgres.
NS: Sí. Té un límit: diguem que no hi treballen més de 10 persones alhora. Si en necessiteu 20, llançarem un segon pod. El clonarem completament, havent rebut el segon volum complet, tindrà els mateixos 10 clons "prims". No veus aquesta oportunitat?
DS: Hem d'afegir problemes de seguretat aquí. Aquest tipus d'organització implica que aquest pod té alts privilegis (capacitats), perquè pot realitzar operacions no estàndard al sistema de fitxers... Però repeteixo: crec que a mitjà termini arreglaran l'emmagatzematge a Kubernetes, i en els núvols arreglaran tota la història amb volums: tot "funcionarà". Hi haurà redimensionament, clonació... Hi ha un volum: diem: “Creeu-ne un de nou a partir d'això”, i al cap d'un segon i mig obtenim el que necessitem.
NS: No crec en un segon i mig durant molts terabytes. A Ceph ho fas tu, però parles dels núvols. Aneu al núvol, feu un clon d'un volum EBS de diversos terabytes a l'EC2 i mireu quin serà el rendiment. No trigarà uns segons. M'interessa molt quan arribaran a aquest nivell. Entenc el que dius, però demano discrepar.
DS: D'acord, però vaig dir a mitjà termini, no a curt termini. Durant uns quants anys.
Sobre l'operador de PostgreSQL de Zalando
Enmig d'aquesta reunió, Alexey Klyukin, un antic desenvolupador de Zalando, també es va unir i va parlar sobre la història de l'operador PostgreSQL:
És fantàstic que es toqui aquest tema en general: tant Postgres com Kubernetes. Quan vam començar a fer-ho a Zalando el 2017, era un tema que tothom volia fer, però ningú. Tothom ja tenia Kubernetes, però quan van preguntar què fer amb les bases de dades, fins i tot a la gent li agrada , que predicava K8s, va dir alguna cosa com això:
"Aneu als serveis gestionats i utilitzeu-los, no executeu la base de dades a Kubernetes. En cas contrari, els vostres K8 decidiran, per exemple, fer una actualització, apagar tots els nodes i les vostres dades volaran molt, molt lluny".
Vam decidir fer un operador que, contràriament a aquest consell, llançarà una base de dades Postgres a Kubernetes. I teníem una bona raó... . Aquesta és una migració automàtica per error per a PostgreSQL, feta correctament, és a dir. utilitzant etcd, cònsol o ZooKeeper com a emmagatzematge d'informació sobre el clúster. Un dipòsit així que donarà a tothom qui pregunti, per exemple, quin és el líder actual, la mateixa informació -malgrat que ho tenim tot distribuït- perquè no hi hagi un cervell dividit. A més, teníem per ell.
En general, la necessitat de l'empresa de fer una fallada automàtica va aparèixer després de migrar des d'un centre de dades de maquinari intern al núvol. El núvol es basava en una solució patentada PaaS (Platform-as-a-Service). És de codi obert, però va costar molta feina per posar-lo en marxa. Es deia .
Inicialment, no hi havia Kubernetes. Més precisament, quan es va implementar la nostra pròpia solució, els K8 ja existien, però era tan cru que no era adequat per a la producció. Va ser, al meu entendre, el 2015 o el 2016. El 2017, Kubernetes s'havia tornat més o menys madur; hi havia la necessitat de migrar-hi.
I ja teníem un contenidor Docker. Hi havia un PaaS que utilitzava Docker. Per què no proveu els K8? Per què no escriu el teu propi operador? Murat Kabilov, que ens va venir d'Avito, va començar això com un projecte per iniciativa pròpia -"tocar"- i el projecte "va enlairar".
Però, en general, volia parlar d'AWS. Per què hi havia codi històric relacionat amb AWS...
Quan executeu alguna cosa a Kubernetes, heu d'entendre que K8s és un treball en curs. Està en constant desenvolupament, millora i fins i tot es trenca de tant en tant. Heu de vigilar de prop tots els canvis de Kubernetes, heu d'estar preparats per submergir-vos-hi si passa alguna cosa i aprendre com funciona en detall, potser més del que voldríeu. Això, en principi, s'aplica a qualsevol plataforma en què executeu les vostres bases de dades...
Per tant, quan vam fer la declaració, teníem Postgres executant-se en un volum extern (EBS en aquest cas, ja que estàvem treballant a AWS). La base de dades va créixer, en algun moment va ser necessari redimensionar-la: per exemple, la mida inicial d'EBS era de 100 TB, la base de dades hi va créixer, ara volem fer EBS 200 TB. Com? Suposem que podeu fer un abocament/restauració en una instància nova, però això trigarà molt de temps i implicarà temps d'inactivitat.
Per tant, volia un canvi de mida que ampliés la partició EBS i després digués al sistema de fitxers que utilitzés el nou espai. I ho vam fer, però en aquell moment Kubernetes no tenia cap API per a l'operació de redimensionament. Com que vam treballar a AWS, vam escriure codi per a la seva API.
Ningú t'impedeix fer el mateix amb altres plataformes. No hi ha cap indici a la declaració que només es pot executar a AWS i que no funcionarà en tota la resta. En general, es tracta d'un projecte de codi obert: si algú vol accelerar l'aparició de l'ús de la nova API, és benvingut. Menja , sol·licituds d'extracció: l'equip de Zalando intenta respondre-hi amb força rapidesa i promocionar l'operador. Pel que jo sé, el projecte a Google Summer of Code i altres iniciatives similars. Zalando hi està treballant molt activament.
Bonus PS!
Si esteu interessats en el tema de PostgreSQL i Kubernetes, tingueu en compte també que el proper dimarts de Postgres va tenir lloc la setmana passada, on vaig parlar amb Nikolai Alexander Kukushkin de Zalando. El vídeo està disponible .
PPS
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com