[이스티오] Istio Envoy AccessLog 살펴보기

기본적으로 Envoy AccessLog는 IP주소를 기반으로 생성된다.

 

한 번의 통신이 발생 했을 때 통신의 주체의 각 Envoy가 로그를 생성하기 때문에 2개의 로그가 만들어진다.

 

이때 생성 된 로그의 IP 주소가 깔끔하게 나오는 게 아니라 매우 난해하게 생성된다.

 

로그 내 필드와 실제 로그를 분석해 보면서 알게 된 Upstream, DownStream에 대해 정리해보겠다.

 

UpStream? DownStream?

두 개념은 트래픽의 방향성이 중요하다.

 

일반적으로

UpStream이란 클라이언트에서 목적지로의 데이터 트래픽을 의미하고,

Outbound는 서버에서 요청지로 보내는 데이터 트래픽을 의미한다.

 

Envoy에서는

UpStream이란 Envoy에게 요청을 받고, 응답을 보내주는 호스트 즉, 서버를 의미하고,

DownStream이란 Envoy에게 요청을 보내는 호스트 즉, 클라이언트를 의미한다.

 

예시 로그를 살펴보자

정리에 활용한 로그는 curl 어플리케이션 Pod에서 httpbin 어플리케이션 Pod으로 요청을 보냈을 때 생성된 두 로그 예시이다.

https://istio.io/latest/docs/tasks/observability/logs/access-log/

 

눈으로 보여야 이해가 빠르기 때문에 통신 과정을 그림으로 표현해봤다.

 

 

통신 과정에서 생성된 curl 측의 envoy가 생성한 로그 예시이다.

$ kubectl logs -l app=curl -c istio-proxy
[2020-11-25T21:26:18.409Z] "GET /status/418 HTTP/1.1" 418 - via_upstream - "-" 0 135 4 4 "-" "curl/7.73.0-DEV" "84961386-6d84-929d-98bd-c5aee93b5c88" "httpbin:8000" "10.44.1.27:80" outbound|8000||httpbin.foo.svc.cluster.local 10.44.1.23:37652 10.0.45.184:8000 10.44.1.23:46520 - default

 

다음으로 httpbin 측의 envoy가 생성한 로그 예시이다.

$ kubectl logs -l app=httpbin -c istio-proxy
[2020-11-25T21:26:18.409Z] "GET /status/418 HTTP/1.1" 418 - via_upstream - "-" 0 135 3 1 "-" "curl/7.73.0-DEV" "84961386-6d84-929d-98bd-c5aee93b5c88" "httpbin:8000" "127.0.0.1:80" inbound|8000|| 127.0.0.1:41854 10.44.1.27:80 10.44.1.23:37652 outbound_.8000_._.httpbin.foo.svc.cluster.local default

 

위 로그에서 현재 정리하고 있는 주제인 IP 주체를 찾아보도록 하겠다.

 

공식 문서에서 제공하고 있는 로그 필드와 예시 로그에서 나타난 값을 정리한 테이블에서

IP와 관련된 내용만 가져와봤다.

Log operator

access log in curl

access log in httpbin

\"%UPSTREAM_HOST%\"	"10.44.1.27:80"	"127.0.0.1:80"
%UPSTREAM_CLUSTER%	outbound|8000||httpbin.foo.svc.cluster.local	inbound|8000||
%UPSTREAM_LOCAL_ADDRESS%	10.44.1.23:37652	127.0.0.1:41854
%DOWNSTREAM_LOCAL_ADDRESS%	10.0.45.184:8000	10.44.1.27:80
%DOWNSTREAM_REMOTE_ADDRESS%	10.44.1.23:46520	10.44.1.23:37652

 

처음 분석을 할때 필드명들이 매우 매우 난해했었다.

 

나름대로 먼저 이해했던 의미를 정리해보자면,

LOCAL: 현재 관점에서 통신 주체 중 자신

REMOTE: 현재 관점에서 통신 주체 중 상대방

이다.

 

이 의미를 곱씹으며 로그를 분석해보겠다.

 

UPSTREAM_CLUSTER

