Visão geral dos registros de fluxo de VPC

Os registros de fluxo de VPC gravam uma amostra de fluxos de rede enviada e recebida por instâncias de VM, incluindo instâncias usadas como nós do Google Kubernetes Engine. Esses registros são usados para monitoramento de rede, perícia forense, análise de segurança em tempo real e otimização de despesas.

É possível ver os registros de fluxo no Cloud Logging e exportá-los para qualquer destino compatível com a exportação do Cloud Logging.

Os registros de fluxo são agregados por conexão das VMs do Compute Engine e exportados em tempo real. Quando você assina o Pub/Sub, é possível analisar os registros de fluxo com APIs de streaming em tempo real.

Propriedades principais

  • Os registros de fluxo de VPC fazem parte do Andromeda, o software que aciona redes VPC. Eles não causam atrasos ou penalidades de desempenho quando ativados.
  • Os registros de fluxo de VPC funcionam com redes VPC, não com redes legadas. Eles são ativados ou desativados por sub-rede. Se forem ativados em uma sub-rede, os registros de fluxo de VPC coletam dados de todas as instâncias de VM nessa sub-rede.
  • Os registros de fluxo de VPC fornecem amostras dos fluxos TCP, UDP, ICMP, ESP e GRE de cada VM. São fornecidas amostras para os fluxos de entrada e os de saída. Esses fluxos podem ser entre a VM e outra VM, um host no seu data center no local, um serviço do Google ou um host na Internet. Se um fluxo for capturado por amostragem, os registros de fluxo de VPC gerarão um registro para o fluxo. Cada registro de fluxo inclui as informações descritas na seção Formato do registro.
  • Os registros de fluxo de VPC interagem com as regras de firewall das seguintes maneiras:
    • Os pacotes de saída são amostrados antes das regras de firewall de saída. Mesmo que uma regra de firewall de saída negue pacotes de saída, é possível que esses pacotes sejam amostrados por registros de fluxo de VPC.
    • Os pacotes de entrada são amostrados depois das regras de firewall de entrada. Se uma regra de firewall de entrada negar pacotes de entrada, esses pacotes não serão amostrados por registro de fluxo de VPC.
  • É possível usar filtros nos registros de fluxo de VPC para gerar apenas determinados registros.
  • Os registros de fluxo de VPC são compatíveis com VMs que têm várias interfaces de rede. É necessário ativar os registros de fluxo de VPC para cada sub-rede, em cada VPC, que contenha uma interface de rede.
  • Para registrar fluxos entre pods no mesmo nó do Google Kubernetes Engine (GKE), ative a visibilidade intranós no cluster.

Casos de uso

Monitoramento de rede

Os registros de fluxo de VPC fornecem visibilidade em tempo real da capacidade e do desempenho da rede. Você pode:

  • monitorar a rede VPC;
  • realizar o diagnóstico de rede;
  • filtrar os registros de fluxo por VM e por aplicativo para entender as alterações no tráfego;
  • entender o crescimento do tráfego para previsão de capacidade.

Como entender o uso da rede e como otimizar as despesas de tráfego

É possível analisar o uso da rede com os registros de fluxo de VPC. Você pode analisar os fluxos de rede de:

  • tráfego entre regiões e zonas;
  • tráfego para países específicos na Internet;
  • principais talkers.

Com base na análise, você pode otimizar as despesas de tráfego da rede.

Perícia forense da rede

É possível usar os registros de fluxo de VPC para fazer uma análise forense na rede. Por exemplo, se houver um incidente, você pode examinar:

  • quais IPs conversaram com quem e quando isso aconteceu;
  • todos os IPs comprometidos, pela análise de todos os fluxos de rede de entrada e de saída.

Análise de segurança em tempo real

É possível aproveitar as APIs de streaming em tempo real (por meio do Pub/Sub) e as integrar aos sistemas de Gerenciamento e Correlação de Eventos de Segurança (SIEM, na sigla em inglês). Isso pode fornecer monitoramento em tempo real, correlação de eventos, análise e alertas de segurança.

Coleta de registros

Os registros de fluxo são coletados para cada conexão de VM em intervalos específicos. Todos os pacotes coletados para um determinado intervalo, em uma determinada conexão, são agregados por um período de tempo (intervalo de agregação), em uma única entrada do registro de fluxo. Esses dados são enviados para o Logging.

