Descripción general de los registros de flujo de VPC

Los registros de flujo de VPC registran una muestra de flujos de red que envían y reciben las instancias de VM, incluidas las instancias que se usan como nodos de Google Kubernetes Engine. Estos registros se pueden usar para supervisar redes, detectar intrusiones, realizar análisis de seguridad en tiempo real y optimizar gastos.

Puedes ver los registros de flujo en Cloud Logging y los puedes exportar a cualquier destino que admita la exportación de Cloud Logging.

Los registros de flujo se agregan por conexión desde las VM de Compute Engine y se exportan en tiempo real. Cuando te suscribes a Pub/Sub, puedes analizar los registros de flujo mediante las API de transmisión en tiempo real.

Propiedades principales

  • Los registros de flujo de VPC son parte de Andromeda, el software que impulsa las redes de VPC. Los registros de flujo de VPC no presentan demoras ni penalizaciones de rendimiento cuando se habilitan.
  • Los registros de flujo de VPC funcionan con redes de VPC, no con redes heredadas. Puedes habilitar o inhabilitar los registros de flujo de VPC por subred. Cuando los registros de flujo de VPC se encuentran habilitados en una subred, recolectan información de todas las instancias de VM de esa subred.
  • Los registros de flujo de VPC realizan un muestreo de los flujos de TCP y UDP de cada VM, entrantes y salientes. Estos flujos pueden estar entre la VM y otra VM, un host en el centro de datos local, un servicio de Google o un host en Internet. Si se captura un flujo mediante el muestreo, los registros de flujo de VPC generan un registro para el flujo. Cada informe de flujo incluye la información que se describe en la sección Formato del registro.
  • Los registros de flujo de VPC interactúan con reglas de firewall de las siguientes maneras:
    • Los paquetes de salida se muestrean antes de las reglas de firewall de salida. Incluso si una regla de firewall de salida rechaza los paquetes salientes, los registros de flujo de VPC pueden muestrear esos paquetes.
    • Los paquetes de entrada se muestrean después de las reglas de firewall de entrada. Si una regla de firewall de entrada deniega paquetes entrantes, los registros de flujo de VPC no muestrean esos paquetes.
  • Puedes usar filtros en los registros de flujo de VPC para generar solo ciertos registros.
  • Los registros de flujo de VPC admiten las VM que tienen interfaces de red múltiples. Debes habilitar los registros de flujo de VPC para cada subred, en cada VPC, que contenga una interfaz de red.
  • Para registrar flujos entre Pods en el mismo nodo de Google Kubernetes Engine (GKE), debes habilitar la visibilidad dentro de los nodos del clúster.

Casos de uso

Supervisión de red

El registro de flujo de VPC te permite ver en tiempo real la capacidad de procesamiento y rendimiento. Puedes llevar a cabo las siguientes acciones:

  • Supervisar la red de VPC
  • Realizar diagnósticos de la red
  • Filtrar los registros de flujo por VM y por aplicación para comprender los cambios en el tráfico
  • Comprender el crecimiento del tráfico para realizar una previsión de la capacidad

Cómo comprender el uso de la red y optimizar los gastos de tráfico de red

Con el registro de flujos de VPC puedes analizar el uso de la red. Puedes analizar los siguientes elementos del flujo de la red:

  • El tráfico entre regiones y zonas
  • El tráfico de Internet hacia países específicos
  • Los usuarios que más conversan

Puedes utilizar el análisis como base para optimizar los gastos del tráfico de red.

Intrusiones en la red

Puedes utilizar el registro de flujo de VPC para detectar las intrusiones en la red. Por ejemplo, si ocurre un incidente, puedes examinar los siguientes elementos:

  • Qué IP se comunicó con quién y en qué momento
  • Los IP comprometidos, mediante el análisis del flujo de red de entrada y de salida

Análisis de seguridad en tiempo real

Puedes aprovechar las API de transmisión en tiempo real (a través de Pub/Sub) y, también, integrar en los sistemas de SIEM (información de seguridad y administración de eventos). Esto te brinda supervisión en tiempo real, correlación de eventos, análisis y alertas de seguridad.

Recopilación de registros

Los registros de flujo se recopilan para cada conexión de VM en intervalos específicos. Todos los paquetes recopilados de un intervalo determinado para una conexión en particular se agregan durante un período (intervalo de agregación) en una sola entrada de registro de flujo. Estos datos se envían a Logging.

Los registros se almacenan en Logging durante 30 días de forma predeterminada. Si quieres conservar los registros por más tiempo, debes exportarlos a un destino admitido.

