[도커/쿠버네티스 기초] Kubernetes Deployment 배포 - Recreate, RollingUpdate, Blue/Green, Canary

현재 서비스에 대한 배포가 필요할 때 이에 대한 도움을 주는 것이 Deployment 컨트롤러입니다. 배포에는 ReCeate, Rolling Update, Blue/Green, Canary 방식이 존재합니다.

1. Recreate
Deployment 컨트롤러를 만들면 Ver 1.0에서 Ver 2.0으로 배포를 하기 위해 먼저 Ver 1.0의 Pod를 삭제합니다. 그렇게 되면 서비스에 대한 다운타임이 발생하게 됩니다. 그 이후 Ver 2.0에 대한 Pod를 생성하게 됩니다. 이 경우엔 서비스 다운이 일어나기 때문에 일시적인 정지가 가능한 서비스만 사용이 가능한 배포 방식입니다.

2. RollingUpdate
Ver 1.0 에서 Ver 2.0으로 배포를 하기 위해 먼저 Deployment는 Ver 2.0의 Pod를 생성합니다. 그럼 Ver 1.0과 2.0이 모두 사용되기 때문에 그만큼 자원 사용률이 늘어나게 됩니다. 1.0 버전과 2.0 버전 모두 서비스를 하게 되기 때문에 누군가는 1.0 버전을 사용하고 누군가는 2.0 버전을 사용하게 됩니다. 그 이후 Ver 1.0의 Pod를 1개를 삭제하고 이후 남은 Ver 2.0의 Pod를 하나 더 생성하고 남은 Ver 1.0 Pod를 삭제합니다. 완료된 이후에는 2.0 버전의 서비스로만 사용을 하게 됩니다. 이 배포 방식의 경우 추가적인 자원 사용을 요구하지만 서비스의 다운타임이 없어 연속적인 서비스가 가능합니다.

 

3. Blue/Green
해당 배포는 replicas를 이용하는 모든 컨트롤러로 배포가 가능합니다. Ver 0.1에 대한 Pod로 서비스를 할 경우, 새로운 컨트롤러를 만들어서 Ver 0.2의 Pod를 생성합니다. 각각의 Pod는 서로 다른 Label을 가지도록 하고 기존 Service와 Ver 0.1이 라벨을 통해서 연결이 되어있었다면 새로 생성된 라벨로 변경함으로써 업그레이드된 버전으로 서비스를 하게 됩니다. 순간적으로 변경되기 때문에 서비스에 대한 다운타임은 없습니다.
만약 배포 후, Ver 2.0에 문제가 발생한다면 라벨만 1.0으로 변경하면 이전 버전으로 쉽게 롤백이 된다는 장점이 있습니다. 문제가 없다면 기존 1.0 버전의 Pod는 삭제를 하면 됩니다. 해당 배포의 단점은 1.0과 2.0을 동시에 가지고 있어야하기 때문에 자원이 2배가 필요하다는 것입니다.

4. Canary
실험체를 통해서 시험을 해보고 문제가 없다면 정식으로 배포를 진행하는 방식입니다.
해당 방식은 두 가지로 구분을 할 수 있는데 하나는 동일한 Service에 Ver 1.0과 2.0의 Pod를 연결해놓고 가중치를 주어 일부의 트래픽은 1.0으로 일부는 2.0 버전으로 접근되도록 설정하는 방식입니다. 테스트 중 2.0 버전에 문제가 발생할 경우 가중치를 0으로 설정하면 더 이상 트래픽이 할당되지 않아 접근이 되지 않습니다. 해당 방식은 불특정 다수에게 테스팅을 하도록 하는 방식입니다.
두 번째로는 각각의 Service를 버전마다 생성하고, Ingress Controller를 통해 URL Path에 따라서 연결을 합니다. 예를 들면 Ver1.0은 /service 주소를 가지고, Ver2.0은 /V2/service 주소를 가지게 되면 특정 원하는 트래픽에 대해서만 V2 Path로 접근하도록 설정할 수가 있고 2.0 버전이 문제가 없다면 Pod를 늘려주어 정식 배포를 하고 1.0 버전의 Pod는 삭제를 합니다. 그 이후 2.0의 Path를 /service로 변경하여 원래의 URL로 서비스를 하도록 하는 방식입니다.
Canary 배포 방식 또한 다운타임이 존재하지 않습니다.