컨테이너의 가용성 확보하기 - Deployment와 ReplicaSet

여러분의 멋진 서비스가 컨테이너 위에서 실행 중이라고 가정하겠습니다.

 

그런데, 만약 프로그램에 오류가 발생하거나 컨테이너가기동중인 환경에 문제가 생겨 컨테이너가 의도치 않게 중단된다면 어떨까요?

만약 이런 일이 발생한다면 관리자가 직접 터미널을 열고 docker run을 다시 입력할 때까지 서비스가 중단되는 걸까요?

쿠버네티스를 사용하면 컨테이너가 불의의 사고로 중단되더라도 관리자가 복구 커맨드를 입력할 때까지 기다릴 필요 없이, 마치 오뚜기처럼 컨테이너를 다시 실행해 장애를 최소화합니다.

 

쿠버네티스의 고가용성을 책임지는 오늘의 주인공, 디플로이먼트(Deployment)와 레플리카셋(ReplicaSet)을 소개해보도록 하겠습니다.

디플로이먼트 (Deployment)

디플로이먼트는 쿠버네티스가 관리해야 하는 파드(컨테이너)들이 갖는 정보를 객체로 만들고, 컨테이너 이미지와 해당 이미지로 생성할 컨테이너의 개수 등 컨테이너를 시작하기 위해 필요한 모든 정보(스펙)를 기록합니다.

 

한번 첫 번째 디플로이먼트를 생성해 보겠습니다.

kubectl create deployment demo --image=<컨테이너 이미지명>
# deployment.apps/demo created

디플로이먼트를 생성한 다음, 상세 정보를 확인해보고 싶다면 다음 명령어를 입력해볼 수 있습니다.

kubectl describe deployments/demo

describe 커맨드를 통해 디플로이먼트를 조회하면 Pod Template 이라는 항목이 있고, 이를 통해 디플로이먼트로 *생성하고자 하는 파드의 스펙을 확인할 수도 있습니다.

✅ TIP. 쿠버네티스의 핵심 원리 - 지향 상태(Desired State)

디플로이먼트를 이해할 때 중요한 점은 디플로이먼트는 사용자가 지향하는 파드의 상태를 의미하는 것이지, '이렇게 생긴 파드를 생성하겠다' 라고 선언하는 액션이 아니라는 것입니다.

도커가 docker run [옵션] <이미지> 처럼 컨테이너를 단순히 실행하는 데에 그쳤다면, 쿠버네티스는 잠시 뒤에 다룰 레플리카셋(ReplicaSet) 등의 컨트롤러를 통해 현재 상태를 계속해서 모니터링하고, 현재 상태와 지향하는 상태를 동기화하려 시도합니다.

Pod Template:
      Labels:  app=demo
      Containers:
       demo:
         Image:        <사용한 컨테이너 이미지명>
         Port:         <none>
         Host Port:    <none>
         Environment:  <none>
         Mounts:       <none>
         Volumes:      <none>

디플로이먼트는 실제로는 레플리카셋(ReplicaSet) 이라는 컴포넌트를 생성하며, 디플로이먼트에 정의된 대로 실제 파드를 관리하는 역할은 레플리카셋이 수행합니다.

레플리카셋 (ReplicaSet)

디플로이먼트에 명시하는 정보 중에서는 "주어진 이미지로 몇 개의 파드를 생성할지" 의 정보 역시 존재하는데요, 레플리카셋은 실행 중인 리소스를 *모니터링하다가 디플로이먼트에 적힌 스펙보다 적은 컨테이너가 기동중이면 추가로 컨테이너를 기동하기도 하고, 스펙에 적힌 것보다 많은 컨테이너가 실행 중이면 기존의 컨테이너를 중지하기도 합니다.

✅ TIP - Reconciliation Loop

쿠버네티스의 컨트롤러는 끊임없이 루프를 돌면서 클러스터의 실제 상태와 사용자가 YAML 등에 명시한 상태가 일치하는지를 검사하고, 실제 상태와 원하는 상태를 동기화하는데요, 이를 reconciliation loop 라고 합니다.

디플로이먼트가 업데이트되면 새로운 레플리카셋과 파드가 생성됩니다.

또한 디플로이먼트를 업데이트하면 파드가 그대로 업데이트되는 것이 아니라, 새롭게 생성된 레플리카셋이 현재 상태와 디플로이먼트의 스펙을 비교해 디플로이먼트에 적힌 대로 기존 파드와 레플리카셋을 제거하고 새로운 레플리카셋을 통해 파드를 실행합니다.

디플로이먼트를 활용한 파드 가용성 유지

이제 디플로이먼트와 레플리카셋에 대해 간단히 알 수 있었는데요, 한번 파드에 장애가 발생했다고 가정하고 파드를 종료해 보겠습니다.

# app=demo 라벨을 갖는 파드를 제거합니다.
kubectl delete pods --selector app=demo

"demo-5f6d44788" 은 레플리카셋의 이름입니다.

과연 파드가 제거되었을까요?

하지만 파드 목록을 출력해 보면 제거한 줄 알았던 파드가 다시 실행되는 것을 확인할 수 있습니다.

동일한 "demo-5f6d44788" 을 통해, 이 파드가 동일한 레플리카셋에 의해 생성되었음을 알 수 있습니다.

정확히는 파드가 종료되기는 했지만, 레플리카셋이 파드의 상태를 감시하면서 우리가 원하는 상태와 실제 상태가 일치하지 않는 것을 파악했고, 원하는 상태를 충족시키기 위해 파드를 다시 실행했습니다.

원하는 상태 (Desired State)
- 1개의 파드가 실행되어야 합니다.

실제 상태
- 0개의 파드가 실행중 (파드를 제거했으므로)

이처럼 쿠버네티스에서는 파드(컨테이너)에 어떤 문제가 생겨도 모니터링을 통해 현재 상태와 지향하는 상태를 동기화하려는 성질 때문에 장애를 금방 복구할 수 있는 모습입니다 🙂