Muestreo y procesamiento de registros

Google Cloud crea muestras de los paquetes que ingresan a una VM y salen de ella para generar registros de flujo. No todos los paquetes se capturan en su propio registro. Se captura alrededor de 1 de cada 10 paquetes, pero esta tasa de muestreo puede ser menor según la carga de la VM. No se puede ajustar esta tasa.

Después de que se generan los registros de flujo, Google Cloud los procesa de acuerdo con el siguiente procedimiento:

  1. Filtros: Puedes especificar que solo se generen los registros que coinciden con los criterios especificados. Por ejemplo, puedes filtrar a fin de que solo se generen registros para una VM en particular o solo los registros con un valor de metadatos específico y se descarta el resto.
  2. Agregación: La información de los paquetes de muestra se agrega en un intervalo de agregación configurable para producir una entrada de registro de flujo.
  3. Muestreo del registro de flujo: Este es un segundo proceso de muestreo. Las entradas del registro de flujo también se muestrean según un parámetro configurable de tasa de muestreo.
  4. Metadatos: Si se inhabilita, se descartan todas las anotaciones de metadatos. Si deseas conservar los metadatos, puedes especificar que se conserve el conjunto de campos predeterminado o un conjunto de campos especificado. Consulta Personaliza los campos de metadatos para obtener más información.
  5. Escritura en Logging: Las entradas finales de registro se escriben en Cloud Logging.

Debido a que los registros de flujo de VPC no capturan todos los paquetes, compensa los paquetes perdidos mediante la interpolación de los paquetes capturados. Esto sucede para los paquetes que se pierden debido a la configuración de muestreo inicial y configurable por el usuario.

A pesar de que Google Cloud no captura todos los paquetes, las capturas de registros pueden ser bastante grandes. Para equilibrar las necesidades de visibilidad del tráfico y de costo de almacenamiento, ajusta los siguientes aspectos de la recopilación de registros:

  • Intervalo de agregación: Los paquetes de muestra de un intervalo de tiempo se agregan en una sola entrada de registro. Este intervalo de tiempo puede ser de 5 segundos (predeterminado), 30 segundos, 1 minuto, 5 minutos, 10 minutos o 15 minutos.
  • Tasa de muestreo: Antes de escribirse en Logging, se puede muestrear la cantidad de registros para reducir su número. De forma predeterminada, el volumen de entradas de registro se ajusta en 0.5 (50%), lo que significa que se conserva la mitad de las entradas. Puedes configurar este ajuste de 1.0 (100%, se conservan todas las entradas de registro) a 0.0 (0%, no se conserva ningún registro).
  • Anotaciones de metadatos: De forma predeterminada, las entradas de registro de flujo se anotan con información de metadatos, como los nombres de las VM de origen y destino o la región geográfica de fuentes y destinos externos. Las anotaciones de metadatos se pueden desactivar, o puedes especificar solo ciertas anotaciones para ahorrar espacio de almacenamiento.
  • Filtros: De forma predeterminada, se generan registros para cada flujo en la subred. Puedes establecer filtros para que solo se generen registros que coincidan con ciertos criterios.

Personaliza campos de metadatos

Con cada registro, puedes extraer todos los metadatos relevantes, ningún metadato o metadatos específicos que determines. Puedes especificar los campos de metadatos por sus nombres completos (como src_vpc.project_id) o por campo superior (como src_vpc, que incluye src_vpc.project_id, src_vpc.vpc_name y src_vpc.subnetwork_name).

Solo puedes omitir campos del tipo metadatos, no los campos del tipo base. Los campos base siempre se incluyen y no se pueden omitir. En la sección Formato del registro, se enumeran los campos que son metadatos y los que son base.

Cuando se agregan nuevas anotaciones de metadatos al formato de registro de flujo de VPC, no se agregan a la lista de campos en la configuración “include-all” (incluir todo). “Include-all” solo incluye los siguientes campos:

  • src_instance
  • dest_instance
  • src_vpc
  • dest_vpc
  • src_location
  • dest_location

Las anotaciones nuevas, incluidas las anotaciones de GKE, solo aparecen en los registros si se agregan de forma manual mediante la configuración “personalizada”.

Si quieres obtener instrucciones para personalizar campos de metadatos, consulta Habilita los registros de flujo de VPC cuando creas una subred.

Anotaciones de GKE

