[쿠버네티스 인 액션] 9장. 디플로이먼트 : 선언적 애플리케이션 업데이트 - 디플로이먼트

9.3 디플로이먼트 사용하기 

- 낮은 수준의 레플리케이션 컨트롤러 또는 레플리카셋이 아닌 높은 수준의 선언적 업데이트 리소스이다. 

 

1) 디플로이먼트 실습

kubectl rollout status deployment kubia

 

디플로이먼트 상태 확인하기 위해 사용되는 명령어 

 

2) 디플로이먼트 전략 

- RollingUpdate 전략 : 새 파드를 만들기 전에 이전 파드를 모두 삭제한다. 

ㄴ 여러 버전을 병렬로 실행하는 것을 지원하지 않고 새 버전을 시작하기 전에 이전 버전을 완전히 중지해야하는 경우 이 전략 사용 

ㄴ 짧은 서비스 다운타임이 발생

- Recreate 전략 : 이전 파드를 하나씩 제거하고 동시에 새 파드를 추가해 전체 프로세스에서 애플리케이션을 계속 사용할 수 있도록 하고 서비스 다운 타임이 없도록 한다. 

ㄴ 애플리케이션이 이전 버전과 새 버전을 동시에 실행할 수 있는 경우에만 이 전략을 수행해야 한다. 

 

3) 디플로이먼트 업데이트

kubectl set image deployment kubia nodejs=luska/kubia:v2

 

- 동작은 kubectl rolling-update 이벤트와 유사하다. 

- 추가 레플리카셋이 생성됐고, 그 후 천천히 스케일업했으며, 이전 레플리카셋의 크기를 0으로 스케일 다운했다. 

 

4) 디플로이먼트 롤백 

kubectl rollout undo deployment kubia
kubectl rollout history deployment kubia
kubectl rollout undo deployment kubia -to-revision=1

 

5) maxSurge와 maxUnavailable 속성 소개 

maxSurge	디플로이먼트가 의도하는 레플리카 수보다 얼마나 많은 파드 인스턴스 수를 허용할 수 있는지 결정한다.  - 기본적으로 25%로 설정되고 의도한 개수보다 최대한 25%더 많은 파드 인스턴스가 있을 수 있다.  - 의도하는 레플리카 수가 4개로 설정된 경우 업데이트 중에 5개 이상의 파드 인스턴스가 실행되지 않는다.
maxUnavailable	업데이트 중에 의도하는 레플리카 수를 기준으로 사용할 수 없는 파드 인스턴스 수를 결정한다.  - 기본적으로 25%이하로 설정되고 사용가능한 파드 인스턴스 수는 의도하는 레플리카 수의 75%이하로 떨어지지 않아야 한다.  - 의도하는 레플리카 수가 4로 설정되고 백분율이 25%이면 하나의 파드만 사용할 수 없다.  - 전체 롤아웃 중에 요청을 처리할 수 있는 파드 인스턴스 3개가 있어야 한다.

 

 

의도하는 레플리카 수가 3이면 maxSurge는 모든 파드 수가 4개에 도달하도록 허용했으며, 사용할 수 없는 파드는 허용하지 않는다. 

 

의도하는 레플리카 수가 3이면 maxSurge는 모든 파드 수가 4개에 도달하도록 허용했으며, 레플리카 한 개를 사용할 수 없는 것을 허용한다. 따라서, 롤아웃 프로세스에서 즉시 파드 한개를 삭제하고 파드 두 개를 만든다. 

 

6) 롤아웃 프로세스 일시 중지, 카나리 빌리즈 canary release

kubectl rollout pause deployment kubia

 

- 카나리 릴리즈는 잘못된 버전의 애플리케이션이 롤아웃돼 모든 사용자에게 영향을 주는 위험을 최소화하는 기술이다. 

- 새 버전을 모든 사람에게 롤아웃 하는 대신 하나 또는 적은 수의 이전 파드만 새 버전으로 바꾼다. 

 

https://kubernetes.io/docs/concepts/workloads/management/#canary-deployments

Managing Workloads

name: frontend
replicas: 3
...
labels:
   app: guestbook
   tier: frontend
   track: stable
...
image: gb-frontend:v3

and then you can create a new release of the guestbook frontend that carries the track label with different value (i.e. canary), so that two sets of pods would not overlap:

name: frontend-canary
replicas: 1
...
labels:
   app: guestbook
   tier: frontend
   track: canary
...
image: gb-frontend:v4