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

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

Arquitetura da aplicação 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 da aplicação web Yelb.

O yelb-ui serve código JavaScript para o navegador. Este código é compilado a partir de uma aplicação 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 back-end Postgres (yelb-db). O Cache Redis armazena o número de visualizaçõ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 na AWS ou no Azure.

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

A aplicação Yelb de amostra permite aos utilizadores votar num conjunto de alternativas (restaurantes) e atualiza dinamicamente os gráficos circulares com base no número de votos recebidos. O aplicativo também controla o número de visualizações de página e exibe o nome do host da yelb-appserver instância que atende a solicitação de API após uma votação ou uma atualização de página. Esse recurso permite que você demonstre o aplicativo de forma independente ou colaborativa.

Screenshot da interface do serviço Yelb.

Arquitetura na AWS

Para ajudar a proteger aplicativos da web e APIs contra explorações comuns da web, a AWS oferece o AWS Web Application Firewall (WAF) e o AWS Firewall Manager.

Mapeie os serviços da AWS para os serviços do Azure

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

Mapeamento de serviços	Serviço da AWS	Serviço do Azure
Firewall de acesso à Web	AWS Web Application Firewall (WAF)	Firewall de Aplicativo Web do Azure (WAF)
Balanceamento de carga de aplicação	Balanceador de carga de aplicativo (ALB)	Azure Application Gateway Application Gateway for Containers (AGC)
Rede de entrega de conteúdos	Amazon CloudFront	Azure Front Door (AFD)
Orquestração	Serviço Elastic Kubernetes (EKS)	Serviço Kubernetes do Azure (AKS)
Cofre de segredos	Serviço de gerenciamento de chaves da AWS (KMS)	Azure Key Vault
Registo de containers	Registro do Amazon Elastic Container (ECR)	Registo de Contêineres do Azure (ACR)
Sistema de Nomes de Domínio (DNS)	Rota da Amazônia 53	Azure DNS
Armazenamento em cache	Amazon ElastiCache	Azure Cache for Redis
NoSQL	Amazon DynamoDB	Base de Dados do Azure para PostgreSQL

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

Arquitetura no Azure

Nesta solução, o aplicativo Yelb é implantado em um cluster AKS e é exposto através de um controlador de entrada como o controlador de entrada NGINX. O serviço de 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 Serviço Kubernetes do Azure (AKS).

Este exemplo suporta a 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 controlador de ingresso NGINX fornece os seguintes recursos:

Fácil configuração de controladores de entrada NGINX gerenciados baseados no controlador de entrada NGINX Kubernetes.
Integração com o DNS do Azure para gestão de zonas públicas e privadas.
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 AKS ou em uma rede virtual emparelhada. Você pode proteger o acesso ao aplicativo Yelb usando o Azure Web Application Firewall (WAF), que fornece proteção centralizada de aplicativos Web contra exploits e vulnerabilidades comuns.

Projeto de arquitetura de solução

O diagrama a seguir mostra a arquitetura recomendada no Azure:

A arquitetura da solução consiste no seguinte:

O Application Gateway lida com a terminação TLS e se comunica com o aplicativo back-end por HTTPS.
O Escutador do Gateway de Aplicação usa um certificado SSL obtido do Cofre de Chaves do Azure.
A Política 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 de Back-end do Application Gateway invocam o aplicativo Yelb via HTTPS na porta 443.
O Pool de Back-end do Application Gateway e a Sonda de Integridade 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 AKS.
O cluster AKS está configurado para utilizar o fornecedor Azure Key Vault para o complemento do Driver do Secrets Store CSI, com o objetivo de 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 Cofre de Chaves do Azure.
Um objeto de entrada do Kubernetes emprega o controlador de entrada NGINX para expor o aplicativo via HTTPS através do balanceador de carga interno do AKS.
O serviço Yelb é do tipo ClusterIP e é exposto através 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 AKS e protegê-lo com um firewall de aplicativo Web:

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

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

A tabela a seguir descreve as vantagens e desvantagens do Application Gateway Ingress Controller (AGIC):

