Padrões de atualização para cargas de trabalho com estado no Azure Kubernetes Service (AKS)

Utilize estes padrões para coordenar a disponibilidade da base de dados com uma atualização faseada de um conjunto de nós do Azure Kubernetes Service (AKS).

Os procedimentos deste artigo são estruturas de planeamento, não garantias de disponibilidade ou durabilidade dos dados. O resultado depende da topologia da sua base de dados, do modo de replicação, do armazenamento, do operador, das definições de perturbação, do comportamento de repetição de tentativas do cliente e da carga de trabalho. Ensaie todo o procedimento num ambiente representativo e avalie se cumpre o seu objetivo de tempo de recuperação (RTO) e o objetivo do ponto de recuperação (RPO).

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

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

• O PostgreSQL controlava a transição.
• Réplica do Redis Cluster - atualização contínua em primeiro lugar.
• Conjunto de réplicas do MongoDB com upgrade secundário e contínuo.
• Listas de verificação para atualização urgente em resposta a incidentes de segurança.
• Validação e planeamento da reversão.

Ao contrário de uma atualização padrão de um conjunto de nós do AKS, estes padrões coordenam verificações da replicação da base de dados e mudanças de função com a substituição de nós do Kubernetes. Administradores de bases de dados e AKS podem usar estes padrões. Use a operação documentada de mudança ou atualização para o operador da base de dados que gere a sua implementação. Não substitua estes padrões por instruções específicas do operador.

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

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

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

• Lista de verificação de atualização de emergência
• Comutação controlada do PostgreSQL
• Atualização faseada do Redis Cluster com prioridade às réplicas
• Conjunto de réplicas do MongoDB com atualização secundária e contínua

Escolha um padrão de atualização de base de dados

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

Se precisar de uma atualização acelerada para resolver um problema de segurança, não ignore as verificações de saúde e recuperação da base de dados.

1. Verifique a carga de trabalho e os pré-requisitos para a 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 saúde da replicação usando um comando suportado pela base de dados ou operador. Restaure a cópia de segurança mais recente num ambiente isolado e confirme que os clientes voltam a tentar após erros transitórios de ligação e de eleição.

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

   • PostgreSQL: Usar switchover controlado.
   • Redis Cluster: Use atualização faseada com as réplicas primeiro.
   • Conjunto de réplicas do MongoDB: Use atualização faseada começando pelos secundários.

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

3. Corra com uma rede de segurança:

   • Teste sempre os procedimentos de reversão com antecedência.
   • Monitore as métricas do aplicativo durante a atualização.
   • Mantenha a equipe do banco de dados em espera.
   • Interrompa a atualização se a replicação, o quórum, a cobertura dos slots ou a saúde da aplicação se degradarem.

Comutação controlada do PostgreSQL

Use este padrão de comutação controlada para um primário PostgreSQL com standbys de streaming. Os exemplos mostram verificações do estado de funcionamento, mas os comandos que promovem, isolam e reintegram membros dependem do seu operador do PostgreSQL ou da implementação de alta disponibilidade.

Pré-requisitos

• Use uma versão PostgreSQL suportada e um operador suportado ou uma implementação de alta disponibilidade.
• Coloque membros entre domínios de falha. Configure os Orçamentos de Disrupção de Pods e as restrições de distribuição de topologia para a sua implementação.
• Verifique uma cópia de segurança recente restaurando-a num ambiente isolado.
• Confirme que a aplicação se reconecta após uma alteração principal.
• Regista os comandos específicos do operador para troca, retrocesso e reintegração antes de iniciar a atualização do AKS.

Passo 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 previsto para a comutação deve estar no estado streaming. Se o seu RPO exigir replicação síncrona, verifique também se o candidato dispõe do sync_state esperado para a sua configuração.

Execute a seguinte consulta no 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 receção e repetição atingem o limiar de comutação validado nos seus testes. A replicação em streaming do PostgreSQL é assíncrona por defeito, pelo que um pod pronto, por si só, não demonstra que o standby está sincronizado.

Passo 2: Suspender as escritas e alternar as primárias

Se todo o tráfego de aplicações passar pelo PgBouncer, ligue-se à base de dados de administração do PgBouncer e pause a base de dados da aplicação:

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

PAUSE Aguarda que as conexões ao servidor sejam libertadas de acordo com o modo de pooling configurado. Verifique se as operações de escrita da aplicação não conseguem contornar o PgBouncer antes de depender deste controlo.

Com a escrita em pausa, conclua estas ações recorrendo ao seu operador ou à sua implementação de alta disponibilidade:

1. Verifique novamente as posições de receção e de reprodução do WAL do candidato.
2. Executa a operação de troca suportada.
3. Verifique se existe apenas uma primária gravável.
4. Verifique se o anterior primário foi isolado ou reconfigurado como reserva.
5. Verifique se o serviço writer ou o endpoint é resolvido para o novo primário.

Retome o PgBouncer apenas depois de estas verificações passarem:

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

Passo 3: Validar a transiçã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 a aplicação quanto a operações de leitura, escrita, transações e comportamento de reconexão. Compare o tempo durante o qual as operações de escrita estiveram indisponíveis e o resultado da replicação com os seus valores de RTO e RPO antes de continuar.

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

A replicação síncrona pode reduzir o RPO para transações reconhecidas, mas adiciona latência de commit e pode reduzir a disponibilidade de escrita se os standbys necessários não estiverem disponíveis. O exemplo seguinte espera que quaisquer dois standbys nomeados e diretamente ligados reproduzam cada transação comprometida:

# 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 na latência medida, posicionamento do domínio de falha e requisitos de durabilidade. Esta configuração não garante uma duração específica de transição.

