Istio DestinationRule 이해하기

이번에는 DestistationRule에 대해 알아보겠습니다. DestinationRule은 특정 서비스에 대한 트래픽 정책을 정의하는 중요한 리소스입니다. 이번에는 깊게는 다루지않고 간단하게 어떤식으로 사용되는지에 대해 써보고자합니다.

1. DestinationRule이란?

• 로드 밸런싱(LB) 방식 지정
• 연결 풀(Connection Pool) 설정
• 고장 감지(Fault Detection) 및 재시도(Retry) 정책 적용
• TLS 설정을 통한 보안 강화
• 서브셋(Subsets) 설정을 통한 서비스 버전 관리
• 백엔드 장애 발생 시 트래픽 분산 및 대체 경로 제공

DestinationRule은 일반적으로 VirtualService와 함께 사용되며, VirtualService가 트래픽의 라우팅을 담당한다면, DestinationRule은 해당 트래픽의 처리 방식을 결정합니다. 그렇기에 내가 Canary나 BlueGreen등 해당 배포방식을 적용하기 위해서는 DestinationRule도 같이 적용해야 좀더 무중단배포, 안정성있는 배포가 가능합니다.

2. DestinationRule yaml 작성

yaml은 아래와 같이 작성합니다.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

• host : 트래픽을 전달할 host명입니다. k8s의 실행경우 k8s dns 주소를 넣어주면 됩니다. 해당

• trafficPolicy : 서비스에 대한 트래픽 제어 정책을 정의하는 곳으로, 주요 설정은 다음과 같습니다.

  • loadBalancer: 트래픽을 백엔드 서비스로 전달할 때의 부하 분산 방식을 설정합니다.
    • ROUND_ROBIN: 요청을 백엔드 인스턴스에 순차적으로 분산합니다
    • LEAST_CONN: 연결이 가장 적은 백엔드 인스턴스를 선택합니다.
    • RANDOM: 무작위로 백엔드 인스턴스를 선택합니다.
    • PASSTHROUGH: 부하 분산 없이 요청을 그대로 전달합니다.

• subset : 버전별로 트래픽을 나누어 적용할 수 있도록 서브셋을 정의합니다. 예를 들어, v1과 v2 버전의 서비스가 있을 때, 특정 트래픽을 v1으로만 전달하도록 설정할 수 있습니다. 이를 통해 A/B 테스트, Canary Deployment 등을 수행할 수 있습니다.

더 자세한 옵션은 https://istio.io/latest/docs/reference/config/networking/destination-rule/ istio 공식홈에 자세하게 설명이 되어있습니다.

2. DestinationRule을 통한 Traffic 분산처리 해보기

테스트를 위한 application 배포는 Istio 공식홈에서 제공하는 bookInfo를 이용합니다.

$ wget https://raw.githubusercontent.com/istio/istio/release-1.25/samples/bookinfo/platform/kube/bookinfo.yaml
$ kubectl apply -f bookinfo.yaml

배포가 완료되면 아래와같이 reviews -v1,v2,v3 외 3가지 application이 배포가 된 모습을 볼수 있다.

여기서 reviews 에 대한 Traffic을 분산해보고자 한다.

트래픽을 분산한기 위해 먼저 해당 deployment의 레이블을 봐야한다. DestinationRule에서는 subset을 이용하여 트래픽 분산처리 즉 라벨로 분산처리가 가능하기때문이다. 그렇기에 먼저 deployment의 라벨을 보도록 하자

• review-v1

• review-v2

• review-v3

v1,v2,v3을 구분할 수 있는 방법은 version을 키로 하여 v1,v2,v3의 값으로 지정하여 DestinationRule을 작성하는것이다.

이번엔 DestinationRule을 작성해서 배포해보자

저는 istio가 버전이 1.18버전이라 DestiantionRule 버전이 networking.istio.io/v1alpha3 입니다. 다만.. 버전업 된 istio에서는 networking.istio.io/v1을 사용합니다.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
  namespace: istioexample
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

해당yaml을 sample-destination.rule.yaml으로 저장 후 배포를 해보고 get으로 해당 DestiantionRule이 배포가 잘 되었는지 확인을 해보자

$ kubectl apply -f sample-destinationrule.yaml
$ k get destinationrules.networking.istio.io
NAME      HOST      AGE
reviews   reviews   5m20s

이후 review 서비스들의 버전들을 분리하는 방법을 지정했기에 virtualservice를 업데이트해 트레픽을 v2와 v3으로만 이동시켜보자 이동을 위해 virtualservice,gateway를 작성한다. (위와 같이 istio가 버전이 1.18버전이라 Gateway, Virtualserivces 버전 networking.istio.io/v1alpha3 입니다. 다만.. 버전업 된 istio에서는 networking.istio.io/v1을 사용)

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: review-gw
spec:
  selector:
    istio: ingresesgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: http
    hosts:
    - reviews.example.com

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews.example.com
  http:
  - match:
    - headers:
        end-user:
          exact: sungwoo
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

v1은 작성이 안되어있으므로 v1으로는 Traffic이 흐르지않는다. 그리고 subset으로 지정한 v2와 v3가 있으며 v2는 headers에

end-user: sungwoo 라는 Key가있어야 v2로 움직일 수 있다.

curl로 한번 호출을 해보자 (호출시 /etc/host 에 reviews.example.com 을 Istio ingressGateway External IP를 넣고 진행하면 편리하다..)

 $ curl http://reviews.example.com/reviews/1 | jq

podName이 v3이다..

호출을 해보면 virtualservice의 v3로만 호출 되고 있는것을 알 수 있다. 이번엔 Header를 넣어 호출해보자

$ curl -H "end-user: sungwoo" http://reviews.example.com/reviews/1  | jq

podName v2이다.

이와 같이 DestinationRule을 이용해서 하나의 Kubernetes Service를 라벨기준으로 Subset으로 나눈뒤 VirtualService로 라우팅을 할 수 있다. 이방법을 이용하면 Canary 배포랑 BlueGreen등 트래픽을 관리할수있다.

3. 정리

DestinationRule은 기본적으로 Loadbalnace도 되어있고 그외에 lastConn이라던지 Random 알고리즘도 지원을 한다. 그 외에도 KeepAlive나 서킷브레이커 등 많은것들을 활용할수있는데 이부분에 대해서도 글을 추후에 작성하도록 해야겠다..