쿠버네티스(디플로이먼트)

쿠버네티스,쿠버플로우

쿠버네티스(디플로이먼트)

세용용용용 2023. 7. 7. 12:17

8.1 디플로이먼트

레플리케이션 컨트롤러 보다 더 상위 수준의 컨트롤러 리소스

디플로이먼트는 애플리케이션(컨트롤러, 파드)를 배포하고 선언적으로 업데이트를 수행하는 리소스이다.

디플로이먼트 리소스는, 하위에 레플리카셋 컨트롤러를 제어하고, 레플리카셋 컨트롤러가 하위 파드를 제어하는 구조!!!

1) 디플로이먼트 정의

디플로이먼트 리소스의 필드는 레플리카셋의 필드와 특별히 다르지 않다.

디플로이먼트 리소스에 만 적용할 수 있는 배포 전략 관련 필드는 다음과 같음

spec :

startegy :

type : [RollingUpdate | Recreate]

rollingupdate :

maxUnavailable : <정수 | 비율>

maxSurage :

- RollingUpdata :롤링 업데이트 방식(기본값)

* maxUnavailable : 롤링업데이트 프로세스 중에서 사용할 수 없는 최대 파드의 수(기본값 :25%)( 정수 : 3, 비율 : 10%)

* maxSurage : 생성할 수 있는 최대 파드의 수(기본값 : 25%)

- Recreate : 재생성(기존 파드는 모두 삭제되고, 새로운 파드 생성)

컨테이너 최소 대기 시간

롤링업데이트를 수행할 때 새로운 파드가 배포되고 배포된 파드의 컨테이너가 실제 준비되기까지 대기할 시간을 지정할 수 있다.

spec :

minReadySeconds : <초>

- minReadySeconds : 새로 배포된 컨테이너가 준비되기까지 대기할 시간( 기본값 : 0초)

2) 디플로이먼트 생성

vim myapp-deploy-v1.yaml

디플로이먼트 리소스 생성

kubectl create -f myapp-deploy.yaml --record

확인하기 위한 서비스도 생성하자

vim myapp-svc-deploy.yaml

kubectl create -f myapp-svc-deploy.yaml

로드 밸런서 서비스의 외부 ip를 확인하자

kubectl get service myapp-svc-deploy

(2) 디플로이먼트 모니터링 준비

새로운 터미널을 하나 추가로 열어 컨트롤러 및 파드의 상태를 모니터링 ㄱ ㄱ ㄱ

watch -n1 -d kubectl get all

새로운 터미널을 추가로 열어 웹 요청 및 응답을 모니터링

watch -n1 -d curl http://192.168.56.200

롤아웃 상태를 확인하는 방법은 다음과 같다.

myapp-deploy 디플로이먼트가 정상적으로 배포된 것을 확인할 수 있다.

롤아웃 히스토리를 확인하자.

kubectl rollout history deployment myapp-deploy

앞에서 디플로이먼트 리소스 생성할때 --record 옵션을 사용하여 생성하면 변경사유에 해당 명령이 기록된다. 그리고 디플로이먼트의 리비전이 남게 되는데 이를 이용해 무엇 때문에 리소스가 변경되었는지, 필요하다면 롤백을 할 수 있다.

4) 디플로이먼트 롤링업데이트

버전1 >>> 버전2

kubectl set image deploy myapp-deploy myapp=ghcr.io/c1t1d0s7/go-myweb:v2.0

kubectl set image (디플로이먼트 이름) (컨테이너이름 = 새 이미지)

롤아웃 상태를 확인!!

kubectl rollout status deployment myapp-deploy

롤아웃이 정상적으로 완료되었다.

롤아웃 히스토리를 확인해보자

kubectl rollout history deployment myapp-deploy

kubectl set image 명령으로 업데이트시 --record 옵션을 사용하지 않아 어떤 이유에서 변경되었는지 기록되지 않음 ㅠㅠㅠㅠ,

나중에 추적을 어렵게 만들어짐

(3) 버전2 >> 버전3

이번에는 버전2에서 버전3으로 업데이트를 하자. 꼭!!! 추적을 위해 --record 옵션을 사용하자

kubectl set image deployment myapp-deploy myapp=ghcr.io/c1t1d0s7/go-myweb:v3.0 --record

변경 사유가 기록된 것을 확인할 수 있다!!!!

(4) 버전3 >>> 버전2

이번에는 버전3에서 버전2로 롤백 해보자!!!!

kubectl rollout undo deployment myapp-deploy --to-revision=2

롤아웃 히스토리 확인

kubectl rollout history deployment myapp-deploy

(5) 버전2 >>> 버전3

이제는 새로 디플로이먼트 오브젝트를 생성해 롤링업데이트를 수행해보자!!!!

vim myapp-deploy-v3.yaml

여기서 어노테이션 필드가 중요하다

deployment.metadata.annotations.kubernetes.io/change-cause 필드에 디플로이먼트 리소스의 변경 사유에 대해 명령이 아닌 문자열로 기록할 수 있다!!!!

myapp-deploy라는 이름을 가진 Deployment를 정의합니다. 이 Deployment는 롤링 업데이트 전략을 사용하며, 최대 1개의 Pod를 사용할 수 없는 상태로 업데이트하고, 최대 1개의 추가 Pod를 허용합니다. 또한, Pod가 준비되기까지 최소 20초를 기다리며, 총 3개의 Pod 인스턴스를 유지합니다. 각 Pod는 ghcr.io/c1t1d0s7/go-myweb:v3.0 이미지를 사용하고 8080 포트를 열어서 요청을 처리합니다. readinessProbe를 설정하여 Pod의 상태를 주기적으로 확인합니다.

kubectl apply로 변경된 리소스를 적용 ㄱ ㄱ

kubectl apply -f myapp-deploy-v3.yaml

롤아웃 상태를 확인!!!

kubectl rollout status deployment myapp-deploy