Componentes do Gateway de Aplicativos para contêineres

Este artigo fornece descrições detalhadas e requisitos para componentes do Gateway de Aplicativos para contêineres. São fornecidas informações sobre como o Gateway de Aplicativos para contêineres aceita solicitações de entrada e as roteia para um destino de back-end. Para obter uma visão geral do Gateway de Aplicativos para contêineres, confira O que é o Gateway de Aplicativos para contêineres?.

Componentes principais

• Um Gateway de Aplicativos 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 de proxy com base na intenção do cliente.
• O Gateway de Aplicativos para contêineres tem dois recursos filho: associações e front-ends.
  • Os recursos filho são exclusivos apenas do Gateway de Aplicativos para contêineres pai e podem não ser referenciados por outro recurso do Gateway de Aplicativos para contêineres.

Front-ends do Gateway de Aplicativos para contêineres

• Um recurso de front-end do Gateway de Aplicativos para contêineres é um recurso filho do Azure do recurso pai do Gateway de Aplicativos para contêineres.
• Um front-end do Gateway de Aplicativos para contêineres define que o tráfego do cliente do ponto de entrada deve ser recebido por um determinado Gateway de Aplicativos para contêineres.
  • Um front-end não pode ser associado a vários Gateways de Aplicativos para contêineres.
  • Cada front-end fornece um FQDN exclusivo que pode ser referenciado pelo registro CNAME de um cliente.
  • Atualmente, os endereços IP privados não têm suporte.
• Um único Gateway de Aplicativos para contêineres pode dar suporte a vários front-ends.

Associações do Gateway de Aplicativos para contêineres

• Um recurso de associação do Gateway de Aplicativos para contêineres é um recurso filho do Azure do recurso pai do Gateway de Aplicativos para contêineres.
• Uma associação do Gateway de Aplicativos para contêineres 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 delegada.
• O Gateway de Aplicativos para contêineres foi projetado para permitir várias associações.
  • No 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 de /24 para cada implantação (supondo que nenhum recurso tenha sido provisionado anteriormente na sub-rede).
    • Se n números de Gateways de Aplicativos para contêineres forem provisionados, com a suposição de que cada Gateway de Aplicativos para contêineres 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 Gateway de Aplicativos para contêineres devem corresponder à mesma região que o recurso pai do Gateway de Aplicativos para contêineres.

Controlador ALB do Gateway de Aplicativos para contêineres

• Um controlador ALB do Gateway de Aplicativos para contêineres é uma implantação do Kubernetes que orquestra a configuração e a implantação do Gateway de Aplicativos para contêineres, observando as configurações de recursos e recursos personalizados do Kubernetes, como, entre outros, Ingress, Gateway e ApplicationLoadBalancer. Ele usa as APIs de configuração do ARM e do Gateway de Aplicativos para contêineres para propagar a configuração para a implantação do Azure do Gateway de Aplicativos para contêineres.
• O controlador ALB é implantado/instalado por meio do Helm.
• O controlador ALB consiste em dois pods em execução.
  • O pod alb-controller é responsável por orquestrar a intenção do cliente para a configuração de balanceamento de carga do Gateway de Aplicativos para contêineres.
  • O pod alb-controller-bootstrap é responsável pelo gerenciamento de CRDs.

Conceitos gerais/do Azure

Endereço IP privado

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

Delegação de sub-rede

• Microsoft.ServiceNetworking/trafficControllers é o namespace adotado pelo Gateway de Aplicativos para contêineres e pode ser delegado à sub-rede de uma rede virtual.
• Quando a delegação ocorre, o provisionamento de recursos do Gateway de Aplicativos para contêineres não acontece, nem há um mapeamento exclusivo para um recurso de associação do Gateway de Aplicativos para contêineres.
• Qualquer número de sub-redes pode ter uma delegação de sub-rede que seja a mesma ou diferente do Gateway de Aplicativos para contêineres. Uma vez definido, nenhum outro recurso, além do serviço definido, pode ser provisionado na sub-rede, a menos que seja definido explicitamente pela implementação do serviço.

Identidade gerenciada atribuída pelo usuário

• 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 que cada controlador do Azure Load Balancer faça alterações no Gateway de Aplicativos para contêineres.
• O AppGw for Containers Configuration Manager é uma função RBAC integrada que permite que o controlador ALB acesse e configure o recurso Gateway de Aplicativos para contêineres.

Observação

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 Gateway de Aplicativos para contêineres.

Como o Gateway de Aplicativos para contêineres aceita uma solicitação

Cada front-end do Gateway de Aplicativos para contêineres fornece um nome de domínio totalmente qualificado gerado gerenciado pelo Azure. O FQDN pode ser usado como está ou os clientes podem optar por mascarar o FQDN com um registro CNAME.

Antes que um cliente envie uma solicitação ao Gateway de Aplicativos para contêineres, o cliente resolve um CNAME que aponta para o FQDN do front-end; ou o cliente pode resolver diretamente o FQDN fornecido pelo Gateway de Aplicativos para contêineres usando um servidor DNS.

O resolvedor DNS converte o registro DNS em um endereço IP.

Quando o cliente inicia a solicitação, o nome DNS especificado é passado como um cabeçalho de host para o Gateway de Aplicativos para contêineres no front-end definido.

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

Como o Gateway de Aplicativos para contêineres roteia uma solicitação

Solicitações HTTP/2

O Gateway de Aplicativo para Contêineres dá suporte total ao protocolo HTTP/2 para comunicação do cliente com o front-end. A comunicação do Gateway de Aplicativo para Contêineres para o destino de back-end usa o protocolo HTTP/1.1. A configuração HTTP/2 está sempre habilitada e não pode ser alterada. Se os clientes preferirem usar HTTP/1.1 para sua comunicação com o front-end do Gateway de Aplicativo para Contêineres, eles poderão continuar a negociar adequadamente.

Modificações na solicitação

O Gateway de Aplicativos para contêineres insere três cabeçalhos adicionais a todas as solicitações antes que as solicitações sejam iniciadas do Gateway de Aplicativos para contêineres para um destino de back-end:

• x-forwarded-for
• x-forwarded-proto
• x-request-id

x-forwarded-for é o endereço IP do cliente do solicitante original. Se a solicitação estiver chegando por meio de um proxy, o valor do cabeçalho acrescentará o endereço recebido, delimitado por vírgula. No 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 Gateway de Aplicativos para contêineres e 5.6.7.8 é o endereço do tráfego de encaminhamento de proxy para o Gateway de Aplicativos para contêineres.

x-forwarded-proto retorna o protocolo recebido pelo Gateway de Aplicativos para contêineres do cliente. O valor é http ou https.

x-request-id é um guid exclusivo gerado pelo Gateway de Aplicativos para contêineres para cada solicitação do cliente e apresentado na solicitação encaminhada ao destino do 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 Gateway de Aplicativos para contêineres e iniciada a um destino de back-end, conforme definido nos logs de acesso.

Tempos limite de solicitação

O Gateway de Aplicativo para Contêineres impõe os seguintes tempos limite à medida que as solicitações são iniciadas e mantidas entre o cliente, o Gateway de Aplicativo para Contêineres e o back-end.

Timeout	Duration	Descrição
Tempo Limite da Solicitação	60 segundos	tempo pelo qual o Gateway de Aplicativo para Contêineres aguarda a resposta de destino de back-end.
Tempo limite ocioso do HTTP	5 minutos	tempo limite ocioso antes de fechar uma conexão HTTP.
Tempo limite ocioso 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.