A finais do ano pasado tivo lugar outra transmisión en directo da comunidade rusa PostgreSQL , durante o cal o seu cofundador Nikolai Samokhvalov falou co director técnico de Flant, Dmitry Stolyarov, sobre este DBMS no contexto de Kubernetes.
Estamos publicando unha transcrición da parte principal desta discusión, e en Vídeo completo publicado:
Bases de datos e Kubernetes
НС: Hoxe non falaremos de VACUUM e CHECKPOINTs. Queremos falar de Kubernetes. Sei que tes moitos anos de experiencia. Vin os teus vídeos e ata volvín ver algúns deles... Imos directamente ao grano: por que Postgres ou MySQL en K8s?
DS: Non hai nin non pode haber unha resposta definitiva a esta pregunta. Pero, en xeral, isto é a sinxeleza e a conveniencia... potencial. Todo o mundo quere servizos xestionados.
НС: A como , só na casa?
DS: Si: como RDS, en calquera lugar.
НС: "En calquera lugar" é un bo punto. Nas grandes empresas, todo está situado en diferentes lugares. Por que entón, se é unha gran empresa, non se toma unha solución xa preparada? Por exemplo, Nutanix ten os seus propios desenvolvementos, outras empresas (VMware...) teñen o mesmo "RDS, só na casa".
DS: Pero estamos a falar dunha implementación separada que só funcionará baixo determinadas condicións. E se estamos a falar de Kubernetes, hai unha gran variedade de infraestruturas (que pode estar en K8). Esencialmente, este é un estándar para as API na nube...
НС: Tamén é gratuíto!
DS: Non é tan importante. A gratuidade é importante para un segmento non moi grande do mercado. Outra cousa é importante... Probablemente lembras o informe “"?
НС: Si.
DS: Decateime de que era recibido de forma moi ambigua. Algunhas persoas pensaron que estaba a dicir: "Rapaces, imos meter todas as bases de datos en Kubernetes!", mentres que outras decidiron que todas eran bicicletas terribles. Pero quería dicir algo completamente diferente: “Mirade que pasa, que problemas hai e como se poden solucionar. Debemos usar as bases de datos de Kubernetes agora? Produción? Ben, só se che gusta... facer certas cousas. Pero para un dev, podo dicir que o recomendo. Para un desenvolvedor, o dinamismo de crear/eliminar ambientes é moi importante".
NS: Por dev, refírese a todos os ambientes que non son prod? Escenificación, control de calidade...
DS: Se estamos a falar de soportes de perfeccionamento, probablemente non, porque os requisitos son específicos. Se estamos a falar de casos especiais nos que se necesita unha base de datos moi grande para a posta en escena, probablemente non... Se este é un ambiente estático e de longa duración, cal é o beneficio de ter a base de datos situada en K8s?
НС: Ningún. Pero onde vemos ambientes estáticos? Un ambiente estático quedará obsoleto mañá.
DS: A posta en escena pode ser estática. Temos clientes...
НС: Si, eu tamén teño un. É un gran problema se tes unha base de datos de 10 TB e 200 GB de almacenamento...
DS: Teño un caso moi chulo! Na posta en escena hai unha base de datos de produtos na que se realizan cambios. E hai un botón: "lanzamento á produción". Estes cambios -deltas- engádense (parece que simplemente se sincronizan a través da API) na produción. Esta é unha opción moi exótica.
НС: Vin startups no Valley que están sentadas en RDS ou incluso en Heroku -son historias de hai 2 ou 3 anos- e descargan o vertedoiro no seu portátil. Porque a base de datos aínda ten só 80 GB e hai espazo no portátil. Despois compran discos adicionais para todos para que teñan 3 bases de datos para levar a cabo diferentes desenvolvementos. Así tamén ocorre. Tamén vin que non teñen medo de copiar prod na posta en escena - depende moito da compañía. Pero tamén vin que teñen moito medo, e que moitas veces non teñen tempo e mans suficientes. Pero antes de pasar a este tema, quero escoitar sobre Kubernetes. Entendo ben que ninguén está aínda en prod?
DS: Temos pequenas bases de datos en prod. Estamos a falar de volumes de decenas de gigabytes e servizos non críticos para os que nos daba preguiza facer réplicas (e non hai tal necesidade). E sempre que haxa almacenamento normal en Kubernetes. Esta base de datos funcionaba nunha máquina virtual, condicionalmente en VMware, enriba do sistema de almacenamento. Colocámolo e agora podemos transferilo de máquina en máquina.
НС: As bases de datos deste tamaño, de ata 100 GB, pódense lanzar en poucos minutos en bos discos e cunha boa rede, non? Unha velocidade de 1 GB por segundo xa non é exótica.
DS: Si, para o funcionamento lineal non é un problema.
НС: Vale, só temos que pensar no prod. E se estamos considerando Kubernetes para ambientes que non sexan de produción, que debemos facer? Iso véxoo en Zalando , en Crujiente , hai outras opcións. E hai - este é o noso bo amigo Álvaro de España: o que fan, en esencia, non é xusto , e toda a distribución (), no que, ademais do propio Postgres, tamén decidiron meter unha copia de seguridade, o proxy Envoy...
DS: Enviado para que? Equilibrar o tráfico de Postgres específicamente?
НС: Si. É dicir, o ven como: se tomas unha distribución e un núcleo de Linux, entón PostgreSQL normal é o núcleo e queren facer unha distribución que sexa compatible coa nube e que se execute en Kubernetes. Montan compoñentes (copias de seguridade, etc.) e depuran para que funcionen ben.
DS: Moi chulo! Esencialmente, este é un software para crear o teu propio Postgres xestionado.
НС: As distribucións de Linux teñen problemas eternos: como facer controladores para que todo o hardware sexa compatible. E teñen a idea de que traballarán en Kubernetes. Sei que na operadora de Zalando vimos hai pouco unha conexión con AWS e esta xa non é moi boa. Non debería haber un vínculo cunha infraestrutura específica: para que serve entón?
DS: Non sei exactamente en que situación entrou Zalando, pero en Kubernetes o almacenamento agora faise de tal xeito que é imposible facer unha copia de seguridade do disco mediante un método xenérico. Recentemente en estándar - na última versión — fixemos posibles instantáneas, pero onde se implementa? Sinceramente, todo segue tan cru... Estamos probando CSI enriba de AWS, GCE, Azure, vSphere, pero en canto comezas a usalo, podes ver que aínda non está listo.
НС: Por iso ás veces temos que depender da infraestrutura. Creo que esta aínda é unha etapa inicial: dores de crecemento. Pregunta: que consellos lle darías aos novatos que queiran probar PgSQL en K8s? Que operador quizais?
DS: O problema é que Postgres é un 3% para nós. Tamén temos unha lista moi grande de software diferente en Kubernetes, nin sequera enumerarei todo. Por exemplo, Elasticsearch. Hai moitos operadores: algúns están a desenvolverse activamente, outros non. Elaboramos requisitos para nós mesmos sobre o que debe ter un operador para que o tomemos en serio. Nun operador especificamente para Kubernetes, non nun "operador para facer algo nas condicións de Amazon"... De feito, usamos bastante (= case todos os clientes) un único operador - (en breve publicaremos un artigo sobre el).
НС: E tampouco para MySQL? Sei que Percona... xa que agora están a traballar en MySQL, MongoDB e Postgres, terán que crear algún tipo de solución universal: para todas as bases de datos, para todos os provedores de nube.
DS: Non tivemos tempo de mirar os operadores para MySQL. Este non é o noso foco principal neste momento. MySQL funciona ben de forma autónoma. Por que usar un operador se só podes lanzar unha base de datos... Podes lanzar un contedor Docker con Postrges, ou podes lanzalo dun xeito sinxelo.
НС: Tamén houbo unha pregunta sobre isto. Non hai ningún operador?
DS: Si, o 100% de nós temos PostgreSQL funcionando sen un operador. Ata aquí. Usamos activamente o operador para Prometheus e Redis. Temos plans para atopar un operador para Elasticsearch - é o que está máis "en chamas", porque queremos instalalo en Kubernetes no 100% dos casos. Así como queremos asegurarnos de que MongoDB estea sempre instalado en Kubernetes. Aquí aparecen certos desexos: hai a sensación de que nestes casos se pode facer algo. E nin sequera miramos a Postgres. Por suposto, sabemos que hai diferentes opcións, pero de feito temos unha independente.
Base de datos para probar en Kubernetes
НС: Pasemos ao tema das probas. Como implementar cambios na base de datos desde a perspectiva de DevOps. Hai microservizos, moitas bases de datos, algo está cambiando nalgún lugar todo o tempo. Como garantir CI/CD normal para que todo estea en orde dende a perspectiva do DBMS. Cal é o teu enfoque?
DS: Non pode haber unha resposta. Hai varias opcións. O primeiro é o tamaño da base que queremos estender. Vostede mesmo mencionou que as empresas teñen diferentes actitudes para ter unha copia da base de datos de produtos no desenvolvemento e no escenario.
НС: E nas condicións do GDPR creo que cada vez teñen máis coidado... Podo dicir que en Europa xa comezaron a poñer multas.
DS: Pero moitas veces podes escribir software que elimina un lixo da produción e o ofusca. Obtéñense datos de produto (instantánea, volcado, copia binaria...), pero anónimos. Pola contra, pode haber scripts de xeración: poden ser accesorios ou só un script que xere unha gran base de datos. O problema é: canto tempo leva crear unha imaxe base? E canto tempo leva implantalo no ambiente desexado?
Chegamos a un esquema: se o cliente ten un conxunto de datos fixo (versión mínima da base de datos), entón usámolos por defecto. Se estamos a falar de ambientes de revisión, cando creamos unha rama, despregamos unha instancia da aplicación: lanzamos alí unha pequena base de datos. Pero saíu ben , cando sacamos un vertedoiro da produción unha vez ao día (pola noite) e construímos un contedor Docker con PostgreSQL e MySQL con estes datos cargados baseados nel. Se precisa ampliar a base de datos 50 veces a partir desta imaxe, isto faise de forma sinxela e rápida.
НС: Por simple copia?
DS: os datos gárdanse directamente na imaxe de Docker. Eses. Temos unha imaxe preparada, aínda que de 100 GB. Grazas ás capas de Docker, podemos implementar rapidamente esta imaxe tantas veces como necesitemos. O método é estúpido, pero funciona ben.
НС: Entón, cando probas, cambia directamente dentro de Docker, non? Copy-on-write dentro de Docker: bótao e vai de novo, todo está ben. Clase! E xa o estás usando ao máximo?
DS: Por moito tempo.
НС: Facemos cousas moi parecidas. Só que non usamos o copy-on-write de Docker, senón algún outro.
DS: Non é xenérico. E Docker funciona en todas partes.
НС: En teoría, si. Pero tamén temos módulos alí, podes facer diferentes módulos e traballar con diferentes sistemas de ficheiros. Que momento aquí. Desde o lado de Postgres, miramos todo isto de forma diferente. Agora mirei dende o lado de Docker e vin que todo funciona para ti. Pero se a base de datos é enorme, por exemplo, 1 TB, entón todo isto leva moito tempo: operacións pola noite, e meter todo en Docker... E se se meten 5 TB en Docker... Ou está todo ben?
DS: Cal é a diferenza: son blobs, só bits e bytes.
НС: A diferenza é a seguinte: faino mediante o vocado e a restauración?
DS: En absoluto necesario. Os métodos para xerar esta imaxe poden ser diferentes.
НС: Para algúns clientes, fixémolo para que, en lugar de xerar regularmente unha imaxe base, manteña constantemente actualizada. É esencialmente unha réplica, pero recibe datos non directamente do mestre, senón a través dun arquivo. Un arquivo binario onde se descargan WAL todos os días, onde se realizan copias de seguridade... Estes WAL chegan entón á imaxe base cun lixeiro atraso (literalmente 1-2 segundos). Clonámolo de calquera forma: agora temos ZFS por defecto.
DS: Pero con ZFS está limitado a un nodo.
НС: Si. Pero ZFS tamén ten un máxico : con el podes enviar unha instantánea e incluso (aínda non o probei, pero...) podes enviar un delta entre dous PGDATA. De feito, temos outra ferramenta que realmente non consideramos para este tipo de tarefas. PostgreSQL ten , que funciona como un rsync "intelixente", saltando moito do que non tes que ver, porque nada cambiou alí. Podemos facer unha sincronización rápida entre os dous servidores e rebobinar do mesmo xeito.
Entón, a partir deste, máis lado de DBA, estamos tentando crear unha ferramenta que nos permita facer o mesmo que dixeches: temos unha base de datos, pero queremos probar algo 50 veces, case simultáneamente.
DS: 50 veces significa que necesitas pedir 50 instancias Spot.
НС: Non, facemos todo nunha máquina.
DS: Pero como se expandirá 50 veces se esta base de datos é, digamos, terabyte. O máis probable é que necesite un condicional de 256 GB de RAM?
НС: Si, ás veces necesitas moita memoria, iso é normal. Pero este é un exemplo da vida. A máquina de produción ten 96 núcleos e 600 GB. Ao mesmo tempo, utilízanse 32 núcleos (incluso 16 núcleos agora ás veces) e 100-120 GB de memoria para a base de datos.
DS: E caben alí 50 copias?
НС: Polo tanto, só hai unha copia, entón a copia en escritura (ZFS) funciona... Vouche contar con máis detalle.
Por exemplo, temos unha base de datos de 10 TB. Fixeron un disco para el, ZFS tamén comprimiu o seu tamaño nun 30-40 por cento. Dado que non facemos probas de carga, o tempo de resposta exacto non é importante para nós: deixe que sexa ata 2 veces máis lento. Está ben.
Damos a oportunidade a programadores, QA, DBA, etc. realizar probas en 1-2 fíos. Por exemplo, poden realizar algún tipo de migración. Non require 10 núcleos á vez; necesita 1 backend de Postgres, 1 núcleo. A migración comezará, quizais aínda comezará, entón utilizarase o segundo núcleo. Temos 16-32 núcleos asignados, polo que 10 persoas poden traballar ao mesmo tempo, sen problema.
Porque fisicamente PGDATA o mesmo, resulta que en realidade estamos a enganar a Postgres. O truco é este: por exemplo, lánzanse 10 Postgres á vez. Cal é o problema habitualmente? Puxeron , digamos un 25%. En consecuencia, isto é de 200 GB. Non poderás lanzar máis de tres destes, porque a memoria esgotarase.
Pero nalgún momento démonos conta de que isto non era necesario: establecemos shared_buffers en 2 GB. PostgreSQL ten , e en realidade é o único que inflúe . Fixémolo en 0,5 TB. E nin sequera importa que en realidade non existan: fai plans coma se existisen.
En consecuencia, cando probamos algún tipo de migración, podemos recoller todos os plans; veremos como ocorrerá na produción. Os segundos alí serán diferentes (máis lentos), pero os datos que realmente lemos e os propios plans (que JOIN hai, etc.) resultan exactamente igual que na produción. E pode executar moitas comprobacións deste tipo en paralelo nunha máquina.
DS: Non cres que hai algúns problemas aquí? A primeira é unha solución que só funciona en PostgreSQL. Este enfoque é moi privado, non é xenérico. A segunda é que Kubernetes (e todo o que van as tecnoloxías na nube agora) implica moitos nodos, e estes nodos son efémeros. E no teu caso é un nodo persistente e con estado. Estas cousas póñenme en conflito.
НС: En primeiro lugar, estou de acordo, esta é unha historia puramente de Postgres. Creo que se temos algún tipo de E/S directa e un grupo de memoria intermedia para case toda a memoria, este enfoque non funcionará: os plans serán diferentes. Pero de momento só traballamos con Postgres, non pensamos noutros.
Sobre Kubernetes. Ti mesmo dinos en todas partes que temos unha base de datos persistente. Se a instancia falla, o principal é gardar o disco. Aquí tamén temos toda a plataforma en Kubernetes, e o compoñente con Postgres está separado (aínda que algún día estará alí). Polo tanto, todo é así: a instancia caeu, pero gardamos o seu PV e simplemente conectámolo a outra (nova) instancia, coma se nada pasase.
DS: Desde o meu punto de vista, creamos pods en Kubernetes. K8s - elástico: os nós son ordenados segundo sexa necesario. A tarefa é simplemente crear unha vaina e dicir que necesita X cantidade de recursos, e entón K8s descubrirao por si só. Pero o soporte de almacenamento en Kubernetes aínda é inestable: En (Este lanzamento foi lanzado semanas hai) estas funcións convértense só en versión beta.
Pasarán de seis meses a un ano: volverase máis ou menos estable, ou polo menos será declarado como tal. Entón, a posibilidade de facer instantáneas e cambiar o tamaño resolve o problema por completo. Porque tes unha base. Si, pode non ser moi rápido, pero a velocidade depende do que estea "baixo o capó", porque algunhas implementacións poden copiar e copiar e escribir a nivel do subsistema do disco.
НС: Tamén é necesario que todos os motores (Amazon, Google...) comecen a admitir esta versión; isto tamén leva algún tempo.
DS: Aínda non os usamos. Usamos o noso.
Desenvolvemento local para Kubernetes
НС: Atopáchesche con tal desexo cando necesitas instalar todas as vainas nunha máquina e facer unha proba tan pequena. Para obter rapidamente unha proba de concepto, mira que a aplicación se executa en Kubernetes, sen dedicarlle un montón de máquinas. Aí está Minikube, non?
DS: Paréceme que este caso - despregado nun nodo - trata exclusivamente de desenvolvemento local. Ou algunhas manifestacións de tal patrón. Comer , hai , . Estamos avanzando cara ao uso de Kubernetes IN Docker. Agora comezamos a traballar con el para probas.
НС: Antes pensaba que se trataba dun intento de envolver todos os pods nunha soa imaxe de Docker. Pero resultou que se trata de algo completamente diferente. De todos os xeitos, hai contedores separados, pods separados, só en Docker.
DS: Si. E hai unha imitación bastante divertida, pero o significado é este... Temos unha utilidade para o despregue - . Queremos que sexa un modo condicional werf up: "Consígueme Kubernetes local." E despois executa o condicional alí werf follow. A continuación, o programador poderá editar o IDE e iniciarase un proceso no sistema que ve os cambios e reconstruí as imaxes, redistribuíndoas aos K8 locais. Así queremos tratar de solucionar o problema do desenvolvemento local.
Instantáneas e clonación de bases de datos na realidade K8s
НС: Se volvemos ao copy-on-write. Notei que as nubes tamén teñen instantáneas. Funcionan de forma diferente. Por exemplo, en GCP: tes unha instancia de varios terabytes na costa leste dos Estados Unidos. Tomas instantáneas periódicamente. Colles unha copia do disco na costa oeste dunha instantánea: nuns minutos todo está listo, funciona moi rápido, só hai que encher a caché na memoria. Pero estes clons (instantáneas) son para "proporcionar" un novo volume. Isto é xenial cando necesitas crear moitas instancias.
Pero para probas, paréceme que as instantáneas, das que falas en Docker ou das que falo en ZFS, btrfs e mesmo LVM..., permiten non crear datos realmente novos nunha máquina. Na nube, seguirás pagando por eles cada vez e esperarás non segundos, senón minutos (e no caso , posiblemente un reloxo).
Pola contra, podes obter estes datos nun ou dous segundos, realizar a proba e tiralos. Estas instantáneas resolven diferentes problemas. No primeiro caso - para ampliar e obter novas réplicas, e no segundo - para probas.
DS: Non estou de acordo. Facer que a clonación de volumes funcione correctamente é tarefa da nube. Non mirei a súa implementación, pero sei como o facemos no hardware. Temos Ceph, permite calquera volume físico () dicir clonar e obtén un segundo volume coas mesmas características en decenas de milisegundos, 'ami, etc. Debes entender que hai unha copia en escritura complicada dentro. Por que a nube non debería facer o mesmo? Estou seguro de que están intentando facelo dun xeito ou doutro.
НС: Pero aínda lles levará segundos, decenas de segundos en levantar unha instancia, levar a Docker alí, etc.
DS: Por que é necesario levantar unha instancia enteira? Temos unha instancia con 32 núcleos, 16... e pode caber nela, por exemplo, catro. Cando pedimos a quinta, a instancia xa se levantará, e logo borrarase.
НС: Si, interesante, Kubernetes resulta ser unha historia diferente. A nosa base de datos non está en K8s e temos unha instancia. Pero clonar unha base de datos de varios terabytes non leva máis de dous segundos.
DS: Isto é xenial. Pero o meu punto inicial é que esta non é unha solución xenérica. Si, é xenial, pero só é adecuado para Postgres e só nun nodo.
НС: É adecuado non só para Postgres: estes plans, como describín, só funcionarán nel. Pero se non nos preocupamos polos plans e só necesitamos todos os datos para probas funcionais, entón é adecuado para calquera DBMS.
DS: Hai moitos anos fixemos algo semellante nas instantáneas de LVM. Este é un clásico. Este enfoque utilizouse moi activamente. Os nodos con estado son só unha dor. Porque non debes soltalos, debes lembralos sempre...
НС: Ves algunha posibilidade dun híbrido aquí? Digamos que o estado é unha especie de pod, que funciona para varias persoas (moitos probadores). Temos un volume, pero grazas ao sistema de ficheiros, os clons son locais. Se a cápsula cae, pero o disco permanece, a cápsula levantarase, contará a información sobre todos os clons, recollerá todo de novo e dirá: "Aquí están os teus clons que se executan nestes portos, continúa traballando con eles".
DS: Tecnicamente isto significa que dentro de Kubernetes é un pod no que executamos moitos Postgres.
НС: Si. Ten un límite: digamos que non traballan máis de 10 persoas con el ao mesmo tempo. Se necesitas 20, lanzaremos unha segunda cápsula deste tipo. Clonarémolo completamente, despois de recibir o segundo volume completo, terá os mesmos 10 clons "finos". Non ves esta oportunidade?
DS: Necesitamos engadir aquí problemas de seguridade. Este tipo de organizacións implica que este pod ten altos privilexios (capacidades), porque pode realizar operacións non estándar no sistema de ficheiros... Pero repito: creo que a medio prazo arranxarán o almacenamento en Kubernetes, e en as nubes arranxarán toda a historia con volumes: todo "só funcionará". Haberá redimensionamento, clonación... Hai un volume - dicimos: "Crear un novo a partir diso", e despois de segundo e medio conseguimos o que necesitamos.
НС: Non creo nun segundo e medio para moitos terabytes. En Ceph faino ti mesmo, pero falas das nubes. Vaia á nube, fai un clon dun volume EBS de varios terabytes en EC2 e mira cal será o rendemento. Non tardará uns segundos. Estou moi interesado en cando chegarán a este nivel. Entendo o que estás dicindo, pero suplico que discrepo.
DS: Ok, pero dixen a medio prazo, non a curto prazo. Durante varios anos.
Sobre o operador para PostgreSQL de Zalando
No medio desta reunión, Alexey Klyukin, un antigo desenvolvedor de Zalando, tamén se uniu e falou sobre a historia do operador PostgreSQL:
É xenial que se toque este tema en xeral: tanto Postgres como Kubernetes. Cando comezamos a facelo en Zalando en 2017, era un tema que todos querían facer, pero ninguén. Todo o mundo xa tiña Kubernetes, pero cando lle preguntaron que facer coas bases de datos, incluso á xente gústalle , que predicaba K8s, dixo algo así:
"Vaia aos servizos xestionados e utilízaos, non executes a base de datos en Kubernetes. En caso contrario, o teu K8 decidirá, por exemplo, facer unha actualización, desactivar todos os nodos e os teus datos voarán moi, moi lonxe.
Decidimos facer un operador que, en contra deste consello, lanzará unha base de datos Postgres en Kubernetes. E tiñamos unha boa razón... . Este é un failover automático para PostgreSQL, feito correctamente, é dicir. usando etcd, consul ou ZooKeeper como almacenamento de información sobre o clúster. Ese repositorio que dará a todos os que pregunten, por exemplo, cal é o actual líder, a mesma información -a pesar de que temos todo repartido- para que non haxa o cerebro dividido. Ademais tiñamos para él.
En xeral, a necesidade da empresa de falla automática apareceu despois de migrar desde un centro de datos de hardware interno á nube. A nube baseouse nunha solución propietaria PaaS (Platform-as-a-Service). É de código aberto, pero fixo falta moito traballo para poñelo en marcha. Chamábase .
Inicialmente, non había Kubernetes. Máis precisamente, cando se implantou a nosa propia solución, os K8 xa existían, pero eran tan toscos que non eran aptos para a produción. Foi, na miña opinión, 2015 ou 2016. En 2017, Kubernetes estaba máis ou menos maduro; había que migrar alí.
E xa tiñamos un contedor Docker. Había un PaaS que usaba Docker. Por que non probar os K8? Por que non escribes o teu propio operador? Murat Kabilov, que chegou a nós dende Avito, comezou isto como un proxecto por iniciativa propia - "xogar" - e o proxecto "despegou".
Pero, en xeral, quería falar de AWS. Por que houbo código histórico relacionado con AWS...
Cando executas algo en Kubernetes, debes entender que K8s é un traballo en curso. Está en constante desenvolvemento, mellora e incluso descompoñendo de cando en vez. Debes estar atento a todos os cambios en Kubernetes, debes estar preparado para mergullar nel se ocorre algo e aprender como funciona en detalle, quizais máis do que che gustaría. Isto, en principio, aplícase a calquera plataforma na que executes as túas bases de datos...
Entón, cando fixemos a declaración, tiñamos Postgres en execución nun volume externo (EBS neste caso, xa que estabamos traballando en AWS). A base de datos medrou, nalgún momento foi necesario redimensionala: por exemplo, o tamaño inicial de EBS era de 100 TB, a base de datos medrou ata el, agora queremos facer EBS 200 TB. Como? Digamos que podes facer un volcado/restauración nunha nova instancia, pero isto levará moito tempo e implicará tempo de inactividade.
Polo tanto, quería un cambio de tamaño que ampliase a partición EBS e que logo indicase ao sistema de ficheiros que use o novo espazo. E fixémolo, pero nese momento Kubernetes non tiña ningunha API para a operación de cambio de tamaño. Xa que traballamos en AWS, escribimos código para a súa API.
Ninguén che impide facer o mesmo para outras plataformas. Non hai ningunha pista na declaración de que só se pode executar en AWS e non funcionará en todo o demais. En xeral, trátase dun proxecto de código aberto: se alguén quere acelerar a aparición do uso da nova API, benvido. Comer , solicitudes de extracción: o equipo de Zalando trata de responderlles con bastante rapidez e promocionar o operador. Polo que sei, o proxecto en Google Summer of Code e outras iniciativas similares. Zalando está a traballar moi activamente niso.
Bonificación PS!
Se estás interesado no tema de PostgreSQL e Kubernetes, ten en conta que o próximo martes de Postgres tivo lugar a semana pasada, onde falei con Nikolai Alexander Kukushkin de Zalando. O vídeo está dispoñible .
PPS
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com