트래픽 흐름 정보
이 페이지에서는 VPC 흐름 로그가 일반적인 용도의 흐름 로그를 보고하는 방법을 설명합니다. VPC 흐름 로그에서 샘플링한 트래픽 흐름의 예는 다음 섹션을 참조하세요.
동일한 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 |
src_instance.* src_vpc.* |
| 응답 | 10.30.0.2 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* |
공유 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 | web server | 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.* |
내부 패스 스루 네트워크 부하 분산기의 VM-VM 흐름
내부 패스 스루 네트워크 부하 분산기의 백엔드 서비스에 VM을 추가할 때 Linux 또는 Windows 게스트 환경은 VM의 로컬 라우팅 테이블에 부하 분산기의 IP 주소를 추가합니다. 그러면 VM은 대상이 부하 분산기의 IP 주소로 설정된 요청 패킷을 허용할 수 있습니다. VM은 응답 시 직접 응답을 보냅니다. 그러나 응답 패킷의 소스 IP 주소는 부하 분산이 적용되는 VM이 아니라 부하 분산기의 IP 주소로 설정됩니다.
내부 패스 스루 네트워크 부하 분산기를 통해 전송된 VM 간 흐름은 소스와 대상 모두에서 보고됩니다. 다음 표에서는 예에 나온 HTTP 요청/응답 쌍에 대해 관찰된 흐름 로그 항목의 필드를 설명합니다. 이 예에서는 네트워크 구성이 다음과 같다고 가정합니다.
- 브라우저 인스턴스 위치 192.168.1.2
- 내부 패스 스루 네트워크 부하 분산기 위치 10.240.0.200
- 웹 서버 인스턴스 위치 10.240.0.3
| 트래픽 방향 | reporter | connection.src_ip | connection.dest_ip | connection.src_instance | connection.dest_instance |
|---|---|---|---|---|---|
| 요청 | SRC | 192.168.1.2 | 10.240.0.200 | 브라우저 인스턴스 | |
| 요청 | DEST | 192.168.1.2 | 10.240.0.200 | 브라우저 인스턴스 | 웹 서버 인스턴스 |
| 응답 | SRC | 10.240.0.3 | 192.168.1.2 | 웹 서버 인스턴스 | 브라우저 인스턴스 |
| 응답 | DEST | 10.240.0.200 | 192.168.1.2 | 브라우저 인스턴스 |
요청하는 VM은 어떤 VM이 요청에 응답할지 알지 못합니다. 또한 다른 VM은 내부 부하 분산기 IP를 소스 주소로 사용하여 응답을 보내므로 어떤 VM이 실제로 응답했는지도 알지 못합니다.
이러한 이유 때문에 요청하는 VM은 dest_instance 정보를 보고서에 추가할 수 없고 src_instance 정보만 추가할 수 있습니다. 응답하는 VM은 다른 VM의 IP 주소를 알고 있기 때문에 src_instance 및 dest_instance 정보를 모두 제공할 수 있습니다.
포드-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 주소에서 인그레스 대상으로의 연결은 부하 분산기 서비스에서 종료됩니다. 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.* |
포드-외부 흐름
포드(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.* |