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 (usando o Pub/Sub) e integrá-las aos sistemas de gerenciamento de eventos e informações 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 30 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:
- 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. Para mais informações, consulte Filtragem de registros.
- 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.
- 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.
- 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. Para mais informações, consulte Anotações de metadados.
- 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, comosrc_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 informações sobre como personalizar campos de metadados, consulte as instruções da CLI gcloud ou da API 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 |
---|---|---|
conexão |
IpConnection
Cinco tuplas que descrevem a conexão |
Camadas |
reportado por |
string
O lado que informou o fluxo. Pode ser SRC ou DEST .
|
Camadas |
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. |
Camadas |
bytes_sent |
int64
Quantidade de bytes enviados da origem para o destino |
Camadas |
packets_sent | int64
Número de pacotes enviados da origem para o destino |
Camadas |
start_time |
string
Carimbo de data/hora (formato de string de data RFC 3339) do primeiro pacote observado durante o intervalo de tempo agregado. |
Camadas |
end_time |
string
Carimbo de data/hora (formato de string de data RFC 3339) do último pacote observado durante o intervalo de tempo agregado |
Camadas |
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 |
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_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, esse campo será preenchido com metadados de local disponíveis. |
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 |
Formato do campo IpConnection
Campo | Tipo | Descrição |
---|---|---|
protocolo | int32 | Número do protocolo IANA |
src_ip | string | Endereço IP de origem |
dest_ip | string | Endereço IP de destino |
src_port | int32 | Porta de origem |
dest_port | int32 | Porta de destino |
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_location | string | Local do cluster. É uma zona ou uma região, dependendo se o cluster for zonal ou regional. |
cluster_name | string | Nome do cluster do GKE |
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" } ]
Formato do campo InstanceDetails
Campo | Tipo | Descrição |
---|---|---|
project_id | string | Código do projeto que contém a VM |
region | string | Região da VM |
vm_name | string | Nome da instância da VM |
zona | string | Zona da VM |
Formato do campo GeographicDetails
Campo | Tipo | Descrição |
---|---|---|
asn | int32 | O número de sistema autônomo (ASN, na sigla em inglês) da rede externa a que este endpoint pertence. |
cidade | string | Cidade para endpoints externos |
continent | string | Continente para endpoints externos |
country | string | País para endpoints externos, representado por códigos de país ISO 3166-1 Alfa-3. |
region | string | Região para endpoints externos |
Formato do campo VpcDetails
Campo | Tipo | Descrição |
---|---|---|
project_id | string | Código do projeto que contém a VPC |
subnetwork_name | string | Sub-rede em que a VM está operando |
vpc_name | string | VPC em que a VM está operando |
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. As expressões de filtro dos registros de fluxo de VPC têm um limite de 2.048 caracteres. Para mais informações, consulte Operadores lógicos de CEL compatíveis.
Para mais informações sobre a CEL, consulte a introdução da CEL e a definição da linguagem. O recurso de filtro de geração é compatível com um subconjunto limitado de sintaxe CEL.
Para informações sobre como criar uma sub-rede que usa filtragem de registros, consulte as instruções da CLI gcloud ou da API sobre Como ativar os registros de fluxo de VPC ao criar uma sub-rede.
Para informações sobre como configurar a filtragem de registros, consulte as instruções da CLI gcloud ou da API sobre como atualizar parâmetros dos registros de fluxo de VPC.
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')"
Exemplo 3: limitar a coleta de registros ao tráfego externo a uma VPC.
gcloud compute networks subnets update my-subnet \ --logging-filter-expr '!(has(src_vpc.vpc_name) && has(dest_vpc.vpc_name))'
Operadores lógicos compatíveis com CEL
Expressão | Tipos compatíveis | Descrição |
---|---|---|
verdadeiro, falso | Booleano | Constantes booleanas |
x == y x != y |
Booleano, Int, String | Operadores de comparação Exemplo: connection.protocol == 6 |
x && y x || y |
Booleano | Operadores lógicos booleanos Exemplo: connection.protocol == 6 && src_instance.vm_name == "vm_1" |
!x | Booleano | Negação |
1, 2.0, 0, ... | Int | Literais numéricos constantes |
x + y | String | Concatenação de string |
"foo", 'foo', ... | String | Literal de string constante |
x.lower() | String | Retorna o valor em minúsculas 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'}) |
has(x) | String | Retorna verdadeiro se o campo estiver presente. |
Exemplos de padrão de tráfego
Esta seção demonstra como os registros de fluxo de VPC funcionam em vários casos de uso.
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.* |
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 "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
edest_vpc.project_id
são para o projeto host porque a sub-rede VPC pertence ao projeto host.src_instance.project_id
edest_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 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
.
reporter | 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. 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 |
---|---|---|---|---|
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.* |
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?
- Sim, é possível ativar os registros de fluxo de VPC para todas as interfaces em uma 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.