쿠버네티스에서 사용하는 배포 방식에 대해 알아보겠습니다.
우선 배포방식에는 크게 4가지로 나눌수 있습니다.
1. ReCreate
2. Rolling Update
3. Blue / Green
4. Canary
- ReCreate
k8s 의 오브젝트 중에 하나인 Deployment 를 만들면 v1 의 pod 를 생성 후 v2 로 업그레이드를
하면 v1 의 pod 들은 삭제되고 v2 의 pod 가 생성되면서 업데이트가 되게 됩니다.
단, 일시적인 다운타임이 존재하게되고 다운타임이 가능 할 경우에만 진행하는 배포 방식 입니다.
- Rolling Update
Deployment 를 만들면 v1의 pod 들이 생성되고 서비스가 이루어질때 v2 의 pod 를 1개생성
하여 v1 과 v2 가 서비스가 되고 v1 의 pod 를 하나 삭제 후 남은 v2 의 pod 를 만들고 남은 v1
pod 가 삭제되면 v2 의 pod 들 로만 서비스 됩니다.
추가적인 자원이 더 필요하지만 다운타임이 필요없게 됩니다.
- Blue / Green
리플라카셋을 관리하는 Controller 를 만들어서 pod 가 생성되면 pod 가 가지고
있는 라벨이 있기 때문에 서비스에 있는 셀렉트와 연결이 됨.
Controller 를 하나 더 만들어서 v2 버젼의 pod 를 만들고 라벨도 v2이고 자원상용량도 2배가 된다.
서비스에 있는 라벨만 v2 로 변경해주면 v2 버전의 서비스를 사용하게 됨, 순간적으로
변경되기 때문에 서비스 다운타임 없이 서비스가 가능하다.
만약 v2 서비스에 문제가 있다면 라벨만 v1 으로 변경만 해주면 롤백이 쉽게 된다.
문제가 없다면 기존버젼 삭제하면 배포가 마무리 된다.
이 배포방식은 최근 많이 사용하고 안정적인 배포 방식이지만 단점은 자원이 2배가 필요하다는
단점이 존재한다.
- Canary
카나리 배포 - 카나리아 라는 새는 1초에 17번 정도 심장이 뛸정도로 심박수가 높고
공기중에 산소량에 만감해서 금방 죽는다. (광산안에 가스가 새는지 체크하는 곳애 사용)
위험이 없는지 우선 최소로 테스트 하고 이상이 없으면 정식으로 배포하는 방식 이다.
v1 에 대한 pod 에 라벨이 붙어있는 상태에서 서비스에 ty:app 에 연결을 하고 운영하고 있을때
테스트 용도로 Controller를 만들고 레플라카스를 1로 해서 v2 에 대한 pod1 를 만들고
ty:app 에 라밸을 달면 기존 서비스에 연결하고 테스트 하는데 문제가 있다면 레플리카스를 0
으로 해서 대처함.
이 방식은 불특정 다수에게 테스트 할때 사용함.
쿠버네티스 에서 사용하는 일반적인 배포방식에 대해 알아보았습니다.
추가적인 사항은 쿠베네티스 공식홈에서 확인하실 수 있습니다.
https://kubernetes.io/ko/docs/reference/
레퍼런스
kubernetes.io