Compartilhar via


Implantar um banco de dados PostgreSQL altamente disponível no AKS

Neste artigo, você implantará um banco de dados PostgreSQL altamente disponível no AKS.

Importante

O software de código aberto é mencionado em toda a documentação e amostras do AKS. O software que você implanta está excluído dos contratos de nível de serviço do AKS, garantia limitada e suporte do Azure. Ao usar tecnologia de código aberto junto com o AKS, consulte as opções de suporte disponíveis nas comunidades e mantenedores de projetos respectivos para desenvolver um plano.

Por exemplo, o repositório do Ray GitHub descreve várias plataformas que variam em tempo de resposta, finalidade e nível de suporte.

A Microsoft assume a responsabilidade por criar os pacotes de código aberto que implantamos no AKS. Essa responsabilidade inclui ter propriedade completa do processo de criação, verificação, sinalização, validação e hotfix, junto com o controle sobre os binários em imagens de contêiner. Para obter mais informações, confira Gerenciamento de vulnerabilidades para o AKS e Cobertura de suporte do AKS.

Criar segredo para o usuário do aplicativo bootstrap

  1. Gere um segredo para validar a implantação do PostgreSQL por meio de logon interativo para um usuário do aplicativo bootstrap usando o comando kubectl create secret.

    PG_DATABASE_APPUSER_SECRET=$(echo -n | openssl rand -base64 16)
    
    kubectl create secret generic db-user-pass \
        --from-literal=username=app \
        --from-literal=password="${PG_DATABASE_APPUSER_SECRET}" \
        --namespace $PG_NAMESPACE \
        --context $AKS_PRIMARY_CLUSTER_NAME
    
  2. Valide se o segredo foi criado com êxito usando o comando kubectl get.

    kubectl get secret db-user-pass --namespace $PG_NAMESPACE --context $AKS_PRIMARY_CLUSTER_NAME
    

Definir variáveis de ambiente para o cluster PostgreSQL

  • Implante um ConfigMap para definir variáveis de ambiente para o cluster PostgreSQL usando o seguinte comando kubectl apply:

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -n $PG_NAMESPACE -f -
    apiVersion: v1
    kind: ConfigMap
    metadata:
        name: cnpg-controller-manager-config
    data:
        ENABLE_AZURE_PVC_UPDATES: 'true'
    EOF
    

Instalar o Prometheus PodMonitors

O Prometheus cria PodMonitors para as instâncias CNPG usando um conjunto de regras de gravação padrão armazenadas no repositório de exemplos do GitHub CNPG. Em um ambiente de produção, essas regras seriam modificadas conforme necessário.

  1. Adicione o repositório Prometheus Community Helm usando o comando helm repo add.

    helm repo add prometheus-community \
        https://prometheus-community.github.io/helm-charts
    
  2. Atualize o repositório Prometheus Community Helm e instale-o no cluster primário usando o comando helm upgrade com o sinalizador --install.

    helm upgrade --install \
        --namespace $PG_NAMESPACE \
        -f https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/docs/src/samples/monitoring/kube-stack-config.yaml \
        prometheus-community \
        prometheus-community/kube-prometheus-stack \
        --kube-context=$AKS_PRIMARY_CLUSTER_NAME
    

Criar uma credencial federada

Nesta seção, você criará uma credencial de identidade federada para backup do PostgreSQL para permitir que o CNPG use a identidade de carga de trabalho do AKS para autenticar no destino da conta de armazenamento para backups. O operador CNPG cria uma conta de serviço do Kubernetes com o mesmo nome do cluster nomeado usado no manifesto de implantação do Cluster CNPG.

  1. Obtenha a URL do emissor OIDC do cluster usando o comando az aks show.

    export AKS_PRIMARY_CLUSTER_OIDC_ISSUER="$(az aks show \
        --name $AKS_PRIMARY_CLUSTER_NAME \
        --resource-group $RESOURCE_GROUP_NAME \
        --query "oidcIssuerProfile.issuerUrl" \
        --output tsv)"
    
  2. Crie uma credencial de identidade federada usando o comando az identity federated-credential create.

    az identity federated-credential create \
        --name $AKS_PRIMARY_CLUSTER_FED_CREDENTIAL_NAME \
        --identity-name $AKS_UAMI_CLUSTER_IDENTITY_NAME \
        --resource-group $RESOURCE_GROUP_NAME \
        --issuer "${AKS_PRIMARY_CLUSTER_OIDC_ISSUER}" \
        --subject system:serviceaccount:"${PG_NAMESPACE}":"${PG_PRIMARY_CLUSTER_NAME}" \
        --audience api://AzureADTokenExchange
    

