메뉴

문서정보

Kubernetes - Deployment

목차

소개

아직 Kubenetes 환경을 구축하지 않았다면 minikube문서를 참고해서 구축하자.

Deployment

쿠버네티스의 최소 배포단위는 POD이다. POD는 실질적인 프로세스이고, Service 형태로 외부에 노출된다. POD이 프로세스이므로 POD의 사양 즉 프로세스의 이름, 프로세스를 실행할 컨테이너 이미지이름, 사용할 포트등의 명세서가 필요하다. 또한 Pod의 복제본 수, 업데이트되는 코드의 롤아웃/롤백 정보 등을 담고 있다.

쿠버네티스는 프로덕션 환경에서 애플리케이션의 배포, 확장, 업데이트와 관련된 작업 과 반복적으로 수행해야 하는 기능을 자동화 하기 위해서 사용한다. 쿠버네티스 Deployment 컨트롤러는 Pod와 노드의 상태를 모니터링 하고 있다가 장애가 발생하면 (Deployment 명세에 따라서) Pod를 새로 실행하거나 교체하는 등의 작업을 자동으로 수행한다.

 Deployment와 POD

아래는 Nginx 를 실행하기 위한 deployment 파일이다. deployment는 yaml 형태로 작성한다.
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

apply 명령을 이용해서 Deployment를 생성 할 수 있다. 설정파일의 이름은 nginx.yaml이다.
# kubectl apply -f ./nginx.yaml 
deployment.apps/nginx-deployment created

Depoly가 만들어졌다. 확인해보자.
kubectl get deployments      
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           93m
파일에 설정한 리플리케이션 갯수 만큼 실행된 걸 확인 할 수 있다. Nginx depolyment의 rollout 상태를 확인해보자.
# kubectl rollout status deployment/nginx-deployment
deployment "nginx-deployment" successfully rolled out
성공적으로 roll out(실행)된 것을 확인 할 수 있다.

get rs를 이용해서 Deployment의 리플리카셋 상태를 확인해보자.
# kubectl get rs                                    
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-6b474476c4   3         3         3       144m

Deployment Update

yaml 파일을 수정하고 update만 하면 된다. 리플리카를 4개로 스케일 아웃 해보자.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
replicas를 4로 수정한다음에 apply 하면 자동으로 롤아웃 된다.
# kubectl apply -f ./nginx.yaml 
deployment.apps/nginx-deployment configured

# kubectl get deployments;      
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
hello-minikube     1/1     1            1           3h3m
nginx-deployment   4/4     4            4           149m

Kubernetes의 배포 전략

Kubernetes는 다양한 환경에서 작동하는 애플리케이션을 위한 여러 배포 전략을 제공한다. 애플리케이션의 상태를 정의 하면 Deploy controller이 정의에 따라서 배포작업을 수행한다.

Recreate Deployment

 Recreate Deployment

현재 실행 중인 pod 인스턴스를 종료하고 새 버전으로 동시에 새로 실행한다. 이 때문에 애플리케이션 중단을 막을 수 없으며, 복구(롤백) 프로세스를 돌리는데에도 시간지연이 발생한다.

이 전략은 간단하고 빠르고 저렴하다는 장점이 있다. 하지만 가장 위험한 배포전략으로 모범 사례에 속하지 않는다. 서비스가 비즈니스, 미션, 수익에 중요하지 않는 경우, 근무 시간외에 배포해도 괜찮은 경우, 개발이나 스테이징 환경 등에 주로 사용한다.

Rolling Update Deployment

 Rolling Deployment

롤링 업데이트는 실행 중인 애플리케이션 인스턴스를 순차적으로 새 릴리즈로 업데이트하는 배포 전략이다.

롤릴 업데이트는 롤백이 비교적 간단하며 recreate Deployment 보다 더 안전하다는 장점이 있다. 하지만 릴리즈 업데이트가 완료되기 전까지, 서로 다른 버전의 애플리케이션이 실행될 수 있으므로 여기에서 발생할 수 있는 문제점을 해결 할 수 있어야 한다. 업데이트 할 때, 각 애플리케이션이 성공적으로 배포됐는지를 확인하기 때문에 배포에 시간이 걸릴 수 있다.

Blue/Green Deployment

 Blue/Green Deployment

블루/그린 배포는 서로 다른 버전의 애플리케이션(혹은 서비스)를 블루(일명 스테이징)와 그린(일명 프로덕션) 두개의 환경을 활용하는 배포 전략이다. 기능 테스트, 품질관리 등의 활동은 블루 환경에서 수행된다. 새로운 변경이 수용되고 테스트가 끝나면, 트래픽을 블루로 라우팅한다.

블루/그린 배포는 간단하고 빠르며 이해하기가 쉽고 구현이 쉽다는 장점이 있다. 롤백도 간단하다. 문제가 발생하며 트래픽을 이전 환경으로 되돌리기만 하면 된다. 다른 배포 전략에 비해서 매우 안전하다.

블루/그린의 단점은 비용에 있다. 마이크로 서비스 환경에서 복제된 두 개의 환경을 구축하는데에는 많은 시간과 비용이 들어갈 수 있다. 품질관리, 승인테스트, 회귀테스트를 수행하긴 하지만 모든 사용자 트래픽을 한 번에 전환하면 위험이 발생 할 수 있다. 따라서 블루/그린 환경을 제대로 구성하기 위해서는 잦은 배포 전략을 유지할 필요가 있다.

Canary Deployment

 Canary Deployment

Canary 배포는 서비스를 일부 사용자에게 점진적으로 릴리즈 하는 배포 전략이다. 대상 환경의 인프라는 작은 단계(25%, 50%, 75%, 100%)로 업데이트 한다. Canary 배포는 다른 배포 전략에 비해서 가장 안전하다.

Canary 배포를 통해 조직은 실제 사용자를 대상으로 현재 버전과 업데이트 버전의 작동 경험을 함께 비교 할 수 있다. 블루/그린 배포처럼 복제를 만들 필요가 없기 때문에 비용 역시 저렴하다. 롤백역시 빠르고 안전하다.

Cnary 배포는 프로덕션 환경에서의 테스트에 많은 기술적 노하우가 필요하다는 단점을 가진다. Canary 스크립트는 복잡 하며, 테스트에 많은 시간이 걸릴 수 있다. 테스트 전략, 모니터링 등에 추가 연구가 필요 할 수 있다.

어떤 배포 전략을 사용해야 할까

소프트웨어 배포 작업을 해본 사람은 쉽지 않은 과정이라는 것을 알고 있을 것이다. 소프트웨어 배포 작업은 기획자, 품질관리자, 개발자, PM 이 커뮤니케이션 할 수 있는 업무시간에 실행하도록 한다. 이를 위해서 필요한 것들은 아래와 같다.

참고