Kubernetes 환경에서 Application을 배포할 때 새로운 Version이 항상 정상적으로 동작하는 것은 아닙니다.
새로운 Image에 오류가 있거나 설정 문제가 발생하면 서비스 장애로 이어질 수 있습니다.
예:
v1 운영
↓
v2 배포
↓
Application 오류 발생
↓
이전 Version 복구 필요
↓
v1 Rollback
Kubernetes는 Deployment History를 저장하고 있어 문제가 발생하면 이전 Version으로 빠르게 복구할 수 있습니다.
| 구성 요소 | 역할 |
|---|---|
| Deployment | Version 관리 |
| ReplicaSet | 이전 상태 저장 |
| Rollout History | 배포 기록 |
| Rollback | 이전 Version 복구 |
| kubectl rollout | 배포 제어 |
Rollback 구조를 이해하면 Production 환경에서 배포 실패에 빠르게 대응할 수 있습니다.
Kubernetes Rollback이란?
Rollback은 현재 배포된 Application Version을 이전 정상 Version으로 되돌리는 기능입니다.
기존 방식:
새 Version 배포
↓
오류 발생
↓
수동으로 이전 설정 복구
Kubernetes 방식:
Deployment History 확인
↓
이전 ReplicaSet 선택
↓
Version 복구
빠른 장애 대응이 가능합니다.
Kubernetes Deployment와 Version 관리 구조
Kubernetes Deployment는 ReplicaSet을 통해 Version을 관리합니다.
구조:
Deployment
↓
ReplicaSet v1
↓
Pod
업데이트:
Deployment
↓
ReplicaSet v2 생성
↓
새 Pod 실행
기존 ReplicaSet 정보는 유지되어 Rollback이 가능합니다.
Kubernetes Rollout History 확인
배포 기록 확인:
kubectl rollout history deployment app결과:
revision 1
revision 2
revision 3각 Version의 변경 기록을 확인할 수 있습니다.
Kubernetes Rollback 실행 방법
이전 Version으로 복구:
kubectl rollout undo deployment app특정 Revision 복구:
kubectl rollout undo deployment app --to-revision=2원하는 Version으로 돌아갈 수 있습니다.
Kubernetes Rollback 동작 과정
Rollback 흐름:
장애 Version 감지
↓
Deployment History 확인
↓
이전 ReplicaSet 활성화
↓
Pod 교체
↓
서비스 정상화
기존 Image와 설정을 다시 적용합니다.
Kubernetes Rollback과 ReplicaSet 관계
Deployment는 ReplicaSet 기록을 유지합니다.
예:
Revision 1
↓
ReplicaSet A
Revision 2
↓
ReplicaSet B
Revision 3
↓
ReplicaSet C
Rollback:
ReplicaSet A 또는 B 활성화
이 구조 때문에 빠른 복구가 가능합니다.
Kubernetes Rollback 상태 확인
배포 상태 확인:
kubectl rollout status deployment appHistory 확인:
kubectl rollout history deployment app현재 Version 확인:
kubectl describe deployment app배포 상태를 분석할 수 있습니다.
Kubernetes Rollback 실패 원인
대표 원인:
| 원인 | 설명 |
|---|---|
| History 없음 | 이전 ReplicaSet 삭제 |
| Image 문제 | 이전 Image 사용 불가 |
| Config 변경 | 환경 설정 오류 |
| Database 변경 | 호환성 문제 |
Rollback 전 배포 관리가 중요합니다.
Kubernetes Revision History 관리
Deployment는 기본적으로 이전 Revision을 보관합니다.
설정:
revisionHistoryLimit: 10보관할 Revision 개수를 지정합니다.
운영 환경에서는 적절한 History 관리가 필요합니다.
Kubernetes Rollback과 Database 문제
Application Rollback은 쉽지만 Database는 주의해야 합니다.
예:
Application v2
↓
Database Schema 변경
↓
Application Rollback
↓
Schema 불일치
Database Migration 전략이 함께 필요합니다.
Kubernetes Rollback과 CI/CD
DevOps Pipeline:
Code 변경
↓
Build Image
↓
Deploy
↓
Health Check
↓
문제 발생
↓
Automatic Rollback
GitOps 환경에서는 자동 Rollback도 가능합니다.
Kubernetes Automatic Rollback
자동 복구 조건:
- Readiness Probe 실패
- Error Rate 증가
- Deployment 실패
Argo Rollouts 같은 도구를 활용하면 자동 Rollback을 구성할 수 있습니다.
Kubernetes Rollback 운영 전략
Production 환경:
배포 전 테스트
↓
Rolling Update
↓
Health Check
↓
Monitoring
↓
Rollback 준비
안정적인 배포 프로세스를 구축합니다.
Kubernetes Rollback과 Monitoring 관계
Rollback 판단에는 Monitoring 데이터가 필요합니다.
확인:
- Error Rate
- Response Time
- CPU
- Memory
- Application Log
문제를 빠르게 감지해야 합니다.
Kubernetes Rollback 장점
| 장점 | 설명 |
|---|---|
| 빠른 복구 | 장애 시간 감소 |
| Version 관리 | 안정적 배포 |
| 자동화 가능 | CI/CD 연결 |
| 운영 안정성 | Risk 감소 |
Rollback은 Production Kubernetes 운영의 필수 기능입니다.
자주 묻는 질문
Rollback하면 Image도 자동으로 변경되나요?
네.
이전 Deployment Revision에 저장된 Image와 설정으로 돌아갑니다.
Rollback하면 데이터도 이전 상태로 돌아가나요?
아닙니다.
Application Version만 변경되므로 Database Backup과 Migration 전략이 필요합니다.
모든 Deployment가 Rollback 가능한가요?
Deployment History가 남아 있다면 가능합니다.
마무리
Kubernetes Rollback은 새로운 Version 배포 실패 시 이전 정상 상태로 빠르게 복구하는 핵심 운영 기능입니다.
| 구성 요소 | 역할 |
|---|---|
| Deployment | 배포 상태 관리 |
| ReplicaSet | Version 기록 |
| Rollout History | 변경 이력 |
| Rollback | 이전 Version 복구 |
Rollback 구조를 이해하면 Kubernetes Production 환경에서 안정적인 배포와 장애 대응 체계를 구축할 수 있습니다.
다음 글에서는 Kubernetes Application 안정성 검증 영역인 Kubernetes Health Check 완벽 가이드! Liveness·Readiness·Startup Probe와 서비스 안정성 구조 이해하기를 진행하겠습니다.