[Kubernetes] 롤링 업데이트 개념

쿠버네티스에서 롤링 업데이트

쿠버네티스(Kubernetes)에서 롤링 업데이트(Rolling Update)는 애플리케이션을 중단 없이 점진적으로 새 버전(이미지, 설정 등)을 배포하는 방법을 의미함.

이를 통해 서비스 가용성을 유지하면서 새로운 버전을 배포할 수 있음.

 

롤링 업데이트의 기본 개념

1. 점진적 배포(Gradual Deployment)
기존 파드를 전부 내려버리고 새 파드를 한 번에 띄우는 방식(“빅뱅” 방식)이 아닌, 기존 파드와 새 파드를 일정 비율/순서대로 교체해 나가는 배포 방식임.

 

2. 무중단 서비스(Zero-downtime)
최대한 “무중단(Zero-downtime)”을 지향함.

기존 버전을 종료하기 전에 일부 새 버전을 먼저 올려서 트래픽을 대체하도록 함.

 

3. ReplicaSet / Deployment 컨트롤러
쿠버네티스에서 롤링 업데이트는 주로 Deployment(혹은 일부 경우 DaemonSet, StatefulSet 등) 리소스를 통해 구현됨.

Deployment는 파드의 Desired State를 정의하고, 이를 유지·관리하기 위해 ReplicaSet을 생성·업데이트·삭제함.

 

동작 메커니즘 - Deployment 및 ReplicaSet

1. Deployment 오브젝트

사용자가 Deployment를 정의할 때, 파드가 실행해야 할 이미지를 비롯해 환경 변수, 레플리카 수(Replicas) 등을 설정함.

Deployment는 이를 기반으로 ReplicaSet(이하 RS)을 생성하여, 원하는 개수(Replicas)의 파드를 기동 및 유지함.

 

2. 롤링 업데이트 시

사용자가 Deployment 스펙(spec)을 변경(예: 컨테이너 이미지 버전을 바꾸거나 환경 변수를 수정)하면,

쿠버네티스는 새 스펙을 반영하기 위해 새로운 ReplicaSet을 생성하고, 동시에 기존 ReplicaSet을 점진적으로 줄여 나가며, 새 RS를 점진적으로 늘림.

 

 

 

동작 메커니즘 - 단계별 롤링 업데이트

Deployment의 .spec.strategy.type이 기본적으로 RollingUpdate로 설정되어 있음.

이때 다음 파라미터를 통해 구체적인 업데이트 과정을 제어할 수 있음.

 

1. maxUnavailable

동시에 다운(down)될 수 있는 파드의 최대 개수(비율)임.

기본값은 25%이며, 이는 레플리카 개수가 4라고 가정하면 최대 1개의 파드가 다운되어도 된다는 의미임.

숫자(정수) 혹은 퍼센트 형태로 설정할 수 있습니다(1, 50% 등).

 

2. maxSurge

새 버전을 배포할 때, 기존 파드 수(Replicas) 대비 추가로 더 띄울 수 있는 최대 파드 수(비율)임.

기본값은 25%이며, 레플리카 4개 기준 최대 1개의 새 파드를 먼저 띄울 수 있다는 의미임.

maxSurge: 1이면 기존 파드가 전부 동작 중일 때, 1개 파드를 추가 생성하여 서비스 다운 없이 대체해 나갈 수 있음.

 

예를 들어, 레플리카 수가 4개이고 maxUnavailable: 1, maxSurge: 1로 설정되어 있다면, 최대 1개 파드가 다운되어도 되고, 동시에 최대 1개 파드를 더 띄울 수 있음.

따라서 실제로는 4 → 5(새 파드 1개 추가) → 3(기존 파드 2개 종료) → … 와 같은 단계별 과정을 통해 기존 파드와 새 파드가 점진적으로 교체됨.

 

동작 메커니즘 - 업데이트 시 발생하는 주요 프로세스

1. 새 ReplicaSet 생성

Deployment 컨트롤러가 새 스펙을 만족시키기 위해 새로운 ReplicaSet(예: my-deployment-<hash>)을 생성함.

 

2. 새 파드 생성

maxSurge 범위 안에서 새 파드를 생성함.

 

