[Service Mesh] 5. Istio Traffic Management (2) - Gateway & Service Entry

Service Mesh 알아보기

1. [Service Mesh] 1. Service Mesh란?
2. [Service Mehs] 2. Envoy Proxy
3. [Service Mesh] 3. Istio?
4. [Service Mesh] 4. Istio Traffic Management (1) - Virtual Service & Destination Rule
5. [Service Mesh] 5. Istio Traffic Managerment (2) - Gateway & Service Entry
6. [Service Mesh] 6. Service Monitoring in Istio
7. [Service Mesh] 7. Logging

---

저번 글에서는 Istio의 Virtual Service와 Destination Rule을 통한 요청 라우팅에 대해 알아보았습니다. 앞서 구축했던 예제들은 모든 컴포넌트가 쿠버네티스 클러스터 내부에 존재한다면 문제가 없지만 실제로는 그렇지 않은 경우도 존재합니다. 예를 들면 외부에 존재하는 DB에 접근하는 것과 같이 외부 컴포넌트와도 상호작용이 발생하게 됩니다. 이번 글에서는 Istio에서 어떤 방식으로 외부 컴포넌트와의 상호작용이 처리되는지 알아보도록 하겠습니다.

 

 

---

Istio Gateway

Istio에서 외부의 모든 요청에 대한 입구는 Istio Gateway를 통해 구성됩니다. Istio Gateway는 HTTP 및 TCP 서비스를 노출시키며 TLS와 같은 보안 관련 기능도 제공합니다. 보통 Istio Gateway는 쿠버네티스의 Load Balancer Service와 함께 구성됩니다. EKS나 GKE를 이용하는 경우, 클라우드 플랫폼의 L4 로드 밸런서가 생성되어 외부에서 접근할 수 있는 Public IP가 부여됩니다.

생성된 로드밸런서가 요청을 받으면  Istio Gateway에 요청을 위임하고 이전 글에서 설명했던 요청 라우팅을 통해 적절한 서비스에 전송됩니다. Istio Gateway와 Kubernetes Ingress가 비슷한 기능을 하고 있는 것처럼 생각할 수도 있지만 Ingress는 자체적으로 구성된 라우팅 규칙을 가지는 반면에 Gateway는 라우팅 규칙이 내장되어 있지 않고 Virtual Service를 통해 이루어진다는 차이점이 존재합니다.

---

Gateway Tutorial

앞서 사용했던 server application를 사용해서 Gateway에 대한 테스트를 진행해보겠습니다.

1. Gateway 구성

먼저 Gateway에 대한 설정을 진행하겠습니다. 

Gateway

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: web-gateway
spec:
  selector:
    app: istio-ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*.greeting.com"

위의 코드에서 selector는 gateway를 위한 gateway-controller를 지정하는 역할을 합니다. 이번 예제에서는 Istio에서 기본적으로 설치되는 Istio-ingressgateway를 사용하도록 지정하였습니다. 위의 메니페스트를 적용하면 Host의 하위 도메인이 greeting.com이며 80번 포트로 들어오는 HTTP 트래픽을 메시로 받게됩니다.

---

2. Virtual Service 구성

Gateway에서 외부 트래픽을 받았다면 이를 메시 내부에서 라우팅하기 위한 Virtual Service를 정의해야 합니다. 이번에는 v1/v2 subset에 대해 80:20의 가중치 비율로 라우팅 되도록 설정하겠습니다.

Virtual Service

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: webservice-vs
spec:
  hosts:
  - webservice
  - webservice.greeting.com
  gateways:
  - web-gateway
  http:
  - route:
    - destination:
        host: webservice
        subset: v1
      weight: 80
    - destination:
        host: webservice
        subset: v2
      weight: 20

처리하고자 하는 게이트웨이를 gateways: 필드에 추가하고, gateway에서 정의했던 host와 일치하거나 일부에 속하도록 호스트 목록을 추가합니다. 

---

3. Traffic Management Test

위의 Gateway, Virtual Service과 Server Application을 통해 구축한 어플리케이션을 테스트해보겠습니다. 저는 Minikube를 사용했기 때문에 Cloud Provider에서 제공해주는 것과 같이 Load Balancer에 External IP를 할당할 수 없습니다.

 

External IP가 Pending 상태이다.

 

 

하지만 minikube service istio-ingressgateway -n istio-system을 통해 외부에서 이 서비스에 접근할 수 있도록 해줍니다.

 

Minikube Service

 

우리가 설정한 Gateway는 80 포트에 대해 열려있기 때문에 이에 해당하는 http://192.168.64.2:30829로 접근을 시도하면 됩니다. 마지막으로 Gateway에서 Host 설정으로 하위 도메인이"greeting.com"이어야 합니다. 하위 도메인을 설정할 수는 없지만 gateway에서는 헤더에 존재하는 Host 필드를 확인하기 때문에 이를 추가해서 요청을 보내도록 하겠습니다. (10번의 요청 결과를 output.txt에 저장하는 shell script를 이용했습니다.)

Shell Script

#!/bin/bash

for num in `seq 1 10`
do 
    curl -v -HHost:webservice.greeting.com http://192.168.64.2:30829/ | tail -1 >> ~/output.txt
done

 

Output
Virtual Service에서 가중치를 80:20으로 설정했기 때문에 10번의 요청을 보내면 8번의 v1과 2번의 v2이 응답됩니다. 

