Sobre os fluxos de tráfego
Nesta página, descrevemos como os registros de fluxo de VPC informam os registros de fluxo para casos de uso comum. Consulte as seções a seguir para ver exemplos de fluxos de tráfego de amostra pelos registros de fluxo de VPC.
Fluxos de VM para VM na mesma rede VPC
Para os fluxos de VM para VM na mesma rede 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 5.342 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 |
| request | 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 |
| request | 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 endereço IP externo
Para fluxos que atravessam a Internet entre uma VM que está em uma rede VPC e um endpoint com um endereço IP externo, os registros de fluxo são informados da VM que está apenas na rede VPC:
- Para fluxos de saída, os registros são informados pela VM da rede VPC que é a origem do tráfego.
- Para fluxos de entrada, os registros são informados pela VM da rede VPC que é o destino do tráfego.
Neste exemplo, a VM 10.10.0.2 troca pacotes pela Internet com um endpoint que tem o endereço IP externo 203.0.113.5. O tráfego de saída de 1.224 bytes enviados de 10.10.0.2 para 203.0.113.5 é relatado a partir da VM de origem, 10.10.0.2. O tráfego de entrada de 5.342 bytes enviados de 203.0.113.5 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 |
|---|---|---|---|---|
| request | 10.10.0.2 | 203.0.113.5 | 1.224 |
src_instance.* src_vpc.* dest_location.* internet_routing_details.* |
| resposta | 203.0.113.5 | 10.10.0.2 | 5.342 |
dest_instance.* dest_vpc.* src_location.* |
Fluxos de VM para local
Para fluxos entre uma VM que está em uma rede VPC e um endpoint local com um endereço IP interno, os registros de fluxo são informados a partir da VM que está apenas na rede VPC:
- Para fluxos de saída, os registros são informados pela VM da rede VPC que é a origem do tráfego.
- Para fluxos de entrada, os registros são informados pela VM da rede VPC que é o destino do tráfego.
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 |
|---|---|---|---|---|
| request | 10.10.0.2 | 10.30.0.2 | 1.224 |
src_instance.* src_vpc.* |
| resposta | 10.30.0.2 | 10.10.0.2 | 5.342 |
dest_instance.* dest_vpc.* |
Fluxos de VM para VM na VPC compartilhada
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 "web server", "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_idedest_vpc.project_idsão para o projeto host porque a sub-rede VPC pertence ao projeto host.src_instance.project_idedest_instance.project_idsã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 | web server | 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 aos registros de fluxo da rede VPC compartilhada.
Fluxos VM para VM para peering de VPC
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.
| reportado por | connection.src_ip | connection.dest_ip | bytes_sent | Anotações |
|---|---|---|---|---|
| source | 10.10.0.2 | 10.50.0.2 | 1.224 |
src_instance.* src_vpc.* |
| destination | 10.50.0.2 | 10.10.0.2 | 5.342 |
dest_instance.* dest_vpc.* |
Fluxos de VM para VM em balanceadores de carga de rede de passagem interna
Ao adicionar uma VM ao serviço de back-end de um balanceador de carga de rede de passagem 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 de rede de passagem interna são informados a partir da origem e 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 de rede de passagem interna 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
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 |
|---|---|---|---|---|
| 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
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 de passagem externa 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. 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á apoiando 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 |
|---|---|---|---|---|
| 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
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
Rede fora do cluster.
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 |
|---|---|---|---|---|
| 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
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 |
|---|---|---|---|---|
| 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
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 |
|---|---|---|---|---|
| SRC | 10.0.12.2 | 203.0.113.1 | 1.224 |
src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.* internet_routing_details.* |