3. kube-scheduler를 통한 노드 할당

생성된 파드는 스케줄러에 의해 적절한 노드로 할당됨.

 

4. Readiness Probe

새 파드가 기동되면, 쿠버네티스는 Readiness Probe를 통해 파드가 “준비 완료(Ready)” 상태가 되었는지를 확인함.

파드가 Ready 상태가 되어야 Service의 엔드포인트(Endpoints)에 등록되어 실제 트래픽을 받을 수 있음.

 

5. 기존 ReplicaSet 줄이기

새 파드가 정상 가동되면, 기존 ReplicaSet의 파드 수를 점진적으로 줄이는 식으로 구 버전 파드를 제거함.

이때 구 버전 파드는 Ready 상태에서 제외되어 더 이상 트래픽을 받지 않게 되고, 최종적으로 파드가 종료됨.

 

6. 완료

새 ReplicaSet이 설정된 레플리카 수만큼 안정적으로 파드를 유지하면 롤링 업데이트가 완료됨.

구 버전을 담당했던 ReplicaSet은 Desired Replicas가 0이 되어 사용되지 않게 되며, 일정 시간이 지난 뒤 자동 정리되거나(Revision History Limit) 남겨 둘 수도 있음.

 

롤링 업데이트 장점

1. 무중단 배포(Zero-downtime)

애플리케이션을 중단하지 않고 새 버전을 교체할 수 있어, 서비스 가용성을 극대화할 수 있음.

 

2. 점진적인 검증(Gradual Verification)

새 버전을 일부 파드에만 배포해보고 문제 여부를 확인한 뒤 점차 확대 배포할 수 있음.

에러 발생 시 롤백을 빠르게 진행할 수 있음.

 

3. 쿠버네티스 자동화

쿠버네티스가 파드 생성·종료·상태 모니터링을 자동화해주므로, 운영자가 일일이 개입하지 않아도 안전한 배포가 가능함.

 

롤링 업데이트 단점

1. 배포 시간 증가

한 번에 모두 업그레이드하는 것보다 상대적으로 시간이 더 오래 걸릴 수 있음.

 

2. 애플리케이션 호환성 이슈

구 버전과 새 버전이 공존하는 동안 API 스키마나 DB 마이그레이션 등에서 호환성 문제가 발생할 수 있음.

 

3. 롤백 처리

업데이트 중 문제가 발견되어 롤백을 진행할 때, 이미 일부 구 버전 파드가 제거된 상태일 수 있으므로, 충분한 이중화와 로그 모니터링이 필요함.

 

주의사항 - Canary 배포와 Blue/Green 배포

1. Canary 배포

롤링 업데이트와 유사하지만, 아주 적은 수의 파드를 먼저 새 버전으로 전환해 트래픽 테스트를 해보고, 문제가 없으면 나머지 파드로 점차 확대 배포함.

Helm, Argo Rollouts 등의 도구를 사용해 canary 전략을 보다 세밀하게 설정할 수 있음.

 

2. Blue/Green 배포

롤링 업데이트를 대신해 “Blue(현재 버전)”와 “Green(새 버전)” 두 개의 독립된 환경(디플로이먼트)을 구축한 뒤, 트래픽 라우팅만 바꿔주는 방식을 쓸 수도 있음.

한 번에 버전을 전환하기 때문에 롤백도 간편하지만, 더 많은 리소스를 소모함.

두 버전이 동시에 떠 있어야 함.

 

주의사항 - Readiness Probe와 상태 검사

1. 배포 시나리오에서 핵심 요소

롤링 업데이트 중 새 파드가 “Ready” 상태에 도달하기 전에는 트래픽이 전달되지 않아야 하며, 이미 트래픽을 받고 있던 구 버전 파드는 정상적으로 종료 전까지 트래픽을 처리해야 함.

이를 위해 readinessProbe, livenessProbe, startupProbe 등을 적절히 설정해 파드가 실제로 정상 동작하는지를 확인해야 함.

 

2. 지연(Graceful Shutdown)

파드가 종료 요청을 받을 때, 애플리케이션이 처리 중인 요청을 정상적으로 마무리할 시간을 줘야 함.

