Replicaset, Deployment

Deployment

Deployment는 컨테이너 애플리케이션을 배포하고 관리하는 역할을 수행한다.

템플릿 필드

RollingUpdate: 새로운 파드가 점진적으로 추가되고 이전 파드가 중지된다.
-> 장점: 서비스 중단 현상 없이 Update/Rollback 가능하다.
-> 단점: 구버전과 새 버전이 공존하는 시간이 발생한다.

Recreate: 새로운 파드가 추가되기 전에 모든 이전 파드가 한 번에 중지된다.
-> 단점: 무중단 방식이 아니기 때문에 다운타임이 발생한다.

RollingUpdate 옵션

• maxSurge : 업데이트 중에 동시에 최대로 추가할 수 있는 파드의 수이다.
• maxUnavailable : 업데이트 과정 중에서 동시에 사용 불가능한 상태가 될 수 있는 파드의 수 이다.

Recreate 종류

- Blue/Green: 2가지를 서버에 마련하고 한꺼번에 교체하는 방법이다.

- Canary: 구버전과 신버전을 구성하여 일부 트래픽을 신버전으로 분산시켜 테스트를 진행한 뒤 서서히 옮기는 방식이다.

장점

1. 현재 운영중인 서비스를 업데이트/재배포하는 것에 도움을 주는 컨트롤러이다.
2. 버전 관리의 역할을 수행해준다.
3. ReplicaSet을 생성하는 Deployment를 정의할 수 있고 배포 작업을 좀 더 세분화하여 조작이 가능하다.
4. 새로운 버전의 컨테이너 애플리케이션을 다양한 전략으로 배포할 수 있게 한다.

ReplicaSet

ReplicaSet: 의도한 Pod 개수를 충족하기 위해 다른 워커 노드에 새로운 Pod를 띄워 개수를 맞춘다.

Pod 갯수가 부족할경우: ReplicaSet이 관리하고자 하는 Pod의 갯수보다 실제 동작중인 Pod의 갯수가 부족하다면 부족한 만큼 추가적인 Pod를 생성하여 갯수를 맞춘다.

Pod 갯수가 초과할경우: ReplicaSet이 관리하고자 하는 Pod의 갯수를 실제 동작중인 Pod의 갯수가 초과한다면 초과된 갯수만큼 Pod를 종료하여 없앤다.

Replica set vs Deployment

Deployment가 좀 더 좋은거 같다.

이유
1. deployment같은 경우 배포를 관리하고 Replica set를 쉽게 업데이트한다.
2. deployment와 같은 경우 Repica set의 변경 사항을 저장하는 Revision을 남기기 때문에 Repica set과 달리 Rollback 이 가능하다.