쿠버네티스(k8s)

[k8s] Kubernetes Canary 사용시 주의사항

curiousKidd 2025. 4. 11. 11:19
반응형

이번에 Kubernetes Canary 배포를 하면서 제일 크게 배운 내용 중 하나가 바로 이거였다.

"카나리 파드만 있고, 스테이블 파드가 하나도 없으면 왜 API 호출이 안되는가?"

처음에 진짜 의문이었다. 헤더에 X-Canary: true 붙이면 Canary Ingress로 가니까 Stable 파드 없어도 되는거 아닌가? 이렇게 생각했는데... 현실은 전혀 아니었다.


결론부터 말하면

NGINX Ingress 구조 상 Canary Ingress는 "보조"일 뿐이고 "메인"은 항상 Stable Ingress다.

  • Stable Ingress → 기본 처리 대상
  • Canary Ingress → 조건 맞을 때 일부 트래픽만 처리 (override)

Stable Ingress가 없는 상태에서는 Canary Ingress만 있다고 해도 트래픽 처리 안 됨.

이유는 NGINX Ingress Controller가 config를 생성할 때 Stable Ingress 기준으로 처리 흐름을 만들기 때문.


정리하면 동작 원리는 이런 식

  1. 클라이언트가 요청 보냄
  2. NGINX Ingress Controller가 조건 판단
  3. 조건 만족 → Canary Ingress 타서 Canary Service로 전달
  4. 조건 불만족 → Stable Ingress 타서 Stable Service로 전달

문제는?

  • Stable Service가 연결된 파드가 없으면
  • NGINX는 요청 전달할 곳이 없어서 에러 or 연결 실패 발생

→ Header에 X-Canary: true 있든 없든 Stable Ingress가 무조건 기본값으로 존재해야 함


그럼 Ingress를 Stable 하나만 두고, Service만 Stable/Canary로 나누면 어떻게 될까?

가능은 한 방식임.

대신 이건 NGINX 설정을 좀 세밀하게 컨트롤해야 함. 대표적인 방법은 Ingress Annotation이나 NGINX Snippet을 사용하는 것.

예시)

nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($http_x_canary = "true") {
    proxy_pass http://fortune-da-beta-canary-service;
  }

하지만 이 방식은 완전히 NGINX에 종속적인 구조라 Kubernetes 기본 Canary 방식이라고 보기엔 좀 어렵고, 운영 난이도도 올라감.


그래서 현실 Best Practice는?

  1. Stable Ingress + Stable Service + Stable Pod 최소 1개 유지
  2. Canary Ingress + Canary Service + Canary Pod 운영
  3. Canary 검증 끝나면 Stable Service가 Canary Pod를 바라보게 변경
  4. 필요하면 Ingress를 하나로 통합

핵심정리 다시 한번

구분 개념 설명

Stable Ingress 필수 항상 기본 처리 Ingress 역할
Canary Ingress 선택 조건 만족시 일부 트래픽 처리
Stable Service 필수 기본 파드 연결
Canary Service 선택 카나리 파드 연결

참고 자료


마무리

카나리 배포할 때 Ingress 구조를 잘못 이해하면 진짜 큰 장애나 운영 이슈로 연결될 수 있다.

특히 "카나리 파드만 남기고 Stable 파드를 다 지웠더니 API가 안들어온다?" 이건 구조상 당연한 현상임.

Canary Ingress는 주인공이 아니라 조연이라는 걸 꼭 기억하자.

반응형