Confiabilidade no Gateway de Aplicativo do Azure para Contêineres

Gateway de Aplicação do Azure for Containers é um serviço gerido de balanceamento de carga e gestão dinâmica de tráfego na camada de aplicação (camada 7) para cargas de trabalho a correr no Kubernetes. Encaminha os pedidos recebidos para os alvos de backend no seu cluster.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como o Gateway de Aplicação do Azure for Containers lida com falhas transitórias, falhas em zonas de disponibilidade, falhas regionais e manutenção de serviços. Descreve também opções de backup e restauro e informações-chave sobre o acordo de nível de serviço (SLA).

Recomendações de implantação de produção para confiabilidade

O Application Gateway for Containers está altamente disponível por defeito. Para cargas de trabalho em produção:

Para um exemplo de arquitetura e orientações sobre topologia, fluxo de tráfego, fiabilidade, segurança e operações, consulte Deploy Application Gateway for Containers on Azure Kubernetes Service.

Visão geral da arquitetura de confiabilidade

Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.

Arquitetura lógica

Uma implementação de Application Gateway para Containers inclui recursos no Azure e no seu cluster Kubernetes.

  • Recursos do Azure: O plano de controlo orquestra a configuração do proxy do gateway com base na sua configuração. O plano de dados gerido pelo Azure corre fora do seu cluster e processa o tráfego das aplicações.
  • Recursos Kubernetes: Defines o roteamento e outras configurações usando recursos Kubernetes. O Controlador ALB corre no seu cluster, monitoriza esses recursos e propaga a sua configuração para o Application Gateway for Containers no Azure.

Pode escolher entre duas estratégias de implantação. Com a estratégia bring your own (BYO), gere o ciclo de vida do Application Gateway para Containers, a associação e os recursos de frontend através das ferramentas do Azure. Com a estratégia gerida pelo controlador ALB, o controlador ALB gere o ciclo de vida desses recursos Azure com base nos recursos Kubernetes que define.

Para uma descrição completa dos componentes, veja componentes do Application Gateway for Containers.

Depois de implementar e configurar o Application Gateway para Containers, ele encaminha os pedidos recebidos para os backend targets, que representam a sua aplicação a correr dentro do Kubernetes.

Se o Controlador ALB ou o plano de controlo não estiverem disponíveis, o plano de dados continua a processar tráfego usando a última configuração aplicada com sucesso. Durante a interrupção, as atualizações de configuração não são propagadas e o serviço não pode aplicar a configuração necessária para eventos de expansão horizontal.

Arquitetura física

O Azure gere e escala automaticamente a infraestrutura do plano de dados com base no tráfego da aplicação. O Application Gateway for Containers é sempre implementado numa configuração altamente disponível: em regiões que suportam zonas de disponibilidade, os gateways são redundantes de zona; em regiões que não suportam zonas de disponibilidade, o Azure utiliza conjuntos de disponibilidade.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Ao usar o Application Gateway para Containers, considere as seguintes boas práticas:

  • Implemente a lógica de repetição de tentativas. Configure os clientes para tentarem novamente pedidos após falhas de ligação transitórias.

  • Configure sondas de saúde com tolerância. Se configurares sondas de saúde personalizadas, define o limiar de insucesso para tolerar falhas transitórias. O limiar de estado não saudável especifica o número de sondas consecutivas falhadas que fazem com que o alvo do backend seja marcado como não saudável. A sonda de saúde padrão usa um limiar de falha de três sondas, o que ajuda a evitar que uma única falha transitória da sonda marque o backend como pouco saudável.

Resiliência a falhas na zona de disponibilidade

Zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Quando implementa o Application Gateway for Containers numa região Azure que suporta zonas de disponibilidade, a Microsoft configura automaticamente o plano de controlo e o plano de dados como redundantes de zona em várias zonas. Não selecionas quais as zonas que o serviço utiliza.

Importante

A Microsoft gere a redundância de zonas para o plano de controlo do Application Gateway for Containers e do plano de dados. Para alcançar resiliência de ponta a ponta entre zonas, configure o seu cluster Kubernetes, recursos Kubernetes e cargas de trabalho backend para fornecer destinos saudáveis entre as zonas.

Requirements

Suporte de região: Para usar redundância de zona, escolha uma região que suporte tanto o Application Gateway para Containers como as zonas de disponibilidade. Verifique a disponibilidade regional do Application Gateway for Containers e compare com a lista de regiões que suportam zonas de disponibilidade.

Considerations

