쿠버네티스 디플로이먼트 (Deployment)

## 디플로이먼트 (Deployment)

• 디플로이먼트는 파드와 레플리카셋에 대한 선언과 업데이트를 제공하는 상위개념의 컨트롤러.
• 이전에 파드를 설명할때 살짝 설명한 컨트롤러이다. 서비스를 파드만 운영하면 복제가 불가능하다. 트래픽이 몰리는 상황이나 배포상황에서 안정적인 서비스를 유지하기 위해서 복제의 조절은 필수적이다.
• 디플로이먼트는 이러한 파드의 복제뿐만 아니라 여러 부분을 조절하도록 해준다.

 

------- nodejs.yaml 생성 ----------

apiVersion: apps/v1

kind: Deployment

metadata:

  name: nodejs-app

  labels:

    app: nodejs-app

spec:

  replicas: 1

  selector:

    matchLabels:

      app: nodejs-app

  template:

    metadata:

      labels:

        app: nodejs-app

    spec:

      containers:

      - name: nodejs-app

        image: uphiller/nodejs-hello-world

        ports:

        - containerPort: 3000

 

 

 

 

 

• 파드 부분에서 생성했던 nodejs 컨테이너를 포함한 디플로이먼트를 실행하는 설정 파일.
• 여기서 제일 중요한 부분은 replicas 의 숫자이다. 복제 부분이다.

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl apply -f nodejs.yaml

 

 

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl get pod

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl get replicaset

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl get deployment

 

• 파드, 레플리카셋, 디플로이먼트가 모두 생성되었다.
• 레플리카셋은 파드의 복제를 관리하고, 디플로이먼트는 복제를 포함한 파드를 생성하며 관리.
• 복제 개수를 1 -> 2 로 변경 후 다시 실행

ubuntu@ip-10-0-1-52:~/deployment$ kubectl apply -f nodejs.yaml

 

 

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl get replicaset

 

ubuntu@ip-10-0-1-52:~$ kubectl get pod

 

 

ubuntu@ip-10-0-1-52:~$ kubectl get deployment

 

 

 

• 레플리케이션 숫자는 설정 파일을 업데이트하여 수정할 수 있다.

 

• 이와 같이 이미지 또한 수정파일을 수정해서 업데이트 할 수 있다.

: TAG 부분을 수정하고 실행해 보자

 

• 업데이트가 잘되었는지 확인하기 위해서는 롤아웃 명령어를 사용해야 한다.

ubuntu@ip-10-0-1-52:~/deployment$ kubectl apply -f nodejs.yaml

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl rollout status deployment.apps/nodejs-app

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl get deployments

 

 

• Rollout 명령어를 사용하면 디플로이먼트의 변경된 상태가 잘 적용되었는지 확인할 수 있으며, 디플로이먼트의 변경 히스토리까지 볼수 있다.

ubuntu@ip-10-0-1-52:~/deployment$ kubectl rollout history deployment.apps/nodejs-app

 

 

 

 

 

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl get pod

• 이처럼 파드는 언제든지 생성되고 없어지는 존재이기 때문에 쿠버네티스 사용자가 직접 서비스를 위해 사용할때는 파드 오브젝트 자체를 컨트롤하지 않고 디플로이먼트와 같은 컨트롤러를 사용하는 것이다.

 

 

 

 

 

 

 

 

• Nodejs-app 디플로이먼트의 히스토리를 확인할 수 있다.

: CHANGE-CAUSE <none>인 이유는 CHANGE-CAUSE를 지정하는 명령어를 실행하지 않았기 때문이다.

: 업데이트 명령을 실행한 다음, 현재 리비전의 CHANGE-CAUSE를 지정하는 명령을 실행하면 된다.

 

ubuntu@ip-10-0-1-52:~$ kubectl annotate deployment.app/nodejs-app kubernetes.io/change-cause="image updated to latest"

 

ubuntu@ip-10-0-1-52:~$ kubectl rollout history deployment.apps/nodejs-app

 

 

• 경우에 따라 디플로이먼트의 롤백을 원할 수도 있다. 예를들어 지속적인 충돌로 인해 디플로이먼트가 안정적이지 않은 경우도 기본적으로 모든 디플로이먼트의 롤아웃 기록은 시스템에 남아있기 때문에 언제든지 롤백이 가능하다.
• 정상적으로 롤백 되는 것을 테스트하기위해 구성 파일에 이미지의 태그를 존재하지 않는 것으로 수정하고 디플로이먼트를 업데이트 해보자.

 

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl apply -f nodejs.yaml

 

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl rollout status deployment.apps/nodejs-app

 

 

• 이는 이미지의 태그를 교체했지만 존재하지 않는 태그여서 업데이트가 되지않는 상황이다.
• 레플리케이션을 보면 이전 레플리케이션 두개와 새 레플리케이션 한개가 존재한다.

ubuntu@ip-10-0-1-52:~/deployment$ kubectl get rs

 

• 파드를 보면 이미지풀에 에러가 난것이 보인다.

ubuntu@ip-10-0-1-52:~/deployment$ kubectl get pods

 

 

 

 

 

• 이처럼 에러가 발생하면 디플로이먼트 컨트롤러가 새로운 레플리케이션의 스케일업을 중지한다.
• 디플로이먼트에 대한 정보를 보면 상황을 좀더 자세히 알수 있다.

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl describe deployment

 

 

 

 

 

 

 

• 문제를 확인했으니 이제 롤백을 해보자

ubuntu@ip-10-0-1-52:~/deployment$ kubectl rollout undo deployment.apps/nodejs-app

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl rollout status deployment.apps/nodejs-app

 

 

 

 

• 정상적인 이전 상태로 롤백 된것을 확인 할 수 있다. 특정 리비전으로 롤백하고 싶을때는 리비전을 명시한 undo 명령을 실행하면 된다.

ubuntu@ip-10-0-1-52:~/deployment$ kubectl rollout history deployment.apps/nodejs-app

 

ubuntu@ip-10-0-1-52:~/deployment$ kubectl rollout undo deployment.apps/nodejs-app --to-revision=3