배경
지난 시간에서 도커헙에 있는 이미지를 바탕으로 쿠버네티스 클러스터에 컨테이너를 배포하고 서비스를 통해 외부 트래픽 연결까지 해보았다. 요약하자면 전체적인 앱 배포까지의 플로우를 실습했다. 그 다음 업데이트는 어케 할까?
iOS 개발의 경험을 미루어볼 때, 앱스토어에 그냥 새로운 빌드버전을 올리고 심사를 받으면, 유저는 업데이트 버전을 확인하고 새 버전을 다운받거나 자동 업데이트가 되었다.
웹의 경우는 어떨까? 쿠버네티스를 통해 앱 업데이트는 어떻게 이루어지는지 알아보자
롤링 업데이트
롤링 업데이트란 한번에 모든 업데이트가 이루어지지않고 일부 사용자 서버에 부분적으로 업데이트를 적용시켜나가는 방식이다.
이전에 앱을 배포하면 deployment를 통해 하나의 앱이 여러 replica set 파드들로 실행되는 것을 볼 수 있다. 업데이트를 동시에 모든 파드에 적용하는 것이 아니라, 점진적으로 수행해나가는 방식으로 이루어진다. 서비스가 정지되는 다운 타임 없이 업데이트를 적용할 수 있다는 것이 가장 큰 장점이다.
이렇게 되면 일시적으로 가용가능한 파드가 줄어든다. 트래픽은 일정하거나 늘어나는 상황에서 가용 가능 파드가 줄어들면 서비스 장애 리스크가 있다. 따라서 트래픽이 적은 새벽 시간에 롤링이 진행해야하지않나하는 생각이 든다.
사전 준비
이전에 배포했던 앱 이외 업데이트 테스트를 할 새로운 앱을 배포해보자.
쿠버네티스 공식 문서에서 지원하는 앱이다.
kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1아래 명령어로 서비스를 오픈하고 로컬로 접속해보면 아래와 같은 간단한 텍스트를 보여주는 웹 서비스를 볼 수 있다.
kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
롤링 업데이트 실습을 위해 추가로 replica set을 만들어주자
kubectl scale deployments/kubernetes-bootcamp --replicas=4아래 명령어를 통해 조회해보면 deployment 내 컨테이너의 이미지 이름을 볼 수 있다.
kubectl describe deployment kubernetes-bootcamp
컨테이너 내 이미지를 다른 이미지로 업데이트 하고 다시 확인해보자!
업데이트 진행
아래 명령어를 통해 새로운 이미지로 업데이트를 수행한다. 기존 deployments 이름을 입력하고 대체할 이미지 이름을 입력한다.
이전의 이미지에 v2로 태그가 붙은 것을 확인할 수 있다.
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2
"jocatalin/kubernetes-bootcamp:v2"이 이미지로 변경된 것을 볼 수 있다.
실제 이 과정에서 모든 파드들이 가동중단되고 업데이트가 되는 것이 아니라, 4개 중 2개만 먼저 업데이트가 되고, 이 업데이트가 모두 완료되면 나머지 2개가 가동중단되고 업데이트 되는 구조이다.
롤백
이전의 업데이트로 되돌리는 과정도 아주 간단하다. rollout을 사용한 명령어 1줄이면 끝!
ctrl+z 수준으로 간단하다..
kubectl rollout undo deployments/kubernetes-bootcamp명령어 수행 이후 describe으로 확인하면 v1 이미지로 되돌아온 것을 볼 수 있다!
Reference
쿠버네티스 공식 문서
Performing a Rolling Update
