디플로이먼트(Deployment)
디플로이먼트는 레플리카 셋 대신 애플리케이션을 배포하고 선언적으로 업데이트 하는 리소스다.
디플로이먼트를 생성하면 레플리카셋 리소스가 생성되고, 레플리카셋 리소스가 파드를 관리한다.
- 디플로이먼트를 만드는 이유
애플리케이션을 업데이트 할 때 추가 레프리카 셋을 만들고 배포를 하는 방식을 통제하여야 하는데, 이를 디플로이먼트가 관리한다.
ex) 낮은 수준의 배포(kubectl을 통한 배포)를 진행하는 중 작업중인 노드가 내려간다면, 배포 중간 상태로 배포가 마무리된다.
디플로이먼트가 레플리카셋을 생성, 레플리카셋이 파드를 생성
디플로이먼트를 작성하며 레플리카셋이 생성한 파드의 이름을 조회하면 <디플로이먼트 이름> + <레플리카셋 해시값> + <파드 해시값> 으로 구성된다.
레플리카셋의 이름은 <디플로이먼트 이름> + <레플리카셋 해시값> 으로 생성되며 이는 레플리카셋이 해당 파드를 관리함을 의미한다.
디플로이먼트가 파드의 템플릿 버전별로 레플리카셋을 생성하기 때문에, 파드 템플릿의 해시값을 사용하면 디플로이먼트에서 지정된 버전의 파드 템플릿에 대하여 항상 동일한 레플리카셋을 사용 할 수 있다.
디플로이먼트 전략
Rolling Update
기본 전략. 하나씩 기존 파드를 제거하고 신규 파드로 교체한다.
Recreate
모든 기존 파드를 삭제한 뒤 새로운 파드를 만들어 낸다. 서비스 다운타임이 발생한다.
신규 파드 업데이트 이후 레플리카셋이 남아있는 이유
$kubectl get rs 와 같은 명령으로 레플리카셋을 조회해보면 기존에 사용되었던 레플리카셋이 지워지지 않고 남아있다. 디플로이먼트에 의해 관리되는데, 업데이트가 끝난 이후에 왜 계속 남아있을까?
디플로이먼트 롤백
새로 배포된 파드 템플릿에서 오류가 발생한 경우 롤아웃을 되돌려야 한다. 이 때, 디플로이먼트를 사용하여 마지막 혹은 정해진 버전으로 쉽게 롤백할 수 있다. 삭제되지 않은 레플리카셋은 이 때 사용된다.
모든 개정 내역의 수는 디폴로이먼트 리소스의 editionHistoryLimit 속성에 의해 제한된다.(쿠버네티스 버전이 올라가면서 revisionHistoryLimit로 변경)
maxSurge와 maxUnavailable
maxSurge
디플로이먼트가 의도하는 레플리카 수보다 얼마나 많은 파드 인스턴스 수를 허용할 것인지. 백분율 혹은 절대값으로 지정. 기본값 25%
maxUnavailable
업데이트 중 의도하는 레플리카 수(Desired State) 기준으로 사용할 수 없는 파드 인스턴스 수. 백분율 혹은 절대값으로 지정. 기본값 25%
minReadySeconds
일정시간동안 준비상태를 검사하여 rollout하는 디플로이먼트 spec의 리소스 속성이다.
오작동 버전의 배포를 방지할 수 있다.
사용 가능한 파드가 되려면 minReadySeconds 기간동안 readiness probe가 성공해야 한다.
롤아웃 데드라인
기본적으로 10분동안 롤아웃이 진행되지 않으면 실패한것으로 간주된다.
디플로이먼트의 ProgressDeadlineExceeded 으로 확인 할 수 있다.
디플로이먼트 스펙의 progressDeadlineSeconds 속성으로 정의 할 수 있다.
'OS & Container > Kubernetes' 카테고리의 다른 글
[쿠버네티스] StatefulSet (0) | 2021.07.03 |
---|---|
[쿠버네티스] Service (0) | 2021.07.01 |
[쿠버네티스] Liveness Probe (0) | 2021.07.01 |
Ubuntu 18.04에서 kubeadm으로 Kubernetes Cluster 구축하기 (0) | 2021.01.29 |