Implantar um cluster PostgreSQL altamente disponível

Nesta seção, você implantará um cluster PostgreSQL altamente disponível usando o CRD (definição de recurso personalizado) do Cluster CNPG.

Parâmetros de CRD do cluster

A tabela a seguir descreve as propriedades de chave definidas no manifesto de implantação YAML para o CRD do cluster:

Propriedade Definição
inheritedMetadata Específico para o operador CNPG. Os metadados são herdados por todos os objetos relacionados ao cluster.
annotations: service.beta.kubernetes.io/azure-dns-label-name Rótulo DNS para uso ao expor os pontos de extremidade de cluster postgres somente leitura e leitura.
labels: azure.workload.identity/use: "true" Indica que o AKS deve injetar dependências de identidade de carga de trabalho nos pods que hospedam as instâncias de cluster do PostgreSQL.
topologySpreadConstraints Exigir zonas diferentes e nós diferentes com rótulo "workload=postgres".
resources Configura uma classe QoS (Qualidade de Serviço) de Garantia. Em um ambiente de produção, esses valores são fundamentais para maximizar o uso da VM do nó subjacente e variam de acordo com a SKU da VM do Azure usada.
bootstrap Específico para o operador CNPG. Inicializa com um banco de dados de aplicativo vazio.
storage / walStorage Específico para o operador CNPG. Define modelos de armazenamento para os PVCs (PersistentVolumeClaims) para armazenamento de dados e logs. Também é possível especificar o armazenamento para os espaços de tabela serem fragmentados para IOPs maiores.
replicationSlots Específico para o operador CNPG. Habilita slots de replicação para alta disponibilidade.
postgresql Específico para o operador CNPG. Mapeia as configurações para postgresql.conf, pg_hba.conf e pg_ident.conf config.
serviceAccountTemplate Contém o modelo necessário para gerar as contas de serviço e mapeia a credencial de identidade federada do AKS para a UAMI para habilitar a autenticação de identidade de carga de trabalho do AKS dos pods que hospedam as instâncias do PostgreSQL para recursos externos do Azure.
barmanObjectStore Específico para o operador CNPG. Configura o conjunto de ferramentas barman-cloud usando a identidade da carga de trabalho do AKS para autenticação no repositório de objetos do Armazenamento de Blobs do Azure.

Parâmetros de desempenho do PostgreSQL

O desempenho do PostgreSQL depende muito dos recursos subjacentes do cluster. A tabela a seguir fornece algumas sugestões sobre como calcular parâmetros-chave para alto desempenho:

Propriedade Valor recomendado Definição
wal_compression lz4 Compacta gravações de páginas completas escritas no arquivo WAL com o método especificado
max_wal_size 6 GB Define o tamanho do WAL que dispara um ponto de verificação
checkpoint_timeout 15min Define o tempo máximo entre os pontos de verificação automáticos do WAL
checkpoint_flush_after 2 MB Número de páginas após as quais as gravações executadas anteriormente são liberadas para o disco
wal_writer_flush_after 2 MB Quantidade de WAL escrito pelo gravador WAL que dispara uma liberação
min_wal_size 4 GB Define o tamanho mínimo para reduzir o WAL para
shared_buffers 25% de memória do nó Define o número de buffers de memória compartilhados usados pelo servidor
effective_cache_size 75% de memória do nó Define a suposição do planejador sobre o tamanho total dos caches de dados
work_mem 1/256 de memória do nó Define a quantidade máxima de memória a ser utilizada para espaços de trabalho de consultas
maintenance_work_mem 6,25% de memória do nó Define a memória máxima a ser usada para operações de manutenção
autovacuum_vacuum_cost_limit 2400 Valor do custo do vácuo disponível antes do repouso, para vácuo automático
random_page_cost 1.1 Define a estimativa de custo do planejador para uma página de disco acessada não sequencialmente
effective_io_concurrency 64 Número de solicitações simultâneas que podem ser tratadas com eficiência pelo subsistema de disco
maintenance_io_concurrency 64 Uma variante de "effective_io_concurrency" usada para o trabalho de manutenção

