Docker, Kubernetes 배포 방식

Docker

도커는 애플리케이션과 그 종속성을 컨테이너라는 격리된 환경에 패키징하여 일관된 실행 환경을 제공하는 플랫폼이다.

애플리케이션과 종속성을 하나의 이미지로 패키징
경량화된 컨테이너 실행 환경 제공
빠른 배포, 확장성, 이식성, 유연성 제공

# Dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
CMD ["node", "server.js"]

Kubernetes

쿠버네티스는 도커 컨테이너를 관리하고 자동화된 배포 및 오케스트레이션을 제공하는 오픈소스 플랫폼이다.

자동화된 배포 및 확장
컨테이너 상태의 모니터링
효율적인 리소스 관리 및 부하 분산

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: node-app
  template:
    metadata:
      labels:
        app: node-app
    spec:
      containers:
        - name: node-app
          image: yourregistry/node-app:latest

도커만으로 부족한 이유

단일 컨테이너 실행과 관리에는 효과적이지만, 복잡한 환경에서는 한계가 있다.

다수 컨테이너 환경에서의 확장성과 관리 복잡성
장애 발생 시 자동 복구 미지원
부하 분산 및 자동화된 트래픽 관리 부재

쿠버네티스가 필요한 시점

컨테이너 개수와 서비스 복잡성이 증가할 때
자동화된 배포, 확장, 복구가 필요할 때
다수의 환경 간 배포 일관성이 필요할 때

Kubernetes에서의 배포 방식

배포 전략

롤링업데이트(Rolling Update): 서비스 중단 없이 점진적으로 컨테이너 업데이트
블루-그린(Blue-Green): 두 가지 환경을 준비하여 즉각적인 전환
카나리(Canary) 배포: 일부 사용자에게만 신규 버전을 점진적으로 적용하여 모니터링
리크리에이트 (Recreate): 기존 컨테이너를 중단하고 새로운 컨테이너로 교체

롤링업데이트(Rolling Update)

점진적으로 새로운 버전을 배포하여 서비스 중단 없이 배포 진행

장점
- 서비스 중단 X
- 안정적인 배포 가능
단점
- 문제가 발생했을 때 롤백이 다소 느릴 수 있음

#example
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-example
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web
          image: myapp:v2

블루-그린(Blue-Green)

두 개의 독립된 환경을 구성하여 새로운 버전을 별도의 환경에서 배포 후 트래픽을 전환.

장점: 빠른 롤백, 즉각적인 전환 가능
단점: 리소스 사용량 증가

# Example
# Blue(현재버전) Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: blue
  template:
    metadata:
      labels:
        app: my-app
        version: blue
    spec:
      containers:
        - name: my-app
          image: myregistry/my-app:blue

# Example
# Green(신규버전) Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: green
  template:
    metadata:
      labels:
        app: my-app
        version: green
    spec:
      containers:
        - name: my-app
          image: myregistry/my-app:green

# Example
# 서비스 설정 (트래픽 전환 예시)
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
    version: blue # 버전 전환 시 blue를 green으로 변경
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

카나리(Canary) 배포

일부 사용자에게만 새로운 버전을 배포하여 점진적으로 테스트 후 전환하는 방식

장점: 안전성이 높으며 문제 발생 시 피해 최소화
단점: 추가 관리와 복잡성 증가

# Example
# DestinationRule 설정 (Istio 기반 설정)
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-app-destination
spec:
  host: my-app # 서비스 호스트명
  subsets:
    - name: stable # 기존 안정 버전
      labels:
        version: stable
    - name: canary # 신규 테스트 버전
      labels:
        version: canary

# Example
# VirtualService 설정
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app-virtualservice
spec:
  hosts:
    - my-app # 적용할 서비스 호스트
  http:
    - route:
        - destination:
            host: my-app
            subset: stable # 기존 버전
          weight: 90 # 기존 버전으로의 트래픽 비율
        - destination:
            host: my-app
            subset: canary # 신규 버전
          weight: 10 # 신규 버전으로의 트래픽 비율

리크리에이트 (Recreate) 배포

기존 컨테이너를 완전히 종료한 후 새로운 컨테이너를 배포하는 방식.

장점: 간단한 구현
단점: 배포 과정 중 서비스 중단 발생

# Example
apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate-example
spec:
  replicas: 3
  strategy:
    type: Recreate # 기존 컨테이너를 모두 종료한 뒤 신규 컨테이너 배포
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: myregistry/my-app:v2

---

배포 전략은 서비스의 성격과 요구사항, 리스크 허용도 등에 따라 다르게 적용될 수 있으며,때로는 여러 전략을 혼합하여 사용하면 더 안전하고 효율적일 수 있다.