Entenda o despejo de lagoas durante interrupções zonais

Isolamento de nós: todos os nós na Zona de Disponibilidade comprometida são isolados. Isso impede que o programador do Kubernetes coloque novos pods nos nós enquanto mantém as cargas de trabalho existentes.

Suspensão do rebalanceamento da zona de disponibilidade: para grupos de nós gerenciados, as operações de rebalanceamento da zona de disponibilidade são suspensas e os grupos do Auto Scaling são atualizados para iniciar novos nós do plano de dados exclusivamente em zonas de disponibilidade saudáveis. Isso garante que a nova capacidade não seja provisionada na zona prejudicada.

Remoção do endpoint: o EndpointSlice controlador remove os endpoints do pod na zona de disponibilidade prejudicada de todos os itens relevantes. EndpointSlices Isso garante que os mecanismos de descoberta de serviços e balanceamento de carga direcionem o tráfego somente para pods que estão sendo executados em zonas de disponibilidade saudáveis.

Preservação da carga de trabalho: o Amazon EKS se abstém de encerrar nós ou remover pods na zona de disponibilidade afetada. Ele mantém a capacidade total na zona prejudicada para que, quando a mudança zonal expirar ou for cancelada, o tráfego possa retornar com segurança sem exigir operações adicionais de escalonamento.

O deslocamento zonal manual fornece controle orientado pelo operador quando problemas específicos da zona de disponibilidade são detectados por meio de monitoramento, alertas ou relatórios de clientes. Esse método requer ação explícita por meio do console ARC, AWS Command Line Interface (AWS CLI) ou mudança APIs zonal, em que os operadores especificam a zona de disponibilidade prejudicada e definem um prazo de expiração para o turno. Os turnos manuais são apropriados quando as equipes têm recursos dedicados de monitoramento e plantão e preferem manter o controle direto sobre as decisões de gerenciamento de tráfego.

O deslocamento automático zonal AWS autoriza o início automático de turnos quando o ARC detecta possíveis falhas ou deficiências na zona de disponibilidade com base em telemetria interna e sinais de saúde em vários, Serviços da AWS incluindo métricas de rede, Amazon Elastic Compute Cloud (Amazon) e Elastic Load Balancing. EC2 AWS encerra automaticamente um deslocamento automático quando os indicadores mostram que o problema foi resolvido. Se você deseja a postura de maior disponibilidade com o mínimo de intervenção manual, recomendamos essa abordagem, pois ela permite uma resposta em menos de um minuto às deficiências detectadas na Zona de Disponibilidade.

Distribuição de nós Multi-AZ: provisione nós de trabalho em pelo menos três zonas de disponibilidade para garantir redundância suficiente quando uma zona ficar indisponível.

Planejamento de capacidade: pré-provisione capacidade computacional suficiente em zonas de disponibilidade saudáveis para acomodar toda a carga de trabalho quando uma zona de disponibilidade é removida do serviço, pois as operações de escalabilidade durante uma interrupção ativa podem encontrar capacidade insuficiente.

Distribuição e pré-escalonamento de pods: implante várias réplicas de cada aplicativo em todas as zonas de disponibilidade e pré-escale componentes críticos do sistema, como o CoreDNS, em todas as zonas. Isso ajuda a garantir que a capacidade suficiente permaneça após a mudança de uma zona.

Habilite a mudança zonal na criação do cluster: Para novos clusters EKS, habilite a integração do deslocamento zonal com o ARC durante o provisionamento inicial por meio do console Amazon EKS ou de ferramentas de infraestrutura como código (IaC) AWS CLI, como. AWS CloudFormation Os clusters do EKS Auto Mode criados com configuração rápida têm a mudança de zona ativada por padrão.

Selecione o método de ativação apropriado: escolha o deslocamento automático zonal para ambientes de produção que exigem disponibilidade máxima com resposta automatizada, especialmente para aplicativos voltados para o cliente, nos quais minutos de inatividade durante um comprometimento da zona de disponibilidade podem ter um impacto significativo nos negócios. Use a mudança de zona manual para ambientes em que as equipes de operações preferem fornecer aprovação explícita antes das mudanças de tráfego ou onde os testes e a validação de aplicativos ainda estão em andamento.

Teste a resiliência antes da implantação na produção: valide o comportamento do cluster sob perda de Single-AZ iniciando manualmente as mudanças zonais de teste ou habilitando a prática de mudança automática zonal para verificar se os aplicativos mantêm a disponibilidade, o desempenho permanece aceitável e a capacidade é suficiente ao operar com uma contagem reduzida de zonas de disponibilidade. É altamente recomendável esse teste para que você possa identificar lacunas na configuração antes que ocorram deficiências reais na Zona de Disponibilidade.

Coordene com a configuração do balanceador de carga: para aplicativos que recebem tráfego externo, ative a mudança zonal ARC nos balanceadores de carga de aplicativos e balanceadores de carga de rede associados para garantir que o tráfego de entrada e o tráfego no cluster leste-oeste mudem juntos durante deficiências na zona de disponibilidade. Essa coordenação evita cenários em que solicitações externas chegam a pods saudáveis, mas esses pods não conseguem se comunicar com dependências na zona afastada.

Monitore as operações de turno: depois de ativar o turno zonal, configure o monitoramento e o alerta para eventos de turno, incluindo ativações de turnos automáticos, iniciações manuais de turnos e vencimentos de turnos, para manter a visibilidade operacional das ações de gerenciamento de tráfego e seu impacto no comportamento do aplicativo.