Rearquitar o aplicativo Web EKS do AWS para o AKS (Serviço de Kubernetes do Azure)

Agora que você tem uma melhor compreensão das diferenças de plataforma entre o AWS e o Azure, vamos examinar a arquitetura do aplicativo Web no AWS e as modificações necessárias para torná-la compatível com o AKS (Serviço de Kubernetes do Azure).

Arquitetura do aplicativo Yelb

O aplicativo Web de exemplo yelb consiste em um componente front-end chamado yelb-ui e um componente de aplicativo chamado yelb-appserver.

Diagrama de arquitetura do aplicativo Web Yelb.

O yelb-ui fornece código JavaScript ao navegador. Esse código é compilado a partir de um aplicativo Angular . O yelb-ui componente também pode incluir um nginx proxy dependendo do modelo de implantação. O yelb-appserver é um aplicativo Sinatra que interage com um servidor de cache (redis-server) e um banco de dados backend Postgres (yelb-db). O Cache Redis armazena o número de exibições de página, enquanto o PostgreSQL persiste os votos. Ambos os serviços são implantados no Kubernetes sem usar nenhum serviço gerenciado para armazenar dados no AWS ou no Azure.

O aplicativo Yelb original é autocontido e não depende de serviços externos, portanto, você pode migrá-lo do AWS para o Azure sem alterações de código. No Azure, você pode usar o Redis Gerenciado do Azure e o Banco de Dados do Azure para PostgreSQL como substituições para os serviços Cache Redis e PostgreSQL implantados no AKS.

O aplicativo de exemplo do Yelb permite que os usuários votem em um conjunto de alternativas (restaurantes) e atualiza dinamicamente gráficos de pizza com base no número de votos recebidos. O aplicativo também controla o número de exibições de página e exibe o hostname da instância que yelb-appserver atende à solicitação de API após uma votação ou atualização da página. Esse recurso permite que você demoize o aplicativo de forma independente ou colaborativa.

Captura de tela da interface de serviço Yelb.

Arquitetura no AWS

Para ajudar a proteger aplicativos Web e APIs contra explorações comuns da Web, a AWS oferece o WAF (Firewall de Aplicativo Web) da AWS e o Gerenciador de Firewall do AWS.

Mapear serviços do AWS para os serviços do Azure

Para recriar a carga de trabalho do AWS no Azure com alterações mínimas, use um equivalente do Azure para cada serviço do AWS. A tabela a seguir resume os mapeamentos de serviço:

Mapeamento de serviço	Serviço AWS	Serviço do Azure
Firewall de acesso à Web	WAF (Firewall do Aplicativo Web) do AWS	WAF (Firewall do Aplicativo Web) do Azure
Balanceamento de carga do aplicativo	ALB (Application Load Balancer)	Gateway de Aplicativo do Azure Gateway de Aplicativo para Contêineres (AGC)
Rede de distribuição de conteúdo	Amazon CloudFront	AFD (Azure Front Door)
Orquestração	EKS (Serviço de Kubernetes Elástico)	AKS (Serviço de Kubernetes do Azure)
Cofre de segredos	KMS (Serviço de Gerenciamento de Chaves) do AWS	Azure Key Vault
Registro de contêiner	Registro de Contêiner Elástico da Amazon (ECR)	Registro de Contêiner do Azure (ACR)
Sistema de nome de domínio (DNS)	Amazon Route 53	Azure DNS
Cache	Amazon ElastiCache	Redis Gerenciado do Azure
NoSQL	Amazon DynamoDB	Banco de Dados do Azure para PostgreSQL

Para obter uma comparação abrangente entre os serviços do Azure e da AWS, confira Comparação de serviços AWS e Azure.

Arquitetura no Azure

