트래픽 흐름 정보
이 페이지에서는 VPC 흐름 로그가 일반적인 용도의 흐름 로그를 보고하는 방법을 설명합니다. VPC 흐름 로그에서 샘플링한 트래픽 흐름의 예는 다음 섹션을 참조하세요.
VM 흐름
다음 섹션에서는 VPC 흐름 로그 샘플 트래픽이 가상 머신(VM) 인스턴스에서 전송 및 수신되는 방법 예시를 보여줍니다. VPC 흐름 로그가 Google Kubernetes Engine 포드의 흐름 로그를 보고하는 방법은 GKE 흐름을 참조하세요.
동일한 VPC 네트워크에서 VM-VM 흐름
동일한 VPC 네트워크의 VM-VM 흐름의 경우, 두 VM이 모두 VPC 흐름 로그가 사용 설정된 서브넷에 있으면 요청하는 VM과 응답하는 VM 모두에서 흐름 로그가 보고됩니다. 이 예시에서 VM 10.10.0.2는 1,224바이트의 요청을 마찬가지로 로깅이 사용 설정된 서브넷에 있는 VM 10.50.0.2로 보냅니다. 그러면 10.50.0.2는 요청에 대해 5,342바이트를 포함하는 응답을 보냅니다. 요청하는 VM과 응답하는 VM 모두에서 요청과 응답이 모두 기록됩니다.
| 요청하는 VM(10.10.0.2)의 보고 내용 | ||||
|---|---|---|---|---|
| 요청/응답 | connection.src_ip | connection.dest_ip | bytes_sent | 주석 |
| 요청 | 10.10.0.2 | 10.50.0.2 | 1,224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| 응답 | 10.50.0.2 | 10.10.0.2 | 5,342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| 응답하는 VM(10.50.0.2)의 보고 내용 | ||||
|---|---|---|---|---|
| 요청/응답 | connection.src_ip | connection.dest_ip | 바이트 | 주석 |
| 요청 | 10.10.0.2 | 10.50.0.2 | 1,224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| 응답 | 10.50.0.2 | 10.10.0.2 | 5,342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
VM-외부 IP 주소 흐름
VPC 네트워크에 있는 VM과 외부 IP 주소가 있는 엔드포인트 간에 인터넷을 순회하는 흐름의 경우 VPC 네트워크에 있는 VM에서만 흐름 로그가 보고됩니다.
- 이그레스 흐름의 경우 트래픽의 소스인 VPC 네트워크 VM에서 로그가 보고됩니다.
- 인그레스 흐름의 경우 트래픽의 대상인 VPC 네트워크 VM에서 로그가 보고됩니다.
이 예시에서 VM 10.10.0.2는 외부 IP 주소 203.0.113.5를 가진 엔드포인트를 사용하여 인터넷을 통해 패킷을 교환합니다. 10.10.0.2에서 203.0.113.5로 전송된 1,224바이트의 아웃바운드 트래픽은 소스 VM 10.10.0.2에서 보고됩니다. 203.0.113.5에서 10.10.0.2로 전송된 5,342바이트의 인바운드 트래픽은 트래픽의 대상인 VM 10.10.0.2에서 보고됩니다.
| 요청/응답 | connection.src_ip | connection.dest_ip | bytes_sent | 주석 |
|---|---|---|---|---|
| 요청 | 10.10.0.2 | 203.0.113.5 | 1,224 |
src_instance.* src_vpc.* dest_location.* internet_routing_details.* |
| 응답 | 203.0.113.5 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* src_location.* |
VM-온프레미스 흐름
VPC 네트워크 내부의 VM과 내부 IP 주소가 있는 온프레미스 엔드포인트 간 흐름의 경우 VPC 네트워크 내부의 VM에서만 흐름 로그가 보고됩니다.
- 이그레스 흐름의 경우 트래픽의 소스인 VPC 네트워크 VM에서 로그가 보고됩니다.
- 인그레스 흐름의 경우 트래픽의 대상인 VPC 네트워크 VM에서 로그가 보고됩니다.
이 예시에서 VM 10.10.0.2와 온프레미스 엔드포인트 10.30.0.2는 VPN 게이트웨이 또는 Cloud Interconnect를 통해 연결됩니다. 10.10.0.2에서 10.30.0.2로 전송된 1,224바이트의 아웃바운드 트래픽은 소스 VM 10.10.0.2에서 보고됩니다. 10.30.0.2에서 10.10.0.2로 전송된 5,342바이트의 인바운드 트래픽은 트래픽의 대상인 VM 10.10.0.2에서 보고됩니다.
| 요청/응답 | connection.src_ip | connection.dest_ip | bytes_sent | 주석 |
|---|---|---|---|---|
| 요청 | 10.10.0.2 | 10.30.0.2 | 1,224 |
dest_gateway.* src_instance.* src_vpc.* |
| 응답 | 10.30.0.2 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* src_gateway.* |
공유 VPC의 VM-VM 흐름
공유 VPC의 VM-VM 흐름의 경우 호스트 프로젝트에서 서브넷에 대한 VPC 흐름 로그를 사용 설정할 수 있습니다. 예를 들어 서브넷 10.10.0.0/20은 호스트 프로젝트에 정의된 공유 VPC 네트워크에 속합니다. 서비스 프로젝트에서 생성된 VM을 포함하여 이 서브넷에 속한 VM에서 흐름 로그를 볼 수 있습니다. 이 예시에서 서비스 프로젝트는 'web server', 'recommendation', 'database'입니다.
VM-VM 흐름의 경우, 두 VM이 동일한 프로젝트 또는 동일한 호스트 프로젝트(공유 네트워크의 경우)에 있으면 연결의 다른 엔드포인트에 대한 프로젝트 ID 등의 주석이 제공됩니다. 다른 VM이 다른 프로젝트에 있으면 다른 VM의 주석이 제공되지 않습니다.
다음 표에서는 10.10.0.10 또는 10.10.0.20이 보고한 흐름을 보여줍니다.
- VPC 서브넷은 호스트 프로젝트에 속하기 때문에
src_vpc.project_id및dest_vpc.project_id는 호스트 프로젝트에 해당합니다. - 인스턴스는 서비스 프로젝트에 속하기 때문에
src_instance.project_id및dest_instance.project_id는 서비스 프로젝트에 해당합니다.
|
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 | 웹 서버 | host_project | 10.10.0.20 | recommendation | host_project |
서비스 프로젝트는 공유 VPC 네트워크를 소유하지 않으며 공유 VPC 네트워크의 흐름 로그에 액세스할 수 없습니다.
VPC 네트워크 피어링의 VM-VM 흐름
두 VM이 동일한 Google Cloud 프로젝트에 있지 않으면 피어링된 VPC 네트워크의 VM-VM 흐름이 외부 엔드포인트와 동일한 방식으로 보고됩니다. 다른 VM의 프로젝트 및 기타 주석 정보는 제공되지 않습니다. 두 VM이 서로 다른 네트워크에 있더라도 동일한 프로젝트에 있기만 하면 다른 VM의 프로젝트 및 기타 주석 정보도 제공됩니다.
이 예시에서는 analytics-prod 프로젝트에 있는 VM 10.10.0.2와 webserver-test 프로젝트에 있는 VM 10.50.0.2의 서브넷이 VPC 네트워크 피어링을 통해 연결됩니다.
analytics-prod 프로젝트에서 VPC 흐름 로그가 사용 설정된 경우 10.10.0.2에서 10.50.0.2로 전송된 트래픽(1,224바이트)은 흐름의 소스인 VM 10.10.0.2에서 보고됩니다. 또한 10.50.0.2에서 10.10.0.2로 전송된 트래픽(5,342바이트)은 흐름의 대상인 VM 10.10.0.2에서도 보고됩니다.
이 예시에서 webserver-test 프로젝트에는 VPC 흐름 로그가 사용 설정되지 않았으므로 VM 10.50.0.2에서는 로그가 기록되지 않습니다.
| reporter | connection.src_ip | connection.dest_ip | bytes_sent | 주석 |
|---|---|---|---|---|
| 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.* |
Cloud Load Balancing이 있는 VM 흐름
Cloud Load Balancing을 통한 흐름의 경우 VPC 흐름 로그가 패스 스루 네트워크 부하 분산기, 프록시 네트워크 부하 분산기, 애플리케이션 부하 분산기를 통해 전송된 트래픽을 주석화합니다. 다음 예에서는 이러한 부하 분산기가 내부 부하 분산기로 구성되었다고 가정합니다.
내부 패스 스루 네트워크 부하 분산기를 통한 VM 간 흐름
내부 패스 스루 네트워크 부하 분산기의 백엔드 서비스에 VM을 추가할 때 Google Cloud는 VM의 로컬 라우팅 테이블에 부하 분산기의 IP 주소를 추가합니다. 그러면 VM은 대상이 부하 분산기의 IP 주소로 설정된 요청 패킷을 허용할 수 있습니다. VM은 응답 시 직접 응답을 보냅니다. 그러나 응답 패킷의 소스 IP 주소는 부하 분산이 적용되는 VM이 아니라 부하 분산기의 IP 주소로 설정됩니다.
내부 패스 스루 네트워크 부하 분산기를 통해 전송된 VM 간 흐름은 소스와 대상 모두에서 보고됩니다.
| 클라이언트 VM(192.168.1.2)의 보고 내용 | ||||
|---|---|---|---|---|
| 요청/응답 | connection.src_ip | connection.dest_ip | bytes_sent | 주석 |
| 요청 | 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.* |
| 응답 | 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.* |
| 백엔드 VM(10.240.0.3)의 보고 내용 | ||||
|---|---|---|---|---|
| 요청/응답 | connection.src_ip | connection.dest_ip | 바이트 | 주석 |
| 요청 | 192.168.1.2 | 10.240.0.200 | 1,224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (url_map_name을 제외한 모든 필드) |
| 응답 | 10.240.0.200 | 192.168.1.2 | 5,342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (url_map_name을 제외한 모든 필드) |
백엔드 VM이 클라이언트 VM의 IP 주소를 알고 있기 때문에 클라이언트 VM에 대한 src_instance 및 dest_instance 정보를 제공할 수 있습니다. 백엔드 VM과 달리 클라이언트 VM은 백엔드 VM의 IP 주소를 알지 못하며, 따라서 백엔드 VM에 대한 src_instance 및 dest_instance 정보를 보고서에 추가할 수 없습니다.
VM-to-internal-proxy-Network-Load-Balancer 및 VM-to-internal-Application-Load-Balancer 흐름
내부 프록시 네트워크 부하 분산기 또는 내부 애플리케이션 부하 분산기를 통한 트래픽 흐름은 클라이언트 VM이 VPC 흐름 로그가 사용 설정된 서브넷에 있는 한 클라이언트 VM에서 보고됩니다. 예를 들어 IP 주소가 10.10.0.2인 클라이언트 VM은 부하 분산기 엔드포인트 10.10.0.3에 1,224바이트 요청을 보냅니다. 그런 후 요청이 백엔드에 도달합니다. 그런 다음 백엔드는 5,342바이트가 포함된 회신으로 요청에 응답합니다.
요청과 회신은 모두 클라이언트 VM에 기록됩니다. 클라이언트 VM의 로그는 VM이 속한 Google Cloud 프로젝트에 제공됩니다.
| 클라이언트 VM(10.10.0.2)의 보고 내용 | ||||
|---|---|---|---|---|
| 요청/응답 | connection.src_ip | connection.dest_ip | bytes_sent | 주석 |
| 요청 | 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(애플리케이션 부하 분산기) load_balancing.forwarding_rule_name load_balancing.vpc.* |
| 응답 | 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(애플리케이션 부하 분산기) load_balancing.forwarding_rule_name load_balancing.vpc.* |
Private Service Connect를 통한 VM간 흐름
Private Service Connect를 통한 VM간 흐름에 대해 VPC 흐름 로그 샘플은 Private Service Connect 소비자와 게시된 서비스 사이에 전달됩니다.
게시된 서비스에 대한 Private Service Connect 엔드포인트
Private Service Connect 게시 서비스에 대한 트래픽 흐름은 VPC 흐름 로그가 사용 설정된 서브넷에 두 VM이 모두 있는 경우 소비자 및 생산자 VM 모두에서 보고됩니다. 이 예시에서 소비자 VM 10.10.0.2는 1,224바이트 요청을 Private Service Connect 엔드포인트 10.10.0.3으로 보냅니다. 생산자 VPC에서 요청의 소스 IP 주소는 이 예시에서 10.40.0.2에 해당하는 서비스 연결 서브넷의 IP 주소로 변환됩니다. 요청의 대상 IP 주소는 내부 패스 스루 네트워크 부하 분산기 10.50.0.3의 IP 주소로 변환됩니다. 그런 후 이 요청은 또한 로깅이 사용 설정된 서브넷에 있는 백엔드 VM 10.50.0.2에 도달합니다.
그러면 10.50.0.2는 요청에 대해 5,342바이트를 포함하는 응답을 보냅니다. 요청과 회신 모두 요청 및 응답 VM 모두에서 기록됩니다. 소비자 VM의 로그는 소비자 프로젝트에서 제공되고 생산자 VM의 로그는 생산자 프로젝트에서 제공됩니다.
| 소비자 VM(10.10.0.2)의 보고 내용 | ||||
|---|---|---|---|---|
| 요청/응답 | connection.src_ip | connection.dest_ip | bytes_sent | 주석 |
| 요청 | 10.10.0.2 | 10.10.0.3 | 1,224 |
src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.* |
| 응답 | 10.10.0.3 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.* |
| 생산자 VM(10.50.0.2)의 보고 내용 | ||||
|---|---|---|---|---|
| 요청/응답 | connection.src_ip | connection.dest_ip | bytes_sent | 주석 |
| 요청 | 10.40.0.2 | 10.50.0.3 | 1,224 |
dest_instance.* dest_vpc.* psc.reporter psc.psc_attachment.* |
| 응답 | 10.50.0.3 | 10.40.0.2 | 5,342 |
src_instance.* src_vpc.* psc.reporter psc.psc_attachment.* |
VM-Google-API 흐름
VM의 외부 IP 주소, 비공개 Google 액세스, Private Service Connect 엔드포인트를 통한 Google API에 대한 VM 트래픽의 경우 VPC 흐름 로그는 Google API 정보로 로그 기록을 주석화합니다. 다음 섹션에서는 Private Service Connect 엔드포인트를 통해 전역 Google API에 액세스하는 VM에 대해 VPC 흐름 로그가 로그 기록을 주석화하는 방법의 예시를 보여줍니다.
Private Service Connect를 통해 전역 Google API에 VM 연결
VPC 흐름 로그가 사용 설정된 서브넷에 VM이 있는 한 Google API에 대한 트래픽 흐름이 소비자 VM에서 보고됩니다. 이 예시에서 소비자 VM 10.10.0.2는 1,224바이트 요청을 Private Service Connect 엔드포인트 10.10.110.10으로 보냅니다. 요청은 적합한 Google API(예: Cloud Storage)로 전달됩니다. 그러면 Cloud Storage가 5,342바이트를 포함하는 회신으로 요청에 응답합니다.
요청 및 회신이 모두 요청하는 VM에서 기록됩니다.
| 소비자 VM(10.10.0.2)의 보고 내용 | ||||
|---|---|---|---|---|
| 요청/응답 | connection.src_ip | connection.dest_ip | bytes_sent | 주석 |
| 요청 | 10.10.0.2 | 10.10.110.10 | 1,224 |
src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* dest_google_service.* |
| 응답 | 10.10.110.10 | 10.10.0.2 | 5,342 |
src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* |
GKE 흐름
다음 섹션에서는 VPC 흐름 로그가 포드에 대해 GKE 트래픽을 샘플링하는 방법 예시를 보여줍니다.
포드-ClusterIP 흐름
이 예시에서는 클라이언트 포드(10.4.0.2)에서 cluster-service(10.0.32.2:80)로 트래픽이 전송됩니다. 대상은 대상 포트(8080)에서 선택한 서버 포드 IP 주소(10.4.0.3)로 확인됩니다.
노드 에지에서 흐름은 변환된 IP 주소 및 포트와 함께 두 번 샘플링됩니다. 두 샘플링 시점에서 대상 포드가 포트 8080에서 서비스 cluster-service를 지원하는지 확인하고, 포드 세부정보와 서비스 세부정보를 사용하여 레코드를 주석으로 처리합니다. 동일한 노드에 있는 포드로 트래픽이 라우팅되는 경우 트래픽은 노드를 벗어나지 않으며 전혀 샘플링되지 않습니다.
이 예시에서는 다음 레코드가 있습니다.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | 주석 |
|---|---|---|---|---|
| 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.* |
GKE 외부 부하 분산기 흐름
외부 IP 주소에서 GKE 서비스(35.35.35.35)로의 트래픽은 라우팅을 위해 클러스터의 노드(이 예시에서는 10.0.12.2)로 라우팅됩니다. 기본적으로 외부 패스 스루 네트워크 부하 분산기는 관련 포드를 실행하지 않는 노드까지 포함해 클러스터의 모든 노드에 트래픽을 분산합니다. 트래픽에는 관련 포드로 이동하기 위한 추가 홉이 필요할 수 있습니다. 자세한 내용은 클러스터 외부 네트워킹을 참조하세요.
그러면 트래픽이 노드(10.0.12.2)에서 선택한 서버 포드(10.4.0.2)로 라우팅됩니다. 모든 노드 에지가 샘플링되므로 두 홉이 모두 로깅됩니다. 트래픽이 동일한 노드에 있는 포드로 라우팅되는 경우 이 예시에서 10.4.0.3은 두 번째 홉이 노드를 벗어나지 않으므로 로깅되지 않습니다.
두 번째 홉은 두 노드의 샘플링 시점에서 로깅합니다. 첫 번째 홉의 경우 부하 분산기 IP 및 서비스 포트(80)를 기준으로 서비스를 식별합니다. 두 번째 홉의 경우 대상 포드가 대상 포트(8080)에서 서비스를 지원하고 있음을 식별합니다.
이 예시에서는 다음 레코드가 있습니다.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | 주석 |
|---|---|---|---|---|
| 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.* |
GKE 인그레스 흐름
외부 IP 주소에서 인그레스 대상으로의 연결은 Cloud Load Balancing 서비스에서 종료됩니다. URL에 따라 연결이 NodePort 서비스에 매핑됩니다. 요청을 처리하기 위해 부하 분산기(130.211.0.1)는 서비스의 NodePort를 사용하여 라우팅할 클러스터 노드(10.0.12.2) 중 하나에 연결됩니다. 기본적으로 인그레스를 만들 때 GKE 인그레스 컨트롤러는 관련 포드를 실행하지 않는 노드까지 포함해 클러스터의 모든 노드에 트래픽을 분산하는 HTTP(S) 부하 분산기를 구성합니다. 트래픽에는 관련 포드로 이동하기 위한 추가 홉이 필요할 수 있습니다. 자세한 내용은 클러스터 외부 네트워킹을 참조하세요.
그러면 트래픽은 노드(10.0.12.2)에서 선택된 서버 포드(10.4.0.2)로 라우팅됩니다.
모든 노드 에지가 샘플링되므로 두 홉이 모두 로깅됩니다. 첫 번째 홉의 경우 서비스의 NodePort(60000)를 기준으로 서비스를 식별합니다. 두 번째 홉의 경우 대상 포드가 대상 포트(8080)에서 서비스를 지원하는지 확인합니다. 두 번째 홉은 두 노드의 샘플링 시점에서 로깅됩니다.
그러나 트래픽이 동일한 노드(10.4.0.3)의 포드로 라우팅되는 경우 트래픽이 노드를 벗어나지 않으므로 두 번째 홉이 로깅되지 않습니다.
이 예시에서는 다음 레코드가 있습니다.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | 주석 |
|---|---|---|---|---|
| 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.* |
컨테이너 기반 부하 분산을 사용하는 GKE 인그레스 흐름
외부 IP 주소에서 컨테이너 기반 부하 분산을 사용하는 인그레스로 이동하는 요청은 부하 분산기에서 종료됩니다. 이 유형의 인그레스에서 포드는 부하 분산의 핵심 객체입니다.
그런 다음 부하 분산기(130.211.0.1)에서 선택한 포드(10.4.0.2)로 요청이 직접 전송됩니다. 대상 포드가 대상 포트(8080)에서 서비스를 지원하는 것으로 식별됩니다.
이 예시에는 다음 레코드가 있습니다.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | 주석 |
|---|---|---|---|---|
| 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-외부 흐름
포드(10.4.0.3)에서 외부 IP(203.0.113.1) 로의 트래픽은 패킷이 포드 IP 대신 노드 IP(10.0.12.2)에서 전송되도록 IP 매스커레이딩에서 수정됩니다. 기본적으로 GKE 클러스터는 트래픽을 외부 대상으로 매스커레이드하도록 구성됩니다. 자세한 내용은 IP 매스커레이드 에이전트를 참조하세요.
이 트래픽의 포드 주석을 보려면 포드 IP를 매스커레이드하지 않도록 매스커레이드 에이전트를 구성하면 됩니다. 이 경우 인터넷 트래픽을 허용하려면 포드 IP 주소를 처리하는 Cloud NAT를 구성하면 됩니다. GKE를 사용하는 Cloud NAT에 대한 자세한 내용은 GKE 상호작용을 참조하세요.
이 예시에는 다음 레코드가 있습니다.
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | 주석 |
|---|---|---|---|---|
| SRC | 10.0.12.2 | 203.0.113.1 | 1,224 |
src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.* internet_routing_details.* |