Confiabilidade do Gateway de Aplicativo para contêineres

Gateway de Aplicativo do Azure para Contêineres é um serviço de balanceamento de carga e gerenciamento dinâmico de tráfego de camada de aplicativo gerenciado (camada 7) para cargas de trabalho em execução no Kubernetes. Ele roteia solicitações de entrada para destinos de back-end em seu cluster.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar 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 Gateway de Aplicativo do Azure para contêineres lida com falhas transitórias, falhas de zona de disponibilidade, falhas em toda a região e manutenção do serviço. Ele também descreve as opções de backup e restauração e as principais informações sobre o SLA (contrato de nível de serviço).

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

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

Para obter um exemplo de arquitetura e diretrizes sobre topologia, fluxo de tráfego, confiabilidade, segurança e operações, consulte Implantar o Gateway de Aplicativo para Contêineres no Serviço de Kubernetes do Azure.

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

Uma implantação do Application Gateway for Containers inclui recursos no Azure e no cluster do Kubernetes.

• recursos do Azure: o plano de controle orquestra a configuração de proxy do gateway com base em sua configuração. O data plane gerenciado pelo Azure é executado fora do cluster e processa o tráfego do aplicativo.
• Recursos do Kubernetes: Você define o roteamento e outras configurações usando recursos do Kubernetes. O Controlador ALB é executado em seu cluster, observa esses recursos e propaga sua configuração para o Application Gateway for Containers no Azure.

Você pode escolher entre duas estratégias de implantação. Com a estratégia bring your own (BYO), você gerencia o ciclo de vida do Gateway de Aplicativo para Contêineres, associação e recursos de front-end por meio de ferramentas do Azure. Com a estratégia gerenciada pelo Controlador ALB, o Controlador ALB gerencia o ciclo de vida desses recursos Azure com base nos recursos do Kubernetes definidos.

Para obter uma descrição completa dos componentes, consulte os componentes do Gateway de Aplicativo para Contêineres.

Depois de implantar e configurar o Application Gateway for Containers, ele roteia as solicitações de entrada para os destinos de back-end, que representam seu aplicativo em execução no Kubernetes.

Se o Controlador do ALB ou o plano de controle não estiver disponível, o plano de dados continuará a processar o tráfego usando a última configuração aplicada com êxito. 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.

Arquitetura física

Azure gerencia e dimensiona automaticamente a infraestrutura do plano de dados com base no tráfego do aplicativo. O Gateway de Aplicativo para Contêineres é sempre implantado em uma configuração altamente disponível: em regiões que dão suporte a zonas de disponibilidade, os gateways são com redundância de zona; em regiões que não dão suporte a zonas de disponibilidade, Azure usa conjuntos de disponibilidade.

Resiliência a falhas transitórias

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

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

Ao usar o Gateway de Aplicativo para Contêineres, considere as seguintes práticas recomendadas:

• Implementar lógica de repetição. Configure os clientes para repetir solicitações após falhas transitórias de conexão.

• Configurar investigações de integridade com tolerância. Se você configurar sondas de integridade personalizadas, defina o limite de não integridade para tolerar falhas transitórias. O limite não saudável especifica o número de verificações com falha consecutivas que disparam o destino de backend a ser marcado como não saudável. A sonda de integridade padrão usa um limite de falhas de três sondas, o que ajuda a evitar que uma única falha transitória de sonda marque o back-end como não íntegro.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Quando você implanta o Gateway de Aplicativo para Contêineres em uma região Azure que dá suporte a zonas de disponibilidade, Microsoft configura automaticamente o plano de controle e o plano de dados como com redundância de zona em várias zonas. Você não seleciona quais zonas o serviço usa.

Requirements

Suporte à região: Para usar a redundância de zona, escolha uma região que dê suporte ao Application Gateway for Containers e a zonas de disponibilidade. Verifique a disponibilidade da região do Application Gateway for Containers e compare-a com a lista de regiões que dão suporte a zonas de disponibilidade.

Considerações

Responsabilidade compartilhada com sua plataforma Kubernetes: Microsoft gerencia o redirecionamento de tráfego para o Application Gateway for Containers durante uma falha de zona. Para AKS (Serviço de Kubernetes do Azure), Microsoft gerencia o plano de controle do Kubernetes. Você é responsável por configurar a resiliência de zona para os pools de nós do cluster e outros recursos gerenciados e pelo comportamento de seus aplicativos durante uma interrupção de zona.

