Planeie as implementações de bases de dados no GKE

Esta página explica as práticas recomendadas para executar bases de dados em contentores no GKE. Pode usar uma Implementação para criar um conjunto de instâncias de base de dados em contentores geridas pelo Kubernetes. Em seguida, cria um serviço para fornecer acesso à base de dados independentemente de qualquer Pod específico. O serviço permanece inalterado mesmo que o pod seja movido para um nó diferente.

Para aceder aos dados na instância da base de dados, crie um recurso PersistentVolumeClaim (PVC) e disponibilize-o à sua carga de trabalho.

As bases de dados dependem de discos locais para persistência. Uma base de dados que é executada como um serviço num cluster do Kubernetes e os respetivos ficheiros de base de dados num PersistentVolumeClaim estão associados ao ciclo de vida do cluster. Se o cluster for eliminado, a base de dados também é eliminada.

Se estiver a criar ou implementar uma aplicação com estado em execução no GKE, considere usar uma das seguintes opções de implementação para instâncias de base de dados:

  • Bases de dados totalmente geridas: uma base de dados gerida, como o Cloud SQL ou o Spanner, oferece uma sobrecarga operacional reduzida e está otimizada para a Trusted Cloud by S3NS infraestrutura. As bases de dados geridas requerem menos esforço para manter e operar do que uma base de dados que implementa diretamente no Kubernetes.
  • Aplicação Kubernetes: pode implementar e executar uma instância de base de dados (como MySQL ou PostgreSQL) num cluster do GKE.

Considerações para implementações de bases de dados no GKE

Cada uma das opções anteriores tem compromissos, tendo em conta os objetivos e as restrições da sua empresa. Use a seguinte tabela para decidir se a implementação de bases de dados no GKE é a escolha certa para si.

Ponderação Descrição
Independência da base de dados O ciclo de vida de um PersistentVolumeClaim está associado ao cluster do GKE correspondente. Se não quiser que o ciclo de vida da sua base de dados dependa de um cluster do GKE específico, considere manter a base de dados separada, como uma base de dados gerida ou numa instância de VM.
Dimensionamento com o GKE

Escala vertical: pode configurar os pedidos dos seus pods para serem dimensionados automaticamente. No entanto, tem de garantir que a sua aplicação de base de dados consegue resistir a interrupções quando os pods são dimensionados com o dimensionamento automático de pods vertical.

Escalabilidade horizontal: a sua base de dados pode conseguir escalar horizontalmente as leituras ou as escritas adicionando réplicas. Se a sua base de dados suporta o escalamento horizontal depende de ter uma arquitetura de gravação única ou de várias gravações. Para usar o escalamento horizontal, pode ter de atualizar a configuração da base de dados, além de aumentar o número de réplicas.
Sobrecarga do GKE

Nos clusters do Autopilot, não lhe é faturada a reserva de recursos, apenas os pedidos de recursos.

Nos clusters padrão, o GKE reserva recursos para as suas próprias operações. As bases de dados em clusters padrão não são dimensionadas automaticamente, pelo que a sobrecarga pode ser elevada para pequenos pods.
Número de instâncias de base de dados No contexto do Kubernetes, cada instância da base de dados é executada no seu próprio pod e tem a sua própria PersistentVolumeClaim. Se tiver um número elevado de instâncias, tem de operar e gerir um grande conjunto de pods, nós e reivindicações de volume. Em alternativa, use uma base de dados gerida.
Cópia de segurança de base de dados no GKE

Um PersistentVolumeClaim tem âmbito num cluster do GKE. Este âmbito significa que, quando um cluster do GKE é eliminado, a reivindicação de volume é eliminada. Os ficheiros de base de dados no cluster também são eliminados. Para se proteger contra a perda acidental dos ficheiros da base de dados, recomendamos a replicação ou a criação de cópias de segurança frequentes.

Pode usar a cópia de segurança para o GKE para tirar instantâneos da configuração da sua aplicação e dos dados de volume a intervalos periódicos. A Cópia de segurança do GKE processa o agendamento de cópias de segurança de volumes, a gestão do ciclo de vida das cópias de segurança e o restauro de cópias de segurança para um cluster.

Comportamento de recuperação específico do Kubernetes Quando um pod falha no Kubernetes, é recriado. Do ponto de vista da instância da base de dados, isto significa que, quando um pod é recriado, qualquer configuração que não seja persistente numa base de dados ou num armazenamento estável fora dos pods também é recriada.
Arquitetura de base de dados Se a sua base de dados estiver configurada para usar uma arquitetura ativa-passiva, tem de garantir que apenas uma réplica está configurada como principal. Muitas bases de dados relacionais têm uma opção de comutação por falha ativa-passiva, em que uma base de dados secundária pode ser promovida a principal em caso de falha da principal.
Migração de base de dados Se planeia migrar o seu sistema de base de dados existente para o GKE, consulte Migração de bases de dados: conceitos e princípios (parte 1) e Migração de bases de dados: conceitos e princípios (parte 2).
Nova formação de utilizadores Se mudar de uma implementação autogerida ou gerida pelo fornecedor para uma implementação de base de dados do Kubernetes, tem de voltar a formar os administradores da base de dados para operarem no novo ambiente com a mesma fiabilidade com que operam no ambiente atual. Os programadores de aplicações também podem ter de saber mais sobre as diferenças, mas em menor medida.

A tabela anterior apresenta uma discussão sobre algumas das considerações para a implementação da base de dados. No entanto, a tabela não inclui todas as considerações possíveis. Também tem de considerar a recuperação de desastres, a partilha de ligações e a monitorização.

O que se segue?