No final do ano passado, ocorreu outra transmissão ao vivo da comunidade russa PostgreSQL , durante o qual seu cofundador Nikolai Samokhvalov conversou com o diretor técnico da Flant, Dmitry Stolyarov, sobre este SGBD no contexto do Kubernetes.
Estamos publicando uma transcrição da parte principal desta discussão, e em Vídeo completo postado:
Bancos de dados e Kubernetes
NS: Não falaremos sobre VACUUM e CHECKPOINTs hoje. Queremos falar sobre Kubernetes. Eu sei que você tem muitos anos de experiência. Assisti seus vídeos e até assisti novamente alguns deles... Vamos direto ao ponto: por que Postgres ou MySQL no K8s?
DS: Não há e não pode haver uma resposta definitiva para esta pergunta. Mas, em geral, isso é simplicidade e conveniência... potencial. Todo mundo quer serviços gerenciados.
NS: Para como , só em casa?
DS: Sim: como RDS, em qualquer lugar.
NS: “Em qualquer lugar” é um bom ponto. Nas grandes empresas, tudo está localizado em locais diferentes. Por que então, se é uma empresa grande, não pegar uma solução pronta? Por exemplo, a Nutanix tem desenvolvimentos próprios, outras empresas (VMware...) têm o mesmo “RDS, só em casa”.
DS: Mas estamos falando de uma implementação separada que só funcionará sob certas condições. E se estamos falando de Kubernetes, então há uma enorme variedade de infraestrutura (que pode estar em K8s). Essencialmente, este é um padrão para APIs para a nuvem...
NS: Também é grátis!
DS: Não é tão importante. A liberdade é importante para um segmento não muito grande do mercado. Outra coisa é importante... Você provavelmente se lembra do relatório “"?
NS: Sim
DS: Percebi que foi recebido de forma muito ambígua. Algumas pessoas pensaram que eu estava dizendo: “Pessoal, vamos colocar todos os bancos de dados no Kubernetes!”, enquanto outros decidiram que todas essas bicicletas eram terríveis. Mas queria dizer algo completamente diferente: “Vejam o que está a acontecer, que problemas existem e como podem ser resolvidos. Devemos usar bancos de dados Kubernetes agora? Produção? Bem, só se você gosta de... fazer certas coisas. Mas para um desenvolvedor, posso dizer que recomendo. Para um dev, o dinamismo de criar/excluir ambientes é muito importante.”
NS: Por dev, você quer dizer todos os ambientes que não são prod? Preparação, controle de qualidade…
DS: Se estamos falando de estandes de desempenho, provavelmente não, porque os requisitos são específicos. Se estamos falando de casos especiais em que um banco de dados muito grande é necessário para teste, então provavelmente não... Se este for um ambiente estático e de longa duração, qual é a vantagem de ter o banco de dados localizado no K8s?
NS: Nenhum. Mas onde vemos ambientes estáticos? Um ambiente estático se tornará obsoleto amanhã.
DS: a preparação pode ser estática. Temos clientes...
NS: Sim, eu também tenho um. É um grande problema se você tiver um banco de dados de 10 TB e um teste de 200 GB...
DS: Eu tenho um caso muito legal! Na preparação, há um banco de dados de produtos no qual são feitas alterações. E há um botão: “lançar para produção”. Essas alterações - deltas - são adicionadas (parece que são simplesmente sincronizadas via API) na produção. Esta é uma opção muito exótica.
NS: Já vi startups no Vale que estão no RDS ou mesmo no Heroku - são histórias de 2 a 3 anos atrás - e baixam o dump para seus laptops. Porque o banco de dados ainda tem apenas 80 GB e há espaço no laptop. Depois compram discos adicionais para todos para que tenham 3 bases de dados para realizar diferentes desenvolvimentos. É assim que acontece também. Também vi que eles não têm medo de copiar o produto para a preparação - depende muito da empresa. Mas também vi que eles têm muito medo e que muitas vezes não têm tempo e mãos suficientes. Mas antes de passarmos a este tópico, gostaria de ouvir sobre o Kubernetes. Eu entendi corretamente que ninguém está em produção ainda?
DS: Temos pequenos bancos de dados em produção. Estamos falando de volumes de dezenas de gigabytes e serviços não críticos para os quais tivemos preguiça de fazer réplicas (e não existe essa necessidade). E desde que haja armazenamento normal no Kubernetes. Esse banco de dados funcionava em uma máquina virtual - condicionalmente em VMware, em cima do sistema de armazenamento. Nós o colocamos em e agora podemos transferi-lo de máquina para máquina.
NS: Bancos de dados desse tamanho, de até 100 GB, podem ser implementados em poucos minutos em bons discos e em uma boa rede, certo? Uma velocidade de 1 GB por segundo não é mais exótica.
DS: Sim, para operação linear isso não é um problema.
NS: Ok, só temos que pensar em produção. E se estivermos considerando o Kubernetes para ambientes que não sejam de produção, o que devemos fazer? Eu vejo isso em Zalando , em Crocante , existem algumas outras opções. E aqui está - este é o nosso bom amigo Álvaro, de Espanha: o que eles fazem essencialmente não é apenas , e toda a distribuição (), no qual, além do próprio Postgres, também decidiram colocar um backup, o proxy Envoy...
DS: Enviado para quê? Equilibrando especificamente o tráfego do Postgres?
NS: Sim. Ou seja, eles veem isso como: se você pegar uma distribuição e um kernel Linux, então o PostgreSQL normal é o kernel, e eles querem fazer uma distribuição que seja compatível com a nuvem e rode no Kubernetes. Eles reúnem componentes (backups, etc.) e os depuram para que funcionem bem.
DS: Muito legal! Essencialmente, este é um software para criar seu próprio Postgres gerenciado.
NS: As distribuições Linux têm problemas eternos: como fazer drivers para que todo o hardware seja suportado. E eles têm a ideia de que trabalharão no Kubernetes. Eu sei que na operadora Zalando vimos recentemente uma conexão com AWS e isso não é mais muito bom. Não deveria haver vínculo com uma infraestrutura específica – qual é o sentido então?
DS: Não sei exatamente em que situação o Zalando se meteu, mas no Kubernetes o armazenamento agora é feito de tal forma que é impossível fazer backup do disco usando um método genérico. Recentemente no padrão - na versão mais recente - tornamos possíveis instantâneos, mas onde eles são implementados? Sinceramente, ainda está tudo tão cru... Estamos testando CSI em cima de AWS, GCE, Azure, vSphere, mas assim que você começar a usar, verá que ainda não está pronto.
NS: É por isso que às vezes temos que depender de infraestrutura. Acho que este ainda é um estágio inicial – dores de crescimento. Pergunta: Que conselho você daria aos novatos que desejam experimentar o PgSQL no K8s? Que operadora talvez?
DS: O problema é que o Postgres é 3% para nós. Também temos uma lista muito grande de softwares diferentes no Kubernetes, nem vou listar tudo. Por exemplo, Elasticsearch. Existem muitos operadores: alguns estão em desenvolvimento ativo, outros não. Elaboramos para nós próprios requisitos, o que deve constar da operadora, para que levemos isso a sério. Em uma operadora específica para Kubernetes - não em uma “operadora para fazer algo nas condições da Amazon”... Na verdade, usamos amplamente (= quase todos os clientes) um único operador - (publicaremos um artigo sobre ele em breve).
NS: E também não para MySQL? Eu sei que Percona... como agora eles estão trabalhando em MySQL, MongoDB e Postgres, eles terão que criar algum tipo de solução universal: para todos os bancos de dados, para todos os provedores de nuvem.
DS: Não tivemos tempo de examinar os operadores do MySQL. Este não é o nosso foco principal neste momento. MySQL funciona bem de forma independente. Por que usar um operador se você pode simplesmente iniciar um banco de dados... Você pode iniciar um contêiner Docker com Postrges ou pode iniciá-lo de forma simples.
NS: Houve uma pergunta sobre isso também. Nenhuma operadora?
DS: Sim, 100% de nós temos o PostgreSQL rodando sem operador. Até agora. Usamos ativamente o operador para Prometheus e Redis. Temos planos de encontrar um operador para Elasticsearch - é o que está mais “pegando fogo”, pois queremos instalá-lo no Kubernetes em 100% dos casos. Assim como queremos garantir que o MongoDB também esteja sempre instalado no Kubernetes. Aqui aparecem certos desejos - há uma sensação de que nestes casos algo pode ser feito. E nem olhamos para o Postgres. Claro, sabemos que existem diferentes opções, mas na verdade temos uma autônoma.
Banco de dados para teste em Kubernetes
NS: Vamos passar para o tópico de testes. Como implementar alterações no banco de dados – do ponto de vista do DevOps. Existem microsserviços, muitos bancos de dados, algo está mudando em algum lugar o tempo todo. Como garantir CI/CD normal para que tudo esteja em ordem do ponto de vista do SGBD. Qual é a sua abordagem?
DS: Não pode haver uma resposta. Existem várias opções. O primeiro é o tamanho da base que queremos estender. Você mesmo mencionou que as empresas têm atitudes diferentes em relação a ter uma cópia do banco de dados de produção no desenvolvimento e no palco.
NS: E nas condições do GDPR, acho que estão sendo cada vez mais cuidadosos... Posso dizer que na Europa já começaram a aplicar multas.
DS: Mas muitas vezes você pode escrever software que descarta a produção e a ofusca. Os dados do produto são obtidos (instantâneo, despejo, cópia binária...), mas são anonimizados. Em vez disso, pode haver scripts de geração: podem ser fixtures ou apenas um script que gera um grande banco de dados. O problema é: quanto tempo leva para criar uma imagem base? E quanto tempo leva para implantá-lo no ambiente desejado?
Chegamos a um esquema: se o cliente possui um conjunto de dados fixo (versão mínima do banco de dados), então os usamos por padrão. Se estamos falando de ambientes de revisão, quando criamos uma filial, implantamos uma instância do aplicativo - implementamos um pequeno banco de dados lá. Mas acabou bem , quando fazemos um dump da produção uma vez por dia (à noite) e construímos um contêiner Docker com PostgreSQL e MySQL com esses dados carregados com base nele. Se você precisar expandir o banco de dados 50 vezes a partir desta imagem, isso será feito de forma simples e rápida.
NS: Por simples cópia?
DS: os dados são armazenados diretamente na imagem Docker. Aqueles. Temos uma imagem pronta, ainda que com 100 GB. Graças às camadas do Docker, podemos implantar essa imagem rapidamente quantas vezes precisarmos. O método é estúpido, mas funciona bem.
NS: Aí, quando você testa, ele muda dentro do Docker, certo? Copy-on-write dentro do Docker - jogue fora e vá de novo, está tudo bem. Aula! E você já está aproveitando ao máximo?
DS: Por muito tempo.
NS: Fazemos coisas muito semelhantes. Só que não usamos o copy-on-write do Docker, mas sim algum outro.
DS: Não é genérico. E o Docker funciona em qualquer lugar.
NS: Em teoria, sim. Mas também temos módulos lá, você pode fazer módulos diferentes e trabalhar com sistemas de arquivos diferentes. Que momento aqui. Do lado do Postgres, vemos tudo isso de forma diferente. Agora olhei do lado do Docker e vi que tudo funciona para você. Mas se o banco de dados for enorme, por exemplo, 1 TB, então tudo isso leva muito tempo: operações à noite e colocar tudo no Docker... E se 5 TB forem colocados no Docker... Ou está tudo bem?
DS: Qual é a diferença: são blobs, apenas bits e bytes.
NS: A diferença é esta: você faz isso através de dump e restauração?
DS: Não é de todo necessário. Os métodos para gerar esta imagem podem ser diferentes.
NS: Para alguns clientes, fizemos com que, em vez de gerar regularmente uma imagem base, a mantivéssemos constantemente atualizada. É essencialmente uma réplica, mas recebe dados não diretamente do mestre, mas através de um arquivo. Um arquivo binário onde os WALs são baixados todos os dias, onde os backups são feitos... Esses WALs alcançam a imagem base com um pequeno atraso (literalmente 1-2 segundos). Nós clonamos de qualquer maneira - agora temos o ZFS por padrão.
DS: Mas com o ZFS você está limitado a um nó.
NS: Sim. Mas o ZFS também tem um recurso mágico : com ele você pode enviar um snapshot e até (ainda não testei isso, mas...) você pode enviar um delta entre dois PGDATA. Na verdade, temos outra ferramenta que não consideramos para tais tarefas. PostgreSQL tem , que funciona como um rsync “inteligente”, pulando muita coisa que você não precisa assistir, porque nada mudou ali. Podemos fazer uma sincronização rápida entre os dois servidores e retroceder da mesma forma.
Então, desse lado, mais DBA, estamos tentando criar uma ferramenta que nos permita fazer a mesma coisa que você falou: temos um banco de dados, mas queremos testar algo 50 vezes, quase simultaneamente.
DS: 50 vezes significa que você precisa solicitar 50 instâncias Spot.
NS: Não, fazemos tudo em uma máquina.
DS: Mas como você expandirá 50 vezes se esse banco de dados tiver, digamos, terabyte? Provavelmente ela precisa de 256 GB de RAM condicionais?
NS: Sim, às vezes você precisa de muita memória - isso é normal. Mas este é um exemplo de vida. A máquina de produção possui 96 núcleos e 600 GB. Ao mesmo tempo, 32 núcleos (às vezes até 16 núcleos) e 100-120 GB de memória são usados para o banco de dados.
DS: E cabem 50 cópias aí?
NS: Portanto, há apenas uma cópia, então copy-on-write (ZFS) funciona... Vou contar com mais detalhes.
Por exemplo, temos um banco de dados de 10 TB. Eles fizeram um disco para ele, o ZFS também comprimiu seu tamanho em 30-40 por cento. Como não fazemos testes de carga, o tempo exato de resposta não é importante para nós: deixe ser até 2 vezes mais lento - tudo bem.
Damos oportunidade a programadores, QA, DBA, etc. execute testes em 1-2 threads. Por exemplo, eles podem realizar algum tipo de migração. Não requer 10 núcleos de uma vez - precisa de 1 backend Postgres, 1 núcleo. A migração começará - talvez ainda será iniciado, então o segundo núcleo será usado. Temos de 16 a 32 núcleos alocados, então 10 pessoas podem trabalhar ao mesmo tempo, sem problemas.
Porque fisicamente PGDATA da mesma forma, na verdade estamos enganando o Postgres. O truque é este: por exemplo, 10 Postgres são lançados simultaneamente. Qual é o problema geralmente? Eles põem , digamos 25%. Conseqüentemente, são 200 GB. Você não poderá lançar mais de três deles, porque a memória acabará.
Mas em algum momento percebemos que isso não era necessário: definimos shared_buffers para 2 GB. PostgreSQL tem , e na realidade é o único que influencia . Definimos para 0,5 TB. E nem importa que eles não existam de fato: ele faz planos como se existissem.
Assim, quando testarmos algum tipo de migração, poderemos coletar todos os planos - veremos como isso acontecerá na produção. Os segundos serão diferentes (mais lentos), mas os dados que realmente lemos e os próprios planos (quais JOINs existem, etc.) serão exatamente iguais aos da produção. E você pode executar muitas dessas verificações em paralelo em uma máquina.
DS: Você não acha que há alguns problemas aqui? A primeira é uma solução que só funciona no PostgreSQL. Esta abordagem é muito particular, não é genérica. A segunda é que o Kubernetes (e tudo o que as tecnologias de nuvem farão agora) envolve muitos nós, e esses nós são efêmeros. E no seu caso, é um nó persistente e com estado. Essas coisas me deixam em conflito.
NS: Primeiro, concordo, esta é uma história puramente do Postgres. Acho que se tivermos algum tipo de IO direto e um buffer pool para quase toda a memória, essa abordagem não funcionará - os planos serão diferentes. Mas por enquanto só trabalhamos com Postgres, não pensamos nos outros.
Sobre o Kubernetes. Você mesmo nos diz em todos os lugares que temos um banco de dados persistente. Se a instância falhar, o principal é salvar o disco. Aqui também temos toda a plataforma em Kubernetes, e o componente com Postgres é separado (embora um dia esteja lá). Portanto, tudo é assim: a instância caiu, mas salvamos seu PV e simplesmente conectamos em outra (nova) instância, como se nada tivesse acontecido.
DS: Do meu ponto de vista, criamos pods no Kubernetes. K8s - elástico: os nós são ordenados conforme a necessidade. A tarefa é simplesmente criar um pod e dizer que ele precisa de uma quantidade X de recursos, e então o K8s descobrirá por conta própria. Mas o suporte de armazenamento no Kubernetes ainda é instável: Em (este lançamento foi lançado недели atrás) esses recursos se tornam apenas beta.
Passarão seis meses a um ano - ficará mais ou menos estável, ou pelo menos será declarado como tal. Então a possibilidade de instantâneos e redimensionamento resolve completamente o seu problema. Porque você tem uma base. Sim, pode não ser muito rápido, mas a velocidade depende do que está “nos bastidores”, porque algumas implementações podem copiar e copiar na gravação no nível do subsistema de disco.
NS: Também é necessário que todos os motores (Amazon, Google...) comecem a suportar esta versão - isso também leva algum tempo.
DS: Ainda não os usamos. Nós usamos o nosso.
Desenvolvimento local para Kubernetes
NS: Você já se deparou com esse desejo quando precisa instalar todos os pods em uma máquina e fazer um teste tão pequeno? Para obter rapidamente uma prova de conceito, veja se a aplicação roda em Kubernetes, sem dedicar muitas máquinas para isso. Tem o Minikube, certo?
DS: Parece-me que este caso - implantado em um nó - trata exclusivamente de desenvolvimento local. Ou algumas manifestações desse padrão. Comer Lá , . Estamos avançando no uso do Kubernetes IN Docker. Agora começamos a trabalhar com ele para testes.
NS: Eu costumava pensar que isso era uma tentativa de agrupar todos os pods em uma imagem do Docker. Mas descobriu-se que se trata de algo completamente diferente. De qualquer forma, existem contêineres e pods separados - apenas no Docker.
DS: Sim. E há uma imitação bastante engraçada, mas o significado é este... Temos um utilitário para implantação - . Queremos torná-lo um modo condicional werf up: “Consiga-me Kubernetes locais.” E então execute a condicional lá werf follow. Em seguida, o desenvolvedor poderá editar o IDE, e será lançado um processo no sistema que vê as alterações e reconstrói as imagens, reimplantando-as em K8s locais. É assim que queremos tentar resolver o problema do desenvolvimento local.
Instantâneos e clonagem de banco de dados na realidade do K8
NS: Se voltarmos à cópia na gravação. Percebi que as nuvens também têm instantâneos. Eles funcionam de maneira diferente. Por exemplo, no GCP: você tem uma instância de vários terabytes na costa leste dos Estados Unidos. Você tira instantâneos periodicamente. Você pega uma cópia do disco na costa oeste a partir de um instantâneo - em poucos minutos tudo está pronto, funciona muito rápido, apenas o cache precisa ser preenchido na memória. Mas esses clones (instantâneos) servem para 'provisionar' um novo volume. Isso é legal quando você precisa criar muitas instâncias.
Mas para testes, parece-me que os instantâneos, dos quais você fala no Docker ou eu falo no ZFS, btrfs e até LVM... - eles permitem que você não crie dados realmente novos em uma máquina. Na nuvem, você ainda pagará por eles sempre e não esperará segundos, mas minutos (e no caso , possivelmente um relógio).
Em vez disso, você pode obter esses dados em um ou dois segundos, executar o teste e jogá-los fora. Esses instantâneos resolvem problemas diferentes. No primeiro caso - para ampliar e obter novas réplicas, e no segundo - para testes.
DS: Eu não concordo. Fazer com que a clonagem de volume funcione corretamente é tarefa da nuvem. Não olhei para a implementação deles, mas sei como fazemos isso no hardware. Temos o Ceph, ele permite qualquer volume físico () dizer clonar e obter um segundo volume com as mesmas características em dezenas de milissegundos, 'ami, etc. Você precisa entender que existe uma cópia na gravação complicada. Por que a nuvem não deveria fazer o mesmo? Tenho certeza de que eles estão tentando fazer isso de uma forma ou de outra.
NS: Mas ainda levará segundos, dezenas de segundos para criar uma instância, trazer o Docker até lá, etc.
DS: Por que é necessário criar uma instância inteira? Temos uma instância com 32 núcleos, 16... e cabe nela - por exemplo, quatro. Quando encomendarmos o quinto, a instância já estará levantada e então será deletada.
NS: Sim, interessante, o Kubernetes acabou sendo uma história diferente. Nosso banco de dados não está em K8s e temos uma instância. Mas a clonagem de um banco de dados de vários terabytes não leva mais do que dois segundos.
DS: Isso é ótimo. Mas o meu ponto inicial é que esta não é uma solução genérica. Sim, é legal, mas só é adequado para Postgres e apenas em um nó.
NS: Não é adequado apenas para Postgres: esses planos, como descrevi, só funcionarão nele. Mas se não nos preocupamos com planos e só precisamos de todos os dados para testes funcionais, então isso é adequado para qualquer SGBD.
DS: Muitos anos atrás fizemos algo semelhante nos snapshots do LVM. Este é um clássico. Esta abordagem foi usada de forma muito ativa. Nós com estado são apenas uma dor. Porque você não deve abandoná-los, você deve sempre lembrá-los...
NS: Você vê alguma possibilidade de um híbrido aqui? Digamos que stateful seja algum tipo de pod, funciona para várias pessoas (muitos testadores). Temos um volume, mas graças ao sistema de arquivos, os clones são locais. Se o pod cair, mas o disco permanecer, o pod subirá, contará informações sobre todos os clones, pegará tudo novamente e dirá: “Aqui estão seus clones rodando nessas portas, continue trabalhando com eles”.
DS: Tecnicamente, isso significa que dentro do Kubernetes é um pod no qual executamos muitos Postgres.
NS: Sim. Ele tem um limite: digamos que no máximo 10 pessoas trabalhem com ele ao mesmo tempo. Se você precisar de 20, lançaremos um segundo pod. Vamos cloná-lo totalmente, tendo recebido o segundo volume completo, terá os mesmos 10 clones “finos”. Você não vê essa oportunidade?
DS: Precisamos adicionar questões de segurança aqui. Este tipo de organização implica que este pod tenha altos privilégios (capacidades), pois pode realizar operações não padrão no sistema de arquivos... Mas repito: acredito que a médio prazo eles vão consertar o armazenamento no Kubernetes, e em as nuvens eles vão consertar toda a história com volumes - tudo vai “simplesmente funcionar”. Haverá redimensionamento, clonagem... Existe um volume - dizemos: “Crie um novo baseado nisso”, e depois de um segundo e meio conseguimos o que precisamos.
NS: Não acredito em um segundo e meio para muitos terabytes. No Ceph você faz isso sozinho, mas fala sobre as nuvens. Vá para a nuvem, faça um clone de um volume EBS multi-terabyte no EC2 e veja qual será o desempenho. Não demorará alguns segundos. Estou muito interessado em saber quando eles chegarão a esse nível. Entendo o que você está dizendo, mas discordo.
DS: Ok, mas eu disse no médio prazo, não no curto prazo. Por muitos anos.
Sobre o operador PostgreSQL da Zalando
No meio desta reunião, Alexey Klyukin, ex-desenvolvedor da Zalando, também participou e falou sobre a história do operador PostgreSQL:
É ótimo que este tópico seja abordado em geral: tanto Postgres quanto Kubernetes. Quando começamos a fazer na Zalando em 2017, era um tema que todos queriam fazer, mas ninguém fez. Todo mundo já tinha Kubernetes, mas quando perguntaram o que fazer com os bancos de dados, até as pessoas gostam , que pregou K8s, disse algo assim:
“Vá para serviços gerenciados e use-os, não execute o banco de dados no Kubernetes. Caso contrário, seus K8s decidirão, por exemplo, fazer uma atualização, desligar todos os nós e seus dados voarão para muito, muito longe.”
Decidimos fazer um operador que, contrariando este conselho, lançará um banco de dados Postgres no Kubernetes. E tivemos um bom motivo - . Este é um failover automático para PostgreSQL, feito corretamente, ou seja, usando etcd, consul ou ZooKeeper como armazenamento de informações sobre o cluster. Um repositório que dará a todos que perguntarem, por exemplo, qual é o atual líder, a mesma informação - apesar de termos tudo distribuído - para que não haja divisão cerebral. Além disso, tivemos para ele.
Em geral, a necessidade de failover automático da empresa surgiu após a migração de um data center de hardware interno para a nuvem. A nuvem foi baseada em uma solução proprietária PaaS (Platform-as-a-Service). É Open Source, mas deu muito trabalho para colocá-lo em funcionamento. Era Chamado .
Inicialmente, não existia Kubernetes. Mais precisamente, quando a nossa própria solução foi implementada, os K8s já existiam, mas eram tão rudimentares que não eram adequados para produção. Foi, na minha opinião, 2015 ou 2016. Em 2017, o Kubernetes havia se tornado mais ou menos maduro – havia necessidade de migrar para lá.
E já tínhamos um contêiner Docker. Havia um PaaS que usava Docker. Por que não experimentar o K8s? Por que não escrever seu próprio operador? Murat Kabilov, que veio de Avito até nós, começou este projeto por sua própria iniciativa - “brincar” - e o projeto “decolou”.
Mas, em geral, eu queria falar sobre AWS. Por que havia código histórico relacionado à AWS...
Ao executar algo no Kubernetes, você precisa entender que o K8s é um trabalho em andamento. Ele está em constante desenvolvimento, melhorando e até quebrando de tempos em tempos. Você precisa ficar de olho em todas as mudanças no Kubernetes, estar pronto para mergulhar nele se algo acontecer e aprender como funciona em detalhes - talvez mais do que você gostaria. Isso, em princípio, se aplica a qualquer plataforma na qual você executa seus bancos de dados...
Então, quando fizemos a declaração, tínhamos o Postgres rodando em um volume externo (EBS neste caso, já que estávamos trabalhando na AWS). O banco de dados cresceu, em algum momento foi necessário redimensioná-lo: por exemplo, o tamanho inicial do EBS era 100 TB, o banco de dados cresceu até isso, agora queremos fazer o EBS 200 TB. Como? Digamos que você possa fazer um despejo/restauração em uma nova instância, mas isso levará muito tempo e envolverá tempo de inatividade.
Portanto, eu queria um redimensionamento que aumentasse a partição EBS e então informasse ao sistema de arquivos para usar o novo espaço. E conseguimos, mas naquela época o Kubernetes não tinha nenhuma API para a operação de redimensionamento. Como trabalhamos na AWS, escrevemos código para sua API.
Ninguém está impedindo você de fazer o mesmo com outras plataformas. Não há nenhuma indicação na declaração de que ele só pode ser executado na AWS e não funcionará em todo o resto. Em geral, este é um projeto Open Source: se alguém quiser acelerar o surgimento do uso da nova API, seja bem-vindo. Comer , solicitações pull - a equipe Zalando tenta respondê-las com bastante rapidez e promover a operadora. Pelo que eu saiba, o projeto no Google Summer of Code e algumas outras iniciativas semelhantes. Zalando está trabalhando ativamente nisso.
PS Bônus!
Se você está interessado no tópico PostgreSQL e Kubernetes, observe também que a próxima terça-feira do Postgres aconteceu na semana passada, onde conversei com Nikolai Alexander Kukushkin de Zalando. O vídeo dele está disponível .
PPS
Leia também em nosso blog:
- «";
- «";
- «";
- «".
Fonte: habr.com