Os registros são armazenados no Logging por 30 dias, por padrão. Se você quiser manter os registros por mais tempo, será possível definir um período de retenção personalizado ou exportá-los para um destino compatível.

Amostragem e processamento de registros

O Google Cloud coleta amostras de pacotes de saída e entrada de VM para gerar registros de fluxo. Nem todo pacote é capturado no próprio registro. Cerca de 1 a cada 10 pacotes é capturado, mas essa taxa de amostragem pode ser menor, dependendo da carga da VM. Não é possível ajustar essa taxa.

Depois que os registros de fluxo são gerados, o Google Cloud os processa de acordo com o seguinte procedimento:

  1. Filtragem: é possível especificar que apenas os registros que corresponderem a critérios especificados serão gerados. Por exemplo, é possível filtrar para que apenas os registros de uma determinada VM ou apenas os registros com um determinado valor de metadados sejam gerados, enquanto o restante é descartado.
  2. Agregação: as informações dos pacotes da amostragem são agregadas em um intervalo de agregação configurável para produzir uma entrada de registro de fluxo.
  3. Amostragem do registro de fluxo: este é um segundo processo de amostragem. As entradas do registro de fluxo são amostradas posteriormente, de acordo com um parâmetro configurável de taxa de amostragem.
  4. Metadados: se desativados, todas as anotações de metadados serão descartadas. Se quiser manter os metadados, você poderá especificar que todos os campos ou um conjunto específico de campos sejam mantidos. Consulte as anotações de metadados para mais detalhes.
  5. Gravar no Logging: as entradas de registro finais são gravadas no Cloud Logging.

Como os registros de fluxo de VPC não capturam todos os pacotes, eles compensam os pacotes ausentes por meio da interpolação dos pacotes capturados. Isso acontece com os pacotes perdidos devido a configurações de amostragem iniciais e definidas pelo usuário.

Embora o Google Cloud não capture todos os pacotes, as capturas de registros podem ser muito grandes. É possível equilibrar a visibilidade do tráfego e suas necessidades de custo de armazenamento ajustando os seguintes aspectos da coleta de registros:

  • Intervalo de agregação: pacotes amostrados em um intervalo de tempo são agregados em uma única entrada de registro. Esse intervalo de tempo pode ser de 5 segundos (padrão), 30 segundos, 1 minuto, 5 minutos, 10 minutos ou 15 minutos.
  • Taxa de amostragem: antes de ser gravado no Logging, o número de registros pode ser amostrado para reduzir a quantidade deles. Por padrão, o volume de entrada de registros é escalonado em 0,50 (50%), o que significa que metade das entradas será mantida. É possível definir esse valor de 1.0 (100%, todas as entradas de registro serão mantidas) até 0.0 (0%, nenhum registro será mantido).
  • Anotações de metadados: por padrão, as entradas do registro de fluxo são anotadas com informações de metadados, como os nomes das VMs de origem e de destino ou a região geográfica de origens e destinos externos. É possível desativar as anotações de metadados ou especificar apenas algumas anotações para economizar espaço de armazenamento.
  • Filtragem: por padrão, os registros são gerados a cada fluxo na sub-rede. É possível definir filtros para que sejam gerados apenas registros que correspondam a determinados critérios.

Anotações de metadados

Os registros contêm campos de base e de metadados. A seção Formato de registro lista quais campos são do tipo metadados e quais são do tipo base. Todos os campos de base são sempre incluídos. É possível personalizar quais campos de metadados manter.

  • Se você selecionar todos os metadados, todos os campos de metadados no formato de registros de fluxo de VPC serão incluídos nos registros de fluxo. Quando novos campos de metadados são adicionados ao formato de registro, os registros de fluxo incluem automaticamente os novos campos.

  • Se você não selecionar metadados, todos os campos de metadados serão omitidos.

  • Se você selecionar metadados personalizados, poderá especificar os campos de metadados que quer incluir pelo campo pai, como src_vpc, ou pelos nomes completos, como src_vpc.project_id.

    Quando novos campos de metadados são adicionados ao formato de registro, os registros de fluxo não incluem esses campos, a menos que sejam um novo campo em um campo pai especificado para ser incluído.

    • Quando você especifica metadados personalizados usando campos pais, quando novos campos de metadados são adicionados ao formato de registro no campo pai, os registros de fluxo incluem automaticamente os novos campos.

    • Se você especificar metadados personalizados com o nome completo do campo, quando novos campos de metadados forem adicionados ao campo pai, os registros de fluxo não incluirão os novos campos.

