🔧
DevOps
디플로이먼트
Deployment
애플리케이션을 운영 환경에 배포하는 과정. Blue-Green, Canary, Rolling 등 다양한 전략 존재.
상세 설명
디플로이먼트(Deployment)는 애플리케이션을 운영 환경에 배포하는 프로세스와 Kubernetes의 워크로드 리소스를 모두 지칭합니다. 개발에서 프로덕션까지 코드를 안전하게 전달하는 DevOps의 핵심 활동입니다.
Kubernetes Deployment는 Pod의 선언적 업데이트를 관리합니다. ReplicaSet을 생성하고, 롤링 업데이트로 무중단 배포하며, 히스토리를 유지하여 롤백을 지원합니다. spec에 원하는 상태를 정의하면 컨트롤러가 현재 상태를 맞춰갑니다.
배포 전략으로 Recreate(전체 중단 후 재생성), RollingUpdate(점진적 교체), Blue-Green(환경 전환), Canary(부분 트래픽 검증)가 있습니다. 각 전략은 다운타임, 리소스 사용량, 롤백 용이성에서 트레이드오프가 있습니다.
실무에서는 CI/CD 파이프라인이 자동으로 Deployment를 트리거합니다. GitHub Actions, GitLab CI, ArgoCD 등이 Git push를 감지하여 빌드-테스트-배포를 수행합니다. 환경별(dev/staging/prod) 설정 분리와 승인 게이트가 필수입니다.
코드 예제
# Kubernetes Deployment 매니페스트
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # 초과 Pod 허용 수
maxUnavailable: 0 # 최소 가용성 보장
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: myapp:v1.2.0
ports:
- containerPort: 8080
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
env:
- name: DB_HOST
valueFrom:
secretKeyRef:
name: db-credentials
key: host
---
# kubectl 배포 명령어
# kubectl apply -f deployment.yaml
# kubectl rollout status deployment/web-app
# kubectl rollout history deployment/web-app
# kubectl rollout undo deployment/web-app --to-revision=2실무에서 이렇게 말해요
시니어: "이번 배포는 DB 마이그레이션이 포함되어 있어서 순서가 중요해요. 마이그레이션 먼저, 배포는 그 다음에 하죠."
주니어: "네, Job으로 마이그레이션 실행 후 Deployment 트리거되도록 파이프라인 구성했습니다."
면접관: "Kubernetes Deployment의 롤링 업데이트가 어떻게 동작하는지 설명해주세요."
지원자: "새 ReplicaSet을 생성하고 Pod를 점진적으로 교체합니다. maxSurge로 동시에 생성할 Pod 수, maxUnavailable로 최소 가용성을 설정합니다. readinessProbe가 통과해야 다음 Pod 교체를 진행합니다."
리뷰어: "resources 설정이 없는데, 운영에서 문제 없을까요?"
개발자: "부하 테스트 결과 기반으로 request 256Mi, limit 512Mi로 설정 추가하겠습니다."
주의사항
- readinessProbe 필수 설정 - 없으면 준비 안 된 Pod에 트래픽 유입
- 이미지 태그 :latest 금지 - 버전 명시로 재현성 확보 (예: v1.2.3)
- DB 스키마 변경 시 애플리케이션과 별도 배포 - 의존성 분리
- 배포 전 staging에서 검증 필수 - 운영 직접 배포는 장애 원인