Vantagens	Desvantagens
* Integração nativa: a AGIC fornece integração nativa com os serviços do Azure, especificamente o Azure Application Gateway, que permite o roteamento contínuo e eficiente do tráfego para serviços executados no AKS. * Implantações simplificadas: A implantação do AGIC como um complemento AKS é direta e mais simples em comparação com outros métodos. Ele permite uma configuração rápida e fácil de um Application Gateway e um cluster AKS com AGIC habilitado. * Serviço totalmente gerenciado: AGIC como um complemento é um serviço totalmente gerenciado, fornecendo benefícios como atualizações automáticas e maior suporte da Microsoft. Ele garante que o Ingress Controller permaneça up-toatualizado e adiciona uma camada extra de suporte.	* Abordagem de nuvem única: a AGIC é adotada principalmente por clientes que adotam uma abordagem de nuvem única. Pode não ser a melhor escolha se você precisar de uma arquitetura multicloud onde a implantação em diferentes plataformas de nuvem é um requisito. Nesse caso, você pode querer usar um controlador de entrada independente da nuvem, como NGINX, Traefik ou HAProxy para evitar problemas de bloqueio de vendo.

Vantagens

Desvantagens

* Integração nativa: a AGIC fornece integração nativa com os serviços do Azure, especificamente o Azure Application Gateway, que permite o roteamento contínuo e eficiente do tráfego para serviços executados no AKS.
* Implantações simplificadas: A implantação do AGIC como um complemento AKS é direta e mais simples em comparação com outros métodos. Ele permite uma configuração rápida e fácil de um Application Gateway e um cluster AKS com AGIC habilitado.
* Serviço totalmente gerenciado: AGIC como um complemento é um serviço totalmente gerenciado, fornecendo benefícios como atualizações automáticas e maior suporte da Microsoft. Ele garante que o Ingress Controller permaneça up-toatualizado e adiciona uma camada extra de suporte.

* Abordagem de nuvem única: a AGIC é adotada principalmente por clientes que adotam uma abordagem de nuvem única. Pode não ser a melhor escolha se você precisar de uma arquitetura multicloud onde a implantação em diferentes plataformas de nuvem é um requisito. Nesse caso, você pode querer usar um controlador de entrada independente da nuvem, como NGINX, Traefik ou HAProxy para evitar problemas de bloqueio de vendo.

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

O Azure Application Gateway for Containers fornece balanceamento de carga e gerenciamento de tráfego dinâmico para aplicativos em clusters Kubernetes.

Principais características

O Azure Application Gateway for Containers baseia-se nos recursos do Application Gateway Ingress Controller (AGIC) e permite que você use o balanceador de carga nativo do Application Gateway do Azure. As principais funcionalidades incluem:

Balanceamento de carga: distribui eficientemente o tráfego de entrada em vários contêineres para obter desempenho e escalabilidade ideais.
Implementação da API do Gateway: Suporta a API do Gateway, permitindo que você defina regras e políticas de roteamento de forma nativa do Kubernetes.
Sondas de integridade personalizadas: defina testes de integridade personalizados para monitorar a integridade do contêiner e rotear automaticamente o tráfego para longe de instâncias não íntegras.
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: Suporta terminação TLS, permitindo que a criptografia SSL/TLS e a descriptografia sejam descarregadas para o gateway.
Reescritas de cabeçalhos: reescreva cabeçalhos HTTP de pedidos de clientes e respostas de alvos de back-end usando a definição de recurso personalizada IngressExtension. Para obter mais informações, consulte API de entrada e API de gateway.
Regravações de URL: modifique a URL de solicitações de clientes, incluindo nome de host e/ou caminho, e inclua a URL recém-reescrita ao iniciar solicitações para destinos de back-end. Para obter mais informações, consulte API de entrada e API de gateway.

Limitações

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

Para obter mais informações, consulte Implantando um cluster do Serviço Kubernetes do Azure (AKS) com o Application Gateway for Containers.

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

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

Capacidade de descarregamento do Azure Front Door TLS e Secure Sockets Layer (SSL) para encerrar conexões TLS e descriptografar o tráfego de entrada na porta da frente. O Azure Front Door criptografa novamente 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 Proteger sua origem com o Private Link no Azure Front Door Premium.

O controlador de entrada NGINX expõe o aplicativo web hospedado pelo AKS. Ele é configurado para usar um endereço IP privado como uma configuração IP front-end do balanceador de kubernetes-internal 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 esta solução para cenários em que você está implantando o mesmo aplicativo Web em vários clusters AKS regionais para continuidade de negócios e recuperação de desastres, ou até mesmo em várias plataformas de nuvem ou instalações locais. Nesse caso, o Front Door pode encaminhar chamadas recebidas 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 sensibilidade. Em outras palavras, as solicitações são enviadas para o conjunto de origens mais próximo em relação à latência da 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 fontes quando quiser distribuir o tráfego por um conjunto de fontes de forma uniforme ou de acordo com os coeficientes de peso. O tráfego é distribuído pelo valor de peso se as latências das origens estiverem dentro do intervalo de sensibilidade de latência aceitável no 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 2025-06-25

Compartilhar via