Implantando o PostgreSQL

  1. Implante o cluster PostgreSQL com o CRD do Cluster usando o comando kubectl apply.

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -n $PG_NAMESPACE -v 9 -f -
    apiVersion: postgresql.cnpg.io/v1
    kind: Cluster
    metadata:
      name: $PG_PRIMARY_CLUSTER_NAME
    spec:
      inheritedMetadata:
        annotations:
          service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
        labels:
          azure.workload.identity/use: "true"
    
      instances: 3
      startDelay: 30
      stopDelay: 30
      minSyncReplicas: 1
      maxSyncReplicas: 1
      replicationSlots:
        highAvailability:
          enabled: true
        updateInterval: 30
    
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            cnpg.io/cluster: $PG_PRIMARY_CLUSTER_NAME
    
      affinity:
        nodeSelector:
          workload: postgres
    
      resources:
        requests:
          memory: '8Gi'
          cpu: 2
        limits:
          memory: '8Gi'
          cpu: 2
    
      bootstrap:
        initdb:
          database: appdb
          owner: app
          secret:
            name: db-user-pass
          dataChecksums: true
    
      storage:
        size: 32Gi
        pvcTemplate:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 32Gi
          storageClassName: $POSTGRES_STORAGE_CLASS
    
      walStorage:
        size: 32Gi
        pvcTemplate:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 32Gi
          storageClassName: $POSTGRES_STORAGE_CLASS
    
      monitoring:
        enablePodMonitor: true
    
      postgresql:
        parameters:
          wal_compression: lz4
          max_wal_size: 6GB
          checkpoint_timeout: 15min
          checkpoint_flush_after: 2MB
          wal_writer_flush_after: 2MB
          min_wal_size: 4GB
          shared_buffers: 4GB
          effective_cache_size: 12GB
          work_mem: 62MB
          maintenance_work_mem: 1GB
          autovacuum_vacuum_cost_limit: "2400"
          random_page_cost: "1.1"
          effective_io_concurrency: "64"
          maintenance_io_concurrency: "64"
        pg_hba:
          - host all all all scram-sha-256
    
      serviceAccountTemplate:
        metadata:
          annotations:
            azure.workload.identity/client-id: "$AKS_UAMI_WORKLOAD_CLIENTID"
          labels:
            azure.workload.identity/use: "true"
    
      backup:
        barmanObjectStore:
          destinationPath: "https://${PG_PRIMARY_STORAGE_ACCOUNT_NAME}.blob.core.windows.net/backups"
          azureCredentials:
            inheritFromAzureAD: true
        retentionPolicy: '7d'
    EOF
    
  1. Valide se o cluster postgreSQL primário foi criado com êxito usando o comando kubectl get. O CRD do Cluster CNPG especificou três instâncias, que podem ser validadas exibindo pods em execução depois que cada instância é criada e unida para replicação. Seja paciente, pois pode levar algum tempo para as três instâncias ficarem online e ingressarem no cluster.

    kubectl get pods --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME
    

    Saída de exemplo

    NAME                         READY   STATUS    RESTARTS   AGE
    pg-primary-cnpg-r8c7unrw-1   1/1     Running   0          4m25s
    pg-primary-cnpg-r8c7unrw-2   1/1     Running   0          3m33s
    pg-primary-cnpg-r8c7unrw-3   1/1     Running   0          2m49s
    

Importante

Se você estiver usando o NVMe local com o Armazenamento de Contêineres do Azure e seu pod estiver preso no estado de inicialização com um erro de várias anexações, provavelmente ele ainda está procurando o volume em um nó perdido. Depois que o pod começar a ser executado, ele entrará em estado CrashLoopBackOff porque uma nova réplica foi criada no novo nó sem dados e o CNPG não consegue localizar o diretório pgdata. Para resolver isso, você precisa destruir a instância afetada e criar uma nova. Execute o comando a seguir:

kubectl cnpg destroy [cnpg-cluster-name] [instance-number]  

Validar se o Prometheus PodMonitor está em execução

