Planeje suas implantações de banco de dados no GKE

Nesta página, você verá as práticas recomendadas para executar bancos de dados em contêineres no GKE. Use uma Implantação para criar um conjunto de instâncias de banco de dados conteinerizado gerenciado pelo Kubernetes. Em seguida, você cria um Service para fornecer acesso ao banco de dados, independentemente de qualquer pod específico. O serviço permanece inalterado, mesmo que o pod seja movido para um nó diferente.

Para acessar os dados na instância do banco de dados, crie um recurso PersistentVolumeClaim (PVC) e o disponibilize para a carga de trabalho.

Os bancos de dados dependem muito dos discos locais para manter a persistência. Um banco de dados executado como serviço em um cluster do Kubernetes e os arquivos dele em um PersistentVolumeClaim estão vinculados ao ciclo de vida do cluster. Se o cluster for excluído, o banco de dados também será excluído.

Ao criar ou implantar um aplicativo com estado em execução no GKE, use uma das seguintes opções de implantação para instâncias de banco de dados:

  • Bancos de dados totalmente gerenciados: um banco de dados gerenciado, como o Cloud SQL ou o Spanner, reduz a sobrecarga operacional e é otimizado para a infraestrutura do Google Cloud. Os bancos de dados gerenciados exigem menos esforço de manutenção e operação do que um banco de dados que você implanta diretamente no Kubernetes.
  • Aplicativo do Kubernetes: é possível implantar e executar uma instância de banco de dados (como o MySQL ou o PostgreSQL) em um cluster do GKE.

Considerações sobre implantações de banco de dados no GKE

Cada uma das opções anteriores tem vantagens e desvantagens, dependendo das suas metas e restrições de negócios. Use a tabela a seguir para decidir se a implantação de banco de dados no GKE é a escolha certa para você.

Consideração Descrição
Independência do banco de dados O ciclo de vida de um PersistentVolumeClaim é vinculado ao cluster do GKE correspondente. Se você não quiser que o ciclo de vida do banco de dados dependa de um cluster específico do GKE, considere manter o banco de dados separado, como um banco de dados gerenciado ou em uma instância de VM.
Como escalonar com o GKE

Escalonamento vertical: é possível configurar as solicitações de pods para escalonar automaticamente. No entanto, é preciso garantir que seu aplicativo de banco de dados possa suportar as interrupções quando seus pods forem escalonados verticalmente com o escalonamento automático vertical de pods.

Escalonamento horizontal: é possível que o banco de dados consiga ler ou gravar horizontalmente adicionando réplicas. A compatibilidade com o escalonamento horizontal depende do fato de ele ter uma única arquitetura de gravador ou de vários gravadores. Para usar o escalonamento horizontal, talvez seja necessário atualizar a configuração do banco de dados, além de aumentar o número de réplicas.
Sobrecarga do GKE

Nos clusters do Autopilot, você não é cobrado pelas reservas de recursos, apenas pelas solicitações de recursos.

Em clusters padrão, o GKE reserva recursos para as próprias operações. Bancos de dados em clusters padrão não são escalonados automaticamente. Portanto, a sobrecarga pode ser alta em pods pequenos.
Número de instâncias do banco de dados No contexto do Kubernetes, cada instância de banco de dados é executada no próprio pod e tem o próprio PersistentVolumeClaim. Se você tiver um grande número de instâncias, terá que operar e gerenciar um grande conjunto de pods, nós e reivindicações de volume. Em vez disso, recomendamos usar um banco de dados gerenciado.
Backup de banco de dados no GKE

O escopo de um PersistentVolumeClaim é um cluster do GKE. Isso significa que, quando um cluster do GKE é excluído, a declaração de volume é excluída. Todos os arquivos de banco de dados no cluster também são excluídos. Para se proteger contra a perda acidental de arquivos do banco de dados, recomendamos a replicação ou o backup frequente.

É possível usar o Backup para GKE para criar snapshots da configuração do aplicativo e dados de volume em intervalos periódicos. O Backup para GKE lida com a programação de backups de volume, gerenciando o ciclo de vida do backup e restaurando backups em um cluster.

Comportamento de recuperação específico do Kubernetes Quando um pod falha no Kubernetes, ele é recriado. Do ponto de vista da instância do banco de dados, isso significa que, quando um pod é recriado, qualquer configuração que não seja permanente em um banco de dados ou no armazenamento estável fora dos pods também será recriada.
Arquitetura do banco de dados Se o banco de dados estiver configurado para usar uma arquitetura ativa-passiva, será necessário garantir que apenas uma réplica seja configurada como primária. Muitos bancos de dados relacionais têm uma opção para failover ativo-passivo, em que uma secundária pode ser promovida para principal em caso de falha primária.
Migração de banco de dados Se você planeja migrar o sistema de banco de dados atual para o GKE, consulte Migração de banco de dados: conceitos e princípios (parte 1) e Migração de banco de dados: Conceitos e princípios (parte 2).
Novo treinamento do usuário Novo treinamento: se você passar de uma implantação autogerenciada ou gerenciada por um provedor para uma implantação de banco de dados do Kubernetes, precisará treinar novamente os administradores do banco de dados (DBAs) para operar no novo no ambiente com a mesma confiança que operam no ambiente atual. Os desenvolvedores de aplicativos também podem ter que aprender sobre diferenças em uma extensão menor.

A lista anterior fornece uma discussão sobre algumas das considerações para a implantação do banco de dados. No entanto, a lista não inclui todas as considerações possíveis. Também é preciso considerar a recuperação de desastres, o pool de conexões e o monitoramento.

A seguir