Nesta solução, o aplicativo Yelb é implantado em um cluster do AKS e é exposto por meio de um controlador de entrada como o controlador de entrada NGINX. O serviço do controlador de entrada é exposto por meio de um balanceador de carga interno (ou privado). Para obter mais informações sobre como usar um balanceador de carga interno para restringir o acesso aos seus aplicativos no AKS, consulte Usar um balanceador de carga interno com o AKS (Serviço de Kubernetes do Azure).

Este exemplo dá suporte à instalação de um controlador de entrada NGINX gerenciado com o complemento de roteamento de aplicativo ou um controlador de entrada NGINX não gerenciado usando o gráfico helm. O complemento de roteamento de aplicativos com o controlador de entrada NGINX fornece os seguintes recursos:

Configuração fácil de controladores de entrada NGINX gerenciados com base no controlador de entrada do Kubernetes NGINX.
Integração com o DNS do Azure para gerenciamento de zona pública e privada.
Terminação SSL com certificados armazenados no Azure Key Vault.

Para outras configurações, consulte os seguintes artigos:

O aplicativo Yelb é protegido com um recurso do Gateway de Aplicativo do Azure implantado em uma sub-rede dedicada dentro da mesma rede virtual que o cluster do AKS ou em uma rede virtual emparelhada. Você pode proteger o acesso ao aplicativo Yelb usando o WAF (Firewall de Aplicativo Web) do Azure, que fornece proteção centralizada de aplicativos Web contra explorações e vulnerabilidades comuns.

Design da arquitetura da solução

O diagrama a seguir mostra a arquitetura recomendada no Azure:

A arquitetura da solução consiste no seguinte:

O Gateway de Aplicativo do Azure lida com a terminação TLS e se comunica com o aplicativo de backend via HTTPS.
O Listener do Gateway de Aplicativo usa um certificado SSL obtido do Azure Key Vault.
A Política de WAF do Azure associada ao Ouvinte executa regras OWASP e regras personalizadas contra as solicitações de entrada e bloqueia ataques mal-intencionados.
As configurações HTTP do back-end do Gateway de Aplicativo invocam o aplicativo Yelb via HTTPS na porta 443.
O pool de backend do Gateway de Aplicativo e o Health Probe chamam o controlador de entrada NGINX por meio do balanceador de carga interno do AKS usando HTTPS.
O controlador de entrada NGINX usa o balanceador de carga interno do AKS.
O cluster do AKS é configurado com o provedor Azure Key Vault para o complemento do Driver CSI do repositório de segredos para recuperar segredos, certificados e chaves do Azure Key Vault por meio de um volume CSI.
Um SecretProviderClass recupera o mesmo certificado usado pelo Gateway de Aplicativo do Azure Key Vault.
Um objeto de entrada do Kubernetes emprega o controlador de entrada NGINX para expor o aplicativo por meio de HTTPS por meio do balanceador de carga interno do AKS.
O serviço Yelb é do tipo ClusterIP e é exposto por meio do controlador de entrada NGINX.

Para obter instruções abrangentes sobre como implantar o aplicativo Yelb no AKS usando essa arquitetura, consulte o exemplo complementar.

Soluções alternativas

O Azure oferece várias opções para implantar um aplicativo Web em um cluster do AKS e protegê-lo com um firewall de aplicativo Web:

O AGIC (Controlador de Entrada do Gateway de Aplicativo) é um aplicativo kubernetes, portanto, você pode aproveitar o balanceador de carga L7 do Gateway de Aplicativo nativo do Azure para expor o software de nuvem à Internet para suas cargas de trabalho do AKS (Serviço de Kubernetes do Azure ). O AGIC monitora o cluster do Kubernetes no qual ele está hospedado e atualiza continuamente um Gateway de Aplicativo para que os serviços selecionados sejam expostos à Internet.

O Controlador de Entrada é executado em seu próprio pod no cluster do AKS. O AGIC monitora um subconjunto de Recursos do Kubernetes para alterações, converte o estado do cluster em uma configuração específica do Gateway de Aplicativo e aplica-o ao ARM (Azure Resource Manager). Para obter mais informações, consulte o que é o Controlador de Entrada do Gateway de Aplicativo?.

