Trafficflüsse

Auf dieser Seite wird beschrieben, wie VPC-Flusslogs Protokolle für gängige Trafficflüsse meldet. In den folgenden Abschnitten finden Sie Beispiele:

VM-Datenflüsse

In den folgenden Abschnitten finden Sie Beispiele dafür, wie Traffic-Datenflüsse von und zu VM-Instanzen in VPC-Flusslogs kommentiert werden.

VM-zu-VM-Datenflüsse im derselben VPC-Netzwerk

VM-Datenflüsse innerhalb eines VPC-Netzwerks.
VM-Datenflüsse innerhalb eines VPC-Netzwerk (zum Vergrößern anklicken)

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.*
src_vpc.*
dest_instance.*
dest_vpc.*
antworten 10.50.0.2 10.10.0.2 5.342 src_instance.*
src_vpc.*
dest_instance.*
dest_vpc.*
Wie von antwortender VM gemeldet (10.50.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.*
src_vpc.*
dest_instance.*
dest_vpc.*
antworten 10.50.0.2 10.10.0.2 5.342 src_instance.*
src_vpc.*
dest_instance.*
dest_vpc.*

VM-zu-externe IP-Adressflüsse

VM-zu-Extern-IP-Adressflüsse
VM-zu-externe IP-Adressflüsse (zum Vergrößern anklicken)

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 src_location.*
dest_instance.*
dest_vpc.*

VM-zu-VM-Datenflüsse für freigegebene VPC

Freigegebene VPC-Datenflüsse.
Freigegebene VPC-Datenflüsse (zum Vergrößern anklicken)

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_id und dest_vpc.project_id stehen für das Hostprojekt, da das VPC-Subnetz zum Hostprojekt gehört.
  • src_instance.project_id und dest_instance.project_id sind 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

VPC-Netzwerk-Peering-Datenflüsse
VPC-Netzwerk-Peering-Datenflüsse (zum Vergrößern anklicken)

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-Traffic über Private Service Connect

In VPC-Flow-Logs werden Abläufe zwischen Private Service Connect-Nutzern und veröffentlichten Diensten kommentiert. Im folgenden Beispiel wird beschrieben, wie VPC-Flusslogs Protokolleinträge für Nutzer- und Ersteller-VMs annotieren.

VM-Traffic wird über Private Service Connect geleitet.
VM-Datenflüsse über Private Service Connect (zum Vergrößern anklicken)

Trafficflüsse zu von Private Service Connect veröffentlichten Diensten werden sowohl von Nutzer- als auch von Produzenten-VMs erfasst, sofern sich beide VMs in Subnetzen befinden, für die VPC-Fluss-Logs aktiviert sind. In diesem Beispiel sendet die Nutzer-VM 10.10.0.2 eine Anfrage mit 1.224 Byte an den Private Service Connect-Endpunkt 10.10.0.3. Im VPC des Erstellers wird die Quell-IP-Adresse der Anfrage in eine IP-Adresse im Subnetz des Dienstanhangs übersetzt, in diesem Beispiel 10.40.0.2. Die Ziel-IP-Adresse der Anfrage wird in die IP-Adresse des internen Passthrough-Network Load Balancers 10.50.0.3 übersetzt. Die Anfrage erreicht dann die Backend-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. Die Logs der Nutzer-VM sind im Nutzerprojekt und die Logs der Ersteller-VM im Erstellerprojekt verfügbar.

Wie von der Nutzer-VM (10.10.0.2) gemeldet
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Request 10.10.0.2 10.10.0.3 1.224 src_instance.*
src_vpc.*
psc.reporter
psc.psc_endpoint.*
psc.psc_attachment.*
antworten 10.10.0.3 10.10.0.2 5.342 dest_instance.*
dest_vpc.*
psc.reporter
psc.psc_endpoint.*
psc.psc_attachment.*
Wie von der VM des Erzeugers gemeldet (10.50.0.2)
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Anfrage 10.40.0.2 10.50.0.3 1.224 dest_instance.*
dest_vpc.*
psc.reporter
psc.psc_attachment.*
antworten 10.50.0.3 10.40.0.2 5.342 src_instance.*
src_vpc.*
psc.reporter
psc.psc_attachment.*

VM-zu-Google API-Flüsse

Bei VM-Traffic zu Google APIs über die externe IP-Adresse der VM, den privater Google-Zugriff oder einen Private Service Connect-Endpunkt werden in VPC-Flußprotokollen Protokolleinträge mit Google API-Informationen versehen. Im folgenden Beispiel wird beschrieben, wie VPC-Flußprotokolle Protokolleinträge für eine VM annotieren, die über einen Private Service Connect-Endpunkt auf eine globale Google API zugreift.

VM-Traffic wird über Private Service Connect an Google APIs gesendet.
VM-Zugriffe auf Google APIs über Private Service Connect (zum Vergrößern anklicken)

Trafficflüsse zu einer Google API werden von Nutzer-VMs gemeldet, sofern sich die VM in einem Subnetz befindet, für das VPC-Flusslogs aktiviert sind. In diesem Beispiel sendet die Nutzer-VM 10.10.0.2 eine Anfrage mit 1.224 Byte an den Private Service Connect-Endpunkt 10.10.110.10. Die Anfrage wird an den entsprechenden Google-Dienst weitergeleitet, z. B. an Cloud Storage. Cloud Storage antwortet auf die Anfrage mit einer Antwort, die 5.342 Byte enthält. Sowohl die Anfrage als auch die Antwort werden von der anfragenden VM aufgezeichnet.

Wie von der Nutzer-VM (10.10.0.2) gemeldet
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Request 10.10.0.2 10.10.110.10 1.224 src_instance.*
src_vpc.*
dest_google_service.*
psc.reporter
psc.psc_endpoint.*
antworten 10.10.110.10 10.10.0.2 5.342 src_google_service.*
dest_instance.*
dest_vpc.*
psc.reporter
psc.psc_endpoint.*

VM-Zugriffe über Cloud Load Balancing

In VPC-Fluss-Logs werden Anmerkungen zu Traffic hinzugefügt, der über einen Passthrough-Network Load Balancer, einen Proxy-Network Load Balancer oder einen Application Load Balancer gesendet wird. In den folgenden Beispielen wird davon ausgegangen, dass diese Load Balancer als interne Load Balancer konfiguriert sind.

VM-zu-VM-Datenflüsse über einen internen Passthrough Network Load Balancer

Datenflüsse für den internen Passthrough-Network Load Balancer
Datenflüsse für den internen Passthrough Network Load Balancer (zum Vergrößern klicken)

Wenn Sie dem Backend-Dienst für einen internen Passthrough Network Load Balancer eine VM hinzufügen, Google Cloud fügt die Linux- oder Windows-Gastumgebung die IP-Adresse des Load-Balancers 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.

Wie von Client-VM (192.168.1.2) gemeldet
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Anfrage 192.168.1.2 10.240.0.200 1.224 src_instance.*
src_vpc.*
load_balancing.forwarding_rule_project_id
load_balancing.reporter
load_balancing.type
load_balancing.scheme
load_balancing.forwarding_rule_name
load_balancing.backend_service_name
load_balancing.vpc.*
antworten 10.240.0.200 192.168.1.2 5.342 dest_instance.*
dest_vpc.*
load_balancing.forwarding_rule_project_id
load_balancing.reporter
load_balancing.type
load_balancing.scheme
load_balancing.forwarding_rule_name
load_balancing.backend_service_name
load_balancing.vpc.*
Wie von der Backend-VM (10.240.0.3) gemeldet
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Anfrage 192.168.1.2 10.240.0.200 1.224 src_instance.*
src_vpc.*
dest_instance.*
dest_vpc.*
load_balancing.* (alle Felder außer „url_map_name“)
antworten 10.240.0.200 192.168.1.2 5.342 src_instance.*
src_vpc.*
dest_instance.*
dest_vpc.*
load_balancing.* (alle Felder außer „url_map_name“)

In der Anfrage, die der Load Balancer an die Back-End-VM verteilt, wird die Quell-IP-Adresse auf die IP-Adresse der Client-VM festgelegt. Das bedeutet, dass die Backend-VM src_instance- und dest_instance-Informationen zur Client-VM bereitstellen kann. Im Gegensatz zur Back-End-VM kann die Client-VM jedoch keine src_instance- und dest_instance-Informationen zur Back-End-VM in ihren Bericht aufnehmen, da sie die Anfrage an die IP-Adresse des Load Balancers sendet und die Antwort von dort empfängt, nicht von der Back-End-VM.

VM-Zugriffe über einen internen Proxy-Network Load Balancer oder einen internen Application Load Balancer

Trafficflüsse über einen internen Proxy-Network Load Balancer oder einen internen Application Load Balancer werden von Client-VMs erfasst, sofern sich die Client-VM in einem Subnetz befindet, für das VPC-Fluss-Logs aktiviert sind. Beispiel: Eine Client-VM mit der IP-Adresse 10.10.0.2 sendet eine Anfrage mit 1.224 Byte an den Load Balancer-Endpunkt 10.10.0.3. Die Anfrage erreicht dann ein Back-End. Das Backend antwortet auf die Anfrage mit einer Antwort, die 5.342 Byte enthält. Sowohl die Anfrage als auch die Antwort werden auf der Client-VM aufgezeichnet. Die Protokolle der Client-VM sind im Projekt Google Cloud verfügbar, zu dem die VM gehört.

Wie von Client-VM gemeldet (10.10.0.2)
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Request 10.10.0.2 10.10.0.3 1.224 src_instance.*
src_vpc.*
load_balancing.forwarding_rule_project_id
load_balancing.reporter
load_balancing.type
load_balancing.scheme
load_balancing.url_map_name (für Application Load Balancer)
load_balancing.forwarding_rule_name
load_balancing.vpc.*
antworten 10.10.0.3 10.10.0.2 5.342 dest_instance.*
dest_vpc.*
load_balancing.forwarding_rule_project_id
load_balancing.reporter
load_balancing.type
load_balancing.scheme
load_balancing.url_map_name (für Application Load Balancer)
load_balancing.forwarding_rule_name
load_balancing.vpc.*

GKE-Zugriffe

In den folgenden Abschnitten finden Sie Beispiele dafür, wie VPC-Flussprotokolle GKE-Traffic von und zu Pods annotieren.

Pod-zu-ClusterIP-Datenfluss

Pod-zu-Cluster-IP-Datenfluss
IP-Datenfluss von Pod zu Cluster (zum Vergrößern klicken)

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

Externe Load Balancer-Datenflüsse
Externe Load Balancer-Datenflüsse (zum Vergrößern anklicken)

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 externe 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

Eingehende Datenflüsse
Eingehende Datenflüsse (zum Vergrößern klicken)

Eine Verbindung von einer externen IP-Adresse zu einem Ziel für eingehenden Traffic wird beim Cloud Load Balancing-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

Eingehende Datenflüsse mit containernativem Load Balancing
Eingehende Datenflüsse mit containernativem Load Balancing (zum Vergrößern anklicken)

Anfragen von einer externen IP-Adresse an ein Ingress-Ziel, 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

Pod zu externem Datenfluss
Pod zu externem Datenfluss (zum Vergrößern klicken)

Der Traffic von einem Pod (10.4.0.3) zu einer externen IP-Adresse (203.0.113.1) wird durch IP-Masquerading 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-Anmerkungen 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.*

Hybridkonnektivitätsflüsse

Bei Traffic zwischen Google Cloud und lokalen Netzwerken werden in VPC-Flusslogs Flüsse zwischen VM-Instanzen – einschließlich Instanzen, die als GKE-Knoten verwendet werden – und lokalen Endpunkten, zwischen Google APIs und lokalen Endpunkten sowie Transit-Traffic zwischen lokalen Endpunkten kommentiert. Im folgenden Beispiel wird beschrieben, wie VPC-Flussprotokolle Abläufe zwischen VM-Instanzen in einem VPC-Netzwerk und einem lokalen Endpunkt annotieren.

VM-Datenflüsse zu lokalen Netzwerken.
VM-zu-On-Premises-Datenflüsse (zum Vergrößern anklicken)

Für Datenflüsse zwischen einer VM in einem VPC-Netzwerk und einem lokalen Endpunkt mit einer internen IP-Adresse werden Flusslogs nur vonGoogle Cloud gemeldet. Die folgenden Ressourcen erfassen Ablaufprotokolle:

  • Die VM Meldet Flussprotokolle, wenn für das Subnetz, mit dem die VM verbunden ist, VPC-Flusslogs aktiviert sind.
  • Das Gateway, das das VPC-Netzwerk mit dem lokalen Endpunkt verbindet Meldet Flussprotokolle, wenn für das Gateway VPC-Flusslogs aktiviert sind.

Im obigen Diagramm sendet der lokale Endpunkt 10.30.0.2 eine Anfrage mit 1.224 Byte über Cloud Interconnect an die VM 10.0.0.2 im VPC-Netzwerk. Die VM 10.0.0.2 antwortet auf die Anfrage mit einer Antwort, die 5.243 Byte enthält. Sowohl die Anfrage als auch die Antwort werden sowohl vom VLAN-Anhang für Cloud Interconnect als auch von der VM aufgezeichnet.

Wie vom VLAN-Anhang gemeldet
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Anfrage 10.30.0.2 10.0.0.2 1.224 src_gateway.*
dest_instance.*
dest_vpc.*
antworten 10.0.0.2 10.30.0.2 5.342 src_instance.*
src_vpc.*
dest_gateway.*
Wie von VM (10.0.0.2) gemeldet
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Anfrage 10.30.0.2 10.0.0.2 1.224 src_gateway.*
dest_instance.*
dest_vpc.*
antworten 10.0.0.2 10.30.0.2 5.342 src_instance.*
src_vpc.*
dest_gateway.*

Traffic zwischen VPC-Netzwerken in verschiedenen Projekten

Wenn VPC-Flusslogs für eine Organisation konfiguriert und projektübergreifende Anmerkungen aktiviert sind (Standardeinstellung), werden Trafficflüsse zwischen VPC-Netzwerken in verschiedenen Projekten auf die gleiche Weise wie Trafficflüsse zwischen VPC-Netzwerken im selben Projekt kommentiert. Protokolleinträge für diese Flüsse enthalten Informationen zu beiden Seiten der Verbindung.

Wenn projektübergreifende Anmerkungen deaktiviert sind, enthalten Protokolleinträge nur Informationen zum Melder des Traffic-Flows.

Projektübergreifende Annotationen aktiviert

Im folgenden Beispiel wird beschrieben, wie VPC-Flusslogs Protokolleinträge für VM-zu-VM-Zugriffe zwischen Projekten annotieren, wenn projektübergreifende Anmerkungen aktiviert sind. Projektübergreifende Anmerkungen sind für Trafficflüsse über freigegebene VPC, VPC-Netzwerk-Peering und Network Connectivity Center verfügbar.

VM-zu-VM-Datenflüsse in einer Organisation.
VM-zu-VM-Datenflüsse in einer Organisation (zum Vergrößern anklicken)

VM 10.0.0.2 sendet eine Anfrage mit 1.224 Byte an VM 10.0.0.1.2. VM 10.0.0.1.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.0.0.2)
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Anfrage 10.0.0.2 10.0.1.2 1.224 src_instance.*
src_vpc.*
dest_instance.*
dest_vpc.*
antworten 10.0.1.2 10.0.0.2 5.342 src_instance.*
src_vpc.*
dest_instance.*
dest_vpc.*
Wie von antwortender VM gemeldet (10.0.1.2)
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Anfrage 10.0.0.2 10.0.1.2 1.224 src_instance.*
src_vpc.*
dest_instance.*
dest_vpc.*
antworten 10.0.1.2 10.0.0.2 5.342 src_instance.*
src_vpc.*
dest_instance.*
dest_vpc.*

Projektübergreifende Annotationen deaktiviert

Im folgenden Beispiel wird beschrieben, wie VPC-Flusslogs Protokolleinträge für VM-zu-VM-Flüsse zwischen Projekten annotieren, wenn projektübergreifende Anmerkungen deaktiviert sind.

VM 10.0.0.2 sendet eine Anfrage mit 1.224 Byte an VM 10.0.0.1.2. VM 10.0.0.1.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. Informationen zur anderen VM werden jedoch nicht bereitgestellt.

Wie von anfragender VM gemeldet (10.0.0.2)
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Anfrage 10.0.0.2 10.0.1.2 1.224 src_instance.*
src_vpc.*
antworten 10.0.1.2 10.0.0.2 5.342 dest_instance.*
dest_vpc.*
Wie von antwortender VM gemeldet (10.0.1.2)
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent Annotationen
Anfrage 10.0.0.2 10.0.1.2 1.224 dest_instance.*
dest_vpc.*
antworten 10.0.1.2 10.0.0.2 5.342 src_instance.*
src_vpc.*

Nächste Schritte