Opciones para la configuración de VM de Compute Engine con implementación automática de Envoy

En esta guía, se proporciona información sobre opciones y tareas adicionales para la implementación automatizada de Envoy.

Opciones adicionales de creación de plantillas de instancias

Cuando creas una plantilla de instancias para la implementación automatizada del proxy de Envoy, puedes usar los siguientes parámetros a fin de definir algunos aspectos de la implementación y el comportamiento de los proxies.

Parámetro Valor y descripción Obligatorio u opcional
--service-proxy enabled
Controla si el agente y el proxy de servicio están instalados y configurados en la VM.
Es obligatorio si deseas implementar y configurar de forma automática el proxy de servicio. Si omites esta configuración, el proxy de servicio no se instala ni se configura.
--service-proxy:serving-ports Es una lista de puertos separados por punto y coma.
Los puertos en los que la aplicación o la carga de trabajo entrega contenido. El proxy de servicio intercepta el tráfico entrante y, luego, lo reenvía a los puertos de entrega especificados en el host local.
Opcional.
Si omites esta marca, el proxy de servicio solo controla el tráfico saliente de tu carga de trabajo. El proxy de servicio no controla el tráfico entrante.
--service-proxy:proxy-port Es un solo puerto.
Es el puerto en el que escucha el proxy de servicio. La VM intercepta el tráfico y lo redirecciona a este puerto para que lo administre el proxy de servicio.
Opcional.
Si omites esta marca, el valor predeterminado es 15001
--service-proxy:network Es el nombre de una red de VPC válida.
Se trata de la red de VPC de Google Cloud que se usa en el plano de control del proxy de servicio a fin de generar la configuración dinámica para el proxy de servicio.
Es obligatorio si la VM está en más de una red. De lo contrario, es opcional.
Si omites esta marca, se usa el valor que se especifica mediante el parámetro --network durante la creación de la plantilla de instancias de VM.
--service-proxy:tracing ON u OFF
Permite que el proxy de servicio genere información de seguimiento distribuido. Si se configura como ON, el plano de control del proxy de servicio genera una configuración que permite el seguimiento de solicitudes basado en el ID.
Para obtener más información, consulta la documentación de generate_request_id correspondiente al proxy de Envoy.
Opcional.
Si omites esta marca, el seguimiento no se habilita.
--service-proxy:access-log Es la ruta de acceso al archivo para los registros de acceso que se envían al proxy de servicio mediante el plano de control. Todas las solicitudes entrantes y salientes se registran en este archivo.
Si deseas obtener más información, consulta la documentación Registro de acceso a archivos para el proxy de Envoy.
Opcional. No hay un valor predeterminado. Si no especificas la ruta de acceso al archivo, no se crean los registros.
--service-proxy-labels Son pares clave-valor con el formato key=value.
Se trata de etiquetas que puedes aplicar a tu proxy de servicio. Estas se reflejan en los metadatos de arranque de tu proxy de Envoy. Las etiquetas pueden ser cualquier par key=value que desees establecer como metadatos de proxy (por ejemplo, para su uso con el filtrado de configuración). Puedes usar estas marcas para las etiquetas de aplicación y versión, por ejemplo, app=review o version=canary. También puedes usarlas juntas.
Opcional.

Por ejemplo, el siguiente comando de gcloud crea una plantilla de instancias llamada proxy-it. Las instancias que se crean a partir de esta plantilla tienen instalados el proxy de Envoy y el agente del proxy de servicio.

gcloud beta compute instance-templates create proxy-it \
    --service-proxy enabled

En el siguiente ejemplo, la plantilla de instancias se llama proxy-it, el proxy de Envoy y el agente del proxy de servicio están instalados, el puerto de entrega y el puerto de proxy están configurados, el seguimiento está habilitado, y se define una etiqueta.

gcloud beta compute instance-templates create proxy-it \
  --service-proxy enabled,serving-ports=8080,proxy-port=15001,tracing=ON \
  --service-proxy-labels version=canary

En el siguiente diagrama, se ilustra el flujo de tráfico cuando especificas el puerto de entrega como 8080. Las conexiones TCP entrantes al puerto 8080 se interceptan mediante iptables y se redireccionan al proxy de Envoy, que, luego, las pasa a la aplicación en tu VM que escucha en el puerto TCP 8080. Además, ten en cuenta lo siguiente:

  • Todas las conexiones salientes a las VIP de los servicios que se configuraron en Traffic Director se interceptan mediante iptables, de modo que se configura netfilter. Netfilter garantiza que el tráfico correspondiente que transita la pila de red se intercepte y se redireccione al proxy de Envoy. Luego, se realiza el balanceo de cargas del tráfico según la configuración de Traffic Director.
  • Las otras conexiones entrantes no son interceptadas por iptables, sino que se pasan directamente a servicios de la VM.
  • Todas las conexiones a los extremos externos se pasan directamente a direcciones IP externas sin intercepciones.
  • Todo el tráfico de UDP se pasa directamente al destino sin que iptables lo intercepte.