A tabela a seguir descreve as vantagens e desvantagens do AGIC (Controlador de Entrada do Gateway de Aplicativo):

Vantagens	Desvantagens
* Integração nativa: o AGIC fornece integração nativa com os serviços do Azure, especificamente o Gateway de Aplicativo do Azure, que permite o roteamento contínuo e eficiente do tráfego para serviços em execução no AKS. * Implantações simplificadas: Implantar o AGIC como um add-on do AKS é direto e mais fácil em comparação com outros métodos. Ele habilita uma configuração rápida e fácil de um Gateway de Aplicativo e um cluster do AKS com o AGIC habilitado. * Serviço totalmente gerenciado: o AGIC como complemento é um serviço totalmente gerenciado, fornecendo benefícios como atualizações automáticas e maior suporte da Microsoft. Ele garante que o Controlador de Entrada permaneça up-to-date e adiciona uma camada extra de suporte.	* Abordagem de nuvem única: o AGIC é adotado principalmente por clientes que adotam uma abordagem de nuvem única. Talvez não seja a melhor opção se você precisar de uma arquitetura de várias nuvens em que a implantação em diferentes plataformas de nuvem seja um requisito. Nesse caso, talvez você queira usar um controlador de entrada independente de nuvem, como NGINX, Traefik ou HAProxy, para evitar problemas de bloqueio de fornecedor.

Vantagens

Desvantagens

* Integração nativa: o AGIC fornece integração nativa com os serviços do Azure, especificamente o Gateway de Aplicativo do Azure, que permite o roteamento contínuo e eficiente do tráfego para serviços em execução no AKS.
* Implantações simplificadas: Implantar o AGIC como um add-on do AKS é direto e mais fácil em comparação com outros métodos. Ele habilita uma configuração rápida e fácil de um Gateway de Aplicativo e um cluster do AKS com o AGIC habilitado.
* Serviço totalmente gerenciado: o AGIC como complemento é um serviço totalmente gerenciado, fornecendo benefícios como atualizações automáticas e maior suporte da Microsoft. Ele garante que o Controlador de Entrada permaneça up-to-date e adiciona uma camada extra de suporte.

* Abordagem de nuvem única: o AGIC é adotado principalmente por clientes que adotam uma abordagem de nuvem única. Talvez não seja a melhor opção se você precisar de uma arquitetura de várias nuvens em que a implantação em diferentes plataformas de nuvem seja um requisito. Nesse caso, talvez você queira usar um controlador de entrada independente de nuvem, como NGINX, Traefik ou HAProxy, para evitar problemas de bloqueio de fornecedor.

Para obter mais informações, consulte os seguintes recursos:

O Gateway de Aplicativo do Azure para Contêineres fornece balanceamento de carga e gerenciamento dinâmico de tráfego para aplicativos em clusters de Kubernetes.

Características principais

O Gateway de Aplicativo do Azure para Contêineres baseia-se nos recursos do AGIC (Controlador de Entrada do Gateway de Aplicativo) e permite que você use o balanceador de carga nativo do Gateway de Aplicativo do Azure. Os principais recursos incluem:

