Instalar o AlloyDB Omni usando o orquestrador de contêineres

Selecione uma versão da documentação:

Nesta página, apresentamos uma visão geral do operador do AlloyDB Omni no Kubernetes, com instruções para usá-lo na implantação do AlloyDB Omni em um cluster do Kubernetes. Nesta página, presumimos que você tenha familiaridade básica com a operação do Kubernetes.

Para instruções sobre como instalar o AlloyDB Omni em um ambiente Linux padrão, consulte Instalar o AlloyDB Omni.

Visão geral

Para implantar o AlloyDB Omni em um cluster do Kubernetes, instale o operador do AlloyDB Omni no Kubernetes, uma extensão da API Kubernetes fornecida pelo Google.

Para configurar e controlar um cluster de banco de dados do AlloyDB Omni baseado no Kubernetes, combine arquivos de manifesto declarativos com o utilitário kubectl, assim como qualquer outra implantação baseada no Kubernetes. Não use a CLI para AlloyDB Omni, que é destinada a implantações em máquinas Linux individuais, e não em clusters do Kubernetes.

Imagem de base

A partir da versão 1.5.0, as imagens do Kubernetes do operador do AlloyDB Omni são criadas com base na imagem de base universal (UBI, na sigla em inglês) 9 da Red Hat. Essa transição melhora a segurança, a consistência e a conformidade das suas implantações.

Referências de imagem de resumo SHA

Para evitar ataques de fornecimento e atender aos requisitos da certificação do OpenShift, o operador do AlloyDB Omni usa resumos SHA-256 em vez de tags de versão para todas as referências de imagem do contêiner.

  • Upgrades automáticos: o operador do AlloyDB Omni usa um ImageCatalog interno para gerenciar esses resumos e garantir reversões confiáveis do plano de dados durante upgrades com falha.

  • Ativação: embora ativada por padrão para o pacote certificado do OpenShift, os usuários dos pacotes OLM ou Helm podem ativar manualmente as referências de resumo definindo a variável de ambiente ENABLE_DIGEST_IMAGE_REFS como true usando a configuração de assinatura para OLM ou o valor enableDigestImageRefs no gráfico do Helm.

Antes de começar

Antes de instalar o AlloyDB Omni em um cluster do Kubernetes com o operador do AlloyDB Omni, verifique se você atende aos requisitos a seguir.

Escolha uma opção de download ou instalação

Ao gerenciar cargas de trabalho em um cluster genérico do Kubernetes, é possível usar o Helm ou o OLM. O Helm é um gerenciador de pacotes universal que usa gráficos do Helm para instalar qualquer carga de trabalho, incluindo operadores, em todas as variantes do Kubernetes. O OLM, a opção padrão e preferida nas plataformas OpenShift, gerencia os ciclos de vida dos operadores com pacotes especializados.

Com base no seu ambiente e nas suas ferramentas, escolha um dos seguintes métodos de implantação:

Mídia Locais de download e guias de instalação Implantação em
Operador do AlloyDB Omni com gráfico do Helm Instalar o AlloyDB Omni no Kubernetes Ambiente de contêiner do Kubernetes próprio, por exemplo, nuvens públicas, no local, GKE, Amazon EKS e Azure AKS.

Dica: se as ferramentas de entrega contínua (CD) estiverem integradas ao Helm, use essa opção.
Operador do AlloyDB Omni com pacote OLM OperatorHub.io Ambiente de contêiner do Kubernetes que você traz, por exemplo, no local, nuvens públicas, Google Kubernetes Engine, Amazon EKS e Azure AKS.

Para usar um pacote do OLM, instale o OLM no cluster do Kubernetes antes de instalar o operador. Para mais informações, consulte olm.operatorframework.io.

Dica: se as ferramentas de entrega contínua (CD) já usarem o OLM, escolha essa opção.
Operador do OpenShift com pacote OLM Console da Web do Openshift Container Platform Ambiente do OpenShift

O OpenShift, uma variante do Kubernetes, usa o OLM como método padrão integrado para empacotar e implantar operadores.

Verifique o acesso

Verifique se você tem acesso ao seguinte:

Atender aos requisitos de hardware e software

Cada nó no cluster do Kubernetes precisa ter o seguinte:

  • No mínimo duas CPUs x86 ou AMD64.
  • Pelo menos 8 GB de RAM.
  • Versão do kernel do Linux 4.18 ou posterior.
  • Grupo de controle (cgroup) v2 ativado.

Instalar o operador do AlloyDB Omni

Se você quiser implantar o AlloyDB Omni no seu ambiente de produção, consulte Executar o AlloyDB Omni em produção.

