[K8s] 쿠버네티스 Deployment의 개념

Deployment

디플로이먼트(Deployment)는 파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공한다.

디플로이먼트에서 의도하는 상태를 설명하고, 디플로이먼트 컨트롤러(Controller)는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다. 

 

사용 사례

• 레플리카셋을 롤아웃 할 디플로이먼트 생성. 레플리카셋은 백그라운드에서 파드를 생성한다. 롤아웃 상태를 체크해서 성공 여부를 확인한다.
• 디플로이먼트의 PodTemplateSpec을 업데이트해서 파드의 새로운 상태를 선언한다. 새 레플리카셋이 생성되면, 디플로이먼트는 파드를 기존 레플리카셋에서 새로운 레플리카셋으로 속도를 제어하며 이동하는 것을 관리한다. 각각의 새로운 레플리카셋은 디플로이먼트의 수정 버전에 따라 업데이트한다.
• 만약 디플로이먼트의 현재 상태가 안정적이지 않은 경우 디플로이먼트의 이전 버전으로 롤백한다. 각 롤백은 디플로이먼트의 수정 버전에 따라 업데이트한다.
• 더 많은 로드를 위해 디플로이먼트의 스케일 업.
• 디플로이먼트 롤아웃 일시 중지로 PodTemplateSpec에 여러 수정 사항을 적용하고, 재개하여 새로운 롤아웃을 시작한다.
• 롤아웃이 막혀있는지를 나타내는 디플로이먼트 상태를 이용.
• 더 이상 필요 없는 이전 레플리카셋 정리.

쿠버네티스 공식 docs만 봐도 사실상 ReplicaSet보다 Deployment를 권장하고 있다

분명 ReplicaSet으로 배포를 할 수 있다 하지만 배포한 새로운 Pod에 문제가 발생했을 때 우리는 수동으로

 

- 새로운 ReplicaSet을 만들어 Pod 재배포 or Pod Template 변경 후 적용

- 필요 없는 ReplicaSet과 Pod를 제거

- 롤백 혹은 새로운 버전을 배포할 때마다 1~3번 까지 반복

 

위의 방법으로 반복적인 작업을 해야 한다.하지만 사람손으로 하게 될 경우에 따라오는 실수와 오류들이 많다 

그렇기 때문에 반복 작업을 쿠버네티스에게 위임하여 활용하는 오브젝트 Deployment이다

 

즉 Deployment는 Pod 배포 자동화를 위한 오브젝트이다(ReplicaSet + 배포전략)

 

- 새로운 Pod를 롤아웃/롤백할 때 ReplicaSet생성을 대신해 준다(Pod복제)

- 다양한 배포 전략을 제공하고 이전 파드에서 새로운 파드로의 전환 속도를 제어할 수 있다

- 이제는 Pod을 배포할 때 ReplicaSet이 아닌 Deployment를 사용한다

 

Deployment를 생성 해보고 상태를 확인해보겠다

이번에 사용할 yaml을 확인해보자

apiVersion: apps/v1   #ReplicaSet과 차이점은 kind에 Deployment라고 작성하는거말고는 크게차이점은없다 
kind: Deployment      
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
        project: fastcampus
        env: production
    spec:
      containers:
      - name: my-app
        image: yoonjeong/my-app:1.0
        ports:
        - containerPort: 8080
        resources:
          limits:
            memory: "64Mi"
            cpu: "50m"

 

여기서 해볼거는 

- Deployment를 통한 ReplicaSet 생성과 Pod 복제 결과 확인

- Deployment Pod replicas 변경 후 결과 확인

- Deployment Pod Template 이미지 변경 후 결과 확인

- Deployment Pod Template 레이블 변경 후 결과 확인

 

Deployment를 생성하기전 작업 아래의 명령어를 입력해서 생성했을 때 무슨 일이 일어나는지 확인해보자

# ReplicaSet이 생성하는 Pod 상태 변화 확인 (Watch 모드)
$ kubectl get rs -w

# Deployment를 통해 생성한 Pod 상태 변화 확인 (Watch 모드)
$ kubectl get deployment -w

# Deployment 배포 진행중/완료 상태 확인
$ kubectl rollout status deployment/my-app

rs 와 deployment 명령어로 언제 서비스가 가능한 상태인지 확인 해봤다. 

 

이번에는 아래의 그림처럼 먼저 1.0버전을 배포하고 set image 명령어로 2.0을 배포했을 때의 상태를 확인 해보자

 

이번에 배포할 yaml을 스팩을 확인하고 생성해보겠다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
        project: fastcampus
        env: production
    spec:
      containers:
      - name: my-app
        image: yoonjeong/my-app:1.0
        ports:
        - containerPort: 8080
        resources:
          limits:
            memory: "64Mi"
            cpu: "50m"

yaml 파일의 구성은 위에서 했던 yaml과 별다를게 없다 이번에는 replicas를 3으로 배포 해보겠다 

공통으로 세팅할건 deployment와 rs를 watch 모드로 준비해 놓고 배포하겠다.

 

문제없이 Deployment에 의해 배포되었으며 이벤트로 다시한번 확인해보자 아래 이벤트를 확인해보면 replicaset이

3개로 스케일된걸 확인 할 수있다

 

이번에는 my-app 컨테이너 이미지를 2.0버전으로 변경해보겠다(마찬가지로 watch 모드는 유지해주자)

$ kubectl set image <오브젝트 종류> <오브젝트 이름> <컨테이너 이름>=<이미지 주소>

 

위의 출력을 그림으로 나타내봤는데 이해하기쉽게 설명해보겠다

일단 replicas는 3이기때문에 1.0버전의 Pod는 3개가 띄어져있는데 2.0버전 Pod 하나가 아직 생성되어있지는않고 desired 되어있다 

그다음 Pod가 생성되는 순간 1.0버전의 Pod는 종료가된다 마찬가지로 이러한 상태를 보이는 이뉴는 replicas 3을 유지하기때문이다

똑같이 순차적으로 갯수를 지키며 배포가 성공적으로 완료되었다 

 

describe 명령어로 deployment를 조회한하면 0.1버전은 순차적으로 sclaed down이되는 반면 

0.2버전은 scaled up되는걸 확인 할 수 있다.

 

 

정리

- Deployment가새로운ReplicaSet를생성한다

- 이전ReplicaSet은자신이관리하는Pod을모두제거한다

- 새로운ReplicaSet은새로운Pod을replicas수만큼생성한다

- PodTemplate이변경될때Deployment의롤아웃기능이트리거된다

- PodTemplate이변경되면pod-template-hash값이변경된다

- 변경된pod-template-hash값은ReplicaSet과Pod에모두반영된다

 

 

기술 출처

https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/

디플로이먼트