클라우드 개발자 앙몬드

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. nginx 카나리 제약

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

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

- 내용 중 제약사항 발췌

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 버그 혹은 기능이 예상한 것과 같이 만들어지진 않은 것.

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

간혹 AWS APIGW -> EKS Nginx NLB 504 타임아웃이 발생함.

전체 비율 대비로는 굉장히 적은 개수여서 무시가 가능.

이 경우 EKS Nginx 액세스 로그는 하나도 없어서, Nginx 504는 나오지 않았고,

APIGW C.W 에서만 504 에러가 나옴. 엔드포인트 타임아웃으로 ㅇㅇ

솔루션 : APIGW에 Retry를 줄 것을 권장함. 매니지드가 고가용이긴 하지만 100%로 보기는 어렵기에 ㅇㅇ 굳

https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/

조금 유의할 사항으로, 파드 상태와 파드 내부를 구성하는 컨테이너의 상태는 다르다는 것을 기억하자굳

sum(kube_pod_status_phase{namespace=~".*", phase="Pending"})
# 쿠버 파드 상태 페이즈. 펜딩이 지속되면, 워커노드를 못찾았거나 노드 리소스가 없거나.. 혹은 볼륨 미스매치.
# 파드의 펜딩 걸리는 사유는 대개 노드에 파드를 배치시키지 못할 때 발생한다 ㅇㅇ

sum(kube_pod_status_phase{namespace=~".*", phase!="Running", phase!="Pending"})
# 컨테이너 내부 상태중 Run / Pend가 아닌 애들은 전부 Fail로 취급하였음
# kubectl events로 어느정도 비벼볼 수 있는 메트릭 쿼리가 있을 것으로 예상되나, 현재는 못찾았음
# 해당 부분은 딥 다이브 필요해보임 굳

https://kubernetes.io/ko/docs/concepts/services-networking/service/

인그레스 진입점을 nginx ingress controller로 만든다.

쿠버프록시 서비스 타입은 ExternalName으로 만들고, 그 외부명은 클러스터 FQDN으로 지정한다.

이 FQDN이 실제 어플리케이션으로 진입해 들어가는 서비스의 도메인이다.

현재는 NP타입 서비스를 EN타입에서 지정하여 테스트 완료된 상태.

근데, Nginx Ingress에는 백엔드 엔드포인트를 못찾는다고 징징대는게 그냥 무시할 것.

실제로 엔드포인트 컨트롤러를 통해 EP가 만들어지는 것은 아니기에.

신기한건, 헤드리스 서비스도 비슷한 방식인데, 이건 아예 nginx에서 포워딩을 못한다.

웃긴건 이 헤드리스서비스의 FQDN을 파드 내부에서도 찾지 못하는 현상.

따라서, 단일 인그레스 vs 크로스 네임스페이스  백엔드 포워딩하려면,  nginx-ingress & EN타입 서비스를 선택해야 함.

https://kubernetes.io/docs/concepts/services-networking/service/#headless-services