쿠버네티스(Kubernetes) Deployment란?

지난 포스팅에서는 쿠버네티스의 파드(Pod), 레플리카셋(ReplicaSet)에 대해 알아보았다.

오늘은 이를 아우르는 디플로이먼트(Deployment)에 대해 정리해보고자 한다.

 

 

---

1. 디플로이먼트란?

쿠버네티스의 디플로이먼트(Deployment)는 애플리케이션에 선언적 업데이트를 제공하는 쿠버네티스 리소스 개체이다. 디플로이먼트를 통해 애플리케이션에 사용할 이미지, 유효 포드의 수, 업데이트 방식과 같은 애플리케이션 라이프사이클을 정의할 수 있다.

 

쿠버네티스 Object는 사용자가 원하는 클러스터 워크로드의 형태를 쿠버네티스 시스템에 알리는 방법이다. Object가 생성되면 클러스터가 작동하여 Object를 유지하므로 쿠버네티스 클러스터를 원하는 상태로 둘 수 있다.

 

쿠버네티스에서는 각 Object를 독립적으로 생성하기 보다는 디플로이먼트를 통해서 생성하는 것을 권장하고 있으며, 파드와 레플리카셋(ReplicaSet)의 기준 정보를 지정할 수 있다.

 

다시말해서, 디플로이먼트는 레플리카셋의 상위 Object이기 때문에 디플로이먼트를 생성하면 해당 디플로이먼트에 대응하는 레플리카셋도 함께 생성된다. 따라서 디플로이먼트를 사용하면 파드, 레플리카셋을 직접 생성할 필요가 없다.

 

이러한 디플로이먼트는 다음과 같은 작업을 수행할 수 있다.

• 파드 또는 레플리카셋  배포
• 파드 및 레플리카셋 업데이트
• 이전 디플로이먼트 버전으로 롤백
• 디플로이먼트 스케일 조정
• 디플로이먼트 일시 중지 또는 진행

 

즉, 개념적으로 Deployment = ReplicaSet + Pod + history이며 ReplicaSet을 만드는 것보다 더 윗단계의 선언(추상표현) 이다.

 

 

 

 

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

쿠버네티스는 그럼 왜 Replicaset을 그대로 사용하지 않고, 굳이 상위 개념인 디플로이먼트를 사용해서 간접적으로 레플리카셋을 생성하는 것일까?

 

디플로이먼트를 사용하는 핵심적인 이유는 애플리케이션의 업데이트와 배포를 더욱 편하게 만들기 위해서다. 디플로이먼트는 이름처럼 컨테이너 애플리케이션을 배포하고 관리하는 역할을 담당한다.

 

만일 애플리케이션 컨테이너를 수동으로 업데이트하는 프로세스는 시간이 많이 걸리고 효율이 떨어진다. 서비스를 다음 버전으로 업그레이드하려면 새 버전의 파드를 시작하고, 이전 버전의 파드를 중지하고, 대기한 후 새 버전이 성공적으로 시작되었는지 확인해야 한다. 실패한 경우에는 이전 버전으로 모두 롤백해야한다.

 

이러한 단계를 수작업으로 진행하면 인적 오류가 발생하고 제대로 스크립팅하려면 상당한 노력이 들 수 있으므로, 두 경우 모두 릴리스 프로세스가 걸림돌이 될 수 있다.

 

 디플로이먼트는 이러한 프로세스를 자동화하고 반복 가능하게 만들어 준다. 디플로이먼트는 쿠버네티스 백엔드에서 전적으로 관리되고, 전체 업데이트 프로세스는 클라이언트 상호 작용 없이 서버 측에서 수행된다. 

 배포를 통해 원하는 수의 파드가 항상 실행되고, 가용 상태를 유지하도록 할 수 있다. 또한 업데이트 프로세스는 모두 기록되며 일시 중지, 계속 및 이전 버전으로 롤백 등의 옵션을 통해 버전이 지정된다.

 

디플로이먼트를 통해 애플리케이션을 업데이트할 시, 서비스 무중단을 위해 Pod의 롤링 업데이트* 의 전략을 지정할 수도 있다.

*롤링 업데이트: 기존 버전의 서버를 하나씩 죽이고 새로운 버전의 서버를 하나씩 띄우면서 순차적으로 교체하는 방법

 

---

#References

https://blog.wonizz.tk/2019/09/17/kubernetes-deployment/

https://willseungh0.tistory.com/62

https://willseungh0.tistory.com/55

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