Para instruções sobre como personalizar os campos de metadados, consulte as instruções da API ou do gcloud sobre como ativar a geração de registros de fluxo de VPC quando você cria uma sub-rede.

Anotações do GKE

É possível que fluxos que tenham um endpoint em um cluster do GKE sejam anotados com anotações do GKE, que incluem detalhes do cluster, do pod e do serviço do endpoint.

Anotações de serviço do GKE

O tráfego enviado para um ClusterIP, NodePort ou LoadBalancer recebe anotações de serviço. Se for enviado para um NodePort ou LoadBalancer, o fluxo receberá a anotação de serviço nos dois saltos da conexão.

O tráfego enviado diretamente para a porta de serviço de um pod será anotado com uma anotação de serviço no endpoint de destino.

O tráfego enviado para a porta de serviço de um pod em que o pod está fazendo mais de um serviço na mesma porta de serviço será anotado com vários serviços no endpoint de destino. Isso se limita a dois serviços. Se houver mais, o endpoint será anotado com um marcador MANY_SERVICES especial.

Anotações de pod no tráfego da Internet

O tráfego entre um pod e a Internet não recebe anotações de pod por padrão. Em pacotes para a Internet, o agente de mascaramento traduz o endereço IP do pod para o endereço IP do nó antes que os registros de fluxo de VPC vejam o pacote. Assim, os registros de fluxo de VPC não sabem nada sobre o pod e não podem adicionar o anotações de pod.

Devido ao mascaramento, as anotações de pod só serão visíveis se os destinos estiverem dentro dos destinos padrão não mascaradosou em uma lista nonMasqueradeCIDRs personalizada. Se você incluir destinos de Internet em uma lista nonMasqueradeCIDRs personalizada, será necessário fornecer uma maneira para que os endereços IP internos do pod sejam traduzidos antes de serem entregues à Internet. Para clusters particulares e não particulares, é possível usar o Cloud NAT. Consulte Interação do GKE para mais detalhes.

Formato do registro

Os registros contêm campos básicos, que são os campos principais de cada registro, e campos de metadados que acrescentam informações adicionais. É possível omitir os campos de metadados para economizar custos de armazenamento.

Alguns campos de registro aparecem em um formato múltiplo, com mais de um dado em cada campo. Por exemplo, o campo connection é do formato IpConnection, que contém o endereço IP e a porta de origem e destino, mais o protocolo, em um único campo. Esses vários campos estão descritos abaixo da tabela de formatos de registro.

Campo Formato do campo Tipo de campo: base ou metadados opcionais
connection IpConnection
Cinco tuplas que descrevem a conexão.
Base
start_time string
Carimbo de data/hora (formato de string de data RFC 3339) do primeiro pacote observado durante o intervalo de tempo agregado.
Base
end_time string
Carimbo de data/hora (formato de string de data RFC 3339) do último pacote observado durante o intervalo de tempo agregado
Base
bytes_sent int64
Quantidade de bytes enviados da origem para o destino
Base
packets_sent int64
Número de pacotes enviados da origem para o destino
Base
rtt_msec int64
Latência medida durante o intervalo de tempo, apenas para fluxos TCP. A latência medida é o tempo decorrido entre o envio de um SEQ e o recebimento de um ACK correspondente. O resultado da latência é a soma do RTT da rede e de qualquer tempo consumido pelo aplicativo.
Base
reportado por string
O lado que informou o fluxo. Pode ser ou SRC ou DEST.
Base
src_instance InstanceDetails
Se a origem da conexão for uma VM localizada na mesma VPC, esse campo será preenchido com os detalhes da instância da VM. Em uma configuração de VPC compartilhada, project_id corresponde ao projeto proprietário da instância, geralmente o projeto de serviço.
Metadados
dest_instance InstanceDetails
Se o destino da conexão for uma VM localizada na mesma VPC, esse campo será preenchido com os detalhes da instância da VM. Em uma configuração de VPC compartilhada, project_id corresponde ao projeto proprietário da instância, geralmente o projeto de serviço.
Metadados
src_vpc VpcDetails
Se a origem da conexão for uma VM localizada na mesma VPC, esse campo será preenchido com os detalhes da rede VPC. Em uma configuração de VPC compartilhada, project_id corresponde ao do projeto host.
Metadados
dest_vpc VpcDetails
Se o destino da conexão for uma VM localizada na mesma VPC, esse campo será preenchido com os detalhes da rede VPC. Em uma configuração de VPC compartilhada, project_id corresponde ao do projeto host.
Metadados
src_location GeographicDetails
Se a origem da conexão for externa à VPC, esse campo será preenchido com metadados de local disponíveis.
Metadados
dest_location GeographicDetails
Se o destino da conexão for externo à VPC, este campo será preenchido com metadados de local disponíveis.
Metadados
src_gke_details GkeDetails
Metadados do GKE para endpoints de origem. Disponível apenas se o endpoint for o GKE.
Metadados
dest_gke_details GkeDetails
Metadados do GKE para endpoints de destino. Disponível apenas se o endpoint for o GKE.
Metadados

