Visão geral das observações do Cloud Load Balancing

Com as extensões de serviço, é possível instruir os balanceadores de carga de aplicativo compatíveis a enviar uma chamada do caminho de dados de balanceamento de carga para serviços de chamada gerenciados pelo usuário ou serviços do Google.

Fluxo de dados de callouts

Um balanceador de carga se comunica com uma callout usando um dos seguintes protocolos gRPC do Envoy:

  • O protocolo de processamento externo ou ext_proc.

    Esse protocolo é compatível com extensões de rota, tráfego e autorização e é usado por padrão.

    O protocolo ext_proc permite que o serviço de extensão responda a eventos no ciclo de vida de uma solicitação HTTP examinando e modificando os cabeçalhos ou o corpo da solicitação.

  • A autorização externa ou o protocolo ext_authz.

    Esse protocolo é compatível apenas com extensões de autorização. O suporte para ext_authz está em Prévia.

    O protocolo ext_authz delega decisões de autorização para solicitações recebidas a um serviço externo e independente. Essa API permite que o serviço de extensão responda a eventos no ciclo de vida de uma solicitação HTTP para uma decisão de autorização complexa examinando os cabeçalhos ou metadados da solicitação.

    É possível especificar esse protocolo com a opção wireFormat ao configurar uma extensão de autorização.

É possível implantar esses serviços de extensão em instâncias de máquina virtual (VM) ou no GKE e configurar um grupo de instâncias ou um grupo de endpoints de rede (NEG) para representar os endpoints desses serviços.

O diagrama a seguir mostra como implantar o serviço de back-end de callout com um servidor gRPC em um recurso de computação gerenciado pelo usuário, como uma instância de VM ou cluster do Google Kubernetes Engine (GKE), e representá-lo para o balanceador de carga como um serviço de back-end regular.

Os balanceadores de carga de aplicativo usam callouts para incluir lógica personalizada de serviços de back-end de callout.
Os balanceadores de carga de aplicativo enviam callbacks de extensões de serviço para chamar serviços de back-end (clique para ampliar).

Como as frases de destaque funcionam com o ext_proc

Confira a seguir uma versão abreviada da API gRPC ext_proc.

// The gRPC API to be implemented by the external processing server
service ExternalProcessor {
  rpc Process(stream ProcessingRequest) returns (stream ProcessingResponse) {
  }
}

// Envoy sets one of these fields depending on the processing stage.
message ProcessingRequest {
  oneof request {
    HttpHeaders request_headers = 2;
    HttpHeaders response_headers = 3;
    HttpBody request_body = 4;
    HttpBody response_body = 5;
  }
}

message ProcessingResponse {
  oneof response {
    HeadersResponse request_headers = 1;
    HeadersResponse response_headers = 2;
    BodyResponse request_body = 3;
    BodyResponse response_body = 4;

    ImmediateResponse immediate_response = 7;
  }
}

Depois de receber os cabeçalhos de uma solicitação HTTP, o balanceador de carga envia a mensagem ProcessingRequest ao serviço de extensão com o campo request_headers definido como os cabeçalhos HTTP do cliente.

O serviço de extensão precisa responder à mensagem ProcessingRequest com uma mensagem ProcessingResponse correspondente que contenha as mudanças configuradas nos cabeçalhos ou no corpo da mensagem ProcessingRequest. Como alternativa, o serviço pode definir o campo immediate_response para fazer com que o balanceador de carga encerre o processamento da solicitação e envie a resposta especificada de volta ao cliente.

Para eventos REQUEST_HEADER e RESPONSE_HEADER, o serviço de extensão pode manipular os cabeçalhos HTTP na solicitação ou resposta. O serviço pode adicionar, modificar ou excluir cabeçalhos definindo o campo request_headers ou response_headers na mensagem ProcessingResponse de maneira adequada. Use o campo raw_value para cabeçalhos.

As extensões de tráfego permitem mudar os cabeçalhos e o corpo de solicitações e respostas. O servidor de extensão pode substituir o modo de processamento dinamicamente e permitir que ele ative ou desative a extensão para as fases subsequentes do processamento de solicitações. Os balanceadores de carga não reavaliam as regras de rota depois de chamar uma extensão de tráfego.

