[쿠버네티스] Deployment와 카나리, 블루그린 배포

devOps

[쿠버네티스] Deployment와 카나리, 블루그린 배포

집사킴 2024. 10. 19. 17:27

디플로이먼트(Deployment)란?

디플로이먼트(Deployment)는 Kubernetes에서 파드(Pod)와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공하는 리소스입니다. 이를 통해 개발자는 애플리케이션의 배포 및 관리를 쉽게 할 수 있습니다.

디플로이먼트 리소스가 생긴 이유

무중단 배포(Zero Downtime Deployment)를 구현하기 위해서는 2개 이상의 레플리카셋이 필요합니다.

컨테이너 관리: 하나의 애플리케이션이 여러 개의 컨테이너로 구성될 수 있기 때문에, 이러한 컨테이너를 관리하기 위해 파드가 생성됩니다.
파드 관리: 여러 개의 파드를 안정적으로 운영하기 위해 레플리카셋이 필요합니다.
레플리카셋 관리: 마지막으로, 2개 이상의 레플리카셋을 효과적으로 관리하기 위한 상위 개념으로 디플로이먼트가 등장하게 되었습니다.

관계 구조

Deployment: 레플리카셋과 파드를 관리하는 상위 개념
ReplicaSet: 동일한 파드의 복제본을 관리
Pod: 컨테이너를 실행하는 단위

이러한 계층 구조를 통해 Kubernetes는 애플리케이션의 가용성과 안정성을 극대화할 수 있습니다. 디플로이먼트는 지속적인 배포 및 운영을 가능하게 하여, 클라우드 환경에서의 효율적인 자원 관리를 지원합니다.

Deployment > ReplicaSet > Pod > Container

디플로이먼트 생성

Kubernetes에서 디플로이먼트를 생성하기 위해서는 YAML 형식의 구성 파일이 필요합니다. 아래는 Nginx 서버를 배포하는 디플로이먼트의 예시입니다.

nginx-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

위 YAML 파일에서는 Nginx 서버를 3개의 복제본으로 배포하는 디플로이먼트를 정의하고 있습니다. 각 필드의 의미는 다음과 같습니다:

apiVersion: 사용할 API 버전
kind: 생성할 리소스의 종류 (여기서는 Deployment)
metadata: 리소스의 메타데이터 (이름 및 레이블 포함)
spec: 디플로이먼트의 사양
- replicas: 생성할 파드의 수
- selector: 디플로이먼트에서 관리할 파드의 레이블
- template: 생성할 파드의 템플릿
  - containers: 컨테이너의 정의 (이름, 이미지, 포트 등)

디플로이먼트 생성 및 확인

디플로이먼트를 생성한 후, 아래와 같은 명령어로 상태를 확인할 수 있습니다.

# 디플로이먼트 생성
kubectl apply -f nginx-deployment.yml

# 디플로이먼트 확인
kubectl get deployments

# 롤아웃 상태 확인
kubectl rollout status deployment/nginx-deployment

# 레플리카셋 확인
kubectl get rs

# 포드가 정상적으로 실행 중인지 확인
kubectl get po

디플로이먼트 업데이트

Kubernetes에서 디플로이먼트의 업데이트는 파드 템플릿(= .spec.template)이 변경된 경우에만 롤아웃이 트리거됩니다. 이를 통해 애플리케이션의 새로운 버전을 손쉽게 배포할 수 있습니다. 다음은 디플로이먼트를 업데이트하는 두 가지 주요 방법입니다.

방법 1: 이미지 업데이트

컨테이너 이미지를 업데이트하려면 kubectl set image 명령어를 사용합니다. 아래는 Nginx 이미지를 업데이트하는 예시입니다:

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 # 컨테이너명=이미지명:태그

이 명령어는 Nginx 디플로이먼트의 컨테이너 이미지를 nginx:1.16.1로 변경합니다.

방법 2: Deployment 수정

디플로이먼트를 직접 수정하고자 할 경우, kubectl edit 명령어를 사용할 수 있습니다:

kubectl edit deployment/nginx-deployment

이 명령어를 실행하면 기본 텍스트 편집기가 열리며, 해당 디플로이먼트의 설정을 직접 수정할 수 있습니다.

참고: 위의 두 방법 모두 디플로이먼트의 .yml 파일을 수정하지 않습니다. 이 명령어들은 클러스터에 즉각적인 영향을 미치는 업데이트를 수행합니다.

그 밖의 디플로이먼트 업데이트 방법

디플로이먼트를 업데이트하는 다른 방법들도 존재합니다:

kubectl edit: 디플로이먼트를 편집하여 변경합니다.
kubectl patch: 부분적인 수정을 통해 디플로이먼트를 업데이트합니다.
kubectl apply: 수정된 YAML 파일을 통해 디플로이먼트를 업데이트합니다.
kubectl replace: 기존 디플로이먼트를 새로운 것으로 교체합니다.

쿠버네티스 Deployment의 배포 전략

쿠버네티스의 배포 전략은 .spec.strategy.type에 정의되어 있으며, 기본적으로 두 가지 유형이 있습니다:

1. RollingUpdate (기본값)

기존 파드를 점진적으로 새로운 파드로 교체하는 방식입니다. 일부 파드를 종료하고 새로운 파드를 시작하여 무중단 배포 및 점진적 배포를 가능하게 합니다.

2. Recreate

기존에 실행 중인 모든 파드를 종료한 후 새로운 파드를 생성하는 방식입니다. 이 과정에서 일시적인 다운타임이 발생할 수 있습니다.

고급 배포 전략

RollingUpdate 설정에 추가적인 설정을 통해 고급 배포 전략을 구현할 수 있습니다.

블루 그린 배포

두 개의 환경(블루=current, 그린=new)을 사용하여 애플리케이션의 새 버전을 배포하는 방식입니다. 새 버전이 모두 준비된 이후에 한 번에 새 버전으로 트래픽을 전환합니다.
장점: 다운타임이 없고, 이슈 발생 시 블루 환경으로 빠르게 롤백할 수 있습니다.
단점: 두 환경을 동시에 유지해야 하므로 더 많은 리소스가 필요합니다.
쿠버네티스 적용 예:
- 블루와 그린의 두 개의 Deployment를 나눠서 설정합니다.
- Service에서 두 Deployment 중 하나로 트래픽을 라우팅하도록 설정합니다.
- Green Deployment 배포 성공 시, Service가 Blue에서 Green으로 트래픽을 전환하도록 변경합니다.

카나리 배포 (Canary Deployment)

새 버전을 점진적으로 소규모 사용자에게 먼저 배포한 후, 성공 여부에 따라 점차 범위를 넓혀가는 방식입니다.
장점: 리스크를 최소화할 수 있으며, 이슈 발생 시 빠르게 롤백이 가능합니다.
단점: 전체 배포까지 시간이 오래 걸릴 수 있습니다.
쿠버네티스 적용 예:
- v1, v2 두 개의 Deployment를 나눠서 설정합니다. 각 Service도 각기 연결합니다.
- 로드밸런서에서 트래픽을 분산하여 점진적으로 v2 쪽으로 트래픽 비율을 늘려갑니다.

참고: Istio와 같은 서비스 메쉬를 사용하면 카나리 배포와 블루 그린 배포를 더욱 손쉽게 구현할 수 있습니다.

참고자료