Padrões de atualização de carga de trabalho com estado para o AKS (Serviço de Kubernetes do Azure)

Use estes padrões para coordenar a disponibilidade do banco de dados com uma atualização gradual do pool de nós do AKS (Serviço de Kubernetes do Azure).

Os procedimentos neste artigo são estruturas de planejamento, não garantias de disponibilidade ou durabilidade de dados. O resultado depende da topologia do banco de dados, do modo de replicação, do armazenamento, do operador, das configurações de interrupção, do comportamento de repetição do cliente e da carga de trabalho. Ensaiar o procedimento completo em um ambiente representativo e medir se ele atende ao RTO (objetivo de tempo de recuperação) e ao RPO (objetivo de ponto de recuperação).

Padrões de atualização de banco de dados abordados neste artigo

Este artigo fornece padrões específicos de atualização para bancos de dados em clusters do AKS com cargas de trabalho com estado, incluindo:

• Alternância controlada do PostgreSQL.
• Atualização gradual do Redis Cluster com prioridade para as réplicas.
• Atualização gradual do conjunto de réplicas do MongoDB com os secundários primeiro.
• Listas de verificação para atualização emergencial em respostas a incidentes de segurança.
• Validação e planejamento de reversão.

Ao contrário de uma atualização padrão do pool de nós do AKS, esses padrões coordenam verificações da replicação do banco de dados e alterações de função com a substituição dos nós do Kubernetes. Os administradores de banco de dados e do AKS podem usar esses padrões. Use a operação de substituição ou atualização documentada para o operador de banco de dados que gerencia sua implantação. Não substitua esses padrões por instruções específicas do operador.

Para obter mais informações, consulte estes artigos relacionados:

• Para atualizar seus clusters de produção do AKS, consulte estratégias de atualização para produção do AKS.
• Para comparar as abordagens de atualização para o cluster do AKS, consulte opções e recomendações de atualização.
• Para usar o hub de cenários para ajudá-lo a escolher a abordagem de atualização correta do AKS, consulte os cenários de atualização do AKS: Escolha seu caminho.

Para um início rápido, selecione o padrão para seu produto e topologia implantados:

• Lista de verificação de atualização de emergência
• Alternância controlada do PostgreSQL
• Atualização sem interrupção da primeira réplica do Cluster Redis
• Atualização contínua com prioridade para os secundários do conjunto de réplicas do MongoDB

Escolher um padrão de atualização de banco de dados

Lista de verificação de atualização de emergência

Se você precisar de uma atualização acelerada para resolver um problema de segurança, não ignore as verificações de integridade e recuperação do banco de dados.

1. Verifique a carga de trabalho e os pré-requisitos de atualização do AKS:

   # Verify the database pods and their node placement.
   kubectl get pods -l tier=database -o wide
   
   # Confirm that the latest backup job completed.
   kubectl get job backup-job -o jsonpath='{.status.completionTime}'
   

   Verifique também a integridade da replicação usando um comando compatível com o banco de dados ou operador. Restaure o backup mais recente em um ambiente isolado e confirme que os clientes tentam novamente após erros transitórios de conexão e de eleição.

2. Escolha apenas o padrão que corresponde ao produto e à topologia:

   • PostgreSQL: Use troca controlada.
   • Cluster do Redis: Use atualização contínua com prioridade para a réplica.
   • Conjunto de réplicas do MongoDB: use a atualização contínua começando pelos secundários.

   Para outros produtos de banco de dados, siga as orientações de atualização desse produto ou de seu operador Kubernetes.

3. Execute com uma rede de proteção:

   • Teste sempre os procedimentos de reversão com antecedência.
   • Monitore as métricas do aplicativo durante a atualização.
   • Mantenha a equipe de banco de dados em espera.
   • Interrompa a atualização se a replicação, o quorum, a cobertura de slot ou a integridade do aplicativo forem degradadas.

Comutação controlada do PostgreSQL

Use esse padrão de substituição controlado para um postgreSQL primário com esperas de streaming. Os exemplos mostram verificações de integridade, mas os comandos que promovem, isolam e reintegram membros dependem do seu operador do PostgreSQL ou da implementação de alta disponibilidade.

Prerequisites