As extensões de borda, autorização e rota são compatíveis apenas com cabeçalhos HTTP. Essas extensões não podem inspecionar nem mudar corpos HTTP.

Como as frases de destaque funcionam com o ext_authz

A API ext_authz é compatível apenas com extensões de callout de autorização.

Confira abaixo uma versão abreviada da API.

// A generic interface for performing authorization checks on incoming
// requests to a networked service.
service Authorization {
  // Performs an authorization check based on the attributes associated with
  // the incoming request and return status.
  rpc Check(CheckRequest) returns (CheckResponse) {
  }
}

message CheckRequest {
  // The request attributes.
  AttributeContext attributes = 1;
}

message CheckResponse {
  google.rpc.Status status = 1;
  oneof http_response {
    DeniedHttpResponse denied_response = 2;
    OkHttpResponse ok_response = 3;
  }
  google.protobuf.Struct dynamic_metadata = 4;
}

Depois de receber os cabeçalhos de uma solicitação HTTP, o balanceador de carga envia a mensagem CheckRequest ao serviço de extensão.

O serviço de extensão precisa responder à mensagem CheckRequest com uma mensagem CheckResponse correspondente que contenha as seguintes informações:

  • status: indica o status. OK indica que a solicitação é permitida. Qualquer outro status indica que a solicitação foi negada.

  • denied_response ou ok_response: indica se a resposta é permitida ou negada. Esse campo é acompanhado pelos atributos de resposta HTTP relacionados para uma verificação de autorização.

    • O campo ok_response é usado quando o serviço de autorização permite a solicitação. O serviço pode modificar, adicionar ou remover cabeçalhos de solicitação originais e atualizar os cabeçalhos de resposta HTTP enviados ao cliente. Use o campo raw_value para cabeçalhos.

    • O campo denied_response é usado quando o serviço de autorização nega a solicitação. O serviço pode atualizar os cabeçalhos de resposta HTTP enviados ao cliente.

    Se o serviço de extensão retornar um nome ou valor de cabeçalho não permitido pela mensagem CheckResponse, a solicitação será rejeitada com o código de status 500 Internal Error. Para informações sobre cabeçalhos não permitidos, consulte Limitações com manipulação de cabeçalho.

  • dynamic_metadata: inclui metadados opcionais para uso por extensões que são chamadas após a extensão de autorização, como extensões de tráfego.

Modos de processamento de corpo

Para extensões que oferecem suporte ao processamento de corpo, é possível configurar um dos dois modos de envio a seguir para o processamento de corpo de solicitação e resposta definindo o valor dos campos request_body_send_mode ou response_body_send_mode, respectivamente.

O modo padrão é STREAMED, recomendado para a maioria dos casos de uso.

Modo Descrição Eventos aceitos obrigatórios Extensões compatíveis
STREAMED

As chamadas são executadas no modo de streaming. Essa configuração padrão também será usada se o modo não estiver definido.

O proxy envia partes do corpo para o serviço de extensão e espera uma única resposta por parte. A extensão pode enviar de volta partes modificadas, confirmar partes sem alterações ou excluir partes.

O proxy envia apenas uma quantidade limitada de dados por vez. Portanto, o serviço de extensão precisa confirmar os blocos assim que possível.

Embora o modo de corpo não possa ser alterado de forma dinâmica, um servidor de extensão avançado pode selecionar dinamicamente os futuros eventos HTTP a serem recebidos. Ao retornar a opção ext_proc mode_override durante uma solicitação de cabeçalhos, um servidor de callout pode ativar ou desativar futuros eventos de cabeçalhos, corpo ou trailers.

 Precisa incluir REQUEST_BODY para solicitações ou RESPONSE_BODY para respostas. Extensões de tráfego (para solicitações e respostas).
FULL_DUPLEX_STREAMED

As chamadas são executadas no modo full duplex.

O proxy envia os blocos assim que eles chegam, sem armazená-los em buffer. Como não há buffer, o proxy é menos sensível à latência de extensão.

O proxy pode receber quantos blocos de resposta forem necessários. Os trechos de resposta são desconectados dos trechos enviados pelo proxy. Os próximos blocos são enviados para processamento assim que chegam ao proxy, sem esperar que os blocos e eventos anteriores sejam totalmente processados.

