Informationen zu Trafficflüssen
Auf dieser Seite wird beschrieben, wie VPC-Flusslogs für allgemeine Anwendungsfälle Flusslogs meldet. In den folgenden Abschnitten finden Sie Beispiele für Traffic-Datenflüsse, die von VPC-Flusslogs als Stichprobe verwendet werden.
VM-zu-VM-Datenflüsse im derselben VPC-Netzwerk
Bei VM-zu-VM-Datenflüssen im selben VPC-Netzwerk werden Fluss-Logs sowohl von der anfragenden als auch von der antwortenden VM gemeldet, wenn sich beide VMs in Subnetzen befinden, für die VPC-Fluss-Logs aktiviert sind. In diesem Beispiel sendet die VM 10.10.0.2 eine Anfrage mit 1.224 Byte an die VM 10.50.0.2, die sich ebenfalls in einem Subnetz befindet, für das Logging aktiviert ist. 10.50.0.2 antwortet auf die Anfrage mit einer Antwort, die 5.342 Byte enthält. Sowohl die Anfrage als auch die Antwort werden von den anfragenden und den antwortenden VMs aufgezeichnet.
| Wie von anfragender VM gemeldet (10.10.0.2) | ||||
|---|---|---|---|---|
| Anfrage/Antwort | connection.src_ip | connection.dest_ip | bytes_sent | Annotationen |
| Request | 10.10.0.2 | 10.50.0.2 | 1.224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| antworten | 10.50.0.2 | 10.10.0.2 | 5.342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| Wie von antwortender VM gemeldet (10.50.0.2) | ||||
|---|---|---|---|---|
| Anfrage/Antwort | connection.src_ip | connection.dest_ip | Byte | Annotationen |
| Request | 10.10.0.2 | 10.50.0.2 | 1.224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| antworten | 10.50.0.2 | 10.10.0.2 | 5.342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
VM-zu-Extern-IP-Adressflüsse
Für Datenflüsse, die das Internet zwischen einer VM in einem VPC-Netzwerk und einem Endpunkt mit einer externen IP-Adresse durchlaufen, werden nur Flusslogs von der VM gemeldet, die sich im VPC-Netzwerk befindet:
- Bei ausgehenden Datenflüssen werden die Logs von der VPC-Netzwerk-VM gemeldet, die die Quelle des Traffics ist.
- Bei eingehenden Datenflüssen werden die Logs von der VPC-Netzwerk-VM gemeldet, die das Ziel des Traffics ist.
In diesem Beispiel tauscht die VM 10.10.0.2 Pakete über das Internet mit einem Endpunkt aus, der die externe IP-Adresse 203.0.113.5 hat. Der ausgehende Traffic von 1.224 Byte, der von 10.10.0.2 an 203.0.113.5 gesendet wurde, wird von der Quell-VM 10.10.0.2 gemeldet. Der eingehende Traffic von 5.342 Byte, der von 203.0.113.5 an 10.10.0.2 gesendet wurde, wird vom Ziel des Traffics, der VM 10.10.0.2, gemeldet.
| Anfrage/Antwort | connection.src_ip | connection.dest_ip | bytes_sent | Annotationen |
|---|---|---|---|---|
| Request | 10.10.0.2 | 203.0.113.5 | 1.224 |
src_instance.* src_vpc.* dest_location.* internet_routing_details.* |
| antworten | 203.0.113.5 | 10.10.0.2 | 5.342 |
dest_instance.* dest_vpc.* src_location.* |
VM-zu-Lokal-Datenflüsse
Für Datenflüsse zwischen einer VM in einem VPC-Netzwerk und einem lokalen Endpunkt mit einer internen IP-Adresse werden Flusslogs nur von der VM gemeldet, die sich im VPC-Netzwerk befindet:
- Bei ausgehenden Datenflüssen werden die Logs von der VPC-Netzwerk-VM gemeldet, die die Quelle des Traffics ist.
- Bei eingehenden Datenflüssen werden die Logs von der VPC-Netzwerk-VM gemeldet, die das Ziel des Traffics ist.
In diesem Beispiel sind die VM 10.10.0.2 und der lokale Endpunkt 10.30.0.2 über ein VPN-Gateway oder Cloud Interconnect verbunden. Der ausgehende Traffic von 1.224 Byte, der von 10.10.0.2 an 10.30.0.2 gesendet wurde, wird von der Quell-VM 10.10.0.2 gemeldet. Der eingehende Traffic von 5.342 Byte, der von 10.30.0.2 an 10.10.0.2 gesendet wurde, wird vom Ziel des Traffics, der VM 10.10.0.2, gemeldet.
| Anfrage/Antwort | connection.src_ip | connection.dest_ip | bytes_sent | Annotationen |
|---|---|---|---|---|
| Request | 10.10.0.2 | 10.30.0.2 | 1.224 |
src_instance.* src_vpc.* |
| antworten | 10.30.0.2 | 10.10.0.2 | 5.342 |
dest_instance.* dest_vpc.* |
VM-zu-VM-Datenflüsse für freigegebene VPC
Bei VM-zu-VM-Datenflüssen für freigegebene VPC können Sie VPC-Flusslogs für das Subnet im Hostprojekt aktivieren. Beispiel: Das Subnetz 10.10.0.0/20 gehört zu einem freigegebenen VPC-Netzwerk, das in einem Hostprojekt definiert ist. Sie können Flusslogs von VMs sehen, die zu diesem Subnetz gehören, einschließlich solcher, die von Dienstprojekten erstellt wurden. In diesem Beispiel heißen die Dienstprojekte "Webserver", "Empfehlung", "Datenbank".
Bei VM-zu-VM-Datenflüssen werden, wenn sich beide VMs im selben Projekt oder – im Fall eines freigegebenen Netzwerks – im selben Hostprojekt befinden, Anmerkungen für die Projekt-ID und dergleichen für den anderen Endpunkt in der Verbindung bereitgestellt. Wenn sich die andere VM in einem anderen Projekt befindet, werden keine Annotationen für die andere VM bereitgestellt.
Die folgende Tabelle zeigt einen Datenfluss, der entweder in 10.10.0.10 oder 10.10.0.20 gemeldet wird.
src_vpc.project_idunddest_vpc.project_idstehen für das Hostprojekt, da das VPC-Subnetz zum Hostprojekt gehört.src_instance.project_idunddest_instance.project_idsind für die Dienstprojekte bestimmt, da die Instanzen zu den Dienstprojekten gehören.
| 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 | Empfehlung | host_project |
Dienstprojekte sind nicht Inhaber des freigegebenen VPC-Netzwerks und haben keinen Zugriff auf die Flusslogs des freigegebenen VPC-Netzwerks.
VM-zu-VM-Datenflüsse für VPC-Netzwerk-Peering
Wenn sich die beiden VMs nicht im selben Google Cloud-Projekt befinden, werden VM-zu-VM-Datenflüsse für Peering-VPC-Netzwerke auf die gleiche Weise wie für externe Endpunkte gemeldet. Projekt- und andere Annotationsinformationen für die andere VM werden nicht bereitgestellt. Wenn sich beide VMs in demselben Projekt befinden, auch wenn sie sich in verschiedenen Netzwerken befinden, werden Projekt- und andere Annotationsinformationen auch für die andere VM angegeben.
In diesem Beispiel sind die Subnetze der VM 10.10.0.2 im Projekt "analytics-prod" und der VM 10.50.0.2 im Projekt "webserver-test" über VPC-Netzwerk-Peering verbunden.
Wenn im Projekt "analytics-prod" VPC-Flusslogs aktiviert sind, wird der von 10.10.0.2 an 10.50.0.2 gesendete Traffic (1.224 Byte) von der VM 10.10.0.2 gemeldet, die die Quelle des Datenflusses ist. Der von 10.50.0.2 an 10.10.0.2 gesendete Traffic (5.342 Byte) wird auch von der VM 10.10.0.2 gemeldet, die das Ziel des Datenflusses ist.
In diesem Beispiel sind VPC-Flusslogs im Projekt "webserver-test" nicht aktiviert, also werden von der VM 10.50.0.2 keine Logs aufgezeichnet.
| reporter | connection.src_ip | connection.dest_ip | bytes_sent | Annotationen |
|---|---|---|---|---|
| source | 10.10.0.2 | 10.50.0.2 | 1.224 |
src_instance.* src_vpc.* |
| Ziel | 10.50.0.2 | 10.10.0.2 | 5.342 |
dest_instance.* dest_vpc.* |
VM-zu-VM-Datenflüsse für interne Passthrough Network Load Balancer
Wenn Sie dem Backend-Dienst für einen internen Passthrough Network Load Balancer eine VM hinzufügen, fügt die Linux- oder Windows-Gastumgebung die IP-Adresse des Load-Balancings zur lokalen Routingtabelle der VM hinzu. Dadurch kann die VM Anfragepakete mit Zielen akzeptieren, die auf die IP-Adresse des Load-Balancers festgelegt sind. Wenn die VM antwortet, sendet sie ihre Antwort direkt. Als Quell-IP-Adresse für die Antwortpakete wird jedoch die IP-Adresse des Load Balancers festgelegt und nicht die VM, deren Last ausgeglichen wird.
Über einen internen Passthrough Network Load Balancer gesendete VM-zu-VM-Datenflüsse werden sowohl von der Quelle als auch vom Ziel gemeldet. Als Beispiel für ein HTTP-Anfrage/Antwort-Paar werden in der folgenden Tabelle die Felder der beobachteten Einträge im Flusslog beschrieben. Sehen Sie sich dazu auch die folgende Netzwerkkonfiguration an:
- Browserinstanz bei 192.168.1.2
- Interner Passthrough Network Load Balancer unter 10.240.0.200
- Webserverinstanz bei 10.240.0.3
| Traffic-Richtung | reporter | connection.src_ip | connection.dest_ip | connection.src_instanz | connection.dest_instance |
|---|---|---|---|---|---|
| Anfrage | SRC | 192.168.1.2 | 10.240.0.200 | Browserinstanz | |
| Anfrage | DEST | 192.168.1.2 | 10.240.0.200 | Browserinstanz | Webserverinstanz |
| Antwort | SRC | 10.240.0.3 | 192.168.1.2 | Webserverinstanz | Browserinstanz |
| Antwort | DEST | 10.240.0.200 | 192.168.1.2 | Browserinstanz |
Die anfragende VM weiß nicht, welche VM auf die Anfrage antworten wird. Da die andere VM eine Antwort mit der IP des internen Load-Balancers als Quelladresse sendet, weiß die anfragende VM nicht, welche VM reagiert hat.
Deshalb kann die anfragende VM dest_instance-Daten nicht in ihren Bericht aufnehmen, sondern nur src_instance-Daten. Da die antwortende VM die IP-Adresse der anderen VM kennt, kann sie die Daten von src_instance und dest_instance bereitstellen.
Pod-zu-ClusterIP-Datenfluss
In diesem Beispiel wird der Traffic vom Client-Pod (10.4.0.2) an cluster-service (10.0.32.2:80) gesendet. Das Ziel wird in die ausgewählte Server-Pod-IP-Adresse (10.4.0.3) des Zielports (8080) aufgelöst.
An Knotenrändern wird der Fluss zweimal mit der übersetzten IP-Adresse und dem Port erfasst. Für beide Stichprobenpunkte bestimmen wir, dass der Ziel-Pod den Dienst cluster-service auf Port 8080 sichert, und annotieren den Eintrag mit den Dienst- und Pod-Details. Wenn der Traffic an einen Pod auf demselben Knoten weitergeleitet wird, verlässt der Traffic den Knoten nicht und wird nicht erfasst.
In diesem Beispiel werden die folgenden Einträge gefunden.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | Annotationen |
|---|---|---|---|---|
| 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.* |
Externe GKE-LoadBalancer-Datenflüsse
Traffic von einer externen IP-Adresse an einen GKE-Dienst (35.35.35.35) wird zur Weiterleitung an einen Knoten im Cluster weitergeleitet, in diesem Beispiel 10.0.12.2. Standardmäßig verteilen Passthrough Network Load Balancer den Traffic auf alle Knoten im Cluster, auch auf diejenigen, die keinen relevanten Pod ausführen. Der Traffic benötigt möglicherweise zusätzliche Hops, um zum entsprechenden Pod zu gelangen. Weitere Informationen finden Sie unter Netzwerke außerhalb des Clusters.
Der Traffic wird dann vom Knoten (10.0.12.2) an den ausgewählten Server-Pod (10.4.0.2) weitergeleitet. Beide Hops werden protokolliert, da alle Knotenkanten erfasst werden. Wenn der Traffic an einen Pod auf demselben Knoten wie 10.4.0.3 weitergeleitet wird, wird der zweite Hop nicht protokolliert, da er den Knoten nicht verlässt.
Der zweite Hop wird von den Stichprobenpunkten beider Knoten protokolliert. Für den ersten Hop haben wir den Dienst anhand der IP-Adresse und des Dienstports des Load-Balancers (80) ermittelt. Beim zweiten Hop haben wir festgestellt, dass der Ziel-Pod den Dienst am Zielport (8080) gesichert.
In diesem Beispiel werden die folgenden Einträge gefunden.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | Annotationen |
|---|---|---|---|---|
| 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.* |
Eingehende GKE-Datenflüsse
Eine Verbindung von einer öffentlichen IP-Adresse zu einem Ziel für eingehenden Traffic wird beim Load-Balancer-Dienst beendet. Die Verbindung wird einem NodePort-Dienst gemäß der URL zugeordnet. Zur Verarbeitung der Anfrage stellt der Load-Balancer (130.211.0.1) eine Verbindung zu einem der Clusterknoten (10.0.12.2) her, um das Routing über den NodePort des Dienstes durchzuführen. Standardmäßig erstellt der GKE-Ingress-Controller beim Erstellen eines Ingress-Objekts einen HTTP(S)-Load-Balancer, der den Traffic auf alle Knoten im Cluster verteilt, auch auf diejenigen, die keinen relevanten Pod ausführen. Der Traffic benötigt möglicherweise zusätzliche Hops, um zum entsprechenden Pod zu gelangen. Weitere Informationen finden Sie unter Netzwerke außerhalb des Clusters.
Der Traffic wird dann vom Knoten (10.0.12.2) an den ausgewählten Server-Pod (10.4.0.2) weitergeleitet.
Beide Hops werden protokolliert, da alle Knotenkanten erfasst werden. Für den ersten Hop haben wir den Dienst mit dem NodePort des Dienstes (60000) bestimmt. Für den zweiten Hop bestimmen wir, dass der Ziel-Pod den Dienst am Zielport (8080) sichert. Der zweite Hop wird durch die Stichprobenpunkte beider Knoten protokolliert.
In einem Fall, in dem der Traffic jedoch an einen Pod auf demselben Knoten weitergeleitet wird (10.4.0.3), wird der zweite Hop nicht protokolliert, da der Traffic den Knoten nicht verlassen hat.
In diesem Beispiel werden die folgenden Einträge gefunden.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | Annotationen |
|---|---|---|---|---|
| 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.* |
Eingehende GKE-Datenflüsse mit containernativem Load-Balancing
Anfragen von einer öffentlichen IP-Adresse an ein Ingress, das containernatives Load-Balancing verwendet, werden am Load-Balancer beendet. Bei diesem Ingress-Typ sind Pods Kernobjekte für das Load-Balancing.
Eine Anfrage wird dann direkt vom Load-Balancer (130.211.0.1) an einen ausgewählten Pod (10.4.0.2) gesendet. Wir stellen fest, dass der Ziel-Pod den Dienst am Zielport (8080) sichert.
In diesem Beispiel wird der folgende Eintrag gefunden.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | Annotationen |
|---|---|---|---|---|
| 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 zu externen Datenflüssen
Der Traffic von einem Pod (10.4.0.3) zu einer externen IP-Adresse (203.0.113.1) wird durch IP-Masquerade geändert, sodass die Pakete von der Knoten-IP (10.0.12.2) statt von der Pod-IP gesendet werden. Standardmäßig ist der GKE-Cluster so konfiguriert, dass der Traffic zu externen Zielen maskiert wird. Weitere Informationen finden Sie unter Agent für IP-Masquerade.
Wenn Sie Pod-Annotationen für diesen Traffic ansehen möchten, können Sie den Masquerade-Agent so konfigurieren, dass er Pod-IP-Adressen nicht maskiert. In diesem Fall können Sie Cloud NAT konfigurieren, der die Pod-IP-Adressen verarbeitet, um Traffic zum Internet zuzulassen. Weitere Informationen zu Cloud NAT mit GKE finden Sie unter GKE-Interaktion.
In diesem Beispiel wird der folgende Eintrag gefunden.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | Annotationen |
|---|---|---|---|---|
| SRC | 10.0.12.2 | 203.0.113.1 | 1.224 |
src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.* internet_routing_details.* |