Componentes do Application Gateway for Containers

Este artigo fornece descrições detalhadas e requisitos para componentes do Application Gateway for Containers. Explica como o Application Gateway for Containers aceita pedidos recebidos e os encaminha para um destino backend. Para obter uma visão geral do Application Gateway for Containers, consulte O que é o Application Gateway for Containers.

Componentes centrais

• Um recurso do Gateway de Aplicações para Contentores é um recurso pai do Azure que realiza a implementação do plano de controle.
• O plano de controlo orquestra a configuração proxy com base na intenção do cliente.
• O Application Gateway para Containers tem dois recursos filhos: associações e interfaces principais.
  • Os recursos filhos pertencem exclusivamente ao seu Application Gateway para Containers e não podem ser partilhados com outros recursos do Application Gateway para Containers.

Application Gateway para frontends de contêineres

• Um recurso frontend do Gateway de Aplicações para Contentores é um recurso filho do Azure do recurso pai do Gateway de Aplicações para Contentores.
• Um frontend de Gateway de Aplicação para Contentores define o ponto de entrada que o tráfego de cliente utiliza para um determinado Gateway de Aplicação para Contentores.
  • Não podes associar um frontend a mais do que um Gateway de Aplicações para Containers.
  • Pode criar um registo CNAME usando o FQDN único que cada frontend fornece.
  • Endereços IP privados não são atualmente suportados.
• Um único Gateway de Aplicação para Containers pode suportar mais do que um frontend.

Associações do Application Gateway for Containers

• Um recurso de associação do Gateway de Aplicações para Contêiner é um recurso filho do Azure do recurso pai do Gateway de Aplicações para Contêiner.
• Uma associação do Application Gateway for Containers define um ponto de conexão em uma rede virtual. Uma associação é um mapeamento 1:1 de um recurso de associação para uma sub-rede Azure delegada.
• O Application Gateway for Containers foi concebido para permitir mais do que uma associação.
  • Neste momento, o número atual de associações está limitado a 1.
• Durante a criação de uma associação, o plano de dados subjacente é provisionado e conectado a uma sub-rede dentro da sub-rede da rede virtual definida.
• Cada associação deve assumir que pelo menos 256 endereços estão disponíveis na sub-rede no momento do provisionamento.
  • Uma máscara de sub-rede mínima /24 para cada implementação (assumindo que não há recursos previamente provisionados na sub-rede).
    • Se planeia implementar múltiplos recursos de Gateway de Aplicação para Containers que partilham a mesma sub-rede, calcule os endereços necessários como n×256, onde n é igual ao número de recursos de Gateway de Aplicação para Containers. Isto assume que cada um contém uma associação.
  • Todos os recursos de associação do Application Gateway for Containers devem corresponder à mesma região do recurso pai do Application Gateway for Containers.

Gateway de aplicação para contentores Controlador ALB

• Um controlador de ALB para Application Gateway for Containers é uma implementação no Kubernetes que orquestra a configuração e a implementação do Application Gateway for Containers, monitorizando recursos personalizados e configurações de recursos do Kubernetes, tais como Ingress, Gateway e ApplicationLoadBalancer. Utiliza tanto as APIs de configuração ARM como as do Application Gateway for Containers para propagar a configuração para a implementação do Application Gateway for Containers no Azure.
• Implemente ou instale o controlador ALB com Helm.
• O controlador ALB consiste em dois pods em execução.
  • Alb-Controller Pod orquestra a intenção do cliente para o Application Gateway para a configuração de balanceamento de carga dos contentores.
  • Alb-Controller-Bootstrap Pod gere CRDs.

Política de segurança do Application Gateway for Containers

• Uma política de segurança do Application Gateway for Containers define configurações de segurança, como WAF, para ser utilizada pelo controlador ALB.
• Um único recurso Application Gateway for Containers pode referir-se a mais do que uma política de segurança.
• No momento, o único tipo de diretiva de segurança oferecido é waf para recursos de firewall de aplicativos Web.
• A waf política de segurança é um mapeamento um-para-um entre o recurso de política de segurança e uma política do Firewall de Aplicações Web.
  • Só pode referenciar uma política de firewall de aplicações web em qualquer número de políticas de segurança para um recurso definido de Application Gateway for Containers.