Los flujos que tienen un extremo en un clúster de GKE pueden anotarse con anotaciones de GKE, que pueden incluir detalles del clúster, el Pod y el Service del extremo. Las anotaciones de GKE solo están disponibles con una configuración personalizada de campos de metadatos.

Anotaciones del Service de GKE

El tráfico enviado a un ClusterIP, NodePort o LoadBalancer puede recibir anotaciones del servicio. Si se envía a un NodePort o un LoadBalancer, el flujo recibe la anotación del Service en ambos saltos de la conexión.

El tráfico enviado directamente al puerto de Service de un Pod se anota con una anotación del Service en el extremo de destino.

El tráfico enviado al puerto de Service de un Pod en el que el Pod está creando una copia de seguridad de más de un Service en el mismo puerto se anota con varios Service en el extremo de destino. Se limita a dos Service. Si hay más que eso, el extremo se anotará con un marcador MANY_SERVICES especial.

Anotaciones de Pod en el tráfico de Internet

De forma predeterminada, el tráfico entre un Pod e Internet no recibe anotaciones de Pod. Para los paquetes a Internet, el agente de enmascaramiento traduce la dirección IP del Pod a la dirección IP del nodo antes de que los registros de flujo de VPC vean el paquete, por lo que los registros de flujo de VPC no conocen nada del Pod y no pueden agregar anotaciones del Pod.

Debido al enmascaramiento, las anotaciones de Pod solo son visibles si los destinos se encuentran dentro de los destinos predeterminados sin enmascarar o en una lista nonMasqueradeCIDRs personalizada. Si incluyes destinos de Internet en una lista nonMasqueradeCIDRs personalizada, debes proporcionar una forma de que las direcciones IP internas del Pod se traduzcan antes de que se entreguen a Internet. Para los clústeres privados y no privados, puedes usar Cloud NAT. Consulta Interacción de GKE para obtener más detalles.

Formato del registro

Los registros contienen campos base, que son los campos principales de cada registro, y campos de metadatos que agregan información adicional. Los campos de metadatos se pueden omitir para ahorrar costos de almacenamiento.

Algunos campos de registro se encuentran en formato de varios campos y poseen más de un dato en un campo específico. Por ejemplo, el campo connection tiene el formato IpConnection, que contiene el puerto y la dirección IP de origen y destino, además del protocolo, en un solo campo. Estos campos de varios campos se describen a continuación en la tabla de formato de registros.

Campo Formato del campo Tipo del campo: base o metadatos opcionales
connection IpConnection
5 tuplas que describen esta conexión.
Base
start_time string
Marca de tiempo (string con formato de fecha RFC 3339) del primer paquete que se observó durante el intervalo de tiempo agregado.
Base
end_time string
Marca de tiempo (string con formato de fecha RFC 3339) del último paquete que se observó durante el intervalo de tiempo agregado
Base
bytes_sent int64
Cantidad de bytes que se enviaron desde el origen hacia el destino
Base
packets_sent int64
Cantidad de paquetes que se enviaron desde el origen hacia el destino
Base
rtt_msec int64
Latencia medida durante el intervalo de tiempo solo para flujos TCP. La latencia medida es el tiempo transcurrido entre el envío de un SEQ y la recepción de un ACK correspondiente. El resultado de la latencia es la suma del RTT de la red y el tiempo que consume la aplicación.
Base
reporter string
El lado que reportó el flujo. Puede ser SRC o DEST.
Base
src_instance InstanceDetails
Si la fuente de la conexión era una VM ubicada en la misma VPC, este campo se propaga con los detalles de la instancia de VM. En una configuración de VPC compartida, project_id corresponde al proyecto que posee la instancia, en general, el proyecto de servicio.
Metadatos
dest_instance InstanceDetails
Si el destino de la conexión era una VM ubicada en la misma VPC, este campo se propaga con los detalles de la instancia de VM. En una configuración de VPC compartida, project_id corresponde al proyecto que posee la instancia, en general, el proyecto de servicio.
Metadatos
src_vpc VpcDetails
Si la fuente de la conexión era una VM ubicada en la misma VPC, este campo se propaga con los detalles de la red de VPC. En una configuración de VPC compartida, project_id corresponde a la del proyecto host.
Metadatos
dest_vpc VpcDetails
Si el destino de la conexión era una VM ubicada en la misma VPC, este campo se propaga con los detalles de la red de VPC. En una configuración de VPC compartida, project_id corresponde a la del proyecto host.
Metadatos
src_location GeographicDetails
Si el origen de la conexión es externo a la VPC de Google, este campo se propaga con los metadatos de ubicación disponibles.
Metadatos
dest_location GeographicDetails
Si el destino de la conexión es externo a la VPC de Google, este campo se propaga con los metadatos de ubicación disponibles.
Metadatos
src_gke_details GkeDetails
Metadatos de GKE para los extremos de origen. Solo está disponible si el extremo es GKE. Solo disponible a través de la configuración personalizada de los campos de metadatos.
Metadatos
dest_gke_details GkeDetails
Metadatos de GKE para los extremos de destino. Solo está disponible si el extremo es GKE. Solo disponible a través de la configuración personalizada de los campos de metadatos.
Metadatos

