[Istio] Dark Release

header 기반 라우팅

header 기반 라우팅으로, my-header: canary 라는 header가 존재하면 실험버전으로 보내고, 그 외에는 기존 버전을 보도록 정의하면 다음과 같다.

kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:
  name: webapp
  namespace: default
spec:
  hosts:
    - "*"
  gateways:
    - ingress-gateway-configuration
  http:
    - match:
      - headers:  # IF
          my-header:
            exact: canary
      route: # THEN
      - destination:
          host: webapp
          subset: experimental
    - route: # CATCH ALL
      - destination:
          host: webapp
          subset: original

 

gateway 설정을하고 다음과 같이 헤더를 추가하여 요청을 보내면 실험버전으로 요청이 갈 것이다.

$ curl -H "my-header: canary" localhost:{istio-ingressgateway nodeport}

 

브라우저에서 테스트할때는 크롬의 확장 프로그램 modify headers 와 같은 플러그인을 사용하자.

---

다크 배포

물론 실제 사용자가 위와 같이 카나리를 사용할 수는 없다. 앞서 얘기한 테스트 방법은 개발팀이 테스트할 때 유용할 것이다.

보통은 스테이징을 위한 클러스터를 별도로 마련하지만, 비용이 두배로 든다는 단점이 있다. 실제 라이브 환경과 똑같이 구성하기 때문이다. 다크 배포의 강점은 이미 라이브 클러스터에서 새 버전을 테스트하기 때문에, 테스트만 통과하면 라우팅만 다시 조절해서 새 버전을 배포할 수 있다는 것이다.

 

마이크로서비스에 대해서 다크 배포를 하려는 경우에도 동일하게 헤더기반 라우팅을 정의하면 된다. 

kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:
  name: a-service
  namespace: default
spec:
  hosts:
    - a-service
  http:
    - match:
        - headers:
            x-my-header:
              exact: canary
      route:
        - destination:
            host: a-service
            subset: risky
    - route:
        - destination:
            host: a-service
            subset: safe
---
kind: DestinationRule
apiVersion: networking.istio.io/v1alpha3
metadata:
  name: a-service
  namespace: default
spec:
  host: a-service
  subsets:
    - labels:
        version: safe
      name: safe
    - labels:
        version: risky
      name: risky

 

헤더 전파

다만, 브라우저에서 헤더를 넣어 테스트하려면, 해당 마이크로서비스까지 헤더를 전파해주어야 한다. 앞선 포스팅에서 정리하였듯이, Istio는 헤더를 자동으로 전파해줄 수는 없다.