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

레플리카셋이란?

레플리카셋이란, 쿠버네티스에서 파드를 운영한다 하면, 이전에 도커 컴포즈를 사용했을 때, 동일 서비스에서 scale-out을 통해서 많은 컨테이너를 그 안에서 실행할 수 있었습니다.

 

우리가 쿠버네티스를 사용해서 웹 어플리케이션을 운용할 때에 파드의 수를 동적으로 늘릴 수도 있습니다. 가장 간단한 방법은 동일한 역할을 하는 파드를 여러개 찍어내면 될 것입니다. 그런데 yaml파일로 매번 다른 이름으로 파드를 찍어내는 것은 비효율적입니다. 그래서 쿠버네티스 상에는 이를 가능하게 하는 API 리소스가 존재합니다. 이게 바로 레플리카셋입니다.

레플리카셋은 정해진 수의 파드가 항상 실행할 수 있도록 관리해줍니다. 이 뿐만 아니라 만약 4개의 파드가 수행되어라! 라고 레플리카셋을 만들게 되었는데, 그 4개중에 하나의 파드에 문제가 생겼다고 해 봅시다. 이 때, 레플리카 셋은 해당 파드를 다시 새로운 노드에 스케쥴링하는 작업을 진행하게 됩니다 

스케줄링이란?

프로세스가 생성되어 실행될때 필요한 시스템의 여러자원을 해당 프로세스에게 할당하는 작업을 의미합니다.
또한 프로세스가 생성되어 완료될때까지 프로세스는 여러 종류의 스케줄링 과정을 거치게 됩니다. 

그래서 레플리카셋은 항상 동일 개수의 파드가 실행될 수 있게 해주는 역할을 합니다. 

 

레플리카셋의 동작원리

레플리카셋에서는 spec안에있는 replicas, selector구문이 매우 중요한 속성입니다.

 

여기서 selector는 레이블 셀렉터를 말합니다. 레이블 셀렉터는 우리가 쿠버네티스를 다루다보면 여러번 마주치게 될겁니다. 많은 쿠버네티스 API 리소스가 Label Selector을 통해 기능을 제공합니다. 이를 통해 리소스 간 느슨한 결합을 유지할 수 있다는 장점이 있습니다. 

 

쿠버네티스 오브젝트는 모두 metadata.labels에 Key-Value형태의 레이블 값을 가지게 됩니다. 그리고 Label Selector를 사용하면 matchLabels와 matchExpressions옵션을 제공하게 됩니다. 위에서 조금 짤렸지만 role: web이라고 되어 있는데, 이는 ==역할을 하여 matchLabels아래에 있는 레이블을 가지고 있는 오브젝트들을 리턴하게됩니다. 그리고 그 아래에는 matchExpressions가 있는데, 이는 matchLabels가 필터링 불가능한 다양한 옵션을 제공합니다. 위에서는 In, NotIn을 통해서 필터링하는 것을 보실 수 있습니다.

 

또한 ReplicaSet Controller가 Matser Node인 Control Plane에 존재하게 됩니다. Master Node의 구성요소중에 Controller Manager가 있는데, 여기에 여러가지의 컨트롤러 매니저가 있다고 했었습니다. 그 중 Kube Controller Manager안에 ReplicaSet Controller가 Control Plane에 존재하게 됩니다. 

 

이는 API Server와 계속해서 통신을 하면서, ReplicaSet의 상태를 계속 검사를 합니다. spec.selector에 대응되는 파드의 수가 spec.relicas와 동일한지 지속적으로 검사하고, 다를 경우 스케일 아웃 혹은 인 진행을 합니다. 

 

실습

이제 본격적인 실습을 위해서 매니페스트 파일을 보도록 하겠습니다.

여기서는 apiVersion을 apps/v1로 했고, metadata에 labels을 주지 않았습니다. 그리고 spec에 replicas를 3으로 주었고 selector는 matchLabels로 해서 apps == hello인 것을 지정해 주었습니다. 말 그대로 하자면 이 부분은 replicaset의 옵션 부분입니다.

 

그리고 template는 replicaset이 만드는 Pod템플릿 입니다. template안에다가는 Pod가 가져야 하는 metadata와 spec을 작성해 주시면 됩니다. metadata는 name: hello를 주었고 labels를 주었는데, app: hello를 주었습니다. 나중에 replicaset의 matchLabels로 필터링 하기 위해서입니다. 그리고 spec에는 container의 스펙을 이전에 작성해 주었떤 것처럼 적어주면 됩니다. 이는 이전과 동일합니다.

 

일단 해당 매니페스트 파일을 가지고 apply을 선언형으로 진행해 주었습니다. 그리고 오른쪽 창은 아래 명령어를 활용하였습니다. ( 실시간으로 지켜보기 위해서 )

$ watch kubectl get pod --show-labels

apply했더니 hello로 시작하는 pod3개가 생성되고 Labels로는 app=hello로 셋 다 지정된 것을 보실 수 있습니다.

 

그리고 describe를 통해 replicasets의 정보를 보면 Selector는 app=hello로 잘 지정되었고 name은 hello로 지정되었고 네임스페이스는 default로 아주 잘 지정되었습니다. 그리고 Pod Template도 잘 지정되었습니다 (Nginx)

그리고 위와같이 단축어도 알아볼 수 있습니다.

 

그리고 우리는 ReplicaSet의 동작원리를 심화되게 알아보기 위해 몇가지 실험을 해보려고 합니다. 사실은 ReplicaSet Controller가 Pod가 ReplicaSet에서 관리하는 Pod인지는 체크하지 않습니다. 이 점을 기억하고 실습을 해보도록 하겠습니다.

우선에 기존에 작성된 dummy-pod.yaml을 보면 기존과 똑같은 Pod처럼 보이지만 이미지가 다르고, label은 app=hello로 이전과 동일한 것을 확인할 수 있습니다. 이 상태에서 apply를 하겠습니다.

다음과 같이 정상적으로 dummy Pod가 하나 만들어 졌습니다.

그리고 이전에 작성한 replicaset.yaml을 apply시켰는데, 여기에서 matchLabels로 app=hello를 지정해줬고 replicas=3이였는데, 기존에 dummpy Pod의 label이 app=hello이므로 replicaset.yaml을 apply하게 되면 3개의 Pod를 생성하는게 아닌 2개를 생성하게 되는 원리입니다.

 

$ kubectl edit pod hello-2rpkd

기존의 Pod의 Label을 수정하기 위해 kubectl edit을 해서 label을 app=hello2로 바꾸고 저장했습니다.

저장하고 나온 순간 바로 hello-np8qc라는 Pod가 하나 더 생성 된 것을 보실 수 있습니다. 이처럼 Replicaset Controller는 정상 작동하는 것을 확인했습니다.