IT/Istio

[Istio] Istio Service Mesh의 Inbound 트래픽 흐름에 대하여.

고슴도치 엔지니어 2022. 6. 28. 10:53

Istio Service Mesh(ISM)를 처음 접했을 때, 트래픽의 흐름이 어떤식으로 흘러가는지 파악하기 어려웠는데

 

지금까지 알게 된 내용들을 나름대로 정리 해보려 한다.

 

여기저기서 주워들은 지식들을 모아서 만든 자료이므로 틀린 부분이 있을 수 있어 이 글을 읽는 독자분들도 그 점을 인지하고 그저 참고용으로 사용하셨으면 합니다.

 

아래 내용은 GCP 기반 환경에서 해본 경험을 토대로 작성 되었습니다.

 

출처: https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh/

 

- Istio를 도입할 경우 기능상의 여러 장점을 얻을 수 있지만, 그만큼 복잡한 구조와 지연시간이 늘어나게 됩니다.

 

 

 

 


Inbound Traffic

 

1. istio-ingressgateway

- Kubernetes 클러스터에서 외부와 통신하기 위해 내부적으로 지원하는 "Ingress" 라는 오브젝트는 ISM을 도입하면 더 이상 사용 할 필요가 없는것으로 보임.

- 대신 외부와 통신하기 위해 CSP 에서 제공하는 L4 LB의 External IP를 프로비저닝 하여 가져오는 Load Balancer Type의 Service 인 istio-ingressgateway 를 사용하게 됨.

 

외부 IP를 가지고 있는 LB타입의 istio-ingressgateway 서비스

- istio-ingressgateway는 외부에서 클러스터로 접근하는 모든 통신의 단일 진입점으로 사용 된다.

- istio-ingressgateway라는 로드밸런서 타입 서비스는 컨트롤러로 동작하며 실제로는 istio-ingressgateway라는 이름의 Pod를 실행 시키게 된다. 이 Pod를 Describe 해서 보면 istio-proxy, 즉 envoy를 실행하고 있다.

 

Image: 부분을 살펴보면 asm 이미지 라는것을 알 수 있는데 asm은 GCP에서 제공하는 서비스형 ISM이다.

 

- 이 외에 다루게 되는 커스텀 리소스로 Gateway, VirtualService, DestinationRule 가 있다.

 

2. Gateway

gateway  yaml 예시

- Gateway는 이름에서 알 수 있듯 ISM에 들어오는 대문 역할을 한다. 위 one-gateway는 istio: ingressgateway라는 라벨을 가진 서비스, 즉 istio-ingressgateway에서 실행된다.

- Gateway는 가장 바깥에 있는 대문이므로 노출할 포트, 프로토콜, 호스트 정보 등을 가지고 있다. 

 

 

3. VirtualService

VirtualService yaml 예시

- VirtualService는 계층상Gateway와 쿠버네티스 Service 사이에 있는 오브젝트로 보여지며 Gateway로 들어오는 트래픽을 어떤 Service로 라우팅 할지 규칙을 정의하는 역할을 한다.

- 위 grafana 라는 이름의 VirtualService는 one-gateway와 연결되어 동작하며, /grafana로 들어오는 요청을 grafana라는 서비스(kube-dns 명명 규칙상 grafana.svc.default.local.cluster 가 생략된 표현)로 라우팅 해준다는 의미이다.

 

- GatewayVirtualServiceistio-ingressgateway가 생성하는 envoy Pod의 설정을 변경하는 ConfigMap 성향의 오브젝트라고 생각됨.

 

- 실제로 "istioctl pc routes [istio-ingressgateway pod명].istio-system" 명령어를 사용하면 다음과 같은 결과를 얻는다.

istio-ingressgateway Pod에 적용된 라우팅 규칙

 

여기까지만 해도 Service까지 트래픽이 전달되고 그 이후로는 우리가 익히 아는것 처럼 Pod로 요청이 전송되어 서비스가 제공되지만 Service 아래에 여러개의 Deployment(즉, Pod 그룹) 을 두고 버전 관리를 하고 싶다면 DestinationRule이 필요하다.

 

 

4. DestinationRule (Optional)

- DestinationRule은 Pod의 라벨에 따라 어디로 트래픽을 분산시킬지 정의한다.

grafana 서비스에 v1과 v2 두가지 버전이 존재

- 라벨링 기반으로 여러 Pod를 하나의 subsets로 묶어 트래픽을 제어하는 역할을 한다.

 

- trafficPolicy가 정의되어 있지 않으면 기본적으로 RoundRobin 방식으로 version: v1 라벨링이 되어 있는 Pod에 50%, version: v2 라벨링이 되어 있는 Pod에 50% 트래픽을 분산 해 준다.

 


Outbound Traffic

istio의 Outbound Traffic은 기본적으로 ALLOW_ANY 정책이 적용 되어 있어서.

Pod의 IP를 달고 서비스메시 바깥으로 나간다.

 

Outbound 지점을 한곳으로 모아주고 싶으면 아래 세가지 요소가 필요한데.

(Gateway, VirtualServcie, ServiceEntry)

 

이 세가지 요소에 대한 것은 추후 글에서 다루도록 하겠다.