Formato del campo IpConnection

Campo Tipo Descripción
src_ip string Dirección IP de origen
src_port int32 Puerto de origen
dest_ip string Dirección IP de destino
dest_port int32 Puerto de destino
protocol int32 Número del protocolo IANA

Formato del campo InstanceDetails

Campo Tipo Descripción
project_id string ID del proyecto que contiene la VM.
vm_name string Nombre de la instancia de la VM.
region string Región de la VM
zone string Zona de la VM

Formato del campo VpcDetails

Campo Tipo Descripción
project_id string ID del proyecto que contiene la VPC
vpc_name string VPC en la que opera la VM
subnetwork_name string Subred en la que opera la VM

Formato del campo GeographicDetails

Campo Tipo Descripción
continent string Continente de los extremos externos.
country string País para los extremos externos, representado como un código de país de ISO 3166-1 Alfa-3.
region string Región de los extremos externos.
city string Ciudad de los extremos externos
asn int32 El número del sistema autónomo (ASN) de la red externa a la que pertenece este extremo

Formato del campo GkeDetails

Campo Tipo Descripción
Clúster ClusterDetails Metadatos del clúster de GKE.
Pod PodDetails Metadatos del Pod de GKE, propagados cuando el origen o el destino del tráfico es un Pod.
Service ServiceDetails Metadatos del Service de GKE, propagados solo en los extremos del Service. El registro contiene hasta dos Service. Si hay más de dos Service relevantes, este campo contiene un solo Service con un marcador MANY_SERVICES especial.

Formato del campo ClusterDetails

Campo Tipo Descripción
cluster_name string Nombre del clúster de GKE.
cluster_location string Ubicación del clúster. Puede ser una zona o región, dependiendo de si se trata de un clúster zonal o regional.

Formato del campo PodDetails

Campo Tipo Descripción
pod_name string Nombre del Pod.
pod_namespace string Espacio de nombres del Pod.

Formato del campo ServiceDetails

Campo Tipo Descripción
service_name string Nombre del Service. Si hay más de dos Service relevantes, el campo se configura como un marcador MANY_SERVICES especial.
service_namespace string Espacio de nombres del Service.

Ejemplo:

Si hay dos servicios, el campo Service tiene el siguiente aspecto:

service: [
 0: {
  service_name: "my-lb-service"
  service_namespace: "default"
 }
 1: {
  service_name: "my-lb-service2"
  service_namespace: "default"
 }
]

Si hay más de dos servicios, el campo Service tiene el siguiente aspecto:

service: [
 0: {
  service_name: "MANY_SERVICES"
 }
]

Filtrado de registros

Cuando habilitas los registros de flujo de VPC, puedes configurar un filtro basado en los campos base y de metadatos que solo conservan los registros que coinciden con el filtro. Todos los demás registros se descartan antes de escribirse en Logging, lo que te ahorra dinero y reduce el tiempo necesario para encontrar la información que buscas.

Puedes filtrar en cualquier subconjunto de campos del formato de registro.

Los filtros de registros de flujo de VPC usan CEL, un lenguaje de expresión incorporado para las expresiones lógicas basadas en atributos. Para obtener más información, consulta Operadores lógicos CEL admitidos.

Para obtener más información sobre CEL, consulta la introducción a CEL y la definición de lenguaje. La función de filtro de generación admite un subconjunto limitado de sintaxis CEL.

Ejemplo 1: Limita la recopilación de registros a una VM específica llamada my-vm. En este caso, solo se graban los registros en los que el campo src_instance informado por la fuente del tráfico es my-vm o el campo dst_instance, como lo indica el destino del tráfico es my-vm.

gcloud compute networks subnets update my-subnet \
--logging-filter-expr = "(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance.vm_name == 'my-vm' && reporter=='DEST')"

