[Kubernetes] 쿠버네티스 Deployment (배포)

Deployment 는 Replica Set 중 하나 입니다.
Replica Set에 기능 하나만 추가된 형태라고 보면 됩니다.
Deployment 를 이용하면 가동 중지 시간 없이 자동으로 롤링 업데이트를 할 수 있습니다.
이전에 가동 중지 시간없이 Pod의 Label을 이용해서 수동으로 새로운 버전을 배포했었습니다.

이번에는 자동으로 가동 중지 시간없이 업데이트를 할 수 있는 Deployment 를 알아보겠습니다.

 

 

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#deployment-v1-apps

Kubernetes API Reference Docs

 

Deployment의 yml 형식은 이렇습니다.
형식을 보게 되면 Replica Set 과 99퍼센트 일치하는 것을 볼 수 있습니다.

 

차이점은 롤링 업데이트를 조정하고자 할 때 몇 가지 추가적인 설정을 넣어줄 수 있다는 것입니다.

 

 

만약 기존에 Replica Set 이 실행 중인 상태라면 kubectl delete replicaset {Replica Set 명} 명령어를 사용하여 종료시켜 테스트를 진행하도록 합니다.

 

 

기존 Pod yml 혹은 새로 만들 yml에 Deployment 양식을 넣습니다.
전체적인 형식은 Replica Set 과 똑같으며, kind 부분에 Deployment 가 들어가고 image에 업데이트를 확인하기 위해 초기 버전인 release0 버전으로 넣었습니다.

 

 

kubectl apply 명령어로 적용하고 생성 실행해줍니다.

 

 

kubectl get all 명령어를 통해 확인해보면 deployment 항목이 추가 된 것을 확인할 수 있습니다.
Deployment 는 Replica Set 를 관리하는 쿠버네티스의 엔티티라고 생각하면 될 것 같습니다.

 

 

브라우저에서 다시 확인해보면 접속이 정상적으로 되는 것을 알 수 있습니다.

 

 

이제 업데이트를 하기 위해 추가적으로 설정할 수 있는 내용을 적용해보겠습니다.
그 중에서 minReadySeconds 설정을 진행해주었습니다.
minReadySeconds 설정은 새로운 Pod가 사용 가능한 상태가 되기 위해 컨테이너 간에 충돌 없이 준비되는 최소 시간입니다.
또한 image를 0-5 버전으로 변경해주었습니다.

그리고 나서 kubectl get all 명령어를 입력하면 새로운 ReplicaSet 이 생긴 것을 확인할 수 있습니다.
그런데 기존의 Replica Set이 READY, CURRENT, DESIRED 항목을 보았을 때 아직 실행되고 있는 상태인 것을 확인할 수 있습니다.
즉, 처음에 실행했었던 release 0 버전의 Replica Set 이 실행되고 있는 상태입니다.
지금 상태에서 브라우저에 요청을 하면 0버전의 페이지에 접속을 하게 됩니다.

 

 

어느 정도 시간이 지나고 kubectl get all 명령어를 입력하여 다시 확인해봅시다.
기존의 Replica Set의 DESIRED, CURRENT, READY 항목들이 0으로 바뀌었음으로 종료된 것을 알 수 있습니다.
이제 새로 추가한 Replica Set 의 0-5 버전의 페이지가 연결되는 것을 확인할 수 있습니다.

이 어느 정도의 시간이 지난 것은 설정한 minReadySeconds 설정으로 인한 시간이고, 새로 변경한 내용으로 적용 후 배포함으로서 자동으로 새로운 버전으로 실행되는 것입니다.

 

 

Pod Label 을 이용하는 방식을 사용하면 기존의 실행되고 있던 Pod를 수동으로 종료시키고 새로운 버전으로 업데이트 적용하고 배포했다면 Deployment 를 사용하면 일일히 종료할 필요없이 자동으로 기존 시스템이 종료되고 새로운 버전의 시스템이 실행되게 됩니다.