쿠버네티스 - 디플로이먼트의 배포 방식 :: 롤링 업데이트

목차

배포 방식 - 롤링업데이트

 

 

---

 

 

 

디플로이먼트는 애플리케이션을 배포하고 업데이트를 수행하는 리소스다.
이를 통해 배포하는 방식은 크게 네 가지로 분류되며, 방법마다 장단점이 존재한다.
따라서 서비스에 적합한 배포 방식을 채택해야 한다.

오늘은 가장 기본적이자 대표적으로 쓰이는 롤링업데이트 방식에 대해서 포스팅을 할 예정이다.

 

 

 

 

 

01. 배포 방식 - 롤링업데이트

 

앞선 글에서, 디플로이먼트의 개념 및 이점을 포스팅했었다.

 

(이전 게시물)

쿠버네티스란? 주요 개념 익혀보기 - 레플리카셋, 디플로이먼트, 서비스

(여기서 언급한 디플로이먼트의 장점은, 롤링업데이트 방식의 디플로이먼트 배포 방식일 때 적용되는 장점이다.)

 

롤링업데이트 방식이란, 기존 파드들을 하나씩 삭제 그리고 하나씩 재배포하며, 제로 다운타임을 보장하는 배포 방식을 말한다.

GCP GKE에선 일반적으로 디폴트 방식으로 설정된다.

 

• 장점: 제로 다운타임 (무중단)
• 단점: 배포 중간 과정에서는 이전 버전과 업그레이드 버전이 공존할 수 있음

 

 

 

글로만 보면 이해가 어려울 수 있을 것 같아, 하나의 짧은 프레젠테이션 영상을 준비해보았다.

 

 

 

 

 

 

이처럼, 3개의 파드가 띄워졌을 때, 크게 6단계로 동작한다고 볼 수 있다.

해당 동영상의 페이지를 순서대로 살펴보자.

 

 

 

 

 

 

 

1. 우선 우리는 디플로이먼트를 통해, v1 -> v2로 업그레이드를 하고 싶다고 가정한다.

레플리카셋 사이즈는 3으로 설정되었다고 가정한다. 

이때, 아직 업그레이드가 된 것은 아니니, v1에 3개의 파드가 띄워져 있고, 이들은 모두 정상적으로 동작한다.

 

 

 

2. 디플로이먼트를 통해 롤링업데이트방식 배포를 시작한다.

이때 배포될 리소스(파드)는 우선 한 개가 생성된다. 여기서는 pod1을 대체할 하나의 파드가 생성되었다. 이는 아직 정상실행되고 있지는 않다.

왜냐하면 레플리카셋이 3으로 설정되었기 때문에, 디플로이먼트는 이 개수를 제어하고 있기 때문이다.

(아직 v1의 3개의 파드들이 모두 잘 작동하고 있다.)

 

 

 

 

 

 

3. v1 - pod1을 대체할 v2 - pod1가 실행됨과 동시에, v1 - pod1은 종료된다.

이러면 현재 레플리카셋 설정에 따라 총 3개의 파드가 실행되고 있으면서, 파드의 일부분이 업데이트가 된 것을 알 수 있다.

(여기서 롤링업데이트 방식의 단점(배포 중간 과정에서는 이전 버전과 업그레이드 버전이 공존할 수 있음)이 나타난다.)

 

이제, v1 - pod2을 대체할  v2 - pod2가 생성된다. 앞 전의  v2 - pod1의 상태와 마찬가지로, 아직은 NotReady 상태다.

 

 

 

 

 

 

4. 이전의 단계와 마찬가지로, v1 - pod2을 대체할 v2 - pod2가 실행됨과 동시에, v1 - pod2은 종료된다.

이러면 여전히 총 3개의 파드가 실행되고 있으면서, 파드의 일부분이 더 업데이트 됐다.

 

마찬가지로, 나머지 v1 - pod3을 대체할  v2 - pod3가 생성된다.

이 v2 - pod3 또한, 아직 v1 - pod3이 작동 중이기 때문에, 아직은 NotReady 상태다.

 

 

 

 

 

 

5. 마지막으로, v1 - pod3을 대체할 v2 - pod3가 실행됨과 동시에, v1 - pod3도 종료된다.

 

 

 

 

 

 

6. 이러면 모든 파드들이 ReplicaSet v2버전으로 모두 업데이트된 것을 알 수가 있다.

이 과정에서, 레플리카셋 설정이 3이었기 때문에, 계속 3개의 파드가 띄워졌을 뿐만 아니라, 제로다운타임(무중단) 기반의 배포가 이뤄졌음을 알 수 있었다.

 

 

 

 

 

---

 

 

요즘 회사에서 가장 많이 언급되는 단어 중 하나가 "무중단"이다.

예전 서비스 형태들은, 하나에 모든 기능이 있는 모놀리식 구조였기 때문에 배포가 비교적 많이 이뤄지지 않았다고 하지만,

요즘 트렌드는 마이크로 서비스 구조로 바뀌었기 때문에, 자주 배포를 진행해야 하는 방식으로 바뀌었다고 한다.

 

배포가 잦아짐에 따라, 배포를 할 때마다 서비스가 정지되면 곤란하므로,

안전한 무중단 배포에 대한 니즈 그리고 중요성이 대두되고 있는 것 같다. 

 

이러한 변화 지점에서, 쿠버네티스는 비교적 안정적인 배포 방식을 제공하기 때문에 좋은 것 같다.

(여담 .. 쿠버네티스 개발자 분들은 참 대단한 것 같다..)

 

 

 

그럼 오늘의 포스팅은 여기서 마무리하며, 이후에는 다른 배포 (리크리에이트, 블루앤그린, 카나리) 방식에 대해 포스팅해보도록 하겠다.

 

 

 

 

공부를 통해 배운 내용을 작성하고 있습니다. 혹여 해당 포스팅에서 잘못된 부분이 있을 경우, 알려주시면 빠르게 수정 조치 하도록 하겠습니다. 오늘도 읽어주셔서 감사합니다!