Ejemplo 2: Limita la recopilación de registros a los paquetes cuyas direcciones IP de origen estén en la subred 10.0.0.0/8.

gcloud compute networks subnets update my-subnet \
--logging-filter-expr = "inIpRange(connection.src_ip, '10.0.0.0/8')"

Operadores lógicos CEL admitidos


Expression

Supported Types

Description
true, false Booleano Constantes booleanas
x == y x != y Booleano, Int, String Operadores de comparación Ejemplo: connection.protocol == 6
x && y x || y Booleano Operadores lógicos booleanos Ejemplo: connection.protocol == 6 && src_instance.vm_name == "vm_1"
!x Booleano Negación
1, 2.0, 0, … Int Literales numéricos constantes
x + y String Concatenación de string
“foo”, “foo”, … String Literal de string constante
x.lower() String Muestra el valor de la string en minúsculas.
x.upper() String Muestra el valor de la string en mayúsculas.
x.contains(y) String El resultado es verdadero si la string contiene la substring especificada.
x.startsWith(y) String El resultado es verdadero si la string comienza con la substring especificada.
x.endsWith(y) String El resultado es verdadero si la string termina con la substring especificada.
inIpRange(X, Y) String El resultado es verdadero si X es una IP e Y es un rango de IP que contiene X.
Ejemplo: inIpRange(“1.2.3.1”, “1.2.3.0/24”)
x.containsFieldValue(y) x: lista
y: mapa(string, string)
El resultado es verdadero si la lista contiene un objeto con campos que coinciden con los pares clave-valor especificados.
Ejemplo: dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'})

Ejemplos de patrones de tráfico

En esta sección se explica cómo funcionan los registros de flujo de VPC en los siguientes casos prácticos:

Flujos de VM a VM en la misma VPC

Flujos de VM dentro de una VPC (haz clic para ampliar)
Flujos de VM dentro de una VPC (haz clic para ampliar)

En los flujos de VM a VM en la misma VPC, los registros de flujo se informan desde la VM que envía la solicitud y la VM que responde, siempre y cuando ambas VM estén en subredes que tengan habilitado los registros de flujo de VPC. En este ejemplo, la VM 10.10.0.2 envía una solicitud con 1,224 bytes a la VM 10.50.0.2, que también se encuentra en una subred con el registro habilitado. A su vez, 10.50.0.2 responde a la solicitud con una respuesta que contiene 5,342 bytes. La solicitud y la respuesta se registran desde ambas VM.

Informe de la VM de solicitud (10.10.0.2)
solicitud/respuesta connection.src_ip connection.dest_ip bytes_sent Anotaciones de VPC
solicitud 10.10.0.2 10.50.0.2 1224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
respuesta 10.50.0.2 10.10.0.2 5342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
Informe de la VM de respuesta (10.50.0.2)
solicitud/respuesta connection.src_ip connection.dest_ip bytes Anotaciones de VPC
solicitud 10.10.0.2 10.50.0.2 1224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
respuesta 10.50.0.2 10.10.0.2 5342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*

Flujos de una VM a una entidad externa

Flujos de una VM a una entidad externa (haz clic para ampliar)
Flujos de una VM a una entidad externa (haz clic para ampliar)

En los flujos entre una VM y una entidad externa, los registros de flujo se informan solo desde la VM:

  • En los flujos de salida, los registros se informan desde la VM que se encuentra en el origen del tráfico.
  • En los flujos de entrada, los registros se informan desde la VM que se encuentra en el destino del tráfico.

Esto aplica para las siguientes situaciones:

  • Tráfico entre una red de VPC y una red local a través de Cloud VPN o Cloud Interconnect
  • Tráfico entre VM y ubicaciones de Internet

En este ejemplo, la VM 10.10.0.2 y el extremo local 10.30.0.2 se conectan a través de una puerta de enlace de VPN o de Cloud Interconnect. El tráfico de salida de 1,224 bytes que se envía de 10.10.0.2 a 10.30.0.2 se registra desde la VM de origen, 10.10.0.2. El tráfico de entrada de 5,342 bytes que se envía de 10.30.0.2 a 10.10.0.2 se registra desde el destino del tráfico, la VM 10.10.0.2.

solicitud/respuesta connection.src_ip connection.dest_ip bytes_sent Anotaciones de VPC
solicitud 10.10.0.2 10.30.0.2 1224 src_instance.*
src_vpc.*
dest_location.*
respuesta 10.30.0.2 10.10.0.2 5342 dest_instance.*
dest_vpc.*
src_location.*