• Use uma versão do PostgreSQL com suporte e um operador compatível ou uma implementação de alta disponibilidade.
• Distribua os membros entre domínios de falha. Configure os orçamentos de interrupção do pod e as restrições de propagação de topologia para sua implantação.
• Verifique um backup recente restaurando-o em um ambiente isolado.
• Confirme se o aplicativo se reconecta após uma alteração primária.
• Registre os comandos específicos do operador para comutação, reversão e reingresso antes de iniciar a atualização do AKS.

Etapa 1: Validar a topologia de replicação

Execute a seguinte consulta no primário atual:

kubectl exec <current-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, write_lsn, flush_lsn, replay_lsn
FROM pg_stat_replication;"

O candidato designado para comutação deve estar no estado streaming. Se o seu RPO exigir replicação síncrona, verifique também se o candidato apresenta o sync_state esperado para a sua configuração.

Execute a seguinte consulta no servidor de standby pretendido:

kubectl exec <candidate-standby-pod> -- psql -X -c "
SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();"

Confirme que pg_is_in_recovery() retorna true e que os locais de recebimento e reprodução atendem ao seu limiar de comutação testado. A replicação por streaming do PostgreSQL é assíncrona por padrão, portanto, ter um pod pronto, por si só, não garante que a réplica em espera esteja sincronizada.

Etapa 2: pausar gravações e alternar primárias

Se todo o tráfego de aplicativos passar pelo PgBouncer, conecte-se ao banco de dados de administração pgBouncer e pause o banco de dados do aplicativo:

kubectl exec <pgbouncer-pod> -- psql -p 6432 -U <admin-user> pgbouncer -c "PAUSE app_db;"

PAUSE aguarda que as conexões de servidor sejam liberadas de acordo com o modo de pool configurado. Verifique se as operações de gravação do aplicativo não podem contornar o PgBouncer antes de confiar nesse controle.

Com as gravações pausadas, execute estas ações por meio do operador ou da implementação de alta disponibilidade:

1. Verifique novamente as posições de recepção e de reprodução do WAL do candidato.
2. Execute a operação de comutação suportada.
3. Verifique se existe exatamente um primário gravável.
4. Verifique se o primário anterior está isolado ou reconfigurado como secundário.
5. Verifique se o serviço de gravador ou ponto de extremidade é resolvido para o novo primário.

Retome PgBouncer somente depois que essas verificações passarem:

kubectl exec <pgbouncer-pod> -- psql -p 6432 -U <admin-user> pgbouncer -c "RESUME app_db;"

Etapa 3: Validar a substituição

# Verify the new primary is writable and no longer in recovery.
kubectl exec <new-primary-pod> -- psql -X -c "SELECT pg_is_in_recovery();"

# Verify all expected standbys stream from the new primary.
kubectl exec <new-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, replay_lsn
FROM pg_stat_replication;"

Testar leituras, gravações, transações e comportamento de reconexão do aplicativo. Compare por quanto tempo as gravações não estavam disponíveis e o resultado da replicação com o RTO e o RPO antes de continuar.

Configuração de replicação síncrona opcional

A replicação síncrona pode reduzir o RPO para transações já confirmadas, mas adiciona latência no commit e pode reduzir a disponibilidade de gravação se as réplicas em espera necessárias não estiverem disponíveis. O exemplo a seguir aguarda que quaisquer dois servidores em espera nomeados e conectados diretamente reexecutem cada transação confirmada:

# Use synchronous replication with multiple standbys
# postgresql.conf
synchronous_standby_names = 'ANY 2 (standby1, standby2, standby3)'
synchronous_commit = 'remote_apply'

Escolha synchronous_standby_names e synchronous_commit com base nos requisitos de latência, posicionamento de domínio de falha e durabilidade medidos. Essa configuração não garante uma duração específica de comutação.

Validação de êxito

Para validar seu progresso, use a seguinte lista de verificação:

• O novo primário aceita leituras e gravações.
• Todas as réplicas mostram replicação íntegra.
• O aplicativo se reconecta automaticamente.
• As verificações de integridade de dados e consistência do aplicativo são aprovadas.
• Os testes de backup e restauração são aprovados no novo primário.

Atualizar o pool de nós do AKS

Uma az aks nodepool upgrade operação atualiza todo o pool de nós. O AKS adiciona capacidade extra, isola e drena os nós antigos, recria a imagem deles e repete o processo de acordo com as configurações de atualização do pool de nós. Não execute o comando uma vez para cada nó nem drene manualmente os nós antes da operação gerenciada.

1. Liste os destinos de atualização com suporte para o cluster:

   az aks get-upgrades \
      --resource-group <resource-group-name> \
      --name <cluster-name> \
      --output table
   