Responsabilidade partilhada com a sua plataforma Kubernetes: a Microsoft gere o redirecionamento de tráfego para o Application Gateway para Containers durante uma falha de zona. Para Azure Kubernetes Service (AKS), Microsoft gere o Kubernetes control plane. És responsável por configurar a resiliência das zonas para os pools de nós do teu cluster e outros recursos que geres, bem como pelo comportamento das tuas aplicações durante uma falha de zona.

  • Cluster: Configure os seus pools de nós AKS e outros recursos de cluster delimitados por zonas que gere para abranger zonas de disponibilidade. O AKS gere o plano de controlo; ver Configurar zonas de disponibilidade para pools de nós AKS.

  • As suas cargas de trabalho: É responsável por implementar múltiplas réplicas de pods, distribuí-las por zonas e garantir que estejam disponíveis cargas de trabalho backend saudáveis para servir o tráfego durante uma interrupção de zona. Pode usar pools de nós que abrangem zonas de disponibilidade, restrições de dispersão topológica e anti-afinidade de pods.

  • Objetos de configuração Kubernetes: O Application Gateway para Contentores utiliza objetos de configuração Kubernetes armazenados pela API do cluster. A sua disponibilidade depende do plano de controlo Kubernetes e da configuração que gere no seu cluster.

  • Controlador ALB: Implemente o Controlador ALB no seu cluster Kubernetes para reconciliar a configuração. Não faz parte do caminho de dados do Application Gateway for Containers.

    O Controlador ALB executa duas réplicas, uma a atuar como líder e a outra como secundária. Se o líder ficar indisponível, o secundário pode tornar-se o líder e continuar a propagar a configuração. Ambas as réplicas podem funcionar na mesma zona de disponibilidade, dependendo de como o cluster as programa. És responsável por configurar o cluster e os pods de controlo para a resiliência das zonas. Utilize restrições de dispersão da topologia de pods ou anti-afinidade de pods para distribuir as réplicas entre zonas. Para mais informações, consulte Configurar zonas de disponibilidade para pools de nós AKS.

Custo

O suporte a zonas de disponibilidade para o Application Gateway for Containers não implica custos adicionais para além do preço padrão do serviço. Para detalhes de preços, consulte os preços do Gateway de Aplicação do Azure.

Configurar o suporte à zona de disponibilidade

Ao implementar um novo gateway numa região suportada, fica com redundância entre zonas por defeito. Não precisas de ativar a redundância de zonas nos recursos do Azure.

És responsável por configurar o teu cluster Kubernetes, o controlador ALB e as cargas de trabalho backend para a resiliência das zonas.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar ao implementar o Application Gateway para Containers numa região que suporta zonas de disponibilidade e todas as zonas utilizadas pelo serviço estão operacionais.

  • Operação entre zonas: O plano de dados Application Gateway for Containers gerido pelo Azure distribui os pedidos recebidos entre infraestruturas em múltiplas zonas.

    És responsável por configurar as tuas cargas de trabalho backend para serem distribuídas por zonas e por fornecer destinos íntegros para receber esse tráfego.

  • Replicação de dados entre zonas: O Application Gateway for Containers não armazena dados da aplicação. A plataforma gere o estado de configuração através do plano de controlo redundante de zona para garantir durabilidade e resiliência.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando implementa o Application Gateway para Contentores numa região que suporta zonas de disponibilidade e uma das zonas utilizadas pelo serviço sofre uma falha.

  • Deteção e resposta: O Gateway de Aplicações para Contentores redireciona o tráfego para a infraestrutura nas restantes zonas saudáveis durante uma interrupção de zona. Não precisa de agir para a redistribuição de tráfego do gateway.

    No entanto, és responsável pelo efeito da interrupção no teu cluster Kubernetes e nas aplicações backend.

  • Solicitações ativas: As ligações existentes à zona falhada são canceladas. Os clientes devem tentar novamente as solicitações seguindo as orientações da Resiliência para falhas transitórias. Novas ligações são estabelecidas à infraestrutura nas restantes zonas operacionais.

  • Perda de dados esperada: O Application Gateway for Containers não armazena dados da aplicação. A plataforma gere o estado de configuração através do plano de controlo redundante de zona para garantir durabilidade e resiliência.

  • Tempo de inatividade previsto: Os clientes podem experienciar uma breve interrupção quando as ligações à zona falhada forem interrompidas. Os clientes devem tentar novamente as solicitações para estabelecer novas ligações à infraestrutura nas restantes zonas saudáveis.

    O plano de controlo gerido pelo Azure mantém-se disponível durante uma interrupção de zona única. No entanto, a sua capacidade de aplicar atualizações de configuração também depende da disponibilidade do seu plano de controlo Kubernetes e do controlador ALB.

  • Redistribuição: O Application Gateway for Containers redireciona o tráfego para a infraestrutura nas zonas restantes saudáveis.