Flujos de VM a VM para una VPC compartida

Flujos de VPC compartida (haz clic para ampliar)
Flujos de VPC compartida (haz clic para ampliar)

En los flujos de VM a VM en una VPC compartida, puedes habilitar los registros de flujo de VPC en la subred del proyecto host. Por ejemplo, la subred 10.10.0.0/20 pertenece a una red de VPC compartida que se define en un proyecto host. Puedes ver los registros de flujo de las VM que pertenecen a esta subred, incluidas las que se crean para proyectos de servicio. En este ejemplo, los proyectos de servicio se llaman “webserver” (servidor web), “recommendation” (recomendación), “database” (base de datos).

En los flujos de VM a VM, cuando ambas VM se encuentran en el mismo proyecto (o en el caso de una red compartida, en el mismo proyecto host) se le proporciona, al otro extremo de la conexión, las anotaciones para el ID del proyecto y datos similares. Si la otra VM se encuentra en un proyecto diferente, no se proporcionan las anotaciones para la otra VM.

En la siguiente tabla, se muestra un flujo que registra 10.10.0.10 o 10.10.0.20.

  • src_vpc.project_id y dest_vpc.project_id son para el proyecto host porque la subred de VPC pertenece a él.
  • src_instance.project_id y dest_instance.project_id son para los proyectos de servicio porque las instancias pertenecen a ellos.
connection
.src_ip
src_instance
.project_id
src_vpc
.project_id
connection
.dest_ip
dest_instance
.project_id
dest_vpc
.project_id
10.10.0.10 webserver host_project 10.10.0.20 recommendation host_project

Los proyectos de servicio no son propietarios de la red de VPC compartida y no tienen acceso a los registros de flujo de la red de VPC compartida.

Flujos de VM a VM para el intercambio de tráfico entre redes de VPC

Flujos de intercambio de tráfico de red de VPC (haz clic para ampliar)
Flujos de intercambio de tráfico de red de VPC (haz clic para ampliar)

A menos que ambas VM estén en el mismo proyecto de Google Cloud, los flujos de VM a VM para la VPC de intercambio de tráfico se informan de la misma manera que para los extremos externos: no se proporciona información sobre el proyecto ni otra anotación para la otra VM. Si ambas VM se encuentran en el mismo proyecto, incluso en redes diferentes, sí se proporciona a la otra VM la información del proyecto y otras anotaciones.

En este ejemplo, las subredes de la VM 10.10.0.2 del proyecto analytics-prod y de la VM 10.50.0.2 del proyecto webserver-test se conectan a través del intercambio de tráfico de redes de VPC. Si los registros de flujo de VPC están habilitados en el proyecto analytics-prod, el tráfico (1,224 bytes) que se envía de 10.10.0.2 a 10.50.0.2 se registra desde la VM 10.10.0.2, que es el origen del flujo. El tráfico (5,342 bytes) que se envía de 10.50.0.2 a 10.10.0.2 también se registra desde la VM 10.10.0.2, que es el destino del flujo.

En este ejemplo, los registros de flujo de VPC no se encuentran habilitados en el proyecto webserver-test, por lo que la VM 10.50.0.2 no realiza registros.

reporter connection.src_ip connection.dest_ip bytes_sent Anotaciones de VPC
origen 10.10.0.2 10.50.0.2 1224 src_instance.*
src_vpc.*
destino 10.50.0.2 10.10.0.2 5342 dest_instance.*
dest_vpc.*

Flujos de VM a VM para el balanceo de cargas de TCP/UDP interno

Flujos de balanceo de cargas de TCP/UDP interno (haz clic para ampliar)
Flujos de balanceo de cargas de TCP/UDP interno (haz clic para ampliar)

Cuando agregas una VM al servicio de backend para un balanceador de cargas de TCP/UDP interno, el entorno invitado de Linux o Windows agrega la dirección IP del balanceador de cargas a la tabla de enrutamiento local de la VM. Esto permite que la VM acepte paquetes de solicitud con destinos establecidos en la dirección IP del balanceador de cargas. Cuando la VM responde, envía su respuesta de forma directa; sin embargo, la dirección IP de origen de los paquetes de respuesta está configurada en la dirección IP del balanceador de cargas, y no en la VM del balanceo de cargas.

Los flujos de VM a VM que se envían a través de un balanceador de cargas de TCP/UDP interno se informan desde el origen y el destino. En la siguiente tabla, se explican los campos de entrada de registro del flujo observados para un ejemplo de par solicitud-respuesta HTTP. A los fines de esta ilustración, considera la siguiente configuración de red:

  • Instancia del navegador en 192.168.1.2
  • Balanceador de cargas de TCP/UDP interno en 10.240.0.200
  • Instancia del servidor web en 10.240.0.3
