[Kubernetes] Deployment : 레플리카셋, 파드의 배포를 관리

디플로이먼트 사용하기

레플리카셋만 사용해도 충분히 Micro Service 구조의 컨테이너를 구성할 수 있을 것 같지만, 실제 쿠버네티스 운영 환경에서 레플리카셋을 YAML 파일에서 사용하는 경우는 거의 없다. 대부분은 레플리카셋과 파드의 정보를 정의하는 '디플로이먼트(Deployment)'라는 이름의 오브젝트를 YAML 파일에 정의해 사용한다.

디플로이먼트는 레플리카셋의 상위 오브젝트이기 때문에 디플로이먼트를 생성하면 해당 디플로이먼트에 대응하는 레플리카셋도 함께 생성된다. 따라서 디플로이먼트를 사용하면 파드와 레플리카셋을 직접 생성할 필요가 없다. 간단한 예시를 통해 디플로이먼트를 직접 생성해 보자.

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

위의 YAML 파일의 내용을 해석해 보면 단지 kind 항목이 Deployment로 바뀌었을 뿐, 레플리카셋의 YAML 파일에서 변경된 부분은 거의 없어 보인다. 위의 YAML 파일을 사용해 디플로이먼트를 생성해 보자.

kubectl apply -f deployment-nginx.yaml

생성된 디플로이먼트의 목록은 파드나 레플리카셋에서 목록을 출력했던 것과 동일하게 kubectl get deployment 명령어로 출력할 수 있다.

my-nginx-deployment라는 이름의 디플로이먼트가 생성돼 있으며, READY 항목의 3/3이라는 출력을 통해 3개의 파드가 정상적으로 준비됐음을 알 수 있다. 그러나 이전에 설명했던 것처럼 일정 개수의 파드가 유지되도록 생성하는 것은 레플리카셋이기 때문에 실제로는 디플로이먼트와 함께 레플리카셋 또한 생성되어 있을 것이다.

즉, 디플로이먼트를 생성함으로써 레플리카셋이 생성됐고, 레플리카셋이 파드를 생성한다. 따라서 디플로이먼트를 삭제하면 레플리카셋과 파드 또한 함께 삭제된다.

디플로이먼트를 사용하는 이유

그렇다면, 쿠버네티스는 왜 레플리카셋을 그대로 사용하지 않고, 굳이 상위 개념인 디플로이먼트를 다시 정의해 사용하는 것일까? 레플리카셋만으로도 동일한 개수의 파드를 충분히 유지할 수 있는데도, 디플로이먼트를 사용해 간접적으로 레플리카셋을 생성해야 할 이유가 있을까?

디플로이먼트를 사용하는 핵심적인 이유 중 하나는 애플리케이션의 업데이트와 배포를 더욱 편하게 만들기 위해서이다. 디플로이먼트라는 이름의 Deploy 단어의 뜻이 나타내는 것처럼 디플로이먼트는 컨테이너 애플리케이션을 배포하고 관리하는 역할을 담당한다. 예를 들어 애플리케이션을 업데이트할 때 레플리카셋의 변경 사항을 저장하는 '리비전(revision)'을 남겨 롤백을 가능하게 해 주고, 무중단 서비스를 위해 파드의 롤링 업데이트의 전략을 지정할 수도 있다.

좀 더 쉬운 이해를 위해 디플로이먼트를 이용해 애플리케이션의 버전을 업데이트해 배포하는 간단한 예시를 살펴보자. 이전과 동일한 YAML 파일로 디플로이먼트를 생성하되, 이번에는 --record라고 하는 조금 특수한 옵션을 추가한다.

kubectl apply -f deployment-nginx.yaml --record

자 이제 컨테이너 애플리케이션의 버전이 업데이트되어 파드의 이미지를 변경해야 한다고 가정해 보겠다. 이때 디플로이먼트에서 생성된 파드의 이미지를 변경할 때는 kubectl set image 명령어를 사용할 수 있다. 예를 들어 파드의 이미지의 버전을 nginx:1.11으로 업데이트하고 싶다면 아래와 같은 명령어를 입력하면 된다.

kubectl set image deployment my-nginx-deployment nginx=nginx:1.11 --record

다시 파드의 목록을 확인해 보면 방금 전에 이미지를 업데이트함으로써 새롭게 생성된 파드들이 존재하는 것을 볼 수 있다. 그 뒤에 레플리카셋의 목록을 출력하면 어떤 결과가 나올까?

두 개의 레플리카셋이 존재하는 것을 볼 수 있다. DESIRED, CURRENT 등의 항목이 3으로 표시된 my-nginx-deployment-55 bbf495 bd 레플리카셋은 이미지를 업데이트함으로써 방금 새롭게 생성된 레플리카셋이다. 반면 다른 레플리카셋은 replicas의 값이 0으로 설정돼 파드를 생성하지는 않고 있지만, 첫번째에 생성한 레플리카셋이다.

디플로이먼트는 파드의 정보를 업데이트함으로써 새로운 레플리카셋과 파드를 생성했음에도 불구하고 이전 버전의 레플리카셋을 삭제하지 않고, 남겨두고 있다. 즉, 디플로이먼트는 파드의 정보가 변경되어 업데이트가 발생했을때, 이전의 정보를 리비전으로서 보존한다. 리비전 정보는 다음 명령어로 더욱 자세히 확인할 수 있다.

kubectl rollout history deployment my-nginx-deployment

--record=true 옵션으로 디플로이먼트를 변경하면 변경 사항을 위와 같이 디플로이먼트에 기록함으로써 해당 버전의 레플리카셋을 보존한다. 만약 이전 버전의 레플리카셋으로 되돌리는 롤백을 하고 싶다면 다음의 명령어를 사용하면 된다. --to-revision에는 되돌리려는 리비전의 번호를 입력하면 된다.

kubectl rollout undo deployment my-nginx-deployment --to-revision=1

다시 레플리카셋의 목록을 확인해보면 처음에 생성했던 레플리카셋이 다시 3개의 파드를 생성하고 있는 것을 알 수 있다. 물론 방금 새롭게 생성됐던 레플리카셋의 파드는 0으로 줄어들었다.

쿠버네티스 리소스의 자세한 정보를 출력하는 kubectl describe 명령어를 사용해 디플로이먼트의 정보를 출력해 보면, 현재의 레플리카셋 리비전 정보와 활성화된 레플리카셋 이름을 확인할 수 있다.

 kubectl describe deploy my-nginx-deployment

이처럼 디플로이먼트는 여러 개의 레플리카셋을 관리하기 위한 상위 오브젝트이다.

디플로이먼트를 사용하면 이러한 레플리카셋의 리비전 관리뿐만 아니라 다양한 파드의 롤링 업데이트 정책을 사용할 수도 있다는 장점이 있다. 따라서 쿠버네티스에서도 공식적으로 디플로이먼트를 사용할 것을 권장하고 있다.

당연하게도 지금 당장 명령어를 기억할 필요는 없다. 지금은 '디플로이먼트는 레플리카셋의 상위 수준의 오브젝트이며, 일반적으로 디플로이먼트를 통해 파드를 생성한다' 정도만 알고 넘어가자.

Ref : 시작하세요! 도커/쿠버네티스