Formato do campo IpConnection

Campo Tipo Descrição
src_ip string Endereço IP de origem
src_port int32 Porta de origem
dest_ip string Endereço IP de destino
dest_port int32 Porta de destino
protocolo int32 Número do protocolo IANA

Formato do campo InstanceDetails

Campo Tipo Descrição
project_id string Código do projeto que contém a VM
vm_name string Nome da instância da VM
region string Região da VM
zone string Zona da VM

Formato do campo VpcDetails

Campo Tipo Descrição
project_id string Código do projeto que contém a VPC
vpc_name string VPC em que a VM está operando
subnetwork_name string Sub-rede em que a VM está operando

Formato do campo GeographicDetails

Campo Tipo Descrição
continent string Continente para endpoints externos
country string País para endpoints externos, representado como códigos de país ISO 3166-1 Alfa-3.
region string Região para endpoints externos
city string Cidade para pontos de extremidade externos
asn int32 O número de sistema autônomo (ASN, na sigla em inglês) da rede externa a que este endpoint pertence.

Formato do campo GkeDetails

Campo Tipo Descrição
cluster ClusterDetails Metadados do cluster do GKE.
pod PodDetails Metadados do pod do GKE, preenchidos quando a origem ou o destino do tráfego for um pod.
serviço ServiceDetails Metadados do serviço do GKE, preenchidos apenas em endpoints de serviço. O registro contém até dois serviços. Se houver mais de dois serviços relevantes, esse campo conterá um único serviço com um marcador MANY_SERVICES especial.

Formato do campo ClusterDetails

Campo Tipo Descrição
cluster_name string Nome do cluster do GKE.
cluster_location string Local do cluster. É uma zona ou uma região, dependendo se o cluster for zonal ou regional.

Formato do campo PodDetails

Campo Tipo Descrição
pod_name string Nome do pod.
pod_namespace string Namespace do pod.

Formato do campo ServiceDetails

Campo Tipo Descrição
service_name string Nome do serviço. Se houver mais de dois serviços relevantes, o campo será definido como um marcador MANY_SERVICES especial.
service_namespace string Namespace do serviço.

Exemplo:

Se houver dois serviços, o campo Serviço será semelhante a:

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

Se houver mais de dois serviços, o campo Serviço será semelhante a:

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

Filtragem de registros

Ao ativar os registros de fluxo de VPC, é possível definir um filtro com base nos campos de base e de metadados que preservam apenas os registros que correspondem ao filtro. Todos os outros registros serão descartados antes de serem gravados no Logging. Isso economiza dinheiro e reduz o tempo necessário para encontrar as informações que você está procurando.

É possível filtrar por qualquer subconjunto de campos do Formato de registro.

A filtragem de registros de fluxo de VPC usa CEL, uma linguagem de expressão incorporada para expressões lógicas baseadas em atributos. Para mais informações, consulte Operadores lógicos de CEL compatíveis.

Para mais informações sobre CEL, consulte a introdução sobre a CEL e a definição da linguagem (ambos em inglês). O recurso de filtro de geração é compatível com um subconjunto limitado de sintaxe CEL.

