Descripción general de los mensajes destacados de Cloud Load Balancing

Las extensiones de servicio te permiten indicarle a los balanceadores de cargas de aplicaciones compatibles que envíen un texto destacado desde la ruta de acceso de los datos del balanceo de cargas a servicios de texto destacado administrados por el usuario o servicios de Google.

Flujo de datos de textos destacados

Un balanceador de cargas se comunica con un texto destacado mediante uno de los siguientes protocolos gRPC de Envoy:

• El protocolo de procesamiento externo o ext_proc

  Este protocolo es compatible con las extensiones de ruta, tráfico y autorización, y se usa de forma predeterminada.

  El protocolo ext_proc permite que el servicio de extensión responda a eventos en el ciclo de vida de una solicitud HTTP mediante el examen y la modificación de los encabezados o el cuerpo de la solicitud.

• El protocolo de autorización externa o ext_authz

  Este protocolo solo es compatible con las extensiones de autorización. La compatibilidad con ext_authz está en versión preliminar.

  El protocolo ext_authz delega las decisiones de autorización para las solicitudes entrantes a un servicio externo independiente. Esta API permite que el servicio de extensión responda a eventos en el ciclo de vida de una solicitud HTTP para una decisión de autorización compleja mediante el examen de los encabezados o los metadatos de la solicitud.

  Puedes especificar este protocolo con la opción wireFormat cuando configuras una extensión de autorización.

Puedes implementar estos servicios de extensión en instancias de máquina virtual (VM) o en GKE, y configurar un grupo de instancias o un grupo de extremos de red (NEG) para representar los extremos de estos servicios.

En el siguiente diagrama, se muestra cómo puedes implementar el servicio de backend de texto destacado con un servidor gRPC en un recurso de procesamiento administrado por el usuario, como una instancia de VM o un clúster de Google Kubernetes Engine (GKE), y representarlo en el balanceador de cargas como un servicio de backend normal.

Los balanceadores de cargas de aplicaciones envían textos destacados de extensiones de servicio a servicios de backend de texto destacado (haz clic para ampliar).

Cómo funcionan los textos destacados con ext_proc

A continuación, se muestra una versión abreviada de la API de 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;
  }
}

Después de recibir los encabezados de una solicitud HTTP, el balanceador de cargas envía el mensaje ProcessingRequest al servicio de extensión con el campo request_headers configurado en los encabezados HTTP del cliente.

El servicio de extensión debe responder al mensaje ProcessingRequest con un mensaje ProcessingResponse correspondiente que contenga los cambios configurados en los encabezados o el cuerpo del mensaje ProcessingRequest. Como alternativa, el servicio puede configurar el campo immediate_response para que el balanceador de cargas finalice el procesamiento de la solicitud y envíe la respuesta especificada al cliente.

Para los eventos REQUEST_HEADER y RESPONSE_HEADER, el servicio de extensión puede manipular los encabezados HTTP en la solicitud o la respuesta. El servicio puede agregar, modificar o borrar encabezados configurando el campo request_headers o response_headers en el mensaje ProcessingResponse de forma adecuada. Usa el campo raw_value para los encabezados.

Las extensiones de tráfico permiten cambiar los encabezados y el cuerpo de las solicitudes y las respuestas. El servidor de extensión puede anular el modo de procesamiento de forma dinámica y permitir que habilite o inhabilite la extensión para las fases posteriores del procesamiento de solicitudes. Los balanceadores de cargas no vuelven a evaluar las reglas de ruta después de llamar a una extensión de tráfico.

Las extensiones perimetrales, de autorización y de ruta solo admiten encabezados HTTP. Estas extensiones no pueden inspeccionar ni mutar cuerpos HTTP.

Para las extensiones de ruta y tráfico, los textos destacados se pueden ejecutar de forma asíncrona cuando observabilityMode para la extensión se establece en true y el modo de procesamiento del cuerpo es STREAMED (predeterminado). Las llamadas al backend de extensión se realizan de forma asíncrona, sin pausar el procesamiento de la solicitud en curso. Las respuestas, si las hay, se ignoran.

Cómo funcionan los textos destacados con ext_authz

Vista previa

Este producto o esta función se encuentra sujeto a las "Condiciones de la oferta de la fase previa a la DG" en la sección Condiciones del servicio generales de las Condiciones específicas del servicio. Los productos y las funciones de la fase previa a la DG están disponibles “tal como están” y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

La API de ext_authz solo admite extensiones de texto destacado de autorización.

A continuación, se muestra una versión abreviada de la 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;
}