Dirección del tráfico reporter connection.src_ip connection.dest_ip connection.src_instance connection.dest_instance
Solicitud SRC 192.168.1.2 10.240.0.200 Instancia del navegador
Solicitud DEST 192.168.1.2 10.240.0.200 Instancia del navegador Instancia de webserver
Respuesta SRC 10.240.0.3 192.168.1.2 Instancia de webserver Instancia del navegador
Respuesta DEST 10.240.0.200 192.168.1.2 Instancia del navegador

La VM que envía la solicitud no sabe qué VM responderá. Además, debido a que la otra VM envía una respuesta con la IP del balanceador de cargas interno como la dirección de origen, no sabe qué VM respondió. Por estos motivos, la VM que envía la solicitud no puede agregar información de dest_instance a su registro, solo información de src_instance. Debido a que la VM que responde conoce la dirección IP de la otra VM, puede proporcionar información de src_instance y dest_instance.

Flujo de Pod a ClusterIP

Flujo de Pod a la IP del clúster (haz clic para ampliar)
Flujo de Pod a la IP del clúster (haz clic para ampliar)

En este ejemplo, el tráfico se envía desde el Pod cliente (10.4.0.2) a cluster-service (10.0.32.2:80). El destino se resuelve en la dirección IP del Pod del servidor si seleccionas (10.4.0.3) en el puerto de destino (8080).

En los bordes del nodo, el flujo se muestra dos veces con la dirección IP y el puerto traducidos. Para ambos puntos de muestreo, identificaremos que el Pod de destino respalda el servicio cluster-service en el puerto 8080 y anotamos el registro con los detalles del Service y los detalles del Pod. En caso de que el tráfico se enrute a un Pod en el mismo nodo, el tráfico no sale del nodo y no se muestrea en absoluto.

Se encontraron los siguientes registros. Los campos de GKE solo están disponibles con una configuración de metadatos “personalizada”.

reporter connection.src_ip connection.dst_ip bytes_sent Anotaciones de VPC
SRC 10.4.0.2 10.4.0.3 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
src_gke_details.pod.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.4.0.2 10.4.0.3 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
src_gke_details.pod.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Flujos LoadBalancer externos de GKE

Flujos del balanceador de cargas externo (haz clic para ampliar)
Flujos del balanceador de cargas externo (haz clic para ampliar)

El tráfico de una dirección IP externa a un servicio de GKE (35.35.35.35) se enruta a un nodo en el clúster, 10.0.12.2 en este ejemplo, para el enrutamiento. De forma predeterminada, los balanceadores de cargas de red distribuyen el tráfico entre todos los nodos del clúster, incluso aquellos que no ejecutan un Pod relevante. El tráfico puede necesitar saltos adicionales para llegar al Pod relevante. Para obtener más información, consulta Herramientas de redes fuera del clúster.

El tráfico se enruta desde el nodo (10.0.12.2) hacia el Pod de servidor seleccionado (10.4.0.2). Ambos saltos se registran porque se realizan muestras de todos los perímetros de los nodos. En caso de que el tráfico se enrute a un Pod en el mismo nodo, 10.4.0.3 en este ejemplo, el segundo salto no se registrará, porque no sale del nodo. El segundo salto se registra en los puntos de muestreo de ambos nodos. El segundo salto se registra en los puntos de muestreo de ambos nodos. Para el primer salto, identificamos el Service según la IP del balanceador de cargas y el puerto del Service (80). Para el segundo salto, identificamos que el Pod de destino respalda el Service en el puerto de destino (8080).

En este ejemplo, se encuentran los siguientes registros. Los campos de GKE solo están disponibles con una configuración de metadatos “personalizada”.

reporter connection.src_ip connection.dst_ip bytes_sent Anotaciones de VPC
DEST 203.0.113.1 35.35.35.35 1224 src_location.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Flujos de Ingress de GKE

Flujos de Ingress (haz clic para ampliar)
Flujos de Ingress (haz clic para ampliar)