É possível instalar o operador do AlloyDB Omni usando diferentes métodos, incluindo o Helm e o Operator Lifecycle Manager (OLM).

Helm

Para instalar o operador do AlloyDB Omni, siga estas etapas:

  1. Instale o operador do AlloyDB Omni do registro do OCI: 
    helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
--version 1.9.0 \
--create-namespace \
--namespace alloydb-omni-system \
$(helm install --help | grep -q -- '--rollback-on-failure' && echo '--rollback-on-failure' || echo '--atomic') \
--timeout 5m

    Se a instalação for bem-sucedida, a seguinte saída será exibida:

    NAME: alloydbomni-operator
LAST DEPLOYED: CURRENT_TIMESTAMP
NAMESPACE: alloydb-omni-system
STATUS: deployed
REVISION: 1
TEST SUITE: None

OLM

Para instalar o operador do AlloyDB Omni usando o Operator Lifecycle Manager, siga estas etapas:

  1. Acesse a página Operador do AlloyDB Omni.

  2. Clique em Instalar. Se você ainda não tiver feito isso, siga as instruções para instalar apenas o operador do OLM e o catálogo do OperatorHub.io.

  3. Crie o namespace alloydb-omni-system se ele ainda não existir.

    kubectl create ns alloydb-omni-system

  4. Configure o OLM OperatorGroup para garantir que o operador tenha escopo de cluster.

    kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: operator-sdk-og
  namespace: alloydb-omni-system
spec:
  upgradeStrategy: Default
EOF

  5. Instale o operador usando um recurso de assinatura do OLM.

    kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-alloydb-omni-operator
  namespace: alloydb-omni-system
spec:
  channel: stable
  name: alloydb-omni-operator
  source: operatorhubio-catalog
  sourceNamespace: olm
EOF

  6. Instale o certificado padrão ClusterIssuer. Esta etapa é opcional se você usa emissores de certificados personalizados.

    kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: alloydbomni-selfsigned-cluster-issuer
spec:
  selfSigned: {}
EOF

OLM

Para instalar o operador do AlloyDB Omni no ambiente do Red Hat OpenShift usando o OLM, siga estas etapas:

  1. Faça login no console da Web do Red Hat OpenShift.
  2. Para usuários off-line ou desconectados, é necessário espelhar manualmente as imagens necessárias no registro particular usando ferramentas que preservam resumos SHA, como oc image mirror. Configure um ImageDigestMirrorSet para redirecionar as extrações de imagens do repositório público gcr.io para seu registro particular. Isso garante que o operador do AlloyDB Omni possa extrair as imagens necessárias usando os resumos SHA256 imutáveis.

  3. No console da Web do OpenShift, acesse Operadores > OperatorHub. O operador do AlloyDB Omni está listado nos catálogos Certificado e Comunidade.

  4. No painel do operador do AlloyDB Omni, clique em Instalar.

  5. Instale o certificado padrão ClusterIssuer executando os comandos a seguir. Esta etapa é opcional se você usa emissores de certificados personalizados.

    kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: alloydbomni-selfsigned-cluster-issuer
spec:
  selfSigned: {}
EOF

Configurar o armazenamento conectado do GDC

Para instalar o operador do AlloyDB Omni no GDC conectado, siga as etapas adicionais para configurar o armazenamento, porque os clusters conectados do GDC não definem uma classe de armazenamento padrão. É necessário definir uma classe de armazenamento padrão antes de criar um cluster de banco de dados do AlloyDB Omni.

Para saber como definir o Symcloud Storage como a classe de armazenamento padrão, consulte Definir o Symcloud Storage como a classe de armazenamento padrão.

Para mais informações sobre como alterar o padrão de todas as outras classes de armazenamento, consulte Alterar a StorageClass padrão.

Criar um cluster de banco de dados

Um cluster de banco de dados do AlloyDB Omni contém todos os recursos de armazenamento e computação necessários para executar um servidor do AlloyDB Omni, incluindo o servidor primário, todas as réplicas e todos os seus dados.

Depois de instalar o operador do AlloyDB Omni no cluster do Kubernetes, é possível criar um cluster de banco de dados do AlloyDB Omni no cluster do Kubernetes aplicando um manifesto semelhante ao seguinte:

apiVersion: v1
kind: Secret
metadata:
  name: db-pw-DB_CLUSTER_NAME
type: Opaque
data:
  DB_CLUSTER_NAME: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
spec:
  databaseVersion: "18.4.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      cpu: CPU_COUNT
      memory: MEMORY_SIZE
      disks:
      - name: DataDisk
        size: DISK_SIZE

