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:intercept-all-outbound-traffic (Vista previa) |
Habilita la intercepción de todo el tráfico saliente por medio del proxy de servicio y, luego, redirecciona a un host externo. Usa gcloud beta con esta opción. |
Opcional. |
--service-proxy:exclude-outbound-ip-ranges (Vista previa) |
Una lista separada por punto y coma (;) de las direcciones IP o los rangos CIDR, especificados entre comillas ("), que deben excluirse del redireccionamiento. Solo se aplica cuando se establece la marca intercept-all-outbound-traffic . Usa gcloud beta con esta opción.Por ejemplo: exclude-outbound-ip-ranges="8.8.8.8;129.168.10.0/24" |
Opcional. |
--service-proxy:exclude-outbound-port-ranges (Vista previa) |
Una lista separada por punto y coma (;) de los puertos o rangos de puertos, especificados entre comillas ("), que se deben excluir del redireccionamiento. Solo se aplica cuando se establece la marca intercept-all-outbound-traffic . Usa gcloud beta con esta opción.Por ejemplo: exclude-outbound-port-ranges="81;8080-8090" |
Opcional. |
--service-proxy:scope (Vista previa) |
La opción scope define un límite de configuración lógica para el recurso Gateway .
Cuando se inicia una VM, el proxy de servicio se comunica con Cloud Service Mesh para recuperar la información de enrutamiento correspondiente a las rutas adjuntas a la puerta de enlace con este nombre de permiso. Cuando se especifica scope , se ignora el valor de red. No puedes especificar valores de scope y mesh al mismo tiempo. Usa gcloud beta con esta opción. |
Opcional. |
--service-proxy:mesh (Vista previa) |
La opción mesh define un límite de configuración lógica para un recurso Mesh .
Cuando se inicia una VM, el proxy de servicio se comunica con Cloud Service Mesh para recuperar la información de enrutamiento correspondiente a las rutas conectadas a Mesh con este nombre de malla. Cuando se especifica mesh , se ignora el valor de red. No puedes especificar valores de scope y mesh al mismo tiempo. Usar gcloud beta con esta opción |
Opcional. |
--service-proxy:project-number (Vista previa) |
La opción project-number especifica el proyecto en el que se crean los recursos Mesh y Gateway . Si no se especifica, se usa el proyecto en el que existe la instancia. Esto se aplica solo a las nuevas API de enrutamiento de servicio. |
Opcional. |
--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 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 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, tenga en cuenta lo siguiente:
- Todas las conexiones salientes a las VIP de los servicios que se configuraron en Cloud Service Mesh 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, las cargas del tráfico se balancean cómo configuraste Cloud Service Mesh.
- 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.
Los flujos de tráfico del diagrama son los siguientes:
- El tráfico entrante con el puerto de destino
80
no se intercepta y se enruta directamente al servicio que escucha en el puerto. - El tráfico entrante con el puerto de destino
8080
se intercepta y se redirecciona al puerto del objeto de escucha de Envoy. - Envoy reenvía el tráfico de (2) al servicio 2 que escucha en el puerto de host local
8080
. - Tráfico saliente destinado a la VIP de la regla de reenvío de Cloud Service Mesh y port, interceptados y redireccionados al puerto del objeto de escucha de Envoy.
- Envoy reenvía el tráfico de (4) al extremo del backend de destino Servicio de backend de Cloud Service Mesh.
- Tráfico saliente destinado a la VIP y el puerto que no son de Cloud Service Mesh, no de Cloud Service Mesh interceptar y enrutarse directamente al servicio externo.
Usa etiquetas
Si quieres especificar etiquetas para usar con los metadatos de la malla de servicios de Cloud
o habilitar el registro de acceso para los proxies de Envoy, usa el
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 y, luego, inscribirla en una red de Cloud Service Mesh.
- Actualizar los componentes del proxy de servicio en las VM
Antes de realizar la actualización progresiva, sigue estos pasos:
- Configura el vaciado de conexiones en el servicio de backend con un valor de 30 segundos como mínimo.
- 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.
- 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.
- 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:
Crea una plantilla de instancias nueva sin especificar la marca
--service-proxy
.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 el único MIG conectado al servicio de backend, recomendamos que quites Configuración de la malla de servicios de Cloud que creaste al establecer la malla de servicios en la nube.