Exemplo 1: limitar a coleta de registros a uma VM específica chamada my-vm. Nesse caso, serão gravados apenas os registros em que o campo src_instance for informado como my-vm pela origem do tráfego ou em que o campo dst_instance for informado como my-vm pelo destino do tráfego.

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')"

Exemplo 2: limitar a coleta de registros a pacotes com endereços IP de origem na sub-rede 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 compatíveis com CEL

Expressão Tipos compatíveis Descrição
true, false Booleanos Constantes booleanas
x == y x != y Boolean, Int, String Operadores de comparação Exemplo: connection.protocol == 6
x && y x || y Booleanos Operadores de lógica booleana Exemplo: connection.protocol == 6 && src_instance.vm_name == "vm_1"
!x Booleanos Negação
1, 2.0, 0, ... Int Literais numéricos constantes
x + y String Concatenação de strings
"foo", 'foo', ... String Literal de string constante
x.lower() String Retorna o valor em minúscula da string
x.upper() String Retorna o valor em maiúsculas da string
x.contains(y) String Retorna verdadeiro se a string contiver a substring especificada
x.startsWith(y) String Retorna verdadeiro se a string começar com a substring especificada
x.endsWith(y) String Retorna verdadeiro se a string terminar com a substring especificada
inIpRange(X, Y) String Retorna verdadeiro se X for um IP e Y for um intervalo de IP que contenha X.
Exemplo: inIpRange("1.2.3.1", "1.2.3.0/24")
x.containsFieldValue(y) x: list
y: map(string, string)
Retorna verdadeiro se a lista contiver um objeto com campos que correspondem aos pares de chave-valor especificados.
Exemplo: dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'})

Exemplos de padrão de tráfego

Esta seção demonstra como os registros de fluxo de VPC funcionam nos seguintes casos de uso:

Fluxos de VM para VM na mesma VPC

VM flui dentro de uma VPC (clique para ampliar)
VM flui dentro de uma VPC (clique para ampliar)

Para os fluxos de VM para VM na mesma VPC, os registros de fluxo são informados tanto pela VM solicitante quanto pela que VM que responde, desde que ambas estejam em sub-redes com os registros de fluxo de VPC ativados. Neste exemplo, a VM 10.10.0.2 envia uma solicitação com 1.224 bytes para a VM 10.50.0.2, que também está em uma sub-rede com o registro ativado. Por sua vez, 10.50.0.2 responde ao pedido com uma réplica com 5342 bytes. Tanto a solicitação quanto a resposta são registradas nas duas VMs, a que solicitou e a que respondeu.

Conforme informado pela VM solicitante (10.10.0.2)
solicitação/resposta connection.src_ip connection.dest_ip bytes_sent Anotações de VPC
solicitação 10.10.0.2 10.50.0.2 1.224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
resposta 10.50.0.2 10.10.0.2 5.342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
Conforme informado pela VM respondente (10.50.0.2)
solicitação/resposta connection.src_ip connection.dest_ip bytes Anotações de VPC
solicitação 10.10.0.2 10.50.0.2 1.224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
resposta 10.50.0.2 10.10.0.2 5.342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*

Fluxos de VM para elementos externos

Fluxos de VM para elemento externo (clique para ampliar)
Fluxos de VM para elemento externo (clique para ampliar)

Para fluxos entre uma VM e uma entidade externa, os registros de fluxo são informados apenas a partir da VM:

  • Para fluxos de saída, os registros são informados pela VM de que o tráfego se origina.
  • Para fluxos de entrada, os registros são informados pela VM para que o tráfego se destina.

Isso se aplica a:

  • Tráfego entre uma rede VPC e uma rede no local por meio do Cloud VPN ou do Cloud Interconnect.
  • Tráfego entre VMs e locais na Internet.

Neste exemplo, a VM 10.10.0.2 e o endpoint no local 10.30.0.2 estão conectados por meio de um gateway de VPN ou do Cloud Interconnect. O tráfego de saída de 1.224 bytes enviados de 10.10.0.2 para 10.30.0.2 é relatado a partir da VM de origem, 10.10.0.2. O tráfego de entrada de 5.342 bytes enviados de 10.30.0.2 para 10.10.0.2 é informado a partir do destino do tráfego, a VM 10.10.0.2.