A extensão pode armazenar em buffer, modificar e reagrupar livremente o conteúdo do corpo. Se a extensão não enviar o conteúdo do corpo de volta, a próxima extensão na cadeia vai receber um corpo vazio.

A opção ext_proc mode_override não é aplicável, e o modo não pode ser alterado dinamicamente.

 Precisa incluir REQUEST_BODY e REQUEST_TRAILERS para solicitações ou RESPONSE_BODY e RESPONSE_TRAILERS para respostas. Extensões de tráfego (para solicitações e respostas).

Extensões de rotas (para solicitações).

Back-ends compatíveis para serviços de back-end de callout gerenciados pelo usuário

É possível hospedar extensões de callout gerenciadas pelo usuário em um serviço de back-end que usa um dos seguintes tipos de back-ends que executam serviços gRPC do Envoy:

Otimizações recomendadas para frases de destaque

A integração de uma extensão ao caminho de processamento do balanceamento de carga causa latência adicional para solicitações e respostas. Cada tipo de dado processado pelo serviço de extensão, incluindo cabeçalhos e corpo da solicitação, cabeçalhos e corpo da resposta, conforme aplicável, adiciona latência.

Considere as seguintes otimizações para minimizar a latência:

  • Implante callouts nas mesmas zonas que o serviço de back-end de destino regular para o balanceador de carga. Ao usar um balanceador de carga de aplicativo interno entre regiões, coloque os back-ends do serviço de extensão na mesma região que as sub-redes somente proxy do balanceador de carga.
  • Ao usar um balanceador de carga de aplicativo externo global, coloque os back-ends do serviço de callout nas regiões geográficas em que as VMs de destino, as cargas de trabalho do GKE e as funções do Cloud Run do balanceador de carga regular estão localizadas.
  • Quando possível, configure a extensão para processar apenas os dados necessários. Por exemplo, para modificar apenas os cabeçalhos de solicitação para extensões de rota e tráfego, defina o campo supported_events na extensão como REQUEST_HEADERS.

Limitações

Esta seção lista algumas limitações das frases de destaque.

Limitações com a manipulação de cabeçalhos

Não é possível mudar alguns cabeçalhos. Confira a seguir as limitações da manipulação de cabeçalhos:

  • A manipulação de cabeçalho não é compatível com os seguintes cabeçalhos:

    • X-user-IP
    • CDN-Loop
    • Cabeçalhos que começam com X-Forwarded, X-Google, X-GFE ou X-Amz-
    • connection
    • keep-alive
    • transfer-encoding, te
    • upgrade
    • proxy-connection, proxy-authenticate, proxy-authorization
    • trailers

    Para extensões de tráfego e autorização, a manipulação de cabeçalho também não é compatível com estes: :method, :authority, :scheme ou cabeçalhos de host.

  • Quando um servidor gRPC especifica valores de cabeçalho em HeaderMutation, o balanceador de carga ignora o campo value.

Limitações com o processamento de corpo

A seguir, estão as limitações com clientes e back-ends HTTP/1.1 em relação ao corpo da mensagem, que se aplica ao ext_proc, mas não ao ext_authz.

  • Ao configurar REQUEST_BODY ou RESPONSE_BODY para uma extensão, se o balanceador de carga receber uma solicitação correspondente, ele vai remover o cabeçalho Content-Length da resposta e mudar para a codificação de corpo em partes.

  • Ao transmitir um corpo de mensagem para o servidor ext_proc, no final, o balanceador de carga pode enviar uma mensagem ProcessingRequest final com um corpo vazio e end_stream definido como true para indicar que o fluxo foi encerrado.

Outras limitações

Estas são as limitações das mensagens de resposta do gRPC:

  • O tamanho máximo de uma mensagem de resposta é de 128 kB. Se uma mensagem recebida exceder esse limite, o fluxo será fechado com um erro RESOURCE_EXHAUSTED.

  • O serviço de back-end de callout não pode usar políticas do Cloud Armor, do IAP ou do Cloud CDN.

  • O serviço de back-end de callout precisa usar HTTP/2 como protocolo.

  • Para extensões de autorização, o balanceador de carga não encaminha nenhum corpo de solicitação ao serviço de back-end de callout.

  • Para extensões de rota, o serviço de back-end de callout não pode substituir o modo de processamento do fluxo ext_proc.

A seguir