[ Docker && Kubernetes ] - 쿠버네티스를 이용한 컨테이너 오케스트레이션: Deployment

이번시간에는 디플로이먼트가 무엇인지 알아보고 디플로이먼트의 배포전략에 대해서 간단히 살펴보도록 하겠습니다.

 

디플로이먼트란?

이전에는 REPLICA SET ===> NODE까지의 부분을 살펴보았습니다. 디플로이먼트는 REPLICA SET을 래핑하는 API 리소스 입니다. 사용자는 특수한 목적이 아니라면 파드와 레플리카셋이 아닌 디플로이먼트로 워크로드를 관리하게 됩니다.

 

디플로이먼트를 오브젝트를 생성하면 이에 대응되는 ReplicaSet과 Pod가 자동 생성되게 됩니다.

 

그리고 만약에 서비스 버전이 업데이트 되어 파드를 새로운 버전의 이미지 파드로 교체해야 한다거나, 새 버전의 이슈 ( ex Bug )가 발견되어 롤백을 진행해야 한다면?? 어떻게 해야 할까요.. 이 때 파드의 이미지 버전이 갱신될 때 배포전략을 설정하는 것이 디플로이먼트 입니다.

 

위와같은 전략을 세울 때, 기본적으로 디플로이먼트는 2가지 전략을 제공합니다. Recreate전략과, RollingUpdate전략입니다. 이에 대해서는 뒤에서 더 자세히 알아보도록 하겠습니다.

 

실습

우선 미리 만든 디플로이먼트 매니페스트 파일을 보도록 하겠습니다. 이는 이전의 레플리카 셋을 했을 때와, kind만이 ReplicaSet ==> Deployment로 바뀐것을 보실 수 있습니다.

그리고 apply를 하게되면 pod목록에 3개가 추가된 것을 보실 수 있습니다. 이를 바탕으로 Deployments, Replicasets, pods를 한번 확인해 보도록 하겠습니다.

hello라는 이름의 deployments가 하나 생성된 것을 확인할 수 있습니다. 또한 1개의 Replicaset을 보면 hello-[dummy]라는 이름을 가진 레플리카셋을 보실 수 있습니다. 그리고 pods를 보면 레플리카셋의 이름을 Prefix로 가진 3개의 pods를 보실 수 있습니다.

 

디플로이먼트의 배포전략

우선 기본적으로 설정되는 재배포전략은 재생성입니다. 이는 기존 레플리카셋의 파드를 모두 종료 후 새 레플리카셋의 파드를 새로 생성하는 방법입니다. 다만 프로덕션에서 서비스를 진행중에 있다고 하면, 서비스에 다운타임이 존재하게 됩니다. 서비스의 앞단에서 사용자 트래픽을 받고 있지 않다면 이런 전략을 고려해 볼 수 있습니다.

 

그 다음으로는 롤링 업데이트 ( Rolling Update )전략입니다. 이는 기존 레플리카셋에 파드가 10개가 띄워져 있다고 해 봅시다. 그럼 새 버전의 레플리카셋을 만들어야 하는데, 점진적으로 만들어 나간다고 보시면 됩니다. 

롤링 업데이트는 추가적인 옵션을 제공합니다.

maxSurge: 이는 spec.replicas 수 기준 최대 새로 추가되는 파드의 수가 됩니다. 만약 spec.replicas가 10이고 maxSurge가 1이라면 해당 디플로이먼트가 가지는 파드의 수는 10 + maxSurge를 넘을 수 없다는 이야기입니다.

maxUnavailable: 이는 업데이트 과정에 spec.replicas수 기준 최대 이용 불가능 파드 수라고 보시면 됩니다. 이는 maxSurge와는 다르게 디플로이먼트가 가지는 파드의 수는 10 - maxUnavailable보다 낮아질 수 없다는 이야기입니다.

이들은 예제로 살펴보고 이해해 보도록 하겠습니다.

 

위 그림에서 maxSurge: 1, maxUnavailable: 0인 경우입니다. 이는 초기에 10개의 파드가 생성되어 있다고 하면. 아래와 같은 순서로 재배포가 일어납니다. ( 최대 11, 최소 10 )

• 새로운 파드가 일단 하나 먼저 생성됩니다.
• 기존의 파드를 하나 없앨 수 있습니다.  ( 최대값을 넘어가면 안되기 때문 ) -> 2개 삭제는 안되는데 최소 10개이기 때문
• 반복.. ( 결국 새로운 파드가 10개가 될 때까지 반복 )

이는 파드가 쓰는 자원이 클러스터에 하나 더 추가가 됩니다. 따라서 클러스터의 노드 자원에 문제를 일으킬 수 있습니다. 다만 10개의 파드가 유지되기 때문에, 트레픽 측면에서는 위 전략이 유리해지게 됩니다.

 

 

그리고 maxSurge: 0, maxUnavailable: 1인 경우를 간단히 추살화해보면, 결국은 최대 파드의 수가 10개를 넘어갈 수 없다는 뜻이됩니다. ( 최대 10, 최소 9 ) 이는 아래와 같은 과정으로 진행되게 됩니다.

• 기존의 파드를 하나 없앱니다. ( 하나 더 생성할 수 없습니다 -> 최대 10개이기 때문 )
• 그리고 하나 파드를 생성합니다. ( 하나 더 없앨 수 없음 -> 최소 9개이기 때문 )
• 반복... ( 결국 새로운 파드가 10개가 될 때까지 반복)

이는 노드 자원이 초과될 일이 없다는 장점이 있습니다. 클러스터가 가지고 있는 노드 자원인 파드수가 11개가 되지 않기 때문에, 자원 할당을 했던 노드만으로도 해당 업데이트를 진행할 수 있게 됩니다. 다만 파드수가 하나 줄어들기 때문에, 트레픽이 많은 상황이였다고 하면, 자원이 부족해지게 됩니다.

 

실습

우선 새롭게 만든 rolling-update.yaml파일을 보도록 하겠습니다. 여기서 변경된 부분은 strategy의 type을 RollingUpdate로 해주었습니다. 이를 지정해주지 않으면 기본 옵션인 Recreate로 지정되게 됩니다. 또한 rollingUpdate의 maxSurge: 1, maxUnavailable: 0으로 해서 하나 생성하고 지우는 방식으로 재배포를 하도록 했습니다.

 

그리고 minReadySeconds는 새로운 파드가 생성되고 대기 시간을 명시한 것입니다. 또한 revisionHistoryLimit은 재배포가 이루어지면서 새로운 Replicaset이 만들면서 이미지의 업데이트가 생길때마다 revision이 만들어지게 됩니다. 이 revision을 몇개까지 가질 수 있는지를 명시한 거라고 보시면 됩니다.

 

먼저 업데이트를 하고나서, 이의 revision을 확인하는 명령어를 쳐 보았습니다. 근데 위와같이 CHANGE-CAUSE가 나오지 않는 것을 확인하실 수 있을겁니다. 이는 기본적으로 kubectl이 어떤 CHANGE-CAUSE로 발생했는지 남기지 않습니다. 이는 --record옵션으로 알려줄 수 있습니다.

다음과 같이 --record옵션을 주면, deprecated되었다고 뜨긴 하지만, 문제는 없습니다. 그리고 history를 보면, CHANGE-CAUSE를 보면 해당 revision을 만들 때 썼던 명령어를 보실 수 있게 됩니다.

 

그 다음에는 이제 imperative하게 이미지를 좀 수정해서 rollout이 잘 작동하는지 확인해 보도록 하겠습니다.

리소스를 교체하자마자 파드의 수가 6개가 되면서 재배포가 실행되는 것을 보실 수 있습니다. rolling-8d85fc8b7로 시작하는게 새 파드이고, rolling-b447fb964로 시작하는게 기존의 파드입니다. 이게 다 끝나게 되면 최종적으로 아래와 같이 5개의 파드가 남고 재배포가 완료되는 것을 확인하실 수 있을겁니다.

그리고 리비전 history를 확인해 보도록 하겠습니다. apply했던 파일이 있다면 -f옵션으로 history를 확인할 수 있게 됩니다.

그리고 한가지 명령어가 더 있는데, kubectl rollout undo와 kubectl rollout status라는 명령어가 있습니다.

위의 명령어를 통해 revision=1의 상태로 돌아갈 수 있게 되었고, 이에 대한 상태도 스트리밍 형식으로 확인할 수 있게 됩니다. undo과정이 완료되게 되면 아래와 같은 상태가 됩니다.

기존의 파드인 rolling-b447fb964로 돌아간 것을 확인하실 수 있습니다.