2. Deployment - Recreate, RollingUpdate
배포의 종류 및 작동법
Recreate
- v1의 Pod들이 만들어진다(Pod 하나당 자원이 하나씩 할당)
- Deployment 시 기존 Pod을 삭제한다
- 이때 서비스에 대한 downtime 발생
- 이에 따라 자원 사용량도 없어진다
- v2의 대한 Pod을 생성한다
Recreate으로 버전 업그레이드시 downtime이 발생하여 일시적 정지가 가능한 서비스에만 적용 가능
Rolling Update
- Deployment는 v2에 해당하는 Pod을 생성한다
- v1의 Pod은 여전히 서비스 중임으로 전체적인 Pod의 자원 사용량은 증가된 상태이다
- v1버전과 v2버전의 Pod이 모두 서비스 중인 상태이다
- v1의 팟을 하나 삭제하고 해당 서비스 트래픽을 생성한 v2로 연결
- 이러한 방식으로 트래픽을 돌리면서 v1의 Pod을 삭제하고 그만큼 v2버전의 Pod의 갯수를 늘려가며 버전 업그레이드 시킨다
downtime은 발생하지 않지만 전체적인 자원사용량이 증가하는 시기가 있다 그러나 Pod이 삭제됨으로 Rollback이 용이하지 않음
Blue/Green
- Deployment가 기본적으로 제공하는 기능은 아니다
- Controller로 사용 가능하다
- Service의 Label로 Pod이 연결되어있다
- Controller_1에 v1 Pod들이 관리되고있다(label : ver1)
- Controller_2에 v2 Pod들을 생성시켜 놓는다(label : ver2)
- Service의 연결 Label을 ver1 -> ver2로 변경시킨다
- 서비스에 문제가 없다면 Controller_1의 Pod을 삭제한다
downtime이 발생하지 않는다, 기존 Pod계속 남아있음으로 새로 생성된 Pod에 문제가 생기는 경우 Rollback이 용이하다. 그러나 똑같은 Pod의 수만큼 생성해야 함으로 자원 사용량이 2배 필요하다
Canary
카나리아의 유래
카나리아라는 새는 원래 bpm이 빠르다. 즉 유해한 환경에도 민감하게 반응하여 죽음
이러한 유래를 바탕으로 서비스에 약간의 문제만 발생하여도 바로 감지하도록 설정하는 의미로 쓰인다
불특정 다수를 테스트하는법
- blue/green처럼 label을 설정하는데, type에도 label을 설정하여 이를 바탕으로 Pod을 연결시켜 놓는다
- ReplicaSet으로 테스트 컨트롤러를 만들고 이를 바탕으로 v2버전의 Pod을 생성시켜놓는다
- 즉 트래픽이 v1버전의 Pod과 v2버전의 Pod(테스트용)으로 둘다 서비스 된다
- 만일 테스트중 장애가 발생했다면 ReplicaSet을 0으로 수정하여 테스트 서비스를 종료 시킨다
특정 다수를 테스트 하는법
- Ingress Controller를 사용하여 URL path에 따라 서비스를 연결하도록 지정
- 기본 v1 Pod이 서비스하는 url을 /app이라 하면 v2테스트 Pod url은 /v2/app으로 지정(예시)
- url자체에 지정을 했음으로 글로벌 서비스에서 해당 지역을 테스트할 떄 용이하다
- 테스트 Pod에 문제가 없다고 판단되면 v1 Pod을 삭제하고 v2 Pod을 기본 url로 지정한다
downtime이 없고 테스트 후 서비스함으로 장애 발생율이 적으며, 자원증가량을 조절하기가 용이하다