• Cluster: Configure os pools de nós do AKS e outros recursos de cluster vinculados à zona que você gerencia para abranger zonas de disponibilidade. O AKS gerencia o plano de controle; consulte Configurar zonas de disponibilidade para pools de nós do AKS.

• Suas cargas de trabalho: Você é responsável por implantar várias réplicas de pod, espalhá-las entre zonas e garantir que cargas de trabalho de back-end íntegras estejam disponíveis para atender ao tráfego durante uma interrupção de zona. Você pode usar pools de nós que abrangem zonas de disponibilidade, restrições de propagação de topologia e antiafinidade de pod.

• Objetos de configuração do Kubernetes: O Application Gateway for Containers usa objetos de configuração do Kubernetes armazenados pela API do cluster. A disponibilidade deles depende do plano de controle do Kubernetes e da configuração que você gerencia em seu cluster.

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

  O Controlador ALB executa duas réplicas, com uma atuando como líder e a outra como secundária. Se o líder ficar indisponível, o secundário poderá se tornar o líder e continuar propagando a configuração. Ambas as réplicas podem ser executadas na mesma zona de disponibilidade, dependendo de como o cluster as aloca. Você é responsável por configurar os pods de cluster e controlador para resiliência de zona. Use restrições de propagação de topologia de pod ou antiafinidade de pod para distribuir as réplicas entre zonas. Para obter mais informações, consulte Configurar zonas de disponibilidade para pools de nós do AKS.

Custo

O suporte à zona de disponibilidade para o Application Gateway for Containers não incorre em encargos extras além do preço do serviço padrão. Para obter detalhes de preços, consulte preços do Gateway de Aplicativo do Azure.

Configurar o suporte à zona de disponibilidade

Quando você implanta um novo gateway em uma região com suporte, ele é redundante por zona por padrão. Você não precisa habilitar a redundância de zona nos recursos do Azure.

Você é responsável por configurar seu cluster kubernetes, controlador ALB e cargas de trabalho de back-end para resiliência de zona.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando você implanta o Application Gateway for Containers em uma região que dá suporte a zonas de disponibilidade e todas as zonas usadas pelo serviço estão operacionais.

• Operação entre zonas: O plano de dados do Application Gateway for Containers gerenciado pelo Azure distribui solicitações de entrada em toda a infraestrutura em várias zonas.

  Você é responsável por configurar suas cargas de trabalho de back-end para serem executadas em várias zonas e fornecer targets saudáveis para receber esse tráfego.

• Replicação de dados entre zonas: O Gateway de Aplicativo para Contêineres não armazena dados do aplicativo. A plataforma gerencia o estado de configuração por meio do plano de controle com redundância de zona para fornecer durabilidade e resiliência.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando você implanta o Application Gateway for Containers em uma região que dá suporte a zonas de disponibilidade e uma das zonas usadas pelo serviço tem uma interrupção.

• Detecção e resposta: O Application Gateway for Containers redireciona o tráfego para a infraestrutura nas zonas íntegras restantes durante uma interrupção de zona. Você não precisa tomar medidas para a redistribuição de tráfego do gateway.

  No entanto, você é responsável pelo efeito da interrupção em seu cluster do Kubernetes e aplicativos de back-end.

• Notificação: A Microsoft não notifica você automaticamente quando uma zona está inoperante. No entanto, você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Service Health para notificar você sobre problemas.

• Solicitações ativas: As conexões existentes com a zona com falha são descartadas. Os clientes devem repetir as solicitações seguindo as diretrizes em Resiliência para falhas transitórias. Novas conexões são estabelecidas para infraestrutura nas zonas saudáveis restantes.

• Perda de dados esperada: O Gateway de Aplicativo para Contêineres não armazena dados do aplicativo. A plataforma gerencia o estado de configuração por meio do plano de controle com redundância de zona para fornecer durabilidade e resiliência.

• Tempo de inatividade esperado: Os clientes podem sofrer uma breve interrupção quando as conexões com a zona com falha são descartadas. Os clientes devem repetir as solicitações para estabelecer novas conexões com a infraestrutura nas zonas íntegras restantes.

  O plano de controle gerenciado por Azure permanece disponível durante uma interrupção de zona única. No entanto, sua capacidade de aplicar atualizações de configuração também depende da disponibilidade do plano de controle do Kubernetes e do Controlador ALB.

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