Una conexión de una dirección IP pública a un destino de Ingress finaliza en el Service del balanceador de cargas. La conexión se mapea a un Service NodePort, según la URL. Para entregar la solicitud, el balanceador de cargas (130.211.0.1) se conecta a uno de los nodos del clúster (10.0.12.2) para el enrutamiento mediante el NodePort del Service. De forma predeterminada, cuando se crea un Ingress, el controlador de Ingress de GKE configura un balanceador de cargas de HTTP(S) que distribuye el tráfico en todos los nodos del clúster, incluso aquellos que no ejecutan un Pod relevante. El tráfico puede necesitar saltos adicionales para llegar al Pod relevante. Para obtener más información, consulta Descripción general de la red. El tráfico se enruta desde el nodo (10.0.12.2) hacia el Pod de servidor seleccionado (10.4.0.2).

Ambos saltos se registran porque se realizan muestras de todos los perímetros de los nodos. Para el primer salto, se identifica el Service según su NodePort (60000). Para el segundo salto, se comprueba que el Pod de destino respalde el Service en el puerto de destino (8080). El segundo salto se registra en los puntos de muestreo de ambos nodos. Sin embargo, en un caso en el que el tráfico se enruta a un Pod en el mismo nodo (10.4.0.3), el segundo salto no se registra porque el tráfico no abandonó el nodo.

En este ejemplo, se encuentran los siguientes registros. Los campos de GKE solo están disponibles con una configuración de metadatos “personalizada”.

reporter connection.src_ip connection.dst_ip bytes_sent Anotaciones de VPC
DEST 130.211.0.1 10.0.12.2 1224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Flujos de Ingress de GKE mediante el balanceo de cargas nativo del contenedor

Flujos de Ingress mediante el balanceo de cargas nativo del contenedor (haz clic para ampliar)
Flujos de Ingress mediante el balanceo de cargas nativo del contenedor (haz clic para ampliar)

Las solicitudes de una dirección IP pública a un Ingress que usa el balanceo de cargas nativo del contenedor finalizan en el balanceador de cargas. En este tipo de Ingress, los Pods son objetos principales para el balanceo de cargas. Luego, se envía una solicitud desde el balanceador de cargas (130.211.0.1) directamente a un Pod seleccionado (10.4.0.2). Identificamos que el Pod de destino respalda al Service en el puerto de destino (8080).

Se encontró el siguiente registro. Los campos de GKE solo están disponibles con una configuración de metadatos “personalizada”.

reporter connection.src_ip connection.dst_ip bytes_sent Anotaciones de VPC
DEST 130.211.0.1 10.4.0.2 1224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Pod al flujo externo

Pod al flujo externo (haz clic para ampliar)
Pod al flujo externo (haz clic para ampliar)

El tráfico de un Pod (10.4.0.3) a una IP externa (203.0.113.1) se modifica mediante el enmascaramiento de IP para que los paquetes se envíen desde la IP del nodo (10.0.12.2) en lugar de la IP del Pod. De forma predeterminada, el clúster de GKE está configurado para enmascarar el tráfico a destinos externos. Para obtener más información, consulta agente de enmascaramiento de IP.

Si quieres ver las anotaciones de Pod de este tráfico, puedes configurar el agente de enmascaramiento para que no enmascare las IP de los Pods. En ese caso, para permitir el tráfico a Internet, puedes configurar Cloud NAT, que procesa las direcciones IP del Pod. Para obtener más información sobre Cloud NAT con GKE, consulta la interacción de GKE.

En este ejemplo, se encuentra el siguiente registro. Los campos de GKE solo están disponibles con una configuración de metadatos “personalizada”.

reporter connection.src_ip connection.dst_ip bytes_sent Anotaciones de VPC
SRC 10.0.12.2 203.0.113.1 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_location.*

Precios

Se aplicará el precio estándar para Logging, BigQuery o Pub/Sub. El precio de los registros de flujo de VPC se describe en Precios de telemetría de red.

Preguntas frecuentes

  • ¿Los registros de flujo de VPC incluyen el tráfico permitido y el rechazado en función de las reglas de firewall?

    • Los registros de flujo de VPC incluyen el tráfico desde la perspectiva de una VM. Se registra todo el tráfico de salida (saliente) de una VM, incluso si está bloqueado por una regla de firewall de denegación de salida. El tráfico de entrada (entrante) se registra si una regla de firewall de entrada lo permite. El tráfico de entrada bloqueado por una regla de firewall de denegación de entrada no se registra.
  • ¿Los registros de flujo de VPC funcionan con instancias de VM con interfaces múltiples?

  • ¿Los registros de flujo de VPC funcionan con redes heredadas?

    • No, los registros de flujo de VPC no son compatibles con las redes heredadas.

Próximos pasos