Recuperação de zona

O Application Gateway para Containers recupera-se de forma autónoma de problemas subjacentes. O Azure gere a recuperação da infraestrutura do gateway.

Teste de falhas de zona

A plataforma Application Gateway for Containers gere o encaminhamento do tráfego e a resposta a falhas de zona para o próprio gateway. Não precisa de iniciar ou gerir a resposta do gateway. Se tiveres um cluster Kubernetes que geres, podes usar o Azure Chaos Studio para testar a resposta do cluster a falhas de zona. Para mais informações, consulte Teste de resiliência da zona de disponibilidade.

Resiliência a falhas em toda a região

O Application Gateway for Containers é um serviço de região única. Se a região do Azure onde implementaste um gateway ficar indisponível, esse gateway fica indisponível.

Soluções multirregional personalizadas para resiliência

O Application Gateway for Containers não fornece uma solução integrada de implementação multirregional ou failover. Para projetar para uma falha de região, implemente e configure um gateway e cluster Kubernetes separados em cada região. És responsável por direcionar o tráfego entre os gateways regionais e configurar o failover.

  • Configure o Application Gateway para Containers de forma consistente entre regiões. Para simplificar as implementações e manter as configurações alinhadas, defina a sua infraestrutura como código (IaC) usando ferramentas como o Bicep ou o Terraform.

  • Escolha e configure um serviço global de gestão de tráfego, como o Azure Front Door ou o Gestor de Tráfego do Azure, para direcionar os clientes para os seus gateways regionais. Estes serviços utilizam diferentes modelos de encaminhamento e configurações de sondas de saúde. Configure o serviço selecionado para direcionar o tráfego para longe de um gateway indisponível e reveja a sua documentação para compreender o comportamento de encaminhamento e as considerações sobre failover. O Azure Front Door também oferece funcionalidades como proteção contra negação de serviço distribuída (DDoS), capacidades de firewall de aplicações web (WAF) e encaminhamento baseado em regras.

  • Implemente as suas aplicações backend em cada região e configure-as para fornecer cargas de trabalho saudáveis durante uma interrupção. Se as suas aplicações dependem de dados ou outros serviços Azure, conceba e configure esses serviços para disponibilidade multirregional também. Revise as orientações de fiabilidade de cada serviço para compreender as suas opções multirregionais e limitações.

Backup e restauração

O Application Gateway for Containers não armazena dados de aplicação. O Azure Resource Manager armazena a configuração de recursos do Azure do gateway. Pode recriar estes recursos voltando a implementar a sua configuração.

És responsável por preservar a configuração e os recursos Kubernetes que definem como o gateway é implantado e encaminha o tráfego:

  • Defina os recursos do Azure e as respetivas configurações na infraestrutura como código (IaC), como Bicep ou Terraform, e mantenha as definições no controlo de versões. Podes usá-los para reimplementar os recursos do gateway.

  • Faça backup dos recursos Kubernetes que configuram o gateway, como recursos ApplicationLoadBalancer, Gateway e HTTPRoute. Restaura-os no teu cluster quando precisares de recriar a configuração do encaminhamento.

  • Mantenha a configuração relacionada, incluindo regras personalizadas e políticas de firewall de aplicações web, no controlo de versões ou através do seu processo padrão de backup de configuração. Podes usar pipelines de implantação para recriar os recursos do Azure e Kubernetes de forma consistente.

Resiliência à manutenção de serviços

A Microsoft gere a manutenção do Application Gateway para Containers, mantendo a elevada disponibilidade do serviço.

O tamanho mínimo de sub-rede exigido de /24 para cada associação tem em conta as janelas de manutenção, por isso não precisa de alocar espaço extra de endereços IP para manutenção.

Para mais informações, consulte Escalabilidade e disponibilidade para Application Gateway para Contentores.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para mais informações, consulte Acordos de Nível de Serviço (SLA) para serviços online.

O Application Gateway para Containers SLA mede separadamente o plano de controlo e o plano de dados. Ambos os planos são considerados no cálculo global do SLA.

Conteúdo relacionado

  • Última atualização a