Balanceamento de carga: distribui com eficiência o tráfego de entrada em vários contêineres para um desempenho e escalabilidade ideais.
Implementação da API de Gateway: dá suporte à API do Gateway, permitindo que você defina regras e políticas de roteamento de maneira nativa do Kubernetes.
Probes de integridade personalizadas: defina probes de integridade personalizadas para monitorar a integridade do contêiner e encaminhar automaticamente o tráfego para longe de instâncias comprometidas.
Afinidade de sessão: fornece afinidade de sessão, roteando solicitações subsequentes do mesmo cliente para o mesmo contêiner para uma experiência de usuário consistente.
Política TLS: dá suporte à terminação TLS, permitindo que a criptografia e a descriptografia do SSL/TLS sejam descarregadas para o gateway.
Reescritas de cabeçalhos: Reescreva os cabeçalhos HTTP das solicitações e respostas do cliente a partir dos destinos do back-end usando a IngressExtension definição de recurso personalizada. Para obter mais informações, consulte a API de Entrada e a API de Gateway.
Reescritas de URL: modifique a URL das solicitações do cliente, incluindo o nome do host e/ou o caminho, e inclua a nova URL reescrita ao iniciar solicitações para alvos de back-end. Para obter mais informações, consulte a API de Entrada e a API de Gateway.

Limitações

Atualmente, o Gateway de Aplicativo do Azure para Contêineres não dá suporte aos seguintes recursos:

Para obter mais informações, consulte Implantar um cluster do AKS (Serviço de Kubernetes do Azure) com o Gateway de Aplicativo para Contêineres.

O Azure Front Door é um balanceador de carga de camada 7 global que expõe e protege com segurança cargas de trabalho em execução no AKS usando o Firewall do Aplicativo Web do Azure e um serviço de Link Privado do Azure .

Essa solução usa o Azure Front Door Premium, a criptografia TLS de ponta a ponta, o Firewall do Aplicativo Web do Azure e um serviço de Link Privado para expor e proteger com segurança uma carga de trabalho executada no AKS.

Funcionalidade de descarregamento do TLS do Azure Front Door e SSL (Secure Sockets Layer) para encerrar conexões TLS e descriptografar o tráfego de entrada na porta da frente. O Azure Front Door reenscriptografa o tráfego de entrada antes de encaminhá-lo para o aplicativo Web hospedado pelo AKS. Essa prática impõe criptografia TLS de ponta a ponta para todo o processo de solicitação, desde o cliente até a origem. Para obter mais informações, consulte Proteja sua origem com Private Link no Azure Front Door Premium.

O controlador de entrada NGINX expõe o aplicativo Web hospedado no AKS. Ele é configurado para usar um endereço IP privado como uma configuração de IP de front-end do kubernetes-internal balanceador de carga interno e usa HTTPS como o protocolo de transporte para expor o aplicativo Web. Para obter mais informações, consulte Criar um controlador de entrada usando um endereço IP interno.

Recomendamos essa solução para cenários em que você está implantando o mesmo aplicativo Web em vários clusters regionais do AKS para continuidade de negócios e recuperação de desastre, ou até mesmo em várias plataformas de nuvem ou instalações locais. Nesse caso, o Front Door pode encaminhar chamadas de entrada para um dos back-ends (também conhecidos como origens) usando um dos seguintes métodos de roteamento:

Latência: o roteamento baseado em latência garante que as solicitações sejam enviadas para as origens de latência mais baixas aceitáveis dentro de um intervalo de confidencialidade. Em outras palavras, as solicitações são enviadas para o conjunto de origens mais próximo em relação à latência de rede.
Prioridade: você pode definir prioridades para origens quando quiser configurar uma origem primária para atender a todo o tráfego. A origem secundária pode ser um backup caso a origem primária fique indisponível.
Ponderado: Você pode atribuir um peso às suas origens quando quiser distribuir o tráfego entre um conjunto de origens de forma uniforme ou de acordo com os coeficientes de ponderação. O tráfego será distribuído pelo valor de ponderação se as latências das origens estiverem dentro do intervalo aceitável de sensibilidade de latência do grupo de origem.
Afinidade de sessão: você pode configurar a afinidade de sessão para seus hosts ou domínios de front-end para garantir que as solicitações do mesmo usuário final sejam enviadas para a mesma origem.

Para obter mais informações, consulte Usar o Azure Front Door para proteger cargas de trabalho do AKS.

Comentários

Esta página foi útil?

Last updated on 2026-04-01