Deployment Strategy
Recreate strategy
애플리케이션 인스턴스의 기존 버전을 모두 삭제한 뒤, 새로운 버전의 애플리케이션 인스턴스를 생성하여 배포하는 방식
기존 버전을 중단한 후, 새로운 버전이 동작하기 전까지 애플리케이션의 서비스 중단이 발생한다.
Rolling Updates
서버를 실제로 서비스할 때 서비스적인 장애와 배포에 있어서 부담감을 최소화하고, 서비스가 중단되지 않도록 배포하는 무중단 배포 방법 중 하나
새 버전을 배포하면서, 새 버전 인스턴스를 하나씩 늘려가고 기존 버전의 인스턴스를 하나식 줄여나가는 방식
새 버전의 인스턴스로 트래픽이 이전되기 전까지 이전 버전과 새 버전의 인스턴스가 동시에 존재할 수 있다는 단점이 있지만, 시스템을 무중단으로 업데이트할 수 있다.
deployment 생성 시 strategy를 지정하지 않으면 rolling update 방식으로 배포하는 것으로 간주한다.
두 방식의 동작 차이는 describe deployment 명령으로도 확인할 수 있다.
kubectl describe deployment <NAME>Rollouts
애플리케이션 컨테이너를 점진적으로 배포하거나 업그레이드하는 프로세스
새 deployment를 생성하거나 기존 deployment의 이미지를 업그레이드할 때마다 트리거 된다.
애플리케이션 업그레이드 시 새로운 rollout이 트리거 되고, 이 rollout이 새로운 버전의 deployment를 생성한다.
또한 deployment의 변경 사항을 확인하고, 이전 버전의 deployment로 되돌릴 수 있게 한다.
명령어
# rollout 상태 확인
kubectl rollout status deployment/<NAME>
# rollout 이력 확인
kubectl rollout history deployment/<NAME>
Upgrade
도커 컨테이너 버전, 레이블, replicas 수를 수정하는 등의 작업이 있을 수 있다.
보통 yaml 형식의 deployment 정의 파일을 수정한 뒤, apply 명령으로 반영한다.
kubectl apply -f <FILE>
deployment에 사용하는 이미지를 수정하는 경우에는, 아래와 같이 set 명령어를 사용할 수도 있다.
kubectl set image deployment/<DEPLOYMENT_NAME> <CONTAINER_NAME>=<IMAGE>
# 예시
kubectl set image deployment/my-app nginx=nginx:1.9.1이 경우 기존 정의 파일과 구성이 달라지기 때문에, 추후 정의 파일을 재사용할 때 주의해야 한다.
업그레이드를 진행하면 쿠버네티스 deployment 개체가 새 replicaset를 생성하고 컨테이너를 배치한다. 그리고 update Strategy에 따라 이전 replicaset의 pod를 중단한다.
이전 replicaset의 포드 수나 새 resplicaset의 포드 수 등에 대한 정보는 아래 명령어로 확인할 수 있다.
kubectl get replicasets
Rollback
애플리케이션 업데이트 후 문제가 발생하여, 업데이트를 되돌리고 싶다면 rollout undo 명령을 사용하면 된다.
kubectl rollout undo deployment/<NAME>rollout undo 명령을 실행하면 새로 생성한 replicaset의 pod는 삭제하고, 이전 replicaset의 pod를 다시 생성한다.
참고 문서
https://www.weave.works/blog/kubernetes-deployment-strategies