O operador do CNPG cria automaticamente um PodMonitor para a instância primária usando as regras de registro criadas durante a instalação da comunidade Prometheus.

  1. Valide se o PodMonitor está em execução usando o comando kubectl get.

    kubectl --namespace $PG_NAMESPACE \
        --context $AKS_PRIMARY_CLUSTER_NAME \
        get podmonitors.monitoring.coreos.com \
        $PG_PRIMARY_CLUSTER_NAME \
        --output yaml
    

    Saída de exemplo

     kind: PodMonitor
     metadata:
      annotations:
        cnpg.io/operatorVersion: 1.23.1
    ...
    

Se você estiver usando o Azure Monitor para o Prometheus Gerenciado, precisará adicionar outro monitor de pod usando o nome do grupo personalizado. O Prometheus gerenciado não capta as CRDs (definições de recursos personalizados) na comunidade Prometheus. Além do nome do grupo, os CRDs são os mesmos. Isso permite que monitores de pod para o Prometheus Gerenciado existam lado a lado aqueles que usam o monitor de pod da comunidade. Se você não estiver usando o Prometheus Gerenciado, poderá ignorar isso. Crie um novo monitor de pod:

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -f -
apiVersion: azmonitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: cnpg-cluster-metrics-managed-prometheus
  namespace: ${PG_NAMESPACE}
  labels:
    azure.workload.identity/use: "true"
    cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
spec:
  selector:
    matchLabels:
      azure.workload.identity/use: "true"
      cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
  podMetricsEndpoints:
    - port: metrics
EOF

Verifique se o monitor do pod foi criado (observe a diferença no nome do grupo).

kubectl --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    get podmonitors.azmonitoring.coreos.com \
    -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME \
    -o yaml

Opção A – Workspace do Azure Monitor

Depois de implantar o cluster postgres e o monitor de pod, você pode exibir as métricas usando o portal do Azure em um workspace do Azure Monitor.

Captura de tela mostrando métricas em um workspace do Azure Monitor.

Opção B – Grafana Gerenciado

Como alternativa, depois de implantar os monitores de cluster e pod do Postgres, você pode criar um painel de métricas na instância do Grafana Gerenciada criada pelo script de implantação para visualizar as métricas exportadas para o workspace do Azure Monitor. Você pode acessar o Grafana Gerenciado por meio do portal do Azure. Navegue até a instância do Grafana Gerenciado criada pelo script de implantação e clique no link do Ponto de Extremidade, conforme mostrado aqui:

Captura de tela mostrando uma instância do Espaço Gerenciado do Azure para Grafana.

Clicar no link do Ponto de Extremidade fará com que uma nova janela do navegador seja aberta, na qual você pode criar painéis na instância do Grafana Gerenciado. Seguindo as instruções para configurar uma fonte de dados do Azure Monitor, você pode adicionar visualizações para criar um painel de métricas do cluster Postgres. Depois de configurar a conexão da fonte de dados, no menu principal, clique na opção Fontes de dados e você deverá ver um conjunto de opções de fonte de dados para a conexão da fonte de dados, conforme mostrado aqui:

Captura de tela mostrando as opções de fonte de dados.

Na opção Prometheus Gerenciado, clique na opção para criar um dashboard para abrir o editor do painel. Depois que a janela do editor for aberta, clique na opção Adicionar visualização e clique na opção Prometheus Gerenciado para navegar pelas métricas do cluster Postgres. Depois de selecionar a métrica que deseja visualizar, clique no botão Executar consultas para buscar os dados para a visualização, conforme mostrado aqui:

Captura de tela mostrando o painel de construção.

Clique no botão Salvar para adicionar o painel ao painel. Você pode adicionar outros painéis clicando no botão Adicionar no editor do painel e repetindo esse processo para visualizar outras métricas. Adicionando as visualizações de métricas, você deve ter algo parecido com este:

Captura de tela mostrando salvar o painel.

Clique no ícone Salvar para salvar seu painel.


Próximas etapas

Colaboradores

A Microsoft atualiza este artigo. Os seguintes colaboradores o escreveram originalmente:

  • Ken Kilty | Diretor de TPM
  • Russell de Pina | Diretor de TPM
  • Adrian Joian | Engenheiro sênior de clientes
  • Jenny Hayes | Desenvolvedora sênior de conteúdo
  • Carol Smith | Desenvolvedora sênior de conteúdo
  • Erin Schaffer | Desenvolvedora de Conteúdo 2
  • Adam Sharif | Engenheiro de clientes 2