[k8s] 14. Deployment - Recreate, RollingUpdate

Controller - Deployment

• 현재 서비스를 업데이트 할 때 재배포를 하기 위함
• 대표적으로 ReCreate, Rolling Update, Blue/Green, Canary 방식이 있음

1. ReCreate

• Deployment를 만들면 v1 파드들이 만들어 짐
• 파드 하나당 자원 하나 사용한다고 가정
• 먼저 파드 삭제 후, Downtime동안 자원을 사용하지 않음
• 그 다음 파드 v2를 만들고 다시 자원 할당
• 단점은 Downtime이 발생해서 일시적으로 중단가능한 서비스에만 쓰임

2. Rolling Update

• ReCreate과 달리 v1을 삭제하지 않고 v2를 생성
• 자원은 3개가 되고, 접속하는 사람은 v1이나 v2에 접속하게 됨
• v1을 삭제하고, v2 생성
• 마지막으로 남은 v1을 삭제하여 v2로 업데이트 완료
• 단점: 자원을 추가로 요구, 장점: DownTime이 없음

3. Blue/Green

• Deployment에서 제공되는 기능이 아님
• Replicas를 관리하는 컨트롤러를 이용함
• Controller를 만들고 Pod v1 생성하고 Service에 연결
• 컨트롤러를 추가로 만들고 v2 버전 파드 생성
• 이 때 자원 사용량은 2배가 됨
• 서비스의 셀렉터를 v2로 변경하여 v2 버전의 파드와 연결 --> 순간적으로 변경
• v2에 문제가 발생하면 서비스의 라벨을 v1으로 변경하여 문제 시 롤백 가능
• 문제가 없으면 기존 버전 파드 삭제
• 상당히 많이 사용하고 안정적인 배포 방식이지만 자원이 2배로 필요

4. Canary

• 카나리아는 심장이 1초에 17번 뛸정도로 예민해서 공기질이 나쁘면 바로 죽음
• 결론은 실험용 불쌍한 테스트 새임

한 서비스에 연결시키는 방식

• 컨트롤러에 ty:app라벨과 ver:v1라벨이 붙은 파드를 만들고 ty:app 라벨을 가진 서비스에 연결시킴
• 또 다른 컨트롤러에 ty:app라벨과 ver:v2라벨을 붙인 파드를 만들고 위에 나온 서비스에 연결시킴
• 이렇게하면 사용자는 v1이나 v2에 임의로 연결됨
• 문제가 생기면 문제가 생긴 컨트롤러의 replicas를 0으로 만듦

각각의 서비스에 연결시키는 방식

• v1(2개)은 v1으로 v2(1개)는 v2로 서비스를 연결시킴
• Ingress Controller 컨트롤러로 입력된 url에 따라 서비스로 이동시킴(/app은 v1, /v2/app은 v2로)
• 특정 타겟을 정하고 테스팅 가능
• 테스트 기간이 종료되면 v2 파드를 증가시키고 v1 파드 삭제, Ingress Controller 설정 변경(/v2/app --> /app)
• Zero Downtime이고, 자원 사용량은 최대 2배까지 필요
• 중급강좌때 다룰 예정
• 이 글에선 Recreate과 Rolling Update를 다룸

---

ReCreate, Rolling Update (default)

Recreate

• Deployment를 만들 때, selector, replicas, template을 넣음(ReplicaSet처럼)
• 이 값들은 Deployment에서 직접 만드는게 아니라 ReplicaSet을 만들고 거기서 참고하기 위한 값
• ReplicaSet은 참고한 내용으로 파드들을 만듦
• type:app 서비스를 만들어서 파드의 type:app 라벨에 연결하면 서비스를 통해서 파드에 접근 가능
• Recreate 업데이트를 위해 template을 v2로 변경
• v1 ReplicaSet의 replicas를 0으로 변경 --> 파드 삭제, Downtime 발생
• 새로운 v2 ReplicaSet 생성, 템플릿에는 v2를 넣음 --> v2 파드 생성
• 서비스는 type:app 라벨이므로, v2와 연결됨

Sample YAML

• Deployment에 selector, template, replicas가 들어감
• 배포방식으로 strategy에 type: Recreate이 있네
• revisionHistoryLimit 1: 새로 ReplicaSet을 생성할 때 기존 ReplicaSet을 1개까지만 남기겠다, Default: 10
• replicas가 0이된 ReplicaSet은 버전을 되돌릴 때 사용됨

Rolling Update (default)

• 서비스가 운영중인 상태에서, Deployment에서 새로 템플릿을 v1에서 v2로 교체
• 새로 만든 ReplicaSet의 replicas를 1로 설정 --> 파드 1개 생성, type:app 서비스와 연결
• v1, v2에 트래픽이 분산되며 연결
• v1 ReplicaSet의 replicas를 1로 변경하고 v2의 ReplicaSet의 replicas를 2로 변경
• 마지막으로 v1의 ReplicaSet의 replicas를 0으로 변경
• 기존 ReplicaSet을 지우진 않음

Sample YAML

• strategy, type: RollingUpate
• minReadySeconds: 이 값 없이 업데이트를 하면 v1, v2가 추가되고 삭제되는게 순간적인데, 10과 같은 값을 두면 텀을 줌 --> 실습과정용

Rolling Update 중 v2 ReplicaSet은 왜 v1 파드에 연결되지 않았을까?

• Selector는 똑같이 type:app인데 왜 연결되지 않았을까?
• ReplicaSet에서 추가적인 라벨과 셀렉터를 만듦

출처

인프런 - 대세는 쿠버네티스