쿠버네티스 Ingress와 무중단 배포 전략 정리
1. Ingress 핵심 개념
1-1. Ingress란
- Ingress는 쿠버네티스 클러스터 외부 → 내부 서비스로 들어오는 HTTP/HTTPS 트래픽을 제어하는 API 객체
- 여러 서비스 앞에 서서 단일 진입점(Entry Point) 역할을 한다
- 도메인, 경로, TLS 설정 등을 한 곳에서 관리할 수 있어 복잡한 네트워크 구성을 깔끔하게 정리 가능
Ingress 자체는 “규칙을 적어둔 설정”이고, 실제로 트래픽을 처리하는 건 Ingress Controller다.
1-2. Ingress 주요 기능
-
로드 밸런싱
- 여러 서비스(또는 파드)로 들어오는 요청을 적절히 분산
- 부하를 나눠서 가용성과 성능을 유지
-
SSL/TLS 종료(Termination)
- HTTPS 처리(인증서, 암호화)를 Ingress에서 끝내고
- 백엔드 서비스는 HTTP로만 통신하게 해서 복잡도 감소
-
URL 경로 기반 라우팅
/api,/admin,/static같은 경로에 따라 다른 서비스로 라우팅- 하나의 도메인 아래에 여러 서비스를 붙이는 구조에 유리
-
호스트 기반 라우팅
api.example.com,admin.example.com같은 도메인별로 서비스 분리- 서브도메인 단위로 서비스 경계를 나누기 좋음
-
복잡한 라우팅 규칙
- 정규 표현식을 사용한 경로 매칭 등 세밀한 규칙 가능
- 트래픽 패턴에 따라 다양한 라우팅 전략 설정 가능
1-3. Ingress Controller
Ingress 설정만 있다고 끝나는 게 아니라, 이를 실제로 처리하는 Ingress Controller가 필요하다.
-
역할
- Ingress 리소스를 감시
- 설정이 바뀌면 자동으로 자기 내부 설정(Nginx 등)을 갱신
- 외부 트래픽을 받아서 규칙에 따라 적절한 서비스로 전달
-
대표 구현체
- NGINX Ingress Controller
- HAProxy Ingress
- Traefik
- 클라우드 벤더별 Ingress Controller(GKE, EKS 등)
정리하면
Ingress = 규칙 정의
Ingress Controller = 그 규칙대로 실제로 트래픽을 처리하는 프록시/로드밸런서
2. 쿠버네티스 배포 전략 (무중단 배포)
쿠버네티스는 애플리케이션을 서비스 중단 없이 업데이트하기 위한 여러 전략을 제공한다.
대표적인 방식:
- 롤링 업데이트 (Rolling Update)
- 블루-그린 배포 (Blue-Green)
- 카나리 배포 (Canary)
2-1. 롤링 업데이트 (Rolling Update)
쿠버네티스 기본 배포 방식.
- 새 버전 파드를 조금씩 올리고
- 기존 버전 파드를 조금씩 내리는 방식
- 항상 일정 수의 파드는 살아 있게 유지하면서 업데이트 진행
특징
- 서비스가 한 번에 내려가지 않으므로 가용성 유지
Deployment의spec.strategy설정으로 동작 제어- 문제가 생기면
kubectl rollout undo등으로 손쉽게 롤백 가능 - Ingress나 Service가 트래픽을 살아 있는 파드로 계속 분배하기 때문에 배포 중에도 서비스가 끊기지 않음
사용 포인트
- 일반적인 웹/백엔드 서비스 대부분에서 기본값처럼 사용하는 전략
- 특별히 트래픽 분리나 환경 이중화가 필요 없을 때 적합
2-2. 블루-그린 배포 (Blue-Green Deployment)
두 세트를 동시에 운영하는 방식.
- 블루(현재 운영 버전)
- 그린(새 버전)
흐름
- 블루 환경으로 전체 트래픽 처리 중
- 그린 환경에 새 버전 미리 배포 및 테스트
- 문제가 없으면 로드밸런서/Ingress/Service selector를 바꿔서 트래픽을 한 번에 그린으로 전환
- 문제 발생 시 다시 블루로 되돌리기만 하면 됨
특징
- 전환 시점은 짧지만, 그 전까지는 두 버전을 동시에 운영해야 하므로 리소스가 두 배 필요
- 전환 전, 새 버전을 충분히 검증할 수 있어 위험도가 낮음
- 롤백이 매우 단순하다(트래픽만 원래 환경으로 돌리면 끝)
사용 포인트
- 릴리즈 리스크가 크거나
- 배포 전 후를 명확하게 구분하고 싶은 경우
- 대규모 트래픽, 중요한 서비스 릴리즈에 적합
2-3. 카나리 배포 (Canary Deployment)
새 버전을 일부 트래픽에만 먼저 적용해 보는 방식.
흐름
-
기존 버전(v1)이 대부분 트래픽을 처리
-
새 버전(v2)을 소량 파드로 띄움
-
Ingress/Service/로드밸런서 설정으로
- 예: 트래픽의 5%만 v2로 보내기
-
문제 없으면 비율을 10% → 30% → 50% → 100% 이런 식으로 점진적으로 늘림
-
문제 발견 시, v2로 가는 트래픽만 0으로 줄이면 사실상 롤백
특징
- 전체 서비스에 영향 주지 않고 소수의 사용자로 먼저 검증
- 점진적으로 확대하므로 장애 범위를 최소화
- 트래픽 비율, 특정 사용자 그룹, 특정 경로/헤더 기준으로 분리하는 등 다양한 전략 가능
사용 포인트
- 신규 기능 검증, 실험적 변경 사항
- 실서비스 트래픽으로 안정성을 확인하고 싶은 경우
- A/B 테스트나 단계적 롤아웃에 적합
정리
-
Ingress
- 클러스터 외부 트래픽을 내부 서비스로 라우팅하는 진입점
- 하나의 엔드포인트에 도메인/경로/SSL 등을 모아서 관리
- 실제 트래픽 처리는 Ingress Controller가 담당
-
배포 전략
- 롤링 업데이트: 기본 무중단 배포, 점진적 교체
- 블루-그린: 두 환경 동시에 운영 후 한 번에 스위칭
- 카나리: 일부 트래픽만 새 버전으로 보내며 단계적으로 확대
Ingress와 배포 전략을 묶어서 설계하면
“어떤 버전에 얼마나 트래픽을 보낼지”, “어떻게 롤백할지”를 네트워크 레벨에서 깔끔하게 컨트롤할 수 있다.
개발자 희망자