Componentes do Gateway de Aplicativo para contêineres

Este artigo fornece descrições detalhadas e requisitos para componentes do Gateway de Aplicativos para contêineres. Explica como o Gateway de Aplicações 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 orquestra a configuração de proxy com base na intenção do cliente.
• O Gateway de Aplicativos para contêineres tem dois recursos filhos: associações e front-ends.
  • Os recursos filhos pertencem exclusivamente ao seu Gateway de Aplicativo para Contêineres pai e não podem ser compartilhados com outros recursos do Gateway de Aplicativo 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 Aplicativo para Contêineres define o ponto de entrada que o tráfego do cliente usa para um determinado Gateway de Aplicativo para Contêineres.
  • Não é possível associar um front-end a mais de um Gateway de Aplicativo para Contêineres.
  • Você pode criar um registro CNAME usando o FQDN exclusivo que cada front-end fornece.
  • No momento, não há suporte para endereços IP privados.
• Um único Gateway de Aplicativo para Contêineres pode dar suporte a mais de um front-end.

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 delegada do Azure.
• Gateway de Aplicações para Contêineres foi projetado para permitir mais de uma associação.
  • Neste momento, o número atual de associações é 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 você planeja implantar vários recursos do Gateway de Aplicativo para Contêineres que compartilham a mesma sub-rede, calcule os endereços necessários como n×256, em que n será igual ao número de recursos do Gateway de Aplicativo para Contêineres. Isso pressupõe que cada uma contenha uma associação.
  • 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 Aplicativo para Contêineres para propagar a configuração para a implantação do Gateway de Aplicativo para Contêineres do Azure.
• Implantar ou instalar o Controlador ALB com o Helm.
• O controlador ALB consiste em dois pods em execução.
  • O pod alb-controller alinha a intenção do cliente com a configuração de balanceamento de carga do Gateway de Aplicações para Contêineres.
  • O pod alb-controller-bootstrap gerencia os CRDs.

Política de segurança do Gateway de Aplicações para Contêineres

• Uma política de segurança do Gateway de Aplicações para Contêineres define configurações de segurança, como o WAF, para serem usadas pelo controlador ALB.
• Um único recurso do Gateway de Aplicativo para Contêineres pode se referir a mais de uma política de segurança.
• No momento, o único tipo de política de segurança oferecido é waf para recursos de firewall de aplicativo Web.
• A política de segurança waf é um mapeamento um-para-um entre o recurso de política de segurança e uma política de Firewall de Aplicação Web.
  • Você pode fazer referência a apenas uma política de firewall de aplicativo da Web em qualquer número de políticas de segurança para um recurso Gateway de Aplicativo para Contêineres definido.

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 refere-se 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 Application Gateway para Contêineres e você pode delegar isso à sub-rede de uma rede virtual.
• Quando você delega, não provisiona recursos do Gateway de Aplicativo para Contêineres, nem há um mapeamento exclusivo para um recurso de associação do Gateway de Aplicativo 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. Depois de definido, você não pode provisionar outros recursos 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.
• Você precisa de uma identidade gerenciada atribuída pelo usuário para cada Controlador do Azure Load Balancer, para poder fazer alterações no Application Gateway 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.

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 que é gerado e gerenciado pelo Azure. Você pode usar o FQDN as-is ou mascara-lo com um registro CNAME.

Antes que um cliente envie uma solicitação ao Gateway de Aplicativo para Contêineres, o cliente resolve um CNAME que aponta para o FQDN do front-end ou o cliente resolve diretamente o FQDN fornecido pelo Gateway de Aplicativo 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 a protocolos HTTP/2 e HTTP/1.1 para comunicação entre o cliente e o front-end. 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 negociando adequadamente.

A comunicação entre o Gateway de Aplicativo para contêineres e o destino de back-end é sempre via HTTP/1.1, exceto para gRPC, que usa HTTP/2.

Modificações na solicitação

O Gateway de Aplicativo para Contêineres insere três cabeçalhos extras em todas as solicitações antes de iniciar as solicitações 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 vier 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 Gateway de Aplicativo para Contêineres e 5.6.7.8 é o endereço do tráfego de encaminhamento de proxy para o Gateway de Aplicativo para Contêineres.

x-forwarded-proto retorna o protocolo que o Gateway de Aplicativo para Contêineres recebe do cliente. O valor é http ou https.

x-request-id é um GUID exclusivo que o Gateway de Aplicativo para Contêineres gera para cada solicitação do cliente e apresenta na solicitação encaminhada para o destino back-end. O guid consiste em 32 caracteres alfanuméricos, separados por traços (por exemplo: aaaa0000-bb11-2222-33cc-444444dddddd). Você pode usar este GUID para correlacionar uma solicitação que o Gateway de Aplicativo para Contêineres recebe e inicia para um destino de back-end, conforme definido nos logs de acesso.

Tempos limite de solicitação

O Gateway de Aplicativos para Contêineres impõe os seguintes tempos limite ao iniciar e manter solicitações entre o cliente, o Gateway de Aplicativos para Contêineres e o back-end.