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

Esta página explica as práticas recomendadas para executar bancos de dados em contêineres no GKE. É possível usar uma implantação para criar um conjunto de instâncias de banco de dados conteinerizadas gerenciadas pelo Kubernetes. Em seguida, crie um serviço para fornecer acesso ao banco de dados independentemente de qualquer pod específico. O serviço permanece inalterado mesmo se o pod for movido para um nó diferente.

Para acessar os dados na instância do banco de dados, crie um recurso PersistentVolumeClaim (PVC) e disponibilize-o 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 um serviço em um cluster do Kubernetes e os arquivos de banco de dados 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 compensações, considerando suas metas de negócios e restrições. 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 está 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, é necessário garantir que o aplicativo do banco de dados resista a interrupções quando os pods forem escalonados com o escalonamento automático vertical de pods.

Escalonamento horizontal: o banco de dados pode escalonar horizontalmente leituras ou gravações adicionando réplicas. A compatibilidade do seu banco de dados com a escala horizontal depende se ele tem uma arquitetura de um único escritor ou de vários escritores. Para usar a escala 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 por reservas de recursos, apenas por solicitações de recursos.

Em clusters padrão, o GKE reserva recursos para as próprias operações. Os bancos de dados em clusters padrão não são escalonados automaticamente. Portanto, a sobrecarga pode ser alta para 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. Talvez seja melhor usar um banco de dados gerenciado.
Backup de banco de dados no GKE

Um PersistentVolumeClaim tem como escopo 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 da perda acidental dos arquivos do banco de dados, recomendamos a replicação ou um backup frequente.

É possível usar o Backup para GKE para fazer snapshots da configuração do aplicativo e dos dados de volume em intervalos periódicos. O Backup para GKE processa a programação de backups de volume, gerencia o ciclo de vida do backup e restaura 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 de banco de dados Se o banco de dados estiver configurado para usar uma arquitetura ativa-passiva, verifique se apenas uma réplica está configurada como primária. Muitos bancos de dados relacionais têm uma opção de failover ativo-passivo, em que um secundário pode ser promovido para primário em caso de falha.
Migração de banco de dados Se você planeja migrar seu 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).
Treinamento de usuários 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