3주차 (Ch5)

5장. 무중단 배포

Rolling Update 는 왜 서비스가 끊기는가

Rolling Update 는 설정 값에 따라 파드를 교체하는데, 이전 챕터에서는 50% 설정 값에 의해 절반만큼의 파드를 먼저 교체하고 나머지를 그 후에 교체하는 방식을 사용했다.

📌

Rolling Update 가 발생하는 순간 벌어지는 일

Rolling Update 의 철학은 새 Pod 가 Ready 상태가 될 때까지 기다린 다음에야 기존 Pod 를 내리고, 그 사이 서비스가 두 버전 모두에 트래픽을 분배한다. 이 철학만 보면 잘 설계된 메커니즘이다.

하지만 여기서 발생하는 중단 지점은 Ready 의 개념과 실제 요청을 받을 준비가 된 상태의 개념이 다르다는 것이다.

  • readinessProbe 가 /health 에서 200 을 돌려주는 순간 Pod 는 Ready 상태가 된다.
  • Ready 상태인 Pod 가 첫 트래픽을 받을 때, 커넥션 풀 초기화나 캐시 워밍업이 끝나지 않았을 수 있다.

서로 다른 개념이 가져오는 큰 문제점은 검증 시점이다. Rolling Update 는 배포가 시작되자마자 신규 트래픽의 일부가 곧바로 새 버전으로 흘러간다. 새 버전의 상태를 전혀 고려하지 않으며, “10분 동안 서비스가 괜찮으면 트래픽을 받아야지” 같은 개념이 아예 존재하지 않는다.

이로써 배포와 동시에 트래픽을 받다 보니, 장애가 있는 버전이 배포되었더라도 롤백을 결정할 때에는 이미 장애가 발생한 이후가 된다. 게다가 롤백 과정도 이전 ReplicaSet 을 다시 띄우고 새 ReplicaSet 을 내리는 Rolling Update 방식이기 때문에, 실제로 기존 버전으로 트래픽이 완전히 복구되기까지 수십 초 이상 걸리며 그 사이 문제는 지속된다.

쿠버네티스 서비스를 외부에서 접근하기

Ingress 와 Gateway API

Ingress 와 Gateway API 는 궁극적으로 L7 계층에서 외부 트래픽을 클러스터 안의 Service 로 라우팅하는 공통 목적을 가진다.

⚠️

Ingress 의 한계

  1. 단일 리소스에 모든 걸 담아 역할 분리가 없다 Ingress 오브젝트 하나에 LB·IP·TLS 같은 인프라 관심사와 경로 라우팅 같은 애플리케이션 관심사가 섞여 있어, 데브옵스 조직과 개발 조직이 분리해서 관리할 수 없다.
  2. 과다한 어노테이션 사용 Ingress 스펙은 host + path 라우팅만 정의한다. 그 외 부가 내용(TLS 정책, 타임아웃, 리다이렉트 등)은 전부 컨트롤러별 어노테이션으로 관리한다.
  3. HTTP host/path 외에 빈약한 스펙 코어 스펙은 TCP/UDP/gRPC, 헤더 기반 라우팅, 트래픽 분할 등을 지원하지 않는다.

Gateway API 의 등장

Ingress 와 가장 큰 차이는 역할 기반 리소스 분리를 지원한다는 것이다.

각 역할이 분리되어 있어 역할에 맞는 리소스만 변경하면 된다. 또한 Gateway API 는 기본적으로 가중치 트래픽 분배를 지원하여 카나리·Blue/Green 배포 설정이 수월하다. Gateway API 는 쿠버네티스 1.27 이후 운영 레벨에서 사용이 권장된다.

📌

readinessProbe 와 HealthCheckPolicy

두 가지 모두 헬스 체크를 위해 동작하지만 통신하는 계층이 다르다.

  • readinessProbe 는 “이 Pod 를 Service 엔드포인트에 포함할지”를 kubelet 이 결정한다.
  • HealthCheckPolicy 는 “이 백엔드에 트래픽을 보낼지”를 로드밸런서가 결정한다.

둘 중 하나만 있어도 동작하지만, 외부 로드밸런서는 kubelet 의 판단을 신뢰하지 않기 때문에 로드밸런서 계층에서 직접 한 번 더 확인이 필요하다. 로드밸런서와 Pod 사이에 네트워크 구간이 있기 때문에, 그 구간까지 포함해 “진짜 요청이 가능한지” 확인한다.

무중단 배포 여정

Argo Rollouts 와 Blue/Green 전략

Argo Rollouts 외에도 Flagger 나 Istio 같이 비슷한 역할을 하는 도구들이 있다.

그중 ArgoCD 로 GitOps 를 구성했다면 가장 최적화된 통합을 지원하고, Argo Rollouts Controller 가 리소스를 저렴하게 사용한다.

Flagger 는 트래픽 분할을 직접 하지 않고 Istio·Gateway API·Nginx 등 다른 프로바이더에게 위임한다. 현재 프로젝트에서 Gateway API 로 연동은 되지만 Istio 없이는 기능이 제한적이다.

자주 언급되는 Istio 는 배포 도구가 아닌 서비스 메시이며, 트래픽 분할을 VirtualService 로 직접 할 수 있어 무중단 배포의 엔진이다. Flagger 와 조합하면 강력하지만, 그만큼 비싼 비용을 감당해야 한다(컨트롤 플레인이 기본 메모리 1GB 를 차지하는 편이다).

📝

배포 전략별 특징

  • Rolling Update 점진적으로 전환되지만 신규 버전에 장애 발생 시 일부 사용자가 영향을 받음
  • Blue/Green 즉시 전환·롤백이 가능하지만 리소스를 2 배로 사용
  • Canary 리소스 효율적으로 점진적 전환

Blue/Green 의 대표적 단점은 리소스 2배 사용이다. 현재 Deployment 의 replicas 가 1의 단위 수준이지만, 향후 서비스가 성장해 10의 자리 이상 리소스가 필요해지면 서버는 그 2배의 자원을 확보해야 한다. 예를 들어 20 개의 레플리카 배포를 위해 일시적으로 40 대를 허용할 수 있어야 한다.

Argo Rollouts 는 기존 Deployment manifest 를 삭제하고 Rollout manifest 로 구성을 변경해야 한다. 두 파일이 공존하면 ArgoCD 가 양쪽 모두에 배포하여 Pod 가 중복 생성된다.

현재 Argo Rollouts 로 Blue/Green 전환이 완료되어, 이제 배포 중에 사용자가 끊김을 느끼지 못하게 되었다. 새 버전이 완전히 준비된 상태로 올라오고 30초 동안 확인한 다음 한 번에 트래픽이 전환되며, 문제가 생기면 ReplicaSet 으로 즉시 되돌릴 수 있다. 기존 Rolling Update 의 한계였던 배포와 검증의 역할을 분리해서 관리하게 되었다.