Componentes do Application Gateway for Containers

Este artigo fornece descrições detalhadas e requisitos para componentes do Application Gateway for Containers. São fornecidas informações sobre como o Application Gateway for Containers aceita solicitações de entrada e as roteia para um destino de back-end. 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 Aplicativo para Contêineres é um recurso pai do Azure que implanta o plano de controle.
• O plano de controle é responsável por orquestrar a configuração do proxy com base na intenção do cliente.
• O Application Gateway for Containers tem dois recursos filho; associações e frontends.
  • Os recursos filho são exclusivos apenas do Application Gateway for Containers pai e não podem ser referenciados por outro recurso do Application Gateway for Container.

Application Gateway para frontends de contêineres

• Um recurso frontend do Gateway de Aplicativo para Contêineres é um recurso filho do Azure do recurso pai do Gateway de Aplicativo para Contêineres.
• Um frontend do Application Gateway for Containers define o tráfego do cliente do ponto de entrada que deve ser recebido por um determinado Application Gateway for Containers.
  • Um frontend não pode ser associado a vários Application Gateway for Containers.
  • Cada frontend fornece um FQDN exclusivo que pode ser referenciado pelo registro CNAME de um cliente.
  • Os endereços IP privados não são suportados no momento.
• Um único Application Gateway for Containers pode oferecer suporte a vários frontends.

Associações do Application Gateway for Containers

• Um recurso de associação do Gateway de Aplicativo para Contêineres é um recurso filho do Azure do recurso pai do Gateway de Aplicativo para Contêineres.
• 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 do Azure que foi delegada.
• O Application Gateway for Containers foi projetado para permitir várias associações.
  • 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 /24 mínima para cada implantação (supondo que nenhum recurso tenha sido provisionado anteriormente na sub-rede).
    • Se n número de Application Gateway for Containers for Containers for provisionado, com a suposição de que cada Application Gateway for Containers contém uma associação e a intenção é compartilhar a mesma sub-rede, os endereços necessários disponíveis devem ser n*256.
  • 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 aplicativo para contêineres Controlador ALB

• Um Application Gateway for Containers ALB Controller é uma implantação do Kubernetes que orquestra a configuração e a implantação do Application Gateway for Containers observando as configurações de Recursos Personalizados e de Recursos do Kubernetes, tais como, mas não limitado a, Ingress, Gateway e ApplicationLoadBalancer. Ele usa as APIs de configuração do ARM / Application Gateway for Containers para propagar a configuração para a implantação do Azure do Application Gateway for Containers.
• ALB Controller é implantado / instalado via Helm.
• ALB Controller consiste em dois pods de execução.
  • O pod alb-controller é responsável por orquestrar a intenção do cliente para a configuração de balanceamento de carga do Application Gateway for Containers.
  • alb-controller-bootstrap pod é responsável pelo gerenciamento de CRDs.

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 determinada rede virtual.

Delegação de sub-rede

• Microsoft.ServiceNetworking/trafficControllers é o namespace adotado pelo Application Gateway for Containers e pode ser delegado à sub-rede de uma rede virtual.
• Quando a delegação ocorre, o provisionamento de recursos do Application Gateway for Containers não acontece, nem há um mapeamento exclusivo para um recurso de associação do Application Gateway for 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, nenhum outro recurso, além do serviço definido, pode ser provisionado na sub-rede, a menos que 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.
• Uma Identidade Gerenciada pelo Usuário é necessária para cada Controlador de Balanceador de Carga do Azure fazer alterações no Gateway de Aplicativo para Contêineres.
• 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 front-end do Gateway de Aplicativo para Contêineres fornece um Nome de Domínio Totalmente Qualificado gerado gerenciado pelo Azure. O FQDN pode ser usado no estado em que se encontra ou os clientes podem optar por mascarar o FQDN com um registro CNAME.

Antes de um cliente enviar uma solicitação ao Application Gateway for Containers, o cliente resolve um CNAME que aponta para o FQDN do frontend; ou o cliente pode resolver 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 totalmente o protocolo HTTP/2 para comunicação do cliente para o frontend. A comunicação do Application Gateway for Containers para o destino de back-end usa o protocolo HTTP/1.1. A configuração HTTP/2 está sempre ativada e não pode ser alterada. Se os clientes preferirem usar HTTP/1.1 para sua comunicação com o frontend do Application Gateway for Containers, eles poderão continuar a negociar de acordo.

Alterações ao pedido

O Application Gateway for Containers insere três cabeçalhos extras para todas as solicitações antes que as solicitações sejam iniciadas do Application Gateway for Containers para um destino de back-end:

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

x-forwarded-for é o endereço IP do cliente do solicitante original. Se a solicitação estiver vindo por meio de um proxy, o valor do cabeçalho acrescentará o endereço recebido, 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 na frente do Application Gateway for Containers e 5.6.7.8 é o endereço do tráfego de encaminhamento de proxy para o Application Gateway for Containers.

x-forwarded-proto retorna o protocolo recebido pelo Application Gateway for Containers do cliente. O valor é http ou https.

x-request-id é um guid exclusivo gerado pelo Application Gateway for Containers para cada solicitação de cliente e apresentado na solicitação encaminhada para o destino de back-end. O guid consiste em 32 caracteres alfanuméricos, separados por traços (por exemplo: aaaa0000-bb11-2222-33cc-444444dddddd). Esse guid pode ser usado para correlacionar uma solicitação recebida pelo Application Gateway for Containers e iniciada a um destino de back-end, conforme definido nos logs de acesso.

Tempo limite de solicitação

O Application Gateway for Containers impõe os seguintes tempos limite à medida que as solicitações são iniciadas e mantidas entre o cliente, o Application Gateway for Containers e o back-end.