0. 삭제 명령
시작하기 전에, 다음의 삭제 명령을 이용하여 이미 만들어진 객체들을 정리할 수 있다.
kubectl delete 객체종류 객체ID모든 객체 삭제
kubectl delete all --all--all 대신에 -n 네임스페이스(레이블)을 설정할 수 있다.
파드 강제 삭제
pod가 종료되었는데도 삭제되지 않는 경우가 있는데, 이 경우는 강제 삭제를 이용한다.
kubectl delete pods 파드ID --grade-period 0 --force1. 쿠버네티스의 업데이트 전략
롤링 업데이트
- 정해진 비율만큼의 파드만 점진적으로 배포해나가는 방식
- 최대로 생성할 수 있는 파드의 개수와 최대로 삭제할 수 있는 파드의 개수를 옵션으로 설정해서 업데이트한다.
쿠버네티스 리소스 중에는 디플로이먼트, 데몬셋, 스테이트풀셋이 롤링 업데이트를 지원한다.
블루/그린 업데이트
버전을 구성해서 이전 버전과 새로운 버전에 해당하는 파드를 전부 생성해두고, 트래픽을 새로운 버전으로 전달하는 방식
카나리 업데이트
새로운 버전의 일부만 배포해두고 트래픽도 일부만 새로운 버전으로 전달한다.
배포에 문제가 없으면 점진적으로 새로운 버전을 배포하거나 트래픽을 전환하는 방식
2. 쿠버네티스의 롤링 업데이트
디플로이먼트의 정의를 수정해서 배포하는 경우, 롤링 업데이트를 수행한다.
- 레플리카의 수만 조정한 경우에는 롤링 업데이트(rollout)가 발생하지 않는다.
롤아웃(rollout)
배포를 변경하는 것.
레플리카셋을 새로 만들어 레플리카 수를 지정된 숫자만큼 늘린 후 기존 레플리카의 레플리카 수를 0으로 낮추는 식으로 이루어진다.
롤아웃은 파드의 정의가 변경될 때만 일어난다. 기존 레플리카 수 등 레플리카셋을 유지하며 반영할 수 있는 변경에는 롤아웃이 일어나지 않는다.
이미지를 변경하거나 다른 설정을 변경해서 배포하면, 쿠버네티스는 새로운 버전의 파드를 만든다.
그리고 이 새로운 버전의 파드가 replica 개수만큼 생성이 되면, 이전 버전의 replica를 0으로 만들어서 업데이트를 완료한다.
실습 1) 애플리케이션 스케일링 후 레플리카셋 확인하기
레플리카 수가 2개인 간단한 애플리케이션을 배치한다.
그리고 이 애플리케이션을 스케일링한 후 레플리카셋에 어떤 일이 일어나는지 살펴보겠다.
* 이 실습은 교재의 예제 실습 파일로 진행한다.
cd ch09
# 간단한 웹 애플리케이션을 배치
cd kubectl apply -f vweb/
# 레플리카셋 확인
kubectl get rs -l app=vweb
# 애플리케이션 스케일링
kubectl apply -f vweb/update/vweb-v1-scale.yaml
이 디플로이먼트에 필요한 파드는 2개다. 파드는 레플리카셋으로 관리한다.
# 레플리카셋 다시 확인
kubectl get rs -l app=vweb
스케일링은 기존 레플리카셋만으로 진행된다.
디플로이먼트의 롤아웃 히스토리를 확인한다.
kubectl rollout history deploy/vweb
롤아웃 히스토리를 보면 업데이트가 1건 뿐이다. 파드의 스케일링은 롤아웃을 일으키지 않으므로 초기 배치에 해당하는 한 건만 출력된다. (스케일링 업데이트가 레플리카셋 숫자만 변경했기 때문에 두번째 롤아웃이 일어나지 않는다.)
실습 2) kubectl set 명령 이용하여 디플로이먼트의 이미지 버전 변경하기
이번 업데이트는 파드 정의가 변경되므로 롤아웃이 발생한다.
웹 애플리케이션의 이미지 버전 변경
kubectl set 명령으로 기존 객체 정의를 변경한다.
이 명령을 사용하면 파드의 이미지나 환경 변수 또는 서비스의 레이블 셀렉터 등을 변경할 수 있다.
# 웹 애플리케이션의 이미지 버전을 변경한다.
kubectl set image deployment/vweb
kubectl set 명령으로 이미지를 변경하면 파드 정의가 변경된다.
레플리카셋의 상태 확인
kubectl get rs -l app=vweb
파드 정의가 변경되면 디플로이먼트는 새로운 레플리카셋을 만든다.
롤아웃 히스토리 확인
다음 명령어로 변경된 내역을 확인한다.
kubectl rollout history 객체종류/객체이름kubectl rollout history deploy/vweb
수정은 했지만 실제 변경이 이루어진 것이 없기 때문에 배포에 사용한 것만 등록한다.
새 레플리카셋은 파드를 정해진 숫자까지 늘리고, 기존 레플리카셋은 파드 수를 0으로 줄인다. 이 과정이 두 번째 롤아웃이 된다.
이미지를 변경해서 배포
nano vweb/vweb-v1.yaml 명령을 수행해서 이미지를 수정한다.
image: kiamol/ch09-vweb:v2
파드 확인
kubectl get pods기존의 3개 파드가 모두 중지되고 새로운 파드 2개가 생성되는 것을 확인할 수 있다.
변경된 내역 확인
kubectl rollout history deploy/vweb
REVISION이 새로 추가된 것을 확인할 수 있다.
3. 롤아웃과 롤백을 이용한 디플로이먼트 업데이트
쿠버네티스에서 디플로이먼트를 업데이트할 때는 주로 롤아웃과 롤백 기능을 사용한다.
롤아웃을 통해 새로운 버전을 배포하고, 문제가 생기면 롤백으로 이전 버전으로 되돌릴 수 있다.
디플로이먼트의 업데이트는 주로 이미지의 태그를 변경하거나, Pod 설정에서 replicas 개수를 제외한 다른 내용을 변경해서 수행한다.
예를 들면, 특정 환경 변수를 추가하거나 삭제하는 등의 작업을 할 수 있다.
@danger
‼️ 하지만, 레이블이나 컨테이너의 이미지 부분을 제외한 부분을 함부로 변경하는 것은 다른 객체와의 연관성 문제 때문에 위험하다.
이러한 업데이트 중에 컨테이너에 직접적으로 영향을 주지 않으면서 변경할 수 있는 항목으로는 디플로이먼트의 version 필드가 있다.
이 필드를 수정하면 쿠버네티스가 이를 인식하지만, Pod 내부의 컨테이너 설정에는 영향을 주지 않기 때문에 안정적으로 업데이트할 수 있다.