Esto se ilustra en el siguiente diagrama.

Distribución de tráfico con Traffic Director (haz clic para ampliar)
Distribución de tráfico con Traffic Director (haz clic para ampliar)

Los flujos de tráfico del diagrama son los siguientes:

  1. El tráfico entrante con el puerto de destino 80 no se intercepta y se enruta directamente al servicio que escucha en el puerto.
  2. El tráfico entrante con el puerto de destino 8080 se intercepta y se redirecciona al puerto del objeto de escucha de Envoy.
  3. Envoy reenvía el tráfico de (2) al servicio 2 que escucha en el puerto de host local 8080.
  4. El tráfico saliente destinado al puerto y la VIP de la regla de reenvío de Traffic Director se intercepta y se redirecciona al puerto del objeto de escucha de Envoy.
  5. Envoy reenvía el tráfico de (4) al extremo del backend del servicio de backend de destino de Traffic Director.
  6. El tráfico saliente destinado a una VIP y un puerto que no son de Traffic Director no se intercepta y se enruta directamente a un servicio externo.

Usa etiquetas

Si deseas especificar etiquetas a fin de usarlas con el filtrado de metadatos de Traffic Director o habilitar el registro de acceso para los proxies Envoy, usa los parámetros --service-proxy-labels o --service-proxy access-log.

Por ejemplo:

gcloud compute instance-templates create td-vm-template-auto \
   --service-proxy enabled,access-log=/var/log/envoy/access.log,network=default \
   --service-proxy-labels myapp=review,version=canary

El proxy de Envoy puede interceptar los puertos de verificación de estado para los servicios en las VM. Si haces esto, los sondeos de verificación de estado generan informes sobre tu aplicación y sobre los proxies de Envoy. El tráfico no se dirige a la VM si el proxy de Envoy no se ejecuta de forma correcta. Por ejemplo:

gcloud compute instance-templates create td-vm-template-auto \
  --service-proxy=enabled,serving-ports="80;8080"

Usa el proceso de actualización de grupos de instancias administrados

Si usaste el proceso automatizado para configurar los proxies de Envoy, puedes usar el proceso de actualización de grupos de instancias administrados a fin de actualizar tu grupo de instancias administrado. Usa este proceso para los siguientes fines:

  • Agregar los componentes del proxy de servicio a un grupo de instancias administrado existente e inscribir este grupo en una red de Traffic Director
  • Actualizar los componentes del proxy de servicio en las VM

Antes de realizar la actualización progresiva, sigue estos pasos:

  1. Configura el vaciado de conexiones en el servicio de backend con un valor de 30 segundos como mínimo.
  2. Usa el parámetro --min-ready con un valor de 3 minutos o más cuando llames al actualizador. El parámetro --min-ready hace que el grupo de instancias administrado espere después de que se actualice una VM antes de continuar con la actualización de la siguiente VM. Si esto no fuese así, la VM recién creada no tendría tiempo para iniciar por completo Envoy y el agente del proxy de servicio, y la actualización continuaría con demasiada rapidez.

Para realizar la actualización progresiva en un grupo de instancias administrado, sigue estos pasos.

  1. Crea una plantilla de instancias nueva, como se describió antes, con la información del proxy de servicio. La versión original de la plantilla de instancias se puede usar para la actualización si contiene la información del proxy de servicio y si tu objetivo es actualizar a la versión estable más reciente del software del proxy.
  2. Realiza una actualización progresiva del grupo de instancias administrado. Asegúrate de configurar REPLACE como la acción mínima que debe realizar el Actualizador. El grupo de instancias instala la última versión del software del proxy y la configura como se especifica en la plantilla de instancias.

También puedes quitar los componentes del proxy de servicio de un grupo de instancias administrado mediante el proceso de actualización:

  1. Crea una plantilla de instancias nueva sin especificar la marca --service-proxy.

  2. Realiza una actualización progresiva mediante el proceso de actualización de grupos de instancias administrados.

De esta forma, se quita el proxy de Envoy de tus VM. Si ese grupo de instancias administrado era el único MIG conectado al servicio de backend, te recomendamos quitar la configuración de Traffic Director que creaste cuando configuraste Traffic Director.