solicitação/resposta connection.src_ip connection.dest_ip bytes_sent Anotações de VPC
solicitação 10.10.0.2 10.30.0.2 1.224 src_instance.*
src_vpc.*
dest_location.*
resposta 10.30.0.2 10.10.0.2 5.342 dest_instance.*
dest_vpc.*
src_location.*

Fluxos de VM para VM na VPC compartilhada

Fluxos de VPC compartilhada (clique para ampliar)
Fluxos de VPC compartilhada (clique para ampliar)

Para os fluxos de VM para VM em uma VPC compartilhada, é possível ativar os registros de fluxo de VPC para a sub-rede no projeto host. Por exemplo, a sub-rede 10.10.0.0/20 pertence a uma rede VPC compartilhada definida em um projeto host. É possível visualizar os registros de fluxo das VMs pertencentes a essa sub-rede, incluindo aqueles criados por projetos de serviço. Neste exemplo, os projetos de serviço são chamados de "webserver", "recommendation" e "database".

Para fluxos de VM para VM, se as duas VMs estiverem no mesmo projeto ou, no caso de uma rede compartilhada, no mesmo projeto host, as anotações para ID do projeto e similares serão fornecidas para o outro endpoint na conexão. Se a outra VM estiver em um projeto diferente, as anotações para a outra VM não serão fornecidas.

A tabela a seguir mostra um fluxo informado por 10.10.0.10 ou 10.10.0.20.

  • src_vpc.project_id e dest_vpc.project_id são para o projeto host porque a sub-rede VPC pertence ao projeto host.
  • src_instance.project_id e dest_instance.project_id são para os projetos de serviço porque as instâncias pertencem aos projetos de serviço.
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

Os projetos de serviço não são proprietários da rede VPC compartilhada e não têm acesso aos registros de fluxo da rede VPC compartilhada.

Fluxos de VM para VM em peering de rede VPC

Fluxos de peering de rede VPC (clique para ampliar)
Fluxos de peering de rede VPC (clique para ampliar)

A menos que ambas as VMs estejam no mesmo projeto do Google Cloud, os fluxos de VM para VM em redes VPC com peering são informados da mesma maneira que para os endpoints externos. As informações do projeto e de outras anotações da outra VM não são fornecidas. Se ambas as VMs estiverem no mesmo projeto, mesmo que em redes diferentes, as informações do projeto e de outras anotações também serão fornecidas para a outra VM.

Neste exemplo, as sub-redes da VM 10.10.0.2 (no projeto analytics-prod) e da VM 10.50.0.2 (no projeto webserver-test) estão conectadas por meio do peering de rede VPC. Se os registros de fluxo do VPC estiverem ativados no projeto analytics-prod, o tráfego (1.224 bytes) enviado de 10.10.0.2 para 10.50.0.2 será informado da VM 10.10.0.2, que é a origem do fluxo. O tráfego (5.342 bytes) enviado de 10.50.0.2 para 10.10.0.2 também é informado a partir da VM 10.10.0.2, que é o destino do fluxo.

Neste exemplo, os registros de fluxo de VPC não estão ativados no projeto webserver-test, portanto nenhum registro é gravado pela VM 10.50.0.2.

reporter connection.src_ip connection.dest_ip bytes_sent Anotações de VPC
fonte 10.10.0.2 10.50.0.2 1.224 src_instance.*
src_vpc.*
destino 10.50.0.2 10.10.0.2 5.342 dest_instance.*
dest_vpc.*

Fluxos de VM para VM para balanceamento de carga TCP/UDP interno

Fluxos de balanceamento de carga TCP/UDP interno (clique para ampliar)
Fluxos de balanceamento de carga TCP/UDP interno (clique para ampliar)

Ao adicionar uma VM ao serviço de back-end de um balanceador de carga TCP/UDP interno, o ambiente convidado do Linux ou do Windows adiciona o endereço IP do balanceador de carga à tabela de roteamento local da VM. Isso permite que a VM aceite pacotes de solicitação com destinos definidos para o endereço IP do balanceador de carga. Quando a VM responde, a resposta é enviada diretamente. No entanto, o endereço IP de origem dos pacotes de resposta será definido pelo endereço IP do balanceador de carga, não pela VM com balanceamento de carga.