UpStream Cluster란 Envoy에서 요청을 보내는 호스트 모임으로,

예시 로그에선 요청을 보내는 curl 측의 Envoy에선 목적지인 httpbin으로의 outbound가 명시되고,

요청을 받는 httpbin 측의 Envoy에선 내부로의 inbound가 명시된다.

 

UPSTREAM_HOST

Envoy에게 요청을 받는 목적지(서버)를 의미한다. 즉, httpbin 측 Envoy의 IP를 의미한다.

 

httbin 로그에서는 httpbin app이 요청을 받기 때문에 localhost 주소를 사용한 것을 확인할 수 있다.

 

UPSTREAM_LOCAL_ADDRESS

UpStream 서버로 요청을 보낸 Source의 IP 주소를 의미한다.

 

요청의 주체인 Envoy는 Pod 내의 컨테이너 즉, 사이드카 형태로 존재하기 때문에

curl Pod의 IP 주소와 동일하지만 포트가 다르다.

 

여기서, httpbin 로그에서는 127.0.0.1:41854 인 것을 확인할 수 있는데

이는 로컬 호스트가 UpStream 서버 자체이기 때문에 localhost 주소를 사용한다.

 

DOWNSTREAM_LOCAL_ADDRESS

클라이언트로부터 요청을 받은 Envoy의 IP 주소를 의미한다.

 

- curl 로그

여기서 굉장히 이해가 난해했다.

 

Envoy는 proxy로 클라이언트의 요청을 낚아채서 대신 전달해주는 역할을 한다.

 

즉, 클라이언트(curl)은 httpbin의 Service로 요청을 하게 되고,

Envoy는 해당 요청을 낚아채서 httpbin Service에 빙의한 채 로그를 생성한다.

(여기서 서비스는 쿠버네티스 Service를 찾아보면 된다)

 

그렇기 때문에 클라이언트(curl)의 요청을 받은 httpbin Service(Envoy)의 주소이기 때문에

httpbin Service의 10.0.45.184:8000가 기록된다.

 

- httpbin 로그

받은 요청의 목적지인 httpbin app을 가리키는 주소지만

역시 envoy가 낚아채 로그를 생성했다.

 

DOWNSTREAM_REMOTE_ADDRESS

Envoy로 요청을 보낸 클라이언트의 IP 주소를 의미한다.

 

curl 로그

역시 요청의 클라이언트는 curl이기 때문에 curl Pod 내부에서 curl -> envoy에서의 curl 주소이다.

 

httpbin 로그

httpbin 측 Envoy로 요청을 보낸 curl 측 Envoy의 IP 주소이다.

 

 

통신 흐름 정리

- curl Envoy

1. Slepp app의 외부로의 요청을 Envoy가 낚아챈다.

2. Pod 외부로의 요청을 전달해야하기 때문에 outbound 통신이 된다.

3. httbin Service로의 요청을 낚아 챈 것이기 때문에 curl app(10.44.1.23:46520)에서 httpbin Service(10.0.45.184:8000)로의 요청을 Envoy(10.44.1.23:37652)가 전달한다.

4. 여기서 요청의 최종 목적지는 httpbin app(10.44.1.27:80)이다.

 

- httpbin Envoy

1. 최종 목적지를 httpbin app(10.44.1.27:80)으로 하는 요청이 들어와 Envoy가 낚아챈다.

2. Pod 내부의 httpbin으로 요청을 전달해야하기 때문에 inbound 통신이 된다.

3. 그래서 목적지(UpStream Host)를 httpbin app의 로컬 주소(127.0.0.1:80)로 한다.

4. 즉 10.44.1.23:37652 에서 요청을 받은 httpbin Envoy가 41954포트를 통해 내부의 80포트(httpbin app)로 요청을 전달한다.

 

 

용어가 익숙치 않은 상태에서 분석하다보니 시간도 오래 걸리고 많이 헤맸던 것 같다.

 

요청을 낚아채 전달하고, 로그를 생성하는 주체인 Envoy 관점에서 생각하는 것이 꿀팁이라고 생각한다.