Validação de sucesso

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 dos dados e consistência da aplicação são aprovadas.
• Os testes de backup e de restauro foram bem-sucedidos 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 de pico, limita e drena os nós antigos, reimagina-os e repete o processo de acordo com as definiçõ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 gerida.

1. Liste os alvos de atualização suportados para o cluster:

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

2. Confirme que o plano de controlo já está na versão de destino selecionada. Configure as definições de atualização faseada do conjunto de nós com base no comportamento da carga de trabalho observado nos testes, nas quotas e nos endereços disponíveis da sub-rede. O exemplo seguinte utiliza 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 gerida para o pool de nós, utilizando um alvo devolvido 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. Monitorize os eventos de atualização do AKS e a saúde da base de dados ao longo da operação:

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

   Monitorize a replicação, disponibilidade da base de dados, erros de aplicação, latência e saúde do armazenamento no seu sistema de observabilidade. Se um Orçamento de Interrupção de Pods bloquear um dreno, corrija o problema de disponibilidade de carga de trabalho em vez de contornar o orçamento.

Validar e recuperar

Após a atualização gerida terminar, verifique as versões dos nós, a topologia PostgreSQL e o comportamento da aplicação:

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 suporta o downgrade de um cluster ou pool de nós para uma versão anterior do Kubernetes. Se a base de dados não estiver em bom estado, interrompa as operações de escrita da aplicação e utilize o procedimento de recuperação ou de comutação suportado pelo operador da base de dados. Não redirecione operações de escrita para o anterior nó primário do PostgreSQL, a menos que este se tenha reintegrado em segurança na linha temporal 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 cluster ou pool de nós testado e restaurando ou replicando dados de acordo com o seu plano de recuperação.

Atualização gradual do Redis Cluster com prioridade às réplicas

Use este 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 Redis é atualizar primeiro as réplicas, passar manualmente cada primário para uma réplica atualizada e depois atualizar o primário anterior rebaixado. O Cluster Redis pode devolver erros transitórios ou redirecionamentos durante alterações de topologia. Como o Redis Cluster utiliza replicação assíncrona, pode perder gravações confirmadas. Valide o comportamento de retentativas do cliente e o RPO aceitável antes da atualização.

Passo 1: Registar 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

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

Passo 2: Atualizar réplicas

Para cada réplica, uma de cada vez:

1. Use o seu operador ou mecanismo de implementação de carga de trabalho para substituir ou reiniciar a réplica com capacidade AKS melhorada.
2. Espere que o pod fique pronto e que a replicação sincronize.
3. Confirme com CLUSTER NODES que permanece atribuído ao principal esperado.

Não execute CLUSTER FORGET para um reinício de um pod que preserve a identidade do nó Redis. Se o substituto tiver uma nova identidade de nó, use redis-cli --cluster add-node com --cluster-slave e --cluster-master-id para adicioná-lo como uma réplica do primário pretendido. Espere 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>

Passo 3: Fazer failover e atualizar os primários

Para cada primária, uma de cada vez:

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

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

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

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

4. Substituir ou reiniciar o antigo primário rebaixado com capacidade AKS melhorada.

5. Espere que volte como uma réplica presa antes de passar para a próxima primária.

Não uses CLUSTER FAILOVER FORCE nem TAKEOVER durante uma atualização planeada. Essas opções contornam a coordenação normal e exigem procedimentos separados de recuperação de falhas.

Passo 4: Validar o Redis Cluster

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 dos slots, as atribuições de primária para réplica, o estado da replicação, as leituras e escritas da aplicação, o tratamento de redirecionamentos e o RPO observado.

Atualização faseada do conjunto de réplicas do MongoDB, começando pelos secundários

Utilize este padrão para um conjunto de réplicas do MongoDB com três ou mais membros que tenha um secundário elegível. Durante a redução das primárias e a eleição, as escritas falham até que uma nova primária seja eleita. As aplicações devem tentar novamente escritas elegíveis e transações transitórias de acordo com as orientações do driver MongoDB.

Passo 1: Validar o conjunto de réplicas

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

Confirme que todos os membros previstos estão saudáveis, identifique a primária atual e verifique se pelo menos uma escola secundária eleitável está em atraso. Verifica também a última cópia de segurança através de uma restauração de teste.

Passo 2: Melhorar os secundários

Para cada secundário, um de cada vez:

1. Substitua ou reinicie o membro na capacidade atualizada do AKS utilizando o operador ou o mecanismo de implementação da carga de trabalho.

2. Aguarde que o pod fique pronto.

3. Verifique se o membro regressa ao estado SECONDARY e recupera o atraso 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}))"
   

Passo 3: Reduzir o primário

Candidate-se rs.stepDown() apenas contra a primária atual. O primeiro argumento especifica por quanto tempo o antigo primário não pode ser reeleito. O segundo argumento especifica quanto tempo um secundário elegível tem para recuperar o atraso. 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-se ou devolver um erro à medida que o principal desce. Consulte o estatuto de 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 alcançar o nível necessário dentro do período configurado, o primário não abdica da função. Resolva os problemas da replicação antes de voltar a tentar. Não force a redução durante uma atualização planeada.

Passo 4: Atualizar e validar o antigo primário

Substitua ou reinicie o antigo primário com capacidade AKS melhorada. Espere que regresse como um secundário saudável e depois valide:

• Exatamente um membro é PRIMARY.
• Todos os outros membros que contêm dados estão SECONDARY e atualizados.
• As operações de leitura, escrita, escritas passíveis de repetição e as transações da aplicação funcionam como esperado.
• O intervalo de eleição medido satisfaz o RTO da aplicação.
• As verificações de cópia de segurança e restauro são aprovadas.