Azure / conceitos gerais

Endereço IP privado

• Um endereço IP privado não é explicitamente definido como um recurso do Azure Resource Manager. Um endereço IP privado refere-se a um endereço de host específico dentro da sub-rede de uma dada rede virtual.

Delegação de sub-rede

• Microsoft.ServiceNetworking/trafficControllers é o namespace adotado pelo Application Gateway for Containers e pode delegá-lo à sub-rede de uma rede virtual.
• Quando delegas, não provisionas recursos do Application Gateway para Containers, nem existe um mapeamento exclusivo para um recurso de associação do Application Gateway para Containers.
• Qualquer número de sub-redes pode ter uma delegação de sub-rede igual ou diferente do Application Gateway for Containers. Uma vez definido, não pode provisionar outros recursos na sub-rede a menos que seja explicitamente definido pela implementação do serviço.

Identidade gerida atribuída pelo utilizador

• As identidades gerenciadas para recursos do Azure eliminam a necessidade de gerenciar credenciais no código.
• Precisa de uma identidade gerida pelo utilizador para cada Controlador de Load Balancer do Azure para fazer alterações no Application Gateway para contentores.
• O AppGw for Containers Configuration Manager é uma função RBAC interna que permite que o Controlador ALB acesse e configure o recurso Application Gateway for Containers.

Como o Application Gateway for Containers aceita uma solicitação

Cada frontend de Gateway de Aplicação para Containers fornece um nome de domínio totalmente qualificado gerado e gerido pelo Azure. Pode usar o FQDN como está ou mascará-lo com um registo CNAME.

Antes de um cliente enviar um pedido ao Application Gateway for Containers, o cliente resolve um CNAME que aponta para o FQDN do frontend, ou o cliente resolve diretamente o FQDN fornecido pelo Application Gateway for Containers usando um servidor DNS.

O resolvedor de DNS converte o registro DNS para um endereço IP.

Quando o cliente inicia a solicitação, o nome DNS especificado é passado como um cabeçalho de host para o Application Gateway for Containers no frontend definido.

Um conjunto de regras de roteamento avalia como a solicitação desse nome de host deve ser iniciada para um destino de back-end definido.

Como o Application Gateway for Containers encaminha uma solicitação

Solicitações HTTP/2

O Application Gateway for Containers suporta os protocolos HTTP/2 e HTTP/1.1 para comunicação entre o cliente e o frontend. A configuração HTTP/2 está sempre ativada e não pode ser alterada. Se os clientes preferirem usar HTTP/1.1 para a sua comunicação com o frontend do Application Gateway for Containers, podem continuar a negociar em conformidade.

A comunicação entre o Application Gateway for Containers e o destino de back-end é sempre via HTTP/1.1, exceto para gRPC, que usa HTTP/2.

Alterações ao pedido

O Application Gateway for Containers insere três cabeçalhos extra em todos os pedidos antes de iniciar pedidos para um destino backend:

• x-encaminhado para
• proto x-encaminhado
• X-Solicitação-ID

x-forwarded-for é o endereço IP do cliente do solicitante original. Se o pedido vier através de um proxy, o valor do cabeçalho acrescenta o endereço que recebe, delimitado por vírgula. Por exemplo: 1.2.3.4,5.6.7.8; onde 1.2.3.4 é o endereço IP do cliente para o proxy em frente ao Application Gateway for Containers, e 5.6.7.8 é o endereço do tráfego de encaminhamento do proxy para Application Gateway for Containers.

x-forwarded-proto devolve o protocolo que o Application Gateway for Containers recebe do cliente. O valor é http ou https.

x-request-id é um guid único que o Application Gateway for Containers gera para cada pedido de cliente e apresenta no pedido encaminhado para o destino do backend. O GUID é composto por 32 caracteres alfanuméricos, separados por traços (por exemplo: aaaa0000-bb11-2222-33cc-444444dddddd). Pode usar este guid para correlacionar um pedido que o Application Gateway for Containers recebe e reencaminha para um destino backend conforme definido nos registos de acesso.

Tempo limite de solicitação

O Application Gateway for Containers aplica os seguintes tempos de espera ao iniciar e manter pedidos entre o cliente, o Application Gateway for Containers e o backend.