Después de recibir los encabezados de una solicitud HTTP, el balanceador de cargas envía el mensaje CheckRequest al servicio de extensión.

El servicio de extensión debe responder al mensaje CheckRequest con un mensaje CheckResponse correspondiente que contenga la siguiente información:

• status: Indica el estado. OK indica que se permite la solicitud. Cualquier otro estado indica que se deniega la solicitud.

• denied_response o ok_response: Indica si se permite o se deniega la respuesta. Este campo está acompañado de los atributos de respuesta HTTP relacionados para una verificación de autorización.

  • El campo ok_response se usa cuando el servicio de autorización permite la solicitud. El servicio puede modificar, agregar o quitar cualquier encabezado de solicitud original y actualizar los encabezados de respuesta HTTP que se envían al cliente. Usa el campo raw_value para los encabezados.

  • El campo denied_response se usa cuando el servicio de autorización deniega la solicitud. El servicio puede actualizar los encabezados de respuesta HTTP que se envían al cliente.

  Si el servicio de extensión muestra un nombre o valor de encabezado no permitido a través del mensaje CheckResponse, la solicitud se rechaza con el código de estado 500 Internal Error. Para obtener información sobre los encabezados no permitidos, consulta Limitaciones con la manipulación de encabezados.

• dynamic_metadata: Incluye metadatos opcionales para que los usen las extensiones que se llaman después de la extensión de autorización, como las extensiones de tráfico.

Modos de procesamiento del cuerpo

Para las extensiones que admiten el procesamiento del cuerpo, puedes configurar uno de los siguientes dos modos de envío para el procesamiento del cuerpo de la solicitud y la respuesta configurando el valor de los campos request_body_send_mode o response_body_send_mode, respectivamente.

El modo predeterminado es STREAMED, que se recomienda para la mayoría de los casos de uso.

Modo	Descripción	Eventos admitidos requeridos	Extensiones admitidas
STREAMED	Las llamadas se ejecutan en el modo de transmisión. Esta configuración predeterminada también se usa si no se establece el modo. El proxy envía fragmentos del cuerpo al servicio de extensión y espera una sola respuesta por fragmento. La extensión puede enviar fragmentos modificados, confirmar fragmentos sin cambios o borrar fragmentos. El proxy envía solo una cantidad limitada de datos a la vez. Por lo tanto, el servicio de extensión debe confirmar los fragmentos lo antes posible. Aunque el modo del cuerpo no se puede cambiar de forma dinámica, un servidor de extensión avanzado puede seleccionar de forma dinámica los eventos HTTP futuros que se recibirán. Cuando muestra la opción ext_proc mode_override durante una solicitud de encabezados, un servidor de texto destacado puede habilitar o inhabilitar eventos futuros de encabezados, cuerpo o trailers.	Debe incluir REQUEST_BODY para las solicitudes o RESPONSE_BODY para las respuestas.	Extensiones de tráfico (para solicitudes y respuestas).
FULL_DUPLEX_STREAMED	Las llamadas se ejecutan en el modo dúplex completo. El proxy envía fragmentos a medida que llegan y no los almacena en búfer. Como no hay almacenamiento en búfer, el proxy es menos sensible a la latencia de extensión. El proxy puede recibir tantos fragmentos de respuesta como sea necesario. Los fragmentos de respuesta se desconectan de los fragmentos que envía el proxy. Los fragmentos posteriores se envían para su procesamiento a medida que llegan al proxy, sin esperar a que se procesen por completo los fragmentos y eventos anteriores. La extensión puede almacenar en búfer, modificar y volver a fragmentar el contenido del cuerpo libremente. Si la extensión no vuelve a enviar el contenido del cuerpo, la siguiente extensión de la cadena recibe un cuerpo vacío. La opción ext_proc mode_override no es aplicable y el modo no se puede cambiar de forma dinámica. Advertencia: El proxy se abre hasta el primer fragmento de datos del cuerpo que se procesa. Eso significa que la apertura ante fallas controla cualquier problema relacionado con la conexión a la extensión o el control de encabezados, pero los errores después de este punto se cierran ante fallas y se propagan al usuario final.	Debe incluir REQUEST_BODY y REQUEST_TRAILERS para las solicitudes o RESPONSE_BODY y RESPONSE_TRAILERS para las respuestas.	Extensiones de tráfico (para solicitudes y respuestas). Extensiones de ruta (para solicitudes).

Backends admitidos para servicios de backend de texto destacado administrados por el usuario

Puedes alojar extensiones de texto destacado administradas por el usuario en un servicio de backend que use uno de los siguientes tipos de backends que ejecutan servicios gRPC de Envoy:

• Todos los backends de grupos de instancias administrados y no administrados
• Todos los NEGs zonales
• Todos los NEGs de conectividad híbrida
• NEGs de Private Service Connect que apuntan a servicios de VPC
• NEGs sin servidores que apuntan a servicios de Cloud Run

Nota: Cuando alojas la extensión en Cloud Run, el servicio de Cloud Run debe escuchar en un puerto gRPC de texto sin formato. El servicio de Cloud Run debe configurarse para aceptar tráfico HTTP/2 y debe permitir el acceso no autenticado.

Optimizaciones recomendadas para textos destacados

La integración de una extensión en la ruta de acceso de procesamiento del balanceo de cargas genera una latencia adicional para las solicitudes y respuestas. Cada tipo de datos que procesa el servicio de extensión, incluidos los encabezados de solicitud, el cuerpo de la solicitud, los encabezados de respuesta y el cuerpo de la respuesta, según corresponda, agrega latencia.

Considera las siguientes optimizaciones para minimizar la latencia:

• Implementa textos destacados en las mismas zonas que el servicio de backend de destino normal para el balanceador de cargas. Cuando uses un balanceador de cargas de aplicaciones interno entre regiones, coloca los backends del servicio de extensión en la misma región que las subredes solo de proxy del balanceador de cargas.
• Cuando uses un balanceador de cargas de aplicaciones externo global, coloca los backends del servicio de texto destacado en las regiones geográficas en las que se encuentran las VMs de destino, las cargas de trabajo de GKE y las funciones de Cloud Run del balanceador de cargas normal.
• Cuando sea posible, configura la extensión para que procese solo los datos que necesitas. Por ejemplo, para modificar solo los encabezados de solicitud para las extensiones de ruta y tráfico, configura el campo supported_events en la extensión como REQUEST_HEADERS.

Limitaciones

En esta sección, se enumeran algunas limitaciones con los textos destacados.

Limitaciones con la manipulación de encabezados

No puedes cambiar algunos encabezados. Las siguientes son las limitaciones con la manipulación de encabezados:

• La manipulación de encabezados no es compatible con los siguientes encabezados:

  • X-user-IP
  • CDN-Loop
  • Encabezados que comienzan con X-Forwarded, X-Google, X-GFE o X-Amz-
  • connection
  • keep-alive
  • transfer-encoding, te
  • upgrade
  • proxy-connection, proxy-authenticate, proxy-authorization
  • trailers

  Para las extensiones de tráfico y autorización, la manipulación de encabezados tampoco es compatible con los siguientes encabezados: :method, :authority, :scheme o encabezados de host.

• Cuando un servidor gRPC especifica valores de encabezado en HeaderMutation, el balanceador de cargas ignora el value campo.

Limitaciones con el procesamiento del cuerpo

Las siguientes son las limitaciones con los clientes y backends de HTTP/1.1 con respecto al cuerpo del mensaje, que se aplica a ext_proc, pero no a ext_authz.

• Cuando configuras REQUEST_BODY o RESPONSE_BODY para una extensión, si el balanceador de cargas recibe una solicitud coincidente, quita el encabezado Content-Length de la respuesta y cambia a la codificación del cuerpo fragmentado.

• Mientras transmite un cuerpo de mensaje al servidor ext_proc, al final, el balanceador de cargas puede enviar un mensaje ProcessingRequest final con un cuerpo vacío con end_stream configurado como true para indicar que la transmisión finalizó.

Otras limitaciones

Las siguientes son limitaciones con los mensajes de respuesta de gRPC:

• El tamaño máximo de un mensaje de respuesta es de 128 KB. Si un mensaje recibido supera este límite, la transmisión se cierra con un error RESOURCE_EXHAUSTED.

• El servicio de backend de texto destacado no puede usar políticas de Cloud Armor, IAP ni Cloud CDN.

• El servicio de backend de texto destacado debe usar HTTP/2 como protocolo.

• Para las extensiones de autorización, el balanceador de cargas no reenvía ningún cuerpo de solicitud al servicio de backend de texto destacado.

• Para las extensiones de ruta, el servicio de backend de texto destacado no puede anular el modo de procesamiento de la transmisión ext_proc.

¿Qué sigue?

• Configura un servicio de backend de texto destacado administrado por el usuario

  Un servicio de backend de texto destacado es un requisito previo para configurar extensiones de ruta, autorización y tráfico administradas por el usuario mediante textos destacados.

• Configura una extensión de autorización

• Configura una extensión de ruta

• Configura una extensión de tráfico

• Configura una extensión para llamar a un servicio de Google