➜  ~  tail -f output.txt
 version : 1.0 
 version : 2.0 
 version : 1.0 
 version : 1.0 
 version : 1.0 
 version : 2.0 
 version : 1.0 
 version : 1.0 
 version : 1.0 
 version : 1.0 

 

주의할 점은 Gateway 설정이 추가된 Virtual Service를 구성할 때, gateways: 필드에 mesh 키워드가 없다면 외부 요청이 아닌 서비스 메시 내부적으로 발생하는 서비스에 대해서는 Virtual Service가 적용되지 않게 됩니다. 따라서 위의 설정에서 mesh 키워드를 추가하여 구성해야 합니다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: webservice-vs
spec:
  hosts:
  - webservice
  - webservice.greeting.com
  gateways:
  - web-gateway
  - mesh
  http:
  - route:
    - destination:
        host: webservice
        subset: v1
      weight: 80
    - destination:
        host: webservice
        subset: v2
      weight: 20

---

Outbound Traffic

지금까지 Istio Gateway를 통해 외부 요청에 대한 처리 방법을 알아보았습니다. 하지만 서비스를 운영하면서 클러스터 외부의 서비스에 엑세스 해야하는 경우는 분명 발생합니다. 기본적으로 Istio는 외부 서비스에 접근하는 시도를 제한하지 않지만, 보안과 같은 이슈로 인해 Outbound 트래픽에 대해 제어할 필요가 분명 존재합니다.

문서를 참고하면 Istio는 outbound 트래픽에 대해 2가지 정책을 지원합니다. 기본 값인 ALLOW_ANY는 메시에 등록되지 않은 서비스라도 처리되는 것을 의미하고, REGISTRY_ONLY는 등록되지 않은 서비스라면 block 되는 정책을 의미합니다. ALLOW_ANY는 요청이 처리되긴 하지만 등록되지 않은 서비스는 프록시를 거치는 것이 아니라 어플리케이션(Pod) 네트워크에서 바로 처리됩니다.

 

Naver 접속 가능 확인 (ALLOW_ANY)

 

이와 반대로 Istio의 ConfigMap 중 outbound 설정을 REGISTRY_ONLY로 변경한 후 다시 테스트하면 접근할 수 없다는 결과를 보여줍니다.

Service Entry

물론 메시 내부의 서비스를 등록하는 것처럼 메시 외부의 서비스를 registry에 등록하는 방법도 존재합니다. 이런 기능을 담당하는 방법을 Service Entry라고 합니다. ALLOW_ANY 모드에서도 분명 외부로의 요청은 가능하지만 트래픽 관리는 불가능합니다. 하지만 Service Entry를 통해 서비스를 등록하면 Sidecar Proxy를 통해 외부로 요청이 보내지고 이로 인해 서비스 메시는 트래픽 관리를 수행할 수 있습니다.

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: naver
spec:
  hosts:
  - www.naver.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS
  location: MESH_EXTERNAL

간단하게 설명하면 서비스에 대한 host, port를 설정하고 resolution을 통해 address 조회 방법을 정의합니다. 위의 설정은 DNS 기반을 사용하였고 정적으로 구성할 수도 있습니다. location은 서비스의 위치를 나타내고 naver.com은 메시 외부에 존재하기 때문에 MESH_EXTERNAL로 설정하였습니다. 

---

Egress Gateway

Service Entry를 통해 외부 서비스에 대한 제한을 둘 수는 있지만, 사용 가능한 외부 서비스에 대해서는 메시 내부의 모든 서비스가 접근할 수 있습니다. 하지만, 외부 트래픽에 대한 인증 규칙이나 권한에 대한 검사를 위해 Ingress Gateway와 같이 외부로 나가는 모든 요청이 거치는 구성 요소가 필요합니다. 이를 위해 Istio에서는 Egress Gateway를 정의합니다.

Egress Gateway

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: naver-egressgateway
spec:
  selector:
    app: istio-egressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "www.naver.com"

Egress Gateway에서 받은 요청에 대해 라우팅 규칙을 정의하는 Virtual Service도 생성하겠습니다.

Virtual Service

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: naver-egress-gateway
spec:
  hosts:
  - www.naver.com
  gateways:
  - naver-egressgateway
  - mesh
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-system.svc.cluster.local
        port:
          number: 80
      weight: 100
  - match:
    - gateways:
      - naver-egressgateway
      port: 80
    route:
    - destination:
        host: www.naver.com
        port:
          number: 80
      weight: 100

위의 Virtual Service는 www.naver.com에 관한 모든 요청을 처리하게 됩니다. mesh(sidecar proxy)에서 발생하는 요청은 istio-egressgateway로 라우팅되고, egressgateway에 관한 요청은 Service Entry에서 등록한 서비스 포트 및 호스트와 일치하기 때문에 sidecar proxy를 거쳐 www.naver.com으로 라우팅 됩니다. 즉, www.naver.com로 나가는 모든 요청이 egress-gateway를 거쳐 나가게 되며 이를 통해 외부 연결을 모니터링하기에 용이한 환경을 구축할 수 있습니다.

 

이번 글에서는 Istio Ingress를 통한 외부 요청에 대한 처리 방법과 Egress Gateway & Service Entry를 통한 외부 서비스 요청 제어 방법에 대해 알아보았습니다. 다음 글에서는 Istio 에서는 애플리케이션 메트릭을 어떻게 수집하는지에 대해 알아보도록 하겠습니다.

블로그에 사용된 모든 예제는 Github에서 확인하실 수 있습니다.

---

참고자료

• Istio Document - Gateway
• 아리수님의 블로그
• Istio로 시작하는 서비스 메시