[K8S] 3-Tier 아키텍처 배포와 Rolling Update 실습

Rolling Update

서비스 운영 중에도 중단 없이 애플리케이션을 업데이트하고, 문제가 생기면 순식간에 이전 버전으로 되돌릴 수 있는 기능은 현대 인프라 운영에서 핵심적입니다. 쿠버네티스는 이를 아주 쉽게 구현할 수 있습니다.

이번 포스팅에서는 실제 서비스 환경을 가정한 3-Tier(Web-WAS-DB) 아키텍처를 구성하고, 쿠버네티스의 Rolling Update와 Rollback 기능을 실습해본 내용을 공유합니다.

테스트 환경 구성

전체 구조는 다음과 같습니다.

• Web Tier: Nginx (WAS로의 Reverse Proxy 역할)
• WAS Tier: http-echo (Replica=4, 서비스 가용성 확보)
• DB Tier: PostgreSQL
  • 다만, 이번 테스트는 hashicorp/http-echo 이미지를 사용한 간단한 테스트로, DB Pod는 올라오지만 WAS와의 연결은 없습니다.

Deployment YAML (WAS Tier)

WAS는 응답 시 어떤 Pod가 처리했는지 이름을 표시하도록 구성했습니다.

 1# ...
 2spec:
 3  replicas: 4
 4  strategy:
 5    type: RollingUpdate
 6    rollingUpdate:
 7      maxSurge: 1
 8      maxUnavailable: 1
 9  template:
10    spec:
11      containers:
12        - name: was-app
13          image: hashicorp/http-echo:latest
14          env:
15            - name: MY_POD_NAME
16              valueFrom:
17                fieldRef:
18                  fieldPath: metadata.name
19          args:
20            - "-text=Hello from WAS Tier (Pod: $(MY_POD_NAME))"
21# ...

실습 시나리오

서비스 상태 확인

서비스를 배포한 후, 브라우저나 터미널에서 접속해 봅니다. 저는 터미널에서 1초마다 접속해 내용을 출력하도록 했습니다.

1while true; do echo -n "[$(date +%H:%M:%S)] "; curl -s http://[Node-IP]:[Port]; sleep 1; done

응답하는 Pod의 이름이 달라지는 것을 볼 수 있습니다. 이는 쿠버네티스 서비스가 WAS Pod에 요청을 골고루 분배(로드밸런싱)하고 있기 때문입니다.

Rolling Update 실행

이제 WAS에서 업데이트를 실행해봅니다. 이 실습에서는 응답하는 문구를 Hello from WAS Tier에서 Hello from WAS Tier v2로 바꾸는 단순한 업데이트긴 하지만, 실제 서비스에서 소스코드가 바뀐 상황이라고 상상해봅니다. 😏

 1kubectl patch deployment was-deployment -n lab1-scale-out \
 2  --type='json' \
 3  -p='[
 4    {
 5      "op": "replace",
 6      "path": "/spec/template/spec/containers/0/args",
 7      "value": [
 8        "-text=Hello from WAS Tier v2 (Pod: $(MY_POD_NAME))",
 9        "-listen=:8080"
10      ]
11    }
12  ]'

명령어를 실행하고 k9s 또는 Pod 목록을 보면, 기존 Pod가 하나씩 종료(Terminating)되고 새 버전의 Pod가 하나씩 생성(ContainerCreating)되는 것을 실시간으로 확인할 수 있습니다.

p.s. 실습 중 아주 가끔 502 Bad Gateway가 뜨는 경우가 있었습니다. 이는 컨테이너가 뜨자마자 트래픽이 몰리거나, 종료되는 Pod가 너무 빨리 죽어버렸기 때문입니다. 이를 해결하려면 아래 두 가지를 설정해주어야 합니다.

1. Readiness Probe: 앱이 실제로 준비됐는지 쿠버네티스가 물어보고 준비된 Pod에게만 트래픽을 보냅니다.
2. preStop hook: 기존 Pod가 종료 신호를 받았을 때, 서비스 목록에서 삭제될 시간을 벌어주기 위해 일정 시간 종료를 유예하는 명령어를 지정합니다.

히스토리 확인 및 롤백

업데이트 후 문제가 발견되었다고 가정하고 이전 버전으로 되돌리는 과정도 진행해보았습니다.

1# 배포 이력 확인
2kubectl rollout history deployment/was-deployment -n lab1-scale-out
3
4# 즉시 롤백
5kubectl rollout undo deployment/was-deployment -n lab1-scale-out

명령어 한 줄로 서비스 중단 없이 즉시 이전 상태로 복구되는 모습을 볼 수 있었습니다.

마치며

이전에 토이프로젝트 수준에서 Docker Compose로 서비스를 구성하여 배포한 적은 여러 번 있었지만, 그때는 업데이트를 하려면 서비스를 내려야되는 아쉬움이 있었습니다.

그래서 이번 실습을 통해 쿠버네티스의 Rolling Update를 실제로 실행해보며 무중단 업데이트가 되는 것이 신기했고, 복잡한 스크립트 없이도 설정만으로 안전한 배포를 가능하게 해주는 유용한 도구인 것을 느꼈습니다.