Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Neste artigo, você implantará um banco de dados PostgreSQL altamente disponível no AKS.
- Se você ainda não criou a infraestrutura necessária para essa implantação, siga as etapas em Criar infraestrutura para implantar um banco de dados PostgreSQL altamente disponível no AKS para ser configurado e, em seguida, você poderá retornar a este artigo.
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
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
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.
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
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.
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)"
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
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
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.
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.
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:
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:
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:
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:
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
Azure Kubernetes Service