이를 위해 terminationGracePeriodSeconds 값을 충분히 주고, SIGTERM 신호 처리 로직을 애플리케이션에 구현해야 함.

 

주의사항 - 리비전 히스토리 관리

쿠버네티스는 기본적으로 Deployment의 “리비전 히스토리(Revision History)”를 유지함.

.spec.revisionHistoryLimit 값을 통해 과거 ReplicaSet을 몇 개까지 남길지 설정할 수 있음.

이를 통해 필요 시 빠른 롤백이 가능함.

지나치게 많은 히스토리를 남겨두면 리소스가 불필요하게 차지되므로 적절한 관리가 필요함.

 

주의사항 - 모니터링 및 로그 확인

1. 모니터링 시스템 연동

롤링 업데이트가 수행되는 동안 CPU, 메모리, 트래픽, 에러율(HTTP 5xx, 4xx)을 실시간 모니터링해야 함.

 

2. 로그 분석

새 버전 파드와 기존 파드 모두 로그를 모아서, 에러 패턴이나 장애 징후 등을 재빠르게 파악해야 함.

 

3. 자동 롤백 조건

Argo Rollouts, Flagger 등 고급 배포 툴을 사용하면, 에러율이 일정 기준을 넘어서는 순간 자동으로 롤백하도록 구성할 수 있음.

 

롤링 업데이트 고급 전략

1. 충분한 Canary 테스트 후 롤링 업데이트

운영 트래픽의 일부만 새 버전으로 테스트한 뒤, 서비스 품질에 영향이 없음을 확인하면 롤링 업데이트에 들어가는 전략이 안전함.

 

2. DB 스키마 호환성 관리

구 버전과 새 버전이 동시에 DB를 사용해야 하는 경우, 스키마 호환성(Hybrid Schema) 전략을 미리 수립해야 함.

새 버전 배포 후에 DB 마이그레이션을 하는 방식, 혹은 DB 마이그레이션을 미리 수행해두고 구 버전도 새 스키마에서 동작 가능하도록 구성하는 식으로 중단 없는 배포를 실현함.

 

3. 네트워크 정책 및 트래픽 라우팅 확인

네트워크 폴리시(NetworkPolicy), Ingress 규칙, 서비스 메시(Service Mesh) 설정 등이 새 파드에도 동일하게 적용되는지 사전에 점검해야 함.

 

4. Capacity Planning(리소스 용량 계산)

maxSurge를 통해 추가 파드를 생성할 때, 노드 리소스가 모자라면 스케일 업(Scale Up)이 필요할 수 있음.

HPA(Horizontal Pod Autoscaler), Cluster Autoscaler 등과 연동해 “서비스 운영 중 배포”와 “오토스케일링”이 충돌하지 않도록 잘 계획해야 함.

 

정리

쿠버네티스의 롤링 업데이트(Rolling Update)는 무중단 서비스 제공을 목표로, 기존 파드와 새 파드를 점진적으로 교체해 가는 배포 방식임.

Deployment 오브젝트와 ReplicaSet을 통해 새로운 버전의 파드를 생성·확인(Ready) 후, 기존 파드를 단계적으로 줄여나가는 과정을 자동화함.

maxUnavailable, maxSurge 등의 파라미터를 통해 한 번에 교체할 파드의 개수를 제어할 수 있음.

구 버전 파드와 새 버전 파드가 일시적으로 공존하기 때문에, 애플리케이션 버전 호환성(특히 DB, API 스키마)과 모니터링, 로그 분석 등을 철저히 수행해야 함.

필요에 따라 Canary 배포, Blue/Green 배포 같은 전략을 접목해 더욱 정교한 무중단 배포 시나리오를 구축할 수 있음.

결론적으로, 롤링 업데이트는 쿠버네티스가 제공하는 강력한 배포 전략 중 하나로, 서비스 가용성과 지속적 배포(Continuous Deployment)가 중요한 현대 소프트웨어 개발·운영 환경에서 매우 중요한 역할을 함.

이를 효과적으로 사용하려면 애플리케이션 자체의 준비 프로브(Readiness Probe), 로그·모니터링 체계, DB 호환성 등의 운영 포인트를 꼼꼼히 챙겨야 함.