Kubernetes 환경에서 서비스를 운영할 때 중요한 것은 새로운 버전을 배포하면서 서비스 중단을 최소화하는 것입니다.
기존 방식에서는 새로운 Application 버전을 배포하기 위해 기존 서비스를 종료하고 다시 시작하는 과정이 필요했습니다.
하지만 Kubernetes는 다양한 Deployment Strategy를 통해 안정적인 업데이트를 제공합니다.
예:
기존 Version
↓
새로운 Version 배포
↓
Traffic 이동
↓
문제 확인
↓
정상 운영
Deployment Strategy는 Production 환경에서 서비스 안정성을 결정하는 중요한 운영 기술입니다.
| 전략 | 특징 |
|---|---|
| Rolling Update | 순차적으로 교체 |
| Recreate | 기존 종료 후 새 배포 |
| Blue Green | 새 환경 전환 |
| Canary | 일부 사용자 테스트 |
배포 전략을 이해하면 Kubernetes 환경에서 안정적인 CI/CD 운영 구조를 구축할 수 있습니다.
Kubernetes Deployment Strategy란?
Deployment Strategy는 Application Version 변경 시 Pod를 어떻게 교체할지 결정하는 방식입니다.
예:
v1 Application 운영
↓
새로운 v2 배포
↓
기존 Pod 처리 방식 결정
Kubernetes Deployment가 업데이트 과정을 관리합니다.
Kubernetes Recreate Strategy
Recreate 방식은 기존 Pod를 모두 종료한 후 새로운 Pod를 생성합니다.
흐름:
v1 Pod 실행
↓
기존 Pod 삭제
↓
v2 Pod 생성
장점:
- 단순한 구조
- 설정 쉬움
단점:
- 서비스 중단 발생 가능
개발 환경에서 주로 사용합니다.
Kubernetes Rolling Update Strategy
Rolling Update는 Kubernetes 기본 배포 방식입니다.
기존 Pod를 유지하면서 새로운 Pod를 점진적으로 생성합니다.
흐름:
v1 Pod
↓
v2 Pod 생성
↓
Traffic 전환
↓
v1 Pod 제거
무중단 배포에 가장 많이 사용됩니다.
Kubernetes Rolling Update 동작 구조
예:
Replica:
4개
업데이트:
v1 Pod 4개
↓
v2 Pod 1개 생성
↓
v1 Pod 1개 제거
↓
반복
↓
v2 Pod 4개 완료
서비스 중단 없이 변경됩니다.
Kubernetes maxSurge와 maxUnavailable
Rolling Update에는 두 가지 중요한 설정이 있습니다.
maxSurge
추가 생성 가능한 Pod 수
예:
Replica 10
maxSurge 2
↓
최대 12개 Pod 실행 가능
maxUnavailable
사용 불가능한 Pod 수
예:
Replica 10
maxUnavailable 2
↓
최대 2개까지 서비스 제외 가능
배포 속도와 안정성을 조절합니다.
Kubernetes Rolling Update 설정 예시
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0안정성을 우선하는 설정입니다.
Kubernetes Blue Green Deployment
Blue Green 방식은 두 개의 환경을 운영합니다.
구조:
Blue
↓
현재 운영 Version
Green
↓
새로운 Version
배포:
Green 배포 완료
↓
테스트
↓
Traffic 전환
↓
Blue 종료
빠른 Rollback이 가능합니다.
Kubernetes Blue Green 장점
장점:
- 빠른 전환
- 쉬운 Rollback
- 안정적인 테스트
단점:
- 두 배의 Infrastructure 필요
- 비용 증가
대규모 서비스에서 활용됩니다.
Kubernetes Canary Deployment
Canary는 일부 Traffic만 새로운 Version으로 전달합니다.
예:
전체 사용자 100%
↓
기존 Version 90%
↓
새 Version 10%
문제 확인 후 점진적으로 확대합니다.
Kubernetes Canary 배포 구조
흐름:
v1 Service
↓
90% Traffic
v2 Service
↓
10% Traffic
Istio, Argo Rollouts 같은 도구와 함께 사용합니다.
Kubernetes Deployment Rollback
새 Version에 문제가 발생하면 이전 Version으로 돌아갈 수 있습니다.
확인:
kubectl rollout history deployment appRollback:
kubectl rollout undo deployment app운영 장애 대응에서 중요합니다.
Kubernetes Rollout 상태 확인
배포 상태:
kubectl rollout status deployment app확인:
- 업데이트 진행
- Pod 상태
- 실패 여부
배포 과정 모니터링에 사용합니다.
Kubernetes Deployment 실패 원인
대표 원인:
| 원인 | 설명 |
|---|---|
| Image 오류 | 새 Image 실행 실패 |
| Resource 부족 | Node 배치 실패 |
| Probe 실패 | Health Check 실패 |
| Config 오류 | 환경 설정 문제 |
배포 전 검증이 중요합니다.
Kubernetes Deployment Strategy와 CI/CD
현대 DevOps 구조:
Code Commit
↓
Build
↓
Image 생성
↓
Registry Push
↓
Kubernetes Deployment
↓
Rolling Update
↓
Monitoring
자동 배포 Pipeline과 연결됩니다.
Kubernetes Deployment Strategy 운영 전략
Production 환경:
Rolling Update 기본 적용
↓
Canary 테스트
↓
Blue Green 활용
↓
Rollback 준비
↓
Monitoring 구성
서비스 중요도에 따라 전략을 선택합니다.
Kubernetes Deployment Strategy Monitoring
확인 항목:
- Rollout 상태
- Pod Ready 상태
- Error Rate
- Response Time
- Traffic 변화
배포 후 검증이 중요합니다.
Kubernetes Deployment Strategy 장점
| 장점 | 설명 |
|---|---|
| 무중단 배포 | 서비스 유지 |
| 빠른 Rollback | 장애 대응 |
| 안정적 업데이트 | Risk 감소 |
| 자동화 가능 | CI/CD 연결 |
Deployment Strategy는 Kubernetes 운영의 핵심입니다.
자주 묻는 질문
Kubernetes 기본 배포 방식은 무엇인가요?
Rolling Update입니다.
Blue Green과 Rolling Update 차이는 무엇인가요?
Rolling Update는 기존 환경에서 순차 교체하고 Blue Green은 새로운 환경을 만든 후 전환합니다.
Canary 배포는 왜 사용하나요?
새로운 Version의 위험을 줄이기 위해 일부 사용자에게 먼저 적용합니다.
마무리
Kubernetes Deployment Strategy는 Application Version 변경 시 안정적인 배포를 가능하게 하는 핵심 운영 방식입니다.
| 전략 | 목적 |
|---|---|
| Rolling Update | 무중단 순차 배포 |
| Recreate | 단순 재배포 |
| Blue Green | 빠른 전환 |
| Canary | 점진적 테스트 |
Deployment Strategy를 이해하면 Kubernetes 환경에서 안정적인 Production 배포와 CI/CD 운영 구조를 구축할 수 있습니다.
다음 글에서는 Kubernetes 배포 자동화 영역인 Kubernetes Rollback 완벽 가이드! 장애 발생 시 이전 Version 복구와 Deployment 관리 구조 이해하기를 진행하겠습니다.