쿠버네티스 nginx ingress 카나리 적용

쿠버네티스 상에서 카나리를 적용하는 (트래픽 제어) 형태는 서비스메시를 쓰는것이 공론화 되어있다.

대표적으로 이스티오 서비스메시.

현재 해외에서 서비스메시 대표격은 링커d를 CNCF가 밀어주는 모양.

회사에 자금이 좀 넉넉하다면 아예 nginx 서비스메시를 유료로 도입하는 것도 나쁘진 않을 것.

(SRE 요소로서, nginx LB랑 WAS에서 모든 트래픽적 SLI 를 집계하고 뽑아주니 차라리 이게 더 가성비가 좋을 수 있다.)

 

------------------

서비스 메시 단점으로, 바닐라 쿠버네티스 레이어를 덮게 되기에, 컨트롤패널 2군데를 관리해야 한다.

데브옵스 엔지니어의 관리 범위가 늘어난다는 단점, 에코 확장하면 그것도 봐야한다는 단점.

업무 가중이 심하므로 서비스메시는 가급적 안하고, nginx 인그레스에 카나리 도입 방법을 찾아본다.

 

1. https://intl.cloud.tencent.com/document/product/457/38413

Using Nginx Ingress to Implement Canary Release | Tencent Cloud

https://v2-1.docs.kubesphere.io/docs/quick-start/ingress-canary/ 

Canary Release based on Ingress-Nginx | KubeSphere Documents

 

- 여러개가 있다. nginx 인그레스로 카나리 추가하는거.

-그런데 어떻게 전부 예시들이 인그레스에 백엔드 포워딩 룰을 하나만 한건지.. 전부 하나씩만 테스트 했다.

- 이 테스트 표본으로는 실제 라이브/운영 환경의 인그레스 파일을 감당하고 도입하기엔 무리가 있다.

(일반적으로 인그레스 파일 하나에 로드밸런서 및 WAS 백엔드/포워드/업스트림 룰 여러개를 결정한다)

 

2. nginx 카나리 제약

- nginx 공홈에도 있듯, 카나리 룰 하나만 된다고 적혀있다

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/

Annotations - NGINX Ingress Controller

- 내용 중 제약사항 발췌

Known Limitations

Currently a maximum of one canary ingress can be applied per Ingress rule.

- 인그레스 룰 당 최대 1개의 카나리 인그레스 적용이 가능하다고 한다.

 

(예시)

원본 인그레스.yaml 

ㄴ/a -> a_서비스

ㄴ/b -> b_서비스

ㄴ/c -> c_서비스

 

카나리 인그레스.yaml

(요청 퍼센트 독립시행 확률 0~100. 지금은 10으로 가정)

ㄴ/a -> a'_서비스

ㄴ/b -> b'_서비스

 

위와 같이 yaml 구성해서 만들었을 때, /c 는 카나리가 없기에, 무조건 원본 룰만 적용.

카나리 인그레스는 테스트 결과, /a에 대해서만 카나리 룰이 적용됨.

/b는 최대 1개 적용 규칙에 의거해서, 원본 인그레스 룰에만 영향을 받음.

 

즉 카나리 룰당 최대 1개의 인그레스가 적용된다는 의미를, 다음과 같이 받아들이면

서비스메시가 없는 바닐라 쿠버네티스와 에코 조합으로 카나리 적용이 가능하다는 이론이 만들어진다.

 

(원본 ingress yaml,  카나리 a ingress yaml, 카나리 b ingress yaml, ......)

 

-------------------------------

(최신업뎃 7/1)

nginx 버전 최신. 카나리가 인그레스 오브젝트 단위가 아니라, 리스닝 룰 하나만 먹음. 실사용화 불가로 판단.

사유가 명확치는 않으나 nginx 버그 혹은 기능이 예상한 것과 같이 만들어지진 않은 것.

리스너 룰 하나로는 먹히니 부하테스트 환경 혹은 유입 채널을 격리시키고 싶을 때 사용하면 좋을 듯 하다 ㅇㅇㅇ