Substitua:

  • DB_CLUSTER_NAME: o nome do cluster de banco de dados, por exemplo, my-db-cluster.

  • ENCODED_PASSWORD: a senha de login do banco de dados para a função de usuário padrão postgres, codificada como uma string base64. Por exemplo, Q2hhbmdlTWUxMjM= para ChangeMe123.

  • CPU_COUNT: o número de CPUs disponíveis para cada instância de banco de dados no cluster.

  • MEMORY_SIZE: a quantidade de memória por instância de banco de dados deste cluster de banco de dados. Recomendamos definir isso como 8 gigabytes por CPU. Por exemplo, se você definiu cpu como 2 anteriormente neste manifesto, recomendamos definir memory como 16Gi.

  • DISK_SIZE: o tamanho do disco por instância de banco de dados, por exemplo, 10Gi.

Depois de aplicar esse manifesto, o cluster do Kubernetes vai conter um cluster de banco de dados do AlloyDB Omni com a configuração de memória, CPU e armazenamento especificada. Para estabelecer uma conexão de teste com o novo cluster de banco de dados, consulte Conectar usando o psql pré-instalado.

Para mais exemplos de manifestos, consulte Exemplos de configuração do Kubernetes. Para mais informações sobre manifestos do Kubernetes e como aplicá-los, consulte Como gerenciar recursos.

Secrets de extração de imagem

Se você estiver usando um registro particular para as imagens de contêiner, especifique os secrets de extração de imagem para o cluster de banco de dados. O operador do AlloyDB Omni propaga os secrets de extração de imagem para a conta de serviço do cluster de banco de dados, chamada DB_CLUSTER_NAME-sa.

Para configurar secrets de extração de imagens, forneça os nomes dos secrets na especificação do cluster de banco de dados. A chave secreta precisa existir no mesmo namespace que o cluster de banco de dados.

spec:
  primarySpec:
    serviceAccount:
      imagePullSecrets:
      - name: PULL_SECRET_NAME

Substitua PULL_SECRET_NAME pelo nome do secret de extração de imagem.

Escalonar um cluster de banco de dados

Para escalonar os recursos de computação do cluster de banco de dados, atualize os valores cpu e memory no manifesto db-cluster.yaml e aplique as mudanças. O processo de escalonamento depende se você opta por uma operação de escalonamento regular ou de baixa inatividade.

Escalonamento regular

Quando você atualiza a especificação de escalonamento e aplica o manifesto sem nenhuma outra configuração, os pods do banco de dados são reiniciados instantaneamente. Isso resulta em um breve período de inatividade nas instâncias principal e em espera enquanto as novas alocações de recursos entram em vigor.

Escalonamento com baixa inatividade

Para clusters de alta disponibilidade (HA) com pelo menos um de espera, é possível minimizar o tempo de inatividade durante o escalonamento usando a estratégia de preparação e troca da manutenção de baixa inatividade (LDTM, na sigla em inglês). Essa estratégia aplica as mudanças de escalonamento primeiro ao modo de espera, realiza uma troca rápida e, em seguida, aplica as mudanças à instância principal original. É possível aumentar ou diminuir a escala verticalmente com a estratégia de LDTM.

Para ativar e monitorar o escalonamento com pouco tempo de inatividade, siga estas etapas:

  1. Ativar o escalonamento com pouco tempo de inatividade. Adicione a anotação enableLDTM ao cluster de banco de dados:

    kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME dbcluster.dbadmin.goog/enableLDTM=true

    Substitua DB_CLUSTER_NAME pelo nome do cluster de banco de dados.

  2. Aplique as especificações de escalonamento atualizadas. Atualize os valores cpu e memory em primarySpec.resources no manifesto e aplique as mudanças:

    kubectl apply -f db-cluster.yaml

  3. Monitore o processo de escalonamento. Verifique a condição de status LDTMScalingInProgress para monitorar a operação:

    kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "LDTMScalingInProgress")'

    Substitua DB_CLUSTER_NAME pelo nome do cluster de banco de dados.

    Enquanto o processo está em andamento, o status é true. Quando o escalonamento é concluído, o status da condição muda para false.

Limitações

  • O escalonamento de LDTM só é compatível com clusters de alta disponibilidade com pelo menos um modo de espera.
  • Não é possível realizar duas operações de LDTM ao mesmo tempo. Por exemplo, é possível usar o LDTM para escalonar clusters de banco de dados ou realizar upgrades de versões secundárias, mas não os dois ao mesmo tempo.
  • É necessário reverter manualmente após uma falha na operação de escalonamento do LDTM.

A seguir