Deployment - Recreate, RollingUpdate

Deplyment

• 현재 한 서비스가 운영 중인데, 이 서비스를 업데이트 해야 돼서 재배포를 해야 될 때 도움을 주는 컨트롤러이다.
• 쿠버네티스에서 배포 전략에 따른 서비스 업데이트 방식은 아래 사진과 같다.

• ReCreate
  1. Deployment를 만들면 v1의 Pod들이 만들어진다.
  2. Pod를 업데이트 하려고 한다면, 해당 Pod를 삭제해준다. -> 서비스에 대한 Downtime 발생
  3. v2에 대한 파드를 만들어준다.
• Rolling Update
  1. Deployment를 만들면 v1의 Pod들이 만들어진다.
  2. 먼저 v2에 대한 파드를 하나 만들어준다.
     • v1과 v2에 모두 서비스가 되고 있기 때문에 누군가는 v1에, 또 다른 누군가는 v2에 접속된다.
     • v1이 사라지지 않은 상태에서 v2를 추가하므로 추가적인 자원을 요구하지만 Downtime이 존재하지 않는 장점이 있다.
  3. v1의 Pod 한 개를 제거해준다.
  4. v1에 대한 Pod가 없어질 때까지 (2, 3)번 작업을 반복한다.
• Blue/Green (Deployment 컨트롤러에 한정된 방식 X)
  1. 컨트롤러를 만들어서 v1의 파드가 생성된다. 이때의 파드는 라벨이 존재하므로, Service와 연결이 된다.
  2. 새로운 컨트롤러를 만들어서 v2의 파드를 생성한다. 이때의 라벨은 v1의 라벨과 다른 값을 띈다. -> 이때 자원 사용량이 기존에 2배가 된다.
  3. Service의 셀렉터를 v1에 대한 라벨에서 v2에 대한 라벨로 변경해준다.
     • 기존 파드, v1의 파드와의 관계는 끊어버리고 v2 버전의 새 파드와 바로 연결이 된다.
     • 순간적으로 변경이 되기 때문에 서비스에 대한 Downtime이 없다.
     • 만약 v2에 문제가 발생하면 다시 셀렉터를 v1에 대한 라벨로 바꿔주면 기존 서비스로 전환이 되므로 롤백이 쉽다.
     • v2에 문제가 없다면 v1에 대한 파드를 모두 삭제해주면 된다.  
• Canary
  1. v1과 v2에 대한 컨트롤러를 만들고, 각각 v1 Pod와 v2 Pod에 대해 서로 다른 Service에 연결해준다.
  2. 유입되는 트래픽을 URL에 따라서 서비스에 연결을 해주는 Ingress Controller를 붙여준다. 
  3. v2에 대한 서비스가 문제가 없으면 v1을 삭제해주며 v2에 대한 URL을 기본 URL로 변경해준다.
     • Downtime X
     • 자원 사용량 ⬆️

ReCreate

• Deployment를 만들 때 ReplicaSet에서 넣었던 selector와 replicas, template 값을 똑같이 넣는다.
  • 이 값들은 Deployment가 직접 파드를 만들어서 관리하기 위한 값들이 아니다.
  • ReplicaSet을 만들고 여기에 값들을 지정하기 위한 용도이다.
• 서비스를 업그레이드 하려면, Deployment의 template를 수정해주면 된다.
  • 기존 ReplicaSet의 replicas를 0으로 변경한다.
  • 수정된 template가 반영된 새로운 ReplicaSet이 생성되고 Pod도 생성된다.

• strategy: type: 에 배포 전략을 넣어주면 된다.
• revisionHistoryLimit(기본값 10) 만큼만 파드가 없는 ReplicaSet을 남겨둔다. 즉, 1의 값을 지정하면 새로운 ReplicaSet 하나와, 기존 중 가장 최근의 생성된 ReplicaSet이 존재하게 된다.

Rolling Update

• ReCreate 방식과 비교했을 때 서비스를 업데이트하기 위해 template를 수정하는 과정까지는 동일하다.
• 새로운 ReplicaSet이 만들어지기 시작하는 과정부터 달라진다.
  • 기존의 ReplicaSet의 replicas를 그대로 두고, 새로운 ReplicaSet이 만들어질 때 Deployment에 지정한 replicas가 아닌, 1의 값부터 시작한다.
  • 이후 기존 ReplicaSet의 replicas를 1로 만들고 새 ReplicaSet의 replicas를 1 증가시켜준다.
  • 마지막으로 기존 ReplicaSet의 replicas를 0으로 만들고 v2로만 서비스를 운영한다.
• ReCreate와 마찬가지로 revisionHistoryLimit에 의해 사용이 끝난 ReplicaSet에 대해 삭제 여부가 결정된다.
• v2에 대한 ReplicaSet이 동일한 라벨을 가지고 있는 v1의 파드를 가리키지 않는 이유는 새로운 ReplicaSet이 만들어질 때 파드에 고유한 라벨을 붙여주고, 새 ReplicaSet 또한 이에 대한 고유한 셀렉터를 가지기 때문이다.

• minReadySeconds(기본값 0) 만큼 파드가 사라지고 생성될 때 텀을 줄 수 있다.
  • 만약 값을 지정 안 해서 기본값 0이 들어가면 v1과 v2의 파드들이 추가되고 삭제되는 게 순식간에 진행된다.

 

롤백

kubectl rollout history deployment deployment-1

• 이 명령어를 통해 Deployment에 의해 생성된 ReplicaSet의 revision을 볼 수 있다.

kubectl rollout undo deployment deployment-1 --to-revision=2

• 이 명령어를 통해 ReplicaSet을 롤백시킬 수 있다.
  • 이 명령어를 통해 이전 버전의 ReplicaSet이 가장 최신 버전이 된다.
  • 즉, revision 값이 1인 것과 2인 것이 있을 때 1로 롤백을 시키고 template를 수정할 시에, revision 값이 2인 것이 사라진다.