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.
- Uma máscara de sub-rede /24 mínima para cada implantação (supondo que nenhum recurso tenha sido provisionado anteriormente na sub-rede).
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.
Nota
A função AppGw for Containers Configuration Manager tem permissões de ação de dados que as funções Proprietário e Colaborador não têm. É fundamental que as permissões adequadas sejam delegadas para evitar problemas com o controlador ALB fazendo alterações no serviço 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: d23387ab-e629-458a-9c93-6108d374bc75). 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.
| Limite de tempo excedido | Duração | Description |
|---|---|---|
| Tempo Limite do Pedido | 60 segundos | tempo pelo qual o Application Gateway for Containers aguarda a resposta de destino do back-end. |
| Tempo limite de inatividade HTTP | 5 minutos | tempo limite ocioso antes de fechar uma conexão HTTP. |
| Tempo limite de inatividade do fluxo | 5 minutos | tempo limite ocioso antes de fechar um fluxo individual transportado por uma conexão HTTP. |
| Tempo limite de conexão upstream | 5 segundos | tempo para estabelecer uma conexão com o destino de back-end. |