2. Confirme se o painel de controle já está na versão de destino selecionada. Defina as configurações de atualização sem interrupção do pool de nós com base no comportamento de carga de trabalho testado, na cota e nos endereços de sub-rede disponíveis. O exemplo a seguir usa o valor de produção maxSurge recomendado:

   az aks nodepool update \
      --resource-group <resource-group-name> \
      --cluster-name <cluster-name> \
      --name <node-pool-name> \
      --max-surge 33% \
      --drain-timeout <minutes> \
      --node-soak-duration <minutes>
   

3. Inicie uma atualização gerenciada no pool de nós usando um destino retornado por az aks get-upgrades:

   az aks nodepool upgrade \
      --resource-group <resource-group-name> \
      --cluster-name <cluster-name> \
      --name <node-pool-name> \
      --kubernetes-version <target-version>
   

4. Monitore os eventos de atualização do AKS e a integridade do banco de dados durante toda a operação:

   kubectl events --all-namespaces
   kubectl get pods -l app=postgres -o wide --watch
   

   Monitore a replicação, a disponibilidade do banco de dados, os erros de aplicativo, a latência e a integridade do armazenamento em seu sistema de observabilidade. Se um Orçamento de Interrupção do Pod bloquear um dreno, corrija o problema de disponibilidade da carga de trabalho em vez de ignorar o orçamento.

Validar e recuperar

Após a conclusão da atualização gerenciada, verifique as versões dos nós, a topologia do PostgreSQL e o comportamento do aplicativo:

kubectl get nodes
kubectl get pods -l app=postgres -o wide
kubectl exec <current-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, replay_lsn
FROM pg_stat_replication;"

O AKS não dá suporte ao downgrade de um cluster ou pool de nós para uma versão anterior do Kubernetes. Se o banco de dados não estiver íntegro, pare as gravações do aplicativo e use o procedimento de recuperação ou substituição com suporte do operador de banco de dados. Não redirecione gravações para o antigo PostgreSQL primário, a menos que ele tenha se reintegrado com segurança à linha do tempo atual e tenha sido promovido pelo mecanismo de alta disponibilidade. Se a atualização do Kubernetes causar um problema de compatibilidade irrecuperável, restaure o serviço movendo a carga de trabalho para um pool de nós ou cluster testado e restaurando ou replicando dados de acordo com seu plano de recuperação.

Atualização sem interrupção da primeira réplica do Cluster Redis

Use esse padrão para um Cluster Redis com pelo menos três nós primários e pelo menos uma réplica para cada primário. A ordem documentada de atualização dos nós do cluster do Redis é atualizar primeiro as réplicas, realizar manualmente o failover de cada nó primário para uma réplica já atualizada e, em seguida, atualizar o antigo nó primário rebaixado. O Cluster Redis pode retornar erros transitórios ou redirecionamentos durante as alterações de topologia. Como o Redis Cluster usa replicação assíncrona, ele pode perder gravações reconhecidas. Valide o comportamento de novas tentativas do cliente e o RPO aceitável antes da atualização.

Etapa 1: Registrar e validar a topologia

kubectl exec <redis-pod> -- redis-cli CLUSTER NODES
kubectl exec <redis-pod> -- redis-cli --cluster check 127.0.0.1:6379

Registre cada ID de nó, função, atribuição primária para réplica e intervalo de slot de hash. Não continue, a menos que todos os 16.384 slots estejam cobertos, cada primário tenha uma réplica saudável em um domínio de falha diferente e o cluster informe cluster_state:ok.

Etapa 2: Atualizar réplicas

Para cada réplica, uma de cada vez:

1. Use o operador ou o mecanismo de implantação de carga de trabalho para substituir ou reiniciar a réplica na capacidade atualizada do AKS.
2. Aguarde até que o pod esteja pronto e que a replicação alcance o estado atual.
3. Confirme com CLUSTER NODES que ele continua atribuído ao primário esperado.

Não execute CLUSTER FORGET para uma reinicialização do pod que preserve a identidade do nó Redis. Se a substituição tiver uma nova identidade de nó, use redis-cli --cluster add-node com --cluster-master-id e --cluster-slave para adicioná-la como uma réplica do primário desejado. Aguarde até que a nova réplica apareça na topologia do cluster.