Recuperação de zona

O Application Gateway para Contêineres se recupera automaticamente de problemas subjacentes. Azure gerencia a recuperação da infraestrutura do gateway.

Testar falhas em zonas

A plataforma Application Gateway for Containers gerencia o roteamento de tráfego e a resposta a falhas de zona para o próprio gateway. Você não precisa iniciar ou gerenciar a resposta do gateway. Se você tiver um cluster Kubernetes que você gerencia, poderá usar o Azure Chaos Studio para testar a resposta do cluster a falhas de zona. Para obter 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 em que você implantou um gateway ficar indisponível, esse gateway não estará disponível.

Soluções de várias regiões personalizadas para resiliência

O Application Gateway for Containers não fornece uma solução interna de implantação em várias regiões ou failover. Para lidar com uma indisponibilidade de região, implante e configure um gateway separado e um cluster Kubernetes em cada região. Você é responsável por direcionar o tráfego entre os gateways regionais e configurar o failover.

• Configure o Application Gateway for Containers consistentemente entre regiões. Para simplificar as implantações e manter as configurações alinhadas, defina sua infraestrutura como código (IaC) usando ferramentas como Bicep ou Terraform.

• Escolha e configure um serviço global de gerenciamento de tráfego, como Azure Front Door ou Gerenciador de Tráfego do Azure, para direcionar clientes para seus gateways regionais. Esses serviços usam diferentes modelos de roteamento e configurações de sonda de integridade. Configure o serviço selecionado para direcionar o tráfego para longe de um gateway indisponível e examine sua documentação para entender o comportamento de roteamento e as considerações de failover. Azure Front Door também fornece recursos como proteção contra DDoS (negação de serviço distribuído), recursos de WAF (firewall de aplicativo Web) e roteamento baseado em regras.

• Implante seus aplicativos de back-end em cada região e configure-os para fornecer workloads saudáveis durante uma interrupção. Se seus aplicativos dependerem de dados ou de outros serviços Azure, projete e configure esses serviços para disponibilidade de várias regiões também. Examine as diretrizes de confiabilidade de cada serviço para entender suas opções e limitações multirregionais.

Backup e restauração

O Gateway de Aplicativo para Contêineres não armazena dados do aplicativo. Azure Resource Manager armazena a configuração do recurso do Azure do gateway. Você pode recriar esses recursos reimplantando sua configuração.

Você é responsável por preservar a configuração e os recursos do Kubernetes que definem como o gateway é implantado e como o tráfego é roteado:

• Defina os recursos Azure e suas configurações em IaC (infraestrutura como código), como Bicep ou Terraform, e mantenha as definições no controle de versão. Você pode usá-los para reimplantar os recursos do gateway.

• Faça backup dos recursos do Kubernetes que configuram o gateway, como os recursos ApplicationLoadBalancer, Gateway e HTTPRoute. Restaure-os para o cluster quando precisar recriar a configuração de roteamento.

• Mantenha a configuração relacionada, incluindo regras personalizadas e políticas de firewall de aplicativo Web, no controle de versão ou por meio do processo de backup de configuração padrão. Você pode usar pipelines de implantação para recriar os recursos do Azure e do Kubernetes de forma consistente.

Resiliência à manutenção do serviço

Microsoft gerencia a manutenção do Gateway de Aplicativo para Contêineres, mantendo a alta disponibilidade do serviço.

O tamanho mínimo de sub-rede necessário para cada associação de /24 leva em conta as janelas de manutenção, portanto, você não precisa alocar espaço de endereço IP de sub-rede extra para manutenção.

Para obter mais informações, consulte Dimensionamento e disponibilidade para o Gateway de Aplicativo para Contêineres.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de 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 obter mais informações, consulte SLAs para serviços online.

O SLA do Gateway de Aplicativo para Contêineres mede separadamente o plano de controle e o plano de dados. Ambos os níveis são levados em conta no cálculo geral do SLA.

Conteúdo relacionado

• Implantar o Gateway de Aplicativo para Contêineres no Serviço de Kubernetes do Azure
• Relibilidade em Azure