해결책 | Notion

다행스럽게도 쿠버네티스는 이런 동작까지도 자동화했다. 디플로이먼트 개념을 이용하면, 애플리케이션 업데이트 방법, 개별 전략 활용, 다양한 업데이트 프로세스 조정 등을 기술할 수 있다.

팀과 프로젝트에 따라 몇 분에서 몇 달이 걸릴 수 있는 릴리스 주기별로 모든 마이크로서비스 인스턴스에 대해 다수의 디플로이먼트를 고려하고 있다면, 쿠버네티스 자동화로 이런 노고를 절감할 수 있다.

전 장에서 스케줄러가 효과적으로 역할을 수행하려면 호스트 시스템에 대한 충분한 리소스, 적절한 배치 정책, 적절하게 정의된 자원 프로파일을 포함하는 컨테이너가 필요함을 살펴봤다.

마찬가지로, 디플로이먼트가 정확히 수행되기 위해서는 컨테이너가 훌륭항 클라우드 네이티브 일원이 되어야 한다. 디플로이먼트의 핵심은 예측 범위 안에서 파드 세트를 시작하고 중지하는 기능이다.

이것이 예상대로 작동하려면 컨테이너가 수명주기 이벤트를 잘 수신해야 하고, 또한 다음 장에서 다루겠지만 파드가 성공적으로 실행되었는지를 알려주는 정상상태 확인 종단점을 제공해야 한다.

컨테이너가 이 두 영역을 정확하게 커버한다면 플랫폼은 이전 컨테이너를 깨끗하게 종료할 수 있고, 업데이트된 인스턴스를 시작해 이전 인스턴스를 교체할 수 있다. 그런 다음 업데이트 프로세스의 나머지 부분을 선언적 방법으로 정의해서, 미리 정의된 단게와 예상된 결과를 하나의 원자적 작업으로 실행할 수 있다.

컨테이너 업데이트 동작에 대한 옵션을 한번 살펴보자

kubectl을 사용한 명령형 롤링 업데이트는 더 이상 지원되지 않음 쿠버네티스는 처음부터 롤링 업데이트를 지원해왔다. 첫 번째 구현은 본질적으로 명령형이었다. 즉 kubectl 클라이언트가 각 업데이트 단계에 대한 수행 작업을 서버에 알려준다. kubectl rolling-update 명령은 여전히 존재하나, 이러한 명령형 접근은 다음과 같은 단점으로 인해 더 이상 지원되지 않는다.

kubectl rolling-update는 요청 종료 상태를 보여주지 않으며, 그 대신 시스템을 요청 상태로 만드는 명령을 실행한다.
컨테이너와 레플리케이션컨트롤러를 교체하기 위한 전체 오케스트레이션 로직이 kubectl에 의해 수행된다. 업데이트 프로세스가 진행되는 동안, kubectl은 그 내부에서 API 서버와 상호 작용하고 모니터링하여 고유한 서버측 책임을 클라이언트로 이동시킨다.
시스템을 요청 상태로 만들려면 하나 이상의 명령이 필요할 수도 있다. 이러한 명령은 다은 환경에서도 자동화되고 반복 가능해야 한다.
시간이 지나면 다른 누군가가 당신의 변경사항을 바꿀 수 있다.
서비스가 계속 업데이트 되는 동안, 업데이트 프로세스를 문서화하고 최신으로 유지해야 한다.
배포 내용을 확인하는 유일한 방법은 시스템 상태를 체크하는 것이다. 간혹 현재 시스템 상태는 요청 상태가 아닐 수 있으므로, 이 경우에는 배포 문서를 이용해 현재 시스템 상태와 연관하여 체크해야 한다. 이런 점을 보완하기 위해 쿠버네티스 백엔드에 의해 완전히 관리되는 선언적 업데이트를 지원하는 디플로이먼트 자원 객체가 도입 되었다. 선언적 업데이트는 장점이 많고, 명령형 업데이트 지원은 결국 사라질 것이다.

롤링 배포

쿠버네티스에서 애플리케잇견을 업데이트하는 선언적 방법은 디플로이먼트 개념을 활용하는 것이다. 내부적으로 디플로이먼트는 세트 기반 라벨 셀렉터를 지원하는 레플리카셋을 생성한다.

또한 디플로이먼트 추상화를 통해 RollingUpdate(기본값)와 Recreate같은 전략을 사용해 업데이트 프로세스 동작을 구체화할 수 있다. 아래 예제는 롤링 업데이트 전략을 위한 디플로이먼트 설정의 주요 부분을 보여준다.

apiVerison: apps/v1
kind: Deployment
detadata:
	name: random-generator
spce:
	replicas: 3 #레플리카셋 선언. 롤링업데이트를 위해선 2개 이상이 필요하다.
	strategy:
		type: RollingUpdate
		rollingUpdate:
			maxSurge: 1 #업데이트 동안 일시적으로 지정된 레플리카수에 더해 실행될 수 있는 파드 수 3 + 1
			maxUnavailable: 1 #업데이트 동안 사용 불가능하게 될 수 있는 파드의 수 3 - 1
		selector:
			matchLabels:
				app: random-generator
		template:
			metadata:
				labels:
					app: random-generator
			spec:
				containers:
				- image: k8spatterns/random-generator:1.0
					name: random-generator
					readlinessProbe: #레디니스 점검은 무중단을 제공하기 위한 롤링 배포에 매우 중요함
						exec:
							command: [ "start", "/random-generator-ready"]

RollingUpdate 전량 행동은 업데이트 프로세스 동안 중단이 없음을 보장한다. 내부적으로 이 디플로이먼트 구현은 새로운 레플리카셋을 생성하고 새로운 컨테이너로 이전 컨테이너를 교체함으로써 비슷한 동작을 수행한다.

여기에서 한 가지 향상된 기능은 새로운 컨테이너 생성 비율을 제저할 수 있는 디플로이먼트를 사용한다는 것이다. 디플로이먼트 객체를 사용하면 maxSurge 및 maxUnavaliable 필드를 통해 초과 파드와 사용 가능한 파드 범위를 제어할 수 있다.

선언적 업데이트를 작동시키기 위한 옵션은 다음과 같다.

kubectl replace로 새로운 버전의 디플로이먼트로 전체 디플로이먼트를 교체 한다.
디플로이먼트를 패치(kubectl patch)나 대화식으로 편집(kubectl edit)해서 새로운 버전의 새로운 컨테이너 이미지를 넣는다.
kubectl set image 명령으로 디플로이먼트에 새로운 이미지를 넣는다.

(깃허브 예제 http://bit.ly/2Fc6d6J 참조)

앞서 언급한 명령형 방법으로 서비스를 배포하는 단점을 해결하는 것 외에도 디플로이먼트는 다음과 같은 이점이 있다.