kubectl exec <existing-redis-pod> -- redis-cli --cluster add-node \
   <new-replica-ip>:6379 127.0.0.1:6379 \
   --cluster-slave \
   --cluster-master-id <primary-node-id>

Etapa 3: Fazer failover e atualizar as primárias

Para cada primário, um de cada vez:

1. Escolha uma réplica atualizada e sincronizada dessa primária.

2. Execute CLUSTER FAILOVERna réplica que você deseja promover, não no primário atual:

   kubectl exec <candidate-replica-pod> -- redis-cli CLUSTER FAILOVER
   

3. Consulte ROLE, INFO REPLICATION ou CLUSTER NODES até que o candidato seja o primário e o primário anterior se torne sua réplica. Uma OK resposta significa apenas que o Redis aceitou a solicitação de failover.

4. Substitua ou reinicie o antigo primário rebaixado na capacidade atualizada do AKS.

5. Aguarde até que ela retorne como uma réplica sincronizada antes de passar para o próximo primário.

Não use CLUSTER FAILOVER FORCE ou TAKEOVER durante uma atualização planejada. Essas opções ignoram a coordenação normal e exigem procedimentos separados de recuperação de falhas.

Etapa 4: Validar o cluster Redis

kubectl exec <redis-pod> -- redis-cli CLUSTER INFO
kubectl exec <redis-pod> -- redis-cli CLUSTER NODES
kubectl exec <redis-pod> -- redis-cli --cluster check 127.0.0.1:6379

Verifique a cobertura de slot, as atribuições primárias para réplicas, a integridade da replicação, as leituras e gravações do aplicativo, o tratamento de redirecionamento e o RPO observado.

Atualização sem interrupção do conjunto de réplicas do MongoDB

Use esse padrão para um conjunto de réplicas do MongoDB de três membros ou maiores que tenha um secundário elegível. Durante o rebaixamento do primário e a eleição, as operações de gravação falham até que um novo primário seja eleito. Os aplicativos devem repetir gravações qualificadas e transações transitórias de acordo com as diretrizes do driver do MongoDB.

Etapa 1: Validar o conjunto de réplicas

kubectl exec <mongodb-pod> -- mongosh --quiet --eval "rs.status()"

Confirme se todos os membros esperados estão íntegros, identifique o primário atual e verifique se pelo menos um secundário elegível está preso. Verifique também o backup mais recente por meio de uma restauração de teste.

Etapa 2: Atualizar os secundários

Para cada secundária, uma de cada vez:

1. Substitua ou reinicie o membro na capacidade atualizada do AKS usando o operador ou o mecanismo de implantação de carga de trabalho.

2. Aguarde até que o pod fique pronto.

3. Verifique se o membro retorna ao estado SECONDARY e se sincroniza antes de atualizar outro membro.

   kubectl exec <mongodb-pod> -- mongosh --quiet --eval \
      "rs.status().members.map(member => ({name: member.name, state: member.stateStr, optime: member.optimeDate}))"
   

Etapa 3: Rebaixar o primário

Execute rs.stepDown() somente no primário atual. O primeiro argumento especifica por quanto tempo o primeiro primário não pode ser reelecionado. O segundo argumento especifica por quanto tempo um secundário elegível precisa ser atualizado. Escolha valores com base no seu comportamento eleitoral testado.

kubectl exec <current-primary-pod> -- mongosh --quiet --eval "rs.stepDown(60, 30)"

O comando pode desconectar ou retornar um erro conforme as etapas primárias são interrompidas. Sondar o status do conjunto de réplicas de outro membro até que exatamente uma nova primária seja eleita:

kubectl exec <mongodb-pod> -- mongosh --quiet --eval \
   "rs.status().members.map(member => ({name: member.name, state: member.stateStr}))"

Se nenhum secundário elegível se equiparar ao primário dentro do período configurado, o primário não deixará a função. Resolva a integridade da replicação antes de tentar novamente. Não force o rebaixamento durante uma atualização planejada.

Etapa 4: Atualizar e validar o primário anterior

Substitua ou reinicie o primário anterior na capacidade atualizada do AKS. Aguarde até que ele retorne como um secundário saudável e, em seguida, valide:

• Exatamente um membro é PRIMARY.
• Todos os outros membros com dados estão SECONDARY e sincronizados.
• As leituras e gravações do aplicativo, as gravações repetíveis e as transações se comportam conforme o esperado.
• O intervalo de eleição medido atende ao RTO da aplicação.
• As verificações de backup e restauração passaram.