쿠버네티스 [디플로이먼트]란?

📄디플로이먼트란?

디플로이먼트는 레플리카 셋(feat. 레플리케이션 컨트롤러) 기능을 활용해 실행되는 어플리케이션(파드)을 무중단으로 업데이트하는 기능의 리소스

• 파드의 교체방법: v1태그로 이루어진 파드 그룹이 있다고 가정하고 v2의 파드그룹으로 교체하려할 때 v2의 새 이미지를 Register에 저장하고 다음 두가지 방법을 거쳐 파드를 업데이트 한다.

1. 기존파드삭제->새파드실행 (템플릿 수정, 이전 파드 삭제, 새파드 생성)
   
2. 새파드시작-> 새 파드가 기동되면 파드교체 (v2템플릿으로 파드 생성, 서비스의 레이블셀렉터 변경). 이 후 파드를 삭제하는데 이전 파드 전체를 다 삭제[Recreate 전략]하거나 파드를 단계별로 교체[rollingupdate 전략]하는것이 가능하다. 단계별로 교체하는 것을 롤링 업데이트라 칭하며 서비스의 파드셀렉터에서 이전 파드와 새 파드를 모두 포함한다. 이렇게 다운타임 없이 새 파드로 교체할 경우 v1, v2두 파드 그룹을 동시에 실행해줘야해서 더 많은 하드웨어 리소스를 요구한다.
   

🎡롤링 업데이트

새로운 파드가 기동시 단계별로 기존 파드를 삭제하며 교체하는 방법이다.

• 예전에는 Kubectl을 통해 수동으로 롤링 업데이트를 수행했다. 현재는 Deployment를 통해 롤링 업데이트를 수행하지만 프로세스의 이해를 위해 짚고 넘어간다!
• 1. Replication controller와 RoadBalancer Service 생성(하나의 RC yaml 파일에 두개의 서비스 리소스 작성> kubectl create 명령어를 통해 쿠버네티스 API 게시> RC와 로드밸런서를 실행하고 서비스를 통해 curl을 계속 요청한다.)
• 2. Kubectl을 이용해 Rolling Update(어플리케이션 v2를 만들고 이미지를 register에 저장해 불러온다.> kubectl rolling-update를 실행해 교체할 rc과 새 이미지를 지정한다.(이 때 실행되는 rc는 replicas: 0 인 상태여서 파드는 기동되지 않음) v2의 rc가 새로운 레이블로 파드를 생성하면 v1은 스케일다운, v2는 스케일 업을 통해 롤링이 일어난다.
     
     

🤔그렇다면 왜 Kubectl을 활용한 Rolling update를 사용하지 않는가??

• kubectl rolling-update가 괜찮아보이지만사용하지 않는 이유는 scale up,down을 요청할때 kubectl client단에서 rc에게 스케일링을 요청하는데, 네트워크가 끊길 경우 파드와 rc의 수행이 업데이트 수행을 마치지 못하고 업데이트가 끝이 나서 오류가 일어날 수 있기 때문이다.
• 또한 쿠버네티스는 파드가 배포될 때 명령에 의해서가 아닌 쿠버네티스 자체에서 시스템의 상태를 파악해 파드의 스케일링이 진행되는것을 지향하기 때문에 deployment라는 리소스를 도입하게 된 것이다.

📄디플로이먼트 소개

deployment는 lower-level의 rc, rc-set을 수행하며 배포하고 선언적으로 업데이트 하기 위한 high-level의 리소스이다. deployment 생성 -> 레플리카셋 생성 -> 파드 복제 및 관리

• 레플리카셋만 있어도 파드의 생성및 관리는 가능하지만 여러개의 rc-set을 조화롭게 조정하기 위해 deployment 리소스가 등장하게 되었다고 한다. 이 때 디플로이먼트가 직접 파드를 생성하고 관리하지 않고 기존과 같이 레플리카셋이 그 역할을 맡는다.
• kubectl을 사용해 업데이트를 진행하면 client 단에서 명령해 rolling update가 진행되는데, deployment를 사용하면 control plane의 controller manager가 rolling update를 수행한다.
  

deployment의 생성

rc의 생성과 크게 차이가 없다. (레이블셀렉터, 레플리카 수, 파드 템플릿으로 구성) 디플로이먼트를 생성하는 방법은

• kubectl delete rc -all을 수행해 모든 rc를 삭제하고
• kubectl create -f lsh-deployment-v1.yaml --record 수행 하면
• deployment "lsh" created 라는 문장이 뜸.(--record 옵션을 통해 개정 이력을 기록)
• kubectl rollout status deployment lsh 을 통해 디플로이먼트의 롤아웃이 성공됨을 확인할 수 있다.
• 생성된 파드들은 다음과 같이 레플리카셋의 해시값을 따라가는 특징을 보인다.
  
• Deployment 등장 이전에는 kubectl rolling-update를 실행하며 rc의 이름을 지정해줘야했고 "터미널"에서 업데이트가 완료될 때까지 네트워크가 연결된 상태로 기다려야 했다. 하지만 지금은 Deployment의 템플릿을 수정하기만 하면 rc생성 및 스케일링을 "쿠버네티스"에 맡길 수 있는 장점이 있는것이다.

deployment의 롤링 업데이트 및 상세기능

• 위를 실행하면 lsh deployment의 파드 템플릿이 업데이트 돼 nodejs 컨테이너에 사용되는 이미지가 v2버전으로 업데이트 된다. 이미지 이름만 변경하면 어플리케이션을 최신버전으로 업데이트가 가능하다.(하지만 컨피그맵은 변경되어도 deployment업데이트 시켜주지 않아서 redeploy를 따로해줘야함.)
• 디플로이먼트는 rollout이 끝난다하더라도 이전 rc를 삭제하지 않아 기본적으로 롤백이 쉽다.(editionHistoryLimit 옵션을 통해 너무많은 rc가 남아있지 않도록 제한 기능도 제공) 외에도 디플로이먼트에 --record 옵션이 있다면 개정이력이 기록되어 있어 롤백이 더욱 용이하다.
• 롤아웃 될 때 maxSurge 속성을 통해 의도하는 레플리카 수보다 얼마나 더 많은 파드를 허용할 수 있는지 결정하고 maxUnvaliable을 통해 의도하는 레플리카 수보다 얼마나 사용할 수 없게 할 수 있는가를 결정한다.둘다 default값은 25%. 사진을 보면 이해하기 쉽다. (maxSurge: 교체할 때 파드를 몇 개까지 기동할 수 있는지, maxUnvaliable: 교체할 때 파드의 최소 가용수를 조절)
  
• 이밖에도 rollout 도중 pause를 통해 소규모 애플리케이션을 테스트 하거나, minReadySecond속성을 통해 롤아웃을 지연하며 레디니스 프로브 작동을 수행해 완전하지 않은 서비스를 배제해 사용자가 장애를 눈치못채게 하는 기능이 있다. 또 ProgressDeadLineExceeded를 통해 데드라인을 정의해 롤아웃이 정해진 시간 내 진행되지 않으면 실패한것으로 간주한다(Default 10min)
  

💡결론

- 디플로이먼트는 레플리카 셋 기능을 활용해 실행되는 어플리케이션(파드)을 무중단으로 업데이트하는 기능의 리소스이다.

- 디플로이먼트는 롤링 업데이트를 통해 새로운 파드가 기동시 단계별로 기존 파드를 삭제/교체 한다. (파드의 생성은 레플리카셋이 수행)