Os fluxos de VM para VM enviados por meio de um balanceador de carga TCP/UDP interno são informados tanto da origem quanto do destino. Para um exemplo de par solicitação/resposta HTTP, a tabela a seguir explica os campos das entradas de registro de fluxo observadas. Para este exemplo, considere a seguinte configuração de rede:

  • Instância do navegador em 192.168.1.2
  • Balanceador de carga TCP/UDP interno em 10.240.0.200
  • Instância do servidor da Web em 10.240.0.3
Direção do tráfego reporter connection.src_ip connection.dest_ip connection.src_instance connection.dest_instance
Solicitação SRC 192.168.1.2 10.240.0.200 Instância do navegador
Solicitação DEST 192.168.1.2 10.240.0.200 Instância do navegador Instância do servidor da Web
Resposta SRC 10.240.0.3 192.168.1.2 Instância do servidor da Web Instância do navegador
Resposta DEST 10.240.0.200 192.168.1.2 Instância do navegador

A VM solicitante não sabe qual VM responderá à solicitação. Além disso, uma vez que a outra VM envia uma resposta tendo como endereço de origem o IP do balanceador de carga interno, ela não sabe qual VM respondeu. Por esses motivos, a VM solicitante não pode adicionar informações dest_instance ao seu relatório, mas apenas informações src_instance. Como a VM de resposta conhece o endereço IP da outra VM, ela fornece as duas informações, src_instance e dest_instance.

Pod para o fluxo do ClusterIP

Fluxo do pod para o IP do cluster (clique para ampliar)
Fluxo do pod para o IP do cluster (clique para ampliar)

Neste exemplo, o tráfego é enviado do pod cliente (10.4.0.2) para cluster-service (10.0.32.2:80). O destino é resolvido para o endereço IP do pod do servidor selecionado (10.4.0.3) na porta de destino (8080).

Nas bordas do nó, o fluxo é amostrado duas vezes com o endereço IP e a porta traduzidos. Para ambos os pontos de amostragem, identificaremos que o pod de destino está fazendo o serviço cluster-service na porta 8080 e anotaremos o registro com os detalhes do serviço e os detalhes do pod. Caso o tráfego seja roteado para um pod no mesmo nó, ele não sairá do nó e não será amostrado.

Neste exemplo, são encontrados os seguintes registros.

reporter connection.src_ip connection.dst_ip bytes_sent Anotações de VPC
SRC 10.4.0.2 10.4.0.3 1.224 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 1.224 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.*

Fluxos externos do LoadBalancer do GKE

Fluxos do balanceador de carga externo (clique para ampliar)
Fluxos do balanceador de carga externo (clique para ampliar)

O tráfego de um endereço IP externo para um serviço do GKE (35.35.35.35) será roteado para um nó no cluster, 10.0.12.2 neste exemplo, para roteamento. Por padrão, os balanceadores de carga de rede distribuem o tráfego entre todos os nós no cluster, mesmo aqueles que não executam um pod relevante. O tráfego pode fazer saltos extras para chegar ao pod relevante. Para mais informações, consulte Rede fora do cluster.

O tráfego será roteado do nó (10.0.12.2) para o pod do servidor selecionado (10.4.0.2). Os dois saltos serão registrados porque todas as bordas do nó são amostradas. Caso o tráfego seja roteado para um pod no mesmo nó, 10.4.0.3 neste exemplo, o segundo salto não será registrado, já que não sai do nó. O segundo salto será registrado pelos pontos de amostragem dos dois nós. O segundo salto será registrado pelos pontos de amostragem dos dois nós. No primeiro salto, identificamos o serviço com base no IP do balanceador de carga e na porta de serviço (80). Para o segundo salto, identificamos que o pod de destino está fazendo o serviço na porta de destino (8080).

Neste exemplo, são encontrados os seguintes registros.

reporter connection.src_ip connection.dst_ip bytes_sent Anotações de VPC
DEST 203.0.113.1 35.35.35.35 1.224 src_location.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1.224 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 1.224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Fluxos de entrada do GKE

Fluxos de entrada (clique para ampliar)
Fluxos de entrada (clique para ampliar)

Uma conexão de um endereço IP público com um destino de entrada será encerrada no serviço do balanceador de carga. A conexão será mapeada para um serviço NodePort de acordo com o URL. Para atender à solicitação, o balanceador de carga (130.211.0.1) se conecta a um dos nós do cluster (10.0.12.2) para roteamento usando o NodePort do serviço. Por padrão, ao criar uma entrada, o controlador de entrada do GKE configura um balanceador de carga HTTP(S) que distribui o tráfego por todos os nós do cluster, mesmo aqueles que não estiverem executando um pod relevante. O tráfego pode fazer saltos extras para chegar ao pod relevante. Para mais informações, consulte Visão geral da rede. O tráfego será então roteado do nó (10.0.12.2) para o pod de servidor selecionado (10.4.0.2).

Os dois saltos serão registrados porque todas as bordas do nó serão amostradas. No primeiro salto, identificamos o serviço com base no NodePort do serviço (60000). Para o segundo salto, identificamos que o pod de destino está fazendo o serviço na porta de destino (8080). O segundo salto será registrado pelos pontos de amostragem dos dois nós. No entanto, em um caso em que o tráfego seja roteado para um pod no mesmo nó (10.4.0.3), o segundo salto não será registrado porque o tráfego não terá saído do nó.

Neste exemplo, são encontrados os seguintes registros.

reporter connection.src_ip connection.dst_ip bytes_sent Anotações de VPC
DEST 130.211.0.1 10.0.12.2 1.224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1.224 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 1.224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Fluxos de entrada do GKE que usam o balanceamento de carga nativo de contêiner

Fluxos de entrada que usam balanceamento de carga nativo de contêiner (clique para ampliar)
Fluxos de entrada que usam balanceamento de carga nativo de contêiner (clique para ampliar)

As solicitações de um endereço IP público para uma entrada que usa balanceamento de carga nativo de contêiner são encerradas no balanceador de carga. Nesse tipo de entrada, os pods são objetos principais para balanceamento de carga. Uma solicitação será enviada do balanceador de carga (130.211.0.1) diretamente para um pod selecionado (10.4.0.2). Identificamos que o pod de destino está fazendo o backup do serviço na porta de destino (8080).

Neste exemplo, será encontrado o seguinte registro.

reporter connection.src_ip connection.dst_ip bytes_sent Anotações de VPC
DEST 130.211.0.1 10.4.0.2 1.224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Pod para fluxos externos

Fluxo de pod para externo (clique para ampliar)
Fluxo de pod para externo (clique para ampliar)

O tráfego de um pod (10.4.0.3) para um IP externo (203.0.113.1) é modificado pelo mascaramento de IP de modo que os pacotes são enviados do IP do nó (10.0.12.2) em vez de do IP do pod. Por padrão, o cluster do GKE é configurado para mascarar o tráfego para destinos externos. Para mais informações, consulte Agente de mascaramento de IP.

Para visualizar as anotações de pod para esse tráfego, configure o agente de mascaramento para que não mascare IPs de pod. Nesse caso, para permitir o tráfego para a Internet, configure o Cloud NAT, que processa os endereços IP do pod. Para mais informações sobre o Cloud NAT com o GKE, consulte a Interação do GKE.

Neste exemplo, será encontrado o seguinte registro.

reporter connection.src_ip connection.dst_ip bytes_sent Anotações de VPC
SRC 10.0.12.2 203.0.113.1 1.224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_location.*

Preços

São aplicados preços padrão para o Logging, BigQuery ou Pub/Sub. Os preços de registros de fluxo de VPC estão descritos em Preços de telemetria de rede.

Perguntas frequentes

  • Os registros de fluxo de VPC incluem o tráfego permitido e negado com base nas regras de firewall?

    • Os registros de fluxo de VPC abordam o tráfego a partir da perspectiva de uma VM. Todo o tráfego de saída (saída) de uma VM é registrado, mesmo se ela for bloqueada por uma regra de firewall de negação de saída. O tráfego de entrada (recebido) é registrado se for permitido por uma regra de firewall de permissão de entrada. O tráfego de entrada bloqueado por uma regra de firewall de negação de entrada não será registrado.
  • Os registros de fluxo de VPC funcionam com instâncias de VM com várias interfaces?

  • Os registros de fluxo da VPC funcionam com redes legadas?

    • Não, os registros de fluxo de VPC não são compatíveis com redes legadas.

A seguir