카테고리 없음
[8주차] Istio Traffic Flow : 트래픽 흐름
구구달스
2025. 5. 28. 10:49
CloudNet@ 가시다님이 진행하는 Istio Hands-on Study [1기]
https://jimmysong.io/en/blog/sidecar-injection-iptables-and-traffic-routing/#iptables-manipulation-analysis
의 내용을 정리🚀 Istio에서 트래픽 흐름 쉽게 이해하기
🌐 다이어그램 개요
- 다이어그램은 Local Pod(로컬 Pod)와 Remote Pod(원격 Pod) 간의 트래픽 흐름을 나타냅니다.
Local Pod 안에는 Application Container(애플리케이션 컨테이너)와 Envoy Proxy가 있으며, Envoy는 Inbound Handler(인바운드 처리기)와 Outbound Handler(아웃바운드 처리기)로 나뉩니다.
트래픽은 "Yes" 또는 "No"에 따라 다른 경로를 따라가며, 127.0.0.6이라는 특별한 IP 주소가 중요한 역할을 합니다. - 비유하자면, 이 다이어그램은 우체국에서 편지(트래픽)를 분류하고 배달하는 과정을 보여줍니다. Envoy Proxy는 우체국 직원이고, Application Container는 편지를 받는 사람입니다.
Local Pod와 Remote Pod 간 트래픽 흐름을
Envoy Proxy를 통해 보여줍니다.
🔍 트래픽 흐름 단계별 설명
1. Local Pod Traffic 시작
- 트래픽은 Local Pod에서 시작됩니다. "Local Pod traffic"이라는 블록에서 출발하며, 이는 Pod 안이나 밖으로 나가는 모든 요청을 의미합니다. 이 트래픽은 먼저 Envoy Proxy로 전달됩니다.
- 예를 들어, 사용자가 웹사이트를 열었을 때 브라우저에서 서버로 보내는 요청이 Local Pod Traffic에 해당합니다. 여기서 트래픽의 첫 번째 분기점이 시작됩니다.
Local Pod Traffic은
Envoy Proxy로 처음 전달됩니다.
2. Envoy가 보낸 트래픽 확인
- 첫 번째 결정점은 "Traffic sent by Envoy"입니다. 만약 트래픽이 이미 Envoy에 의해 처리되었다면, 이 트래픽은 Remote Pod로 바로 보냅니다. "Yes" 경로를 따라가면 Remote Pod로 전달됩니다.
- 반대로, Envoy가 처음 보낸 것이 아니라면 "No"로 내려가 다음 단계를 진행합니다. 이는 Envoy가 트래픽을 중간에서 다시 처리할 필요가 없다는 뜻입니다.
Envoy가 보낸 트래픽은 Remote Pod로 바로 가고,
그렇지 않으면 다음 단계로 진행됩니다.
3. 소스 주소 127.0.0.6 확인
- 다음 결정점은 "source address 127.0.0.6"입니다. 이 IP는 Istio에서 특별히 설정된 주소로, Pod 내부에서 Envoy가 애플리케이션으로 보내는 트래픽을 나타냅니다. "Yes"라면 Application Container로 바로 전달됩니다.
- 127.0.0.6은 마치 내부 우편함처럼 작동합니다. Envoy가 이 주소를 사용하면 트래픽이 Pod 밖으로 나가지 않고 바로 Application Container로 가게 됩니다.
127.0.0.6 소스 주소의 트래픽은
Application Container로 바로 전달됩니다.
4. localhost로 가는지 확인
- "to localhost" 결정점에서는 트래픽이 Pod 내부의 localhost로 가는지 확인합니다. "Yes"라면 Application Container로 바로 전달됩니다. "No"라면 Outbound Handler로 보내집니다.
- localhost는 Pod 자신의 IP를 의미합니다. 예를 들어, 같은 Pod 내에서 서로 다른 서비스가 통신할 때 사용됩니다. 이 경우 추가 처리가 필요 없습니다.
localhost로 가는 트래픽은
Application Container로 바로 전달됩니다.
5. Inbound Handler와 Outbound Handler
- Inbound Handler: 외부에서 들어오는 트래픽(예: Remote Pod에서 온 요청)을 처리합니다. 이 트래픽은 Application Container로 전달됩니다.
- Outbound Handler: Pod 밖으로 나가는 트래픽(예: Remote Pod로 가는 요청)을 처리합니다. 이 트래픽은 Envoy를 거쳐 Remote Pod로 보내집니다.
- Inbound와 Outbound는 마치 우체국에서 받은 편지(Inbound)와 보낼 편지(Outbound)를 구분하는 창구와 같습니다.
Inbound Handler는 들어오는 트래픽을,
Outbound Handler는 나가는 트래픽을 처리합니다.
- 이 트래픽 흐름을 우체국에 비유하면 이해하기 쉽습니다. Local Pod Traffic은 편지 배달 요청이고, Envoy Proxy는 우체국 직원입니다. 127.0.0.6은 내부 우편함으로, 같은 건물 내로 보내는 편지를 바로 전달합니다. localhost는 건물 안에서 주고받는 메모이고, Remote Pod는 다른 도시로 보내는 편지입니다. Envoy는 이런 편지들을 올바른 곳으로 배달합니다.
트래픽 흐름은 우체국 배달 과정처럼
Envoy가 단계별로 관리합니다.
📌 핵심 요약
- 트래픽 시작: Local Pod Traffic은 Envoy Proxy로 전달됩니다.
- Envoy 확인: Envoy가 보낸 트래픽은 Remote Pod로 바로 가고, 그렇지 않으면 다음 단계로 진행됩니다.
- 127.0.0.6 주소: 이 소스 주소의 트래픽은 Application Container로 바로 전달됩니다.
- localhost 처리: localhost로 가는 트래픽은 Application Container로 바로 전달됩니다.
- Handler 역할: Inbound Handler는 들어오는 트래픽을, Outbound Handler는 나가는 트래픽을 처리합니다.
- 비유: 트래픽 흐름은 우체국 배달 과정처럼 단계별로 관리됩니다.
🚀 Istio에서 트래픽 라우팅 과정 쉽게 이해하기
🌐 트래픽 라우팅이란?
- 트래픽 라우팅은 네트워크 요청이 올바른 목적지로 전달되는 과정을 의미합니다. Istio에서는 Inbound(들어오는 트래픽)과 Outbound(나가는 트래픽)으로 나뉘어 관리됩니다. Sidecar(Envoy 프록시)는 이 트래픽을 중간에서 가로채고, iptables 규칙에 따라 처리합니다.
- 비유하자면, 트래픽 라우팅은 우체국에서 편지를 분류해 보내는 과정과 같습니다. Inbound는 받은 편지를 열어보고, Outbound는 보낼 편지를 준비하는 단계라고 생각하면 됩니다.
트래픽 라우팅은
Inbound와 Outbound로 나뉘어 Sidecar가 관리합니다.
🔍 Inbound Handler 이해하기
Inbound Handler의 역할
- Inbound Handler는 iptables에 의해 가로채인 트래픽을 localhost로 전달하고, Pod 내 Application Container와 연결합니다. 예를 들어, reviews-v1-545db77b95-jkgv2라는 Pod가 있다고 가정해 봅시다. 이 Pod의 Listener를 확인하려면 다음 명령어를 사용합니다:
istioctl proxy-config listener reviews-v1-545db77b95-jkgv2 --port 15006
- 출력 결과는 다음과 같습니다:
ADDRESS PORT MATCH DESTINATION
0.0.0.0 15006 Addr: *:15006 Non-HTTP/Non-TCP
0.0.0.0 15006 Trans: tls; App: istio-http/1.0,istio-http/1.1,istio-h2; Addr: 0.0.0.0/0 InboundPassthroughClusterIpv4
0.0.0.0 15006 Trans: raw_buffer; App: http/1.1,h2c; Addr: 0.0.0.0/0 InboundPassthroughClusterIpv4
0.0.0.0 15006 Trans: tls; App: TCP TLS; Addr: 0.0.0.0/0 InboundPassthroughClusterIpv4
0.0.0.0 15006 Trans: raw_buffer; Addr: 0.0.0.0/0 InboundPassthroughClusterIpv4
0.0.0.0 15006 Trans: tls; Addr: 0.0.0.0/0 InboundPassthroughClusterIpv4
0.0.0.0 15006 Trans: tls; App: istio,istio-peer-exchange,istio-http/1.0,istio-http/1.1,istio-h2; Addr: *:9080 Cluster: inbound|9080||
0.0.0.0 15006 Trans: raw_buffer; Addr: *:9080 Cluster: inbound|9080||
- 이 결과에서 ADDRESS는 다운스트림 주소, PORT는 Envoy가 듣는 포트, MATCH는 프로토콜이나 주소 매칭, DESTINATION은 라우팅 목적지를 나타냅니다. 포트 15006으로 들어오는 트래픽은 포트 9080으로 라우팅됩니다.
Inbound Handler는
포트 15006 트래픽을 포트 9080으로 전달합니다.
Listener 세부 설정 확인
- 포트 15006 Listener의 상세 설정을 JSON 형식으로 보려면 다음 명령어를 사용합니다:
istioctl proxy-config listeners reviews-v1-545db77b95-jkgv2 --port 15006 -o json
- 출력은 다음과 비슷합니다:
[
{
"name": "virtualInbound",
"address": {
"socketAddress": {
"address": "0.0.0.0",
"portValue": 15006
}
},
"filterChains": [
{
"filterChainMatch": {
"destinationPort": 9080,
"transportProtocol": "tls",
"applicationProtocols": [
"istio",
"istio-peer-exchange",
"istio-http/1.0",
"istio-http/1.1",
"istio-h2"
]
},
"filters": [
{
"name": "envoy.filters.network.http_connection_manager",
"typedConfig": {
"@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager",
"statPrefix": "inbound_0.0.0.0_9080",
"routeConfig": {
"name": "inbound|9080||",
"virtualHosts": [
{
"name": "inbound|http|9080",
"domains": [
"*"
],
"routes": [
{
"name": "default",
"match": {
"prefix": "/"
},
"route": {
"cluster": "inbound|9080||",
"timeout": "0s",
"maxStreamDuration": {
"maxStreamDuration": "0s",
"grpcTimeoutHeaderMax": "0s"
}
},
"decorator": {
"operation": "reviews.default.svc.cluster.local:9080/*"
}
}
]
}
],
"validateClusters": false
}
}
}
]
}
]
}
]
- 이 설정에서 모든 트래픽이 포트 9080으로 라우팅되며, Cluster "inbound|9080||"로 연결됩니다.
Listener 설정은
트래픽을 포트 9080 Cluster로 라우팅합니다.
Cluster 설정 확인
- Cluster 설정을 보려면 다음 명령어를 사용합니다:
istioctl pc cluster reviews-v1-545db77b95-jkgv2 --port 9080 --direction inbound -o json
- 출력은 다음과 같습니다:
[
{
"name": "inbound|9080||",
"type": "ORIGINAL_DST",
"connectTimeout": "10s",
"lbPolicy": "CLUSTER_PROVIDED",
"circuitBreakers": {
"thresholds": [
{
"maxConnections": 4294967295,
"maxPendingRequests": 4294967295,
"maxRequests": 4294967295,
"maxRetries": 4294967295,
"trackRemaining": true
}
]
},
"upstreamBindConfig": {
"sourceAddress": {
"address": "127.0.0.6",
"portValue": 0
}
}
}
]
- TYPE "ORIGINAL_DST"는 원래 목적지(Pod IP)로 트래픽을 보냅니다. "127.0.0.6"은 iptables ISTIO_OUTPUT의 첫 번째 규칙과 연결되며, Application Container로 바로 전달됩니다.
Cluster는 127.0.0.6을 사용해
트래픽을 Application Container로 전달합니다.
🔧 Outbound Handler 이해하기
Outbound Handler의 역할
- Outbound Handler는 iptables에 의해 가로채인 로컬 애플리케이션의 트래픽을 처리하고, Sidecar를 통해 upstream 으로 라우팅합니다.
- 이 트래픽은 virtualOutbound Listener, 0.0.0.0_9080 Listener를 거쳐 Route 9080과 Endpoint를 통해 라우팅됩니다.
Outbound Handler는
로컬 트래픽을 Sidecar를 통해 upstream로 보냅니다.
Route 설정 확인
- ratings.default.svc.cluster.local:9080으로의 라우팅을 보려면 다음 명령어를 사용합니다:
istioctl proxy-config routes reviews-v1-545db77b95-jkgv2 --name 9080 -o json
- 출력의 일부는 다음과 같습니다:
[
{
"name": "ratings.default.svc.cluster.local:9080",
"domains": [
"ratings.default.svc.cluster.local",
"ratings.default.svc.cluster.local:9080",
"ratings",
"ratings:9080",
"ratings.default.svc.cluster",
"ratings.default.svc.cluster:9080",
"ratings.default.svc",
"ratings.default.svc:9080",
"ratings.default",
"ratings.default:9080",
"10.98.49.62",
"10.98.49.62:9080"
],
"routes": [
{
"name": "default",
"match": {
"prefix": "/"
},
"route": {
"cluster": "outbound|9080||ratings.default.svc.cluster.local",
"timeout": "0s",
"retryPolicy": {
"retryOn": "connect-failure,refused-stream,unavailable,cancelled,resource-exhausted,retriable-status-codes",
"numRetries": 2,
"retryHostPredicate": [
{
"name": "envoy.retry_host_predicates.previous_hosts"
}
],
"hostSelectionRetryMaxAttempts": "5",
"retriableStatusCodes": [
503
]
}
}
}
]
}
]
- 이 설정은 트래픽을 "outbound|9080||ratings.default.svc.cluster.local" Cluster로 라우팅합니다.
Route는
트래픽을 ratings Cluster로 보냅니다.
Endpoint 설정 확인
- Endpoint를 보려면 다음 명령어를 사용합니다:
istioctl proxy-config endpoint reviews-v1-545db77b95-jkgv2 --port 9080 -o json --cluster "outbound|9080||ratings.default.svc.cluster.local"
- 출력은 다음과 같습니다:
{
"clusterName": "outbound|9080||ratings.default.svc.cluster.local",
"endpoints": [
{
"locality": {},
"lbEndpoints": [
{
"endpoint": {
"address": {
"socketAddress": {
"address": "172.33.100.2",
"portValue": 9080
}
}
}
}
]
}
]
}
- Endpoint 주소(예: 172.33.100.2:9080)는 ratings 서비스의 실제 IP입니다.
Sidecar는 이 주소를 찾아 트래픽을 라우팅합니다.
Endpoint는
서비스의 실제 IP로 트래픽을 전달합니다.
- Inbound는 집으로 배달된 우편을 열어 확인하는 과정이고, Outbound는 외부로 보낼 편지를 우체국(Sidecar)을 통해 처리하는 과정입니다. istioctl 명령어는 우체국 직원이 편지 분류를 확인하는 도구라고 생각하면 됩니다.
트래픽 라우팅은
우편 배달처럼 Inbound와 Outbound로 나뉘어 관리됩니다.
📌 핵심 요약
- 트래픽 라우팅: Inbound와 Outbound로 나뉘어 Sidecar가 관리합니다.
- Inbound Handler: 포트 15006 트래픽을 포트 9080 Cluster로 전달하며, 127.0.0.6을 사용해 Application Container로 보냅니다.
- Listener와 Cluster: Listener는 트래픽을 포트 9080으로, Cluster는 원래 목적지로 라우팅합니다.
- Outbound Handler: 로컬 트래픽을 Sidecar를 통해 상류(ratings)로 보냅니다.
- Route와 Endpoint: Route는 ratings Cluster로, Endpoint는 실제 IP(172.33.100.2:9080)로 트래픽을 전달합니다.
- 비유: 트래픽 라우팅은 우편 배달 과정처럼 단계별로 관리됩니다.