Controller - Deployment의 네 가지 방식

Deployment란?

현재 한 서비스가 운영중인데 이 서비스를 업데이트해야 할 때 재배포하는 상황에 도움을 주는 Controller이다!

 

몇 가지 일반적으로 사용되는 업그레이드 방식이 Kubernetes에서 어떻게 사용되는지 전반적인 설명을 알아보자

대표적인 네 가지 Deployment의 Upgrade 방식

위와 같이 대표적으로 총 4가지 업그레이드 방식이 있다.

• ReCreate
• Rolling Update
• Blue/Green
• Canary

ReCreate

pod를 삭제하고 다시 생성하는 방식

Deployment에서 v1의 pod들이 만들어진다.

Deployment에서 v1 Pod 구성

pod하나당 하나의 자원이 필요하다고 가정하자.

ReCreate 업그레이드를 진행하면

1. v1 pod를 먼저 삭제한다
2. 서비스에 대한 DownTime이 발생한다.
3. 자원 사용량도 없어지게 된다.
4. v2 pod를 만들어준다.

이 방식은 DownTime이 발생하기 때문에 일시적인 정지가 가능한 서비스일 때 사용 가능

ReCreate와 Rolling update 비교

Rolling Update

v2의 pod를 먼저 생성한 후 v1 pod를 삭제하여 DownTime이 없다

 

Rolling Update 업그레이드를 진행하면

1. v2 pod를 먼저 생성한다.
2. 자원 사용량이 늘어난다.
3. v1 pod를 삭제한다.
4. v2 pod를 더 생성한다.
5. 나머지 v1 pod를 삭제한다.

자원이 더 필요하지만 DownTime이 없다는 큰 장점을 가지고있다.

 

 

Blue/Green

(ReplicaSet) controller의 pod 자동 생성과 Service의 label 매칭을 활용한 업데이트 방식

deployment 자체로 제공되는 기능은 아님!
(1) deployment를 사용해서 구현 가능
(2) ReplicaSet 처럼 Replicas를 관리하는 모든 controller를 이용해서 구현 가능

controller를 이용해 업그레이드를 진행하는 경우

1. controller를 이용해서 pod를 생성
2. pod는 label이 있기때문에 Sevice의 selector와 연결 가능(운영이 되고 있다)
3. v2 pod를 생성하는 controller를 하나 더 만든다(label도 v2이다)
4. 자원 사용량은 기존에 2배가 된다.
5. Service에 있는 label만 변경하게 되면 기존 pod와의 관계가 끊김
6. v2 pod와 바로 연결이 가능
7. 순간적으로 변경되기 때문에 DownTime이 없다.
8. 사용자는 v2의 서비스를 사용하게 됨
9. v2 Service에 문제가 없다면 v1 pod를 삭제한다.

Blue/Green Upgrade 방식

배포 중 v2에 문제가 생기면?
만약 v2에 문제가 생기면 Service에 label만 변경해주면 v1으로 다시 roll back할 수 있다.
v2 pod에 문제가 없을 경우 v1 pod를 삭제하면 된다.

상당히 많이 사용되고있는 안정적인 배포 방식임!

하지만 자원이 두배나 필요하다는 단점이 있다. 

 

Canary

(ReplicaSet) controller의 pod 자동 생성, replicas 설정과 Service의 label 매칭을 활용한 업데이트 방식

테스트를 진행한 후 문제가 없으면 Upgrade를 진행함

Canary 배포의 유례

심박수가 매우 높고 공기 중에 산소량에 민감해 유해한 공기를 마시면 금방 죽음
카나리아를 통해 일산화탄소 등을 감지하는데 사용했다고 함
이렇게 실험체를 통해 위험이 없다고 감지하면 정식으로 배포하는 방식!

Canary

불특정 다수에 대한 Testing 후 Upgrade

Canary Upgrade 방식 - 불특정 다수

1. controller를 활용해 v1 pod를 생성
2. Service에 v1이 아닌 type에 label을 달아서 연결을 해서 운영함
3. test용으로 controller를 만들 때 replicas를 1로 설정해 v2 pod를 하나 생성한다.(label type은 동일)
4. Service에 모두 연결되어 일부 트래픽이 v2 pod로 접근이 된다.
5. v1 v2 버전에 대해 모두 test가 되고 문제가 발생하면 v2의 controller replicas를 0으로 생성
6. 문제가 없다면 v2 pod를 더 생성한 후 v1 pod를 삭제

특정 타겟을 정하고 Testing하는 방식

1. v1과 v2의 Service를 각각 만들어준다.
2. Ingress controller를 활용해 유입되는 트래픽을 URL 경로에 따라 Service에 연결해준다.
3. path 앞 /v2/를 입력하면 새로운 Service를 이용할 수 있음
4. Testing 문제가 없다면 v2 Pod를 증가시키고 Ingress controller path 설정 변경
5. v1 Pod와 Service 삭제

Canary 방식에서 Ingress controller가 특정 타겟의 Testing을 도와줌

예를 들어, 미국에서 새로운 Service를 먼저 배포해서 Test 기간을 갖고 싶은 경우
미국의 트래픽에 대해 path 앞 /v2/를 넣어 v2 Service에 연결해준다.

DownTime이 존재하지 않음!

자원 사용량은 Test를 할 Pod의 수나 v2 Pod 생성 대비 v1 Pod를 down시킬 수 있어

자원 상황에 맞게 적용시킬 수 있다는 장점이 있다!