[Kubernetes] 파드를 사용하는 또 다른 오브젝트들: Jobs, DaemonSets, StatefulSets

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.
 

Kubernetes

---

이번 포스팅에서는 파드를 사용하는 또 다른 상위 리소스 오브젝트들로 Jobs, DaemonSet, StatefulSet에 대해서 알아보도록 하자. 지금까지 살펴본 ReplicaSet, Deployment 와 같은 리소스 오브젝트들도 배웠었는데, 이것들도 파드를 사용하는 상위 리소스 오브젝트들이라고 할 수 있다. 하지만 파드를 사용하는 리소스 오브젝트들로서 Jobs, DaemonSet, StatefulSet은 Replicaset, Deployment 와는 약간 다른 목적으로 사용하곤 한다. 하나씩 살펴보도록 하자.

1. 특정 동작을 수행하고 종료해! : Jobs

가장 먼저 알아볼 리소스 오브젝트는 Jobs 이다. 사실 Jobs는 이른바 '잡' 이라고 부르며 특히 데이터 엔지니어링이나 Airflow를 다루어본 사람들에게는 익숙한 용어일 수 있다. Job에 대해서 정의하면 "특정 동작을 수행하고 종료해야 하는 작업을 위한 오브젝트"이다. 파드를 생성해서 어떤 동작을 수행시킨다는 점에서는 ReplicaSet 이나 Deployment 와 동일하다고 볼 수 있다. 하지만 큰 차이점은 파드의 최종 상태이다. 

 

ReplicaSet 이나 Deployment는 보통 항상 운영되고 있어야 하는 애플리케이션 서버에 주로 이용되며 이런 리소스 오브젝트들이 지향하는 파드의 최종 상태는 실행 중 즉, Running 이다. 하지만 Job이 지향하는 파드의 최종 상태는 정상 종료 즉, Completed 이다.(참고로 파드의 상태 종류에 대해서는 잘 모른다면 저번 포스팅을 참조하자) 즉, Job은 해당 파드 컨테이너의 init 프로세스의 종료 코드(exit code)가 0을 반환해야 하는 것을 목적으로 한다.

 

그러면 Job을 생성하는 간단한 예시 매니페스트를 하나 살펴보자.

 

apiVersion: batch/v1
kind: Job
metadata:
  name: zedd-hello-job
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - image: busybox
          args: ["sh", "-c", "echo Hello, World && exit 0"]
          name: zedd-hello-job

 

위 매니페스트를 보면 Deployment 매니페스트랑 매우 유사함을 볼 수 있다. 특히, template 부분에 파드 템플릿 영역을 정의하면 된다. 하지만 Job 매니페스트를 작성할 때는 주의해야 할 점이 있다. 바로 restartPolicy 이다. 저번 포스팅에서 배운 것처럼 restartPolicy는 파드가 재시작하는 정책을 잘 설정해야 한다. restartPolicy에 명시할 수 있는 값으로는 Always, Never, OnFailure가 있었는데, 이 중 Never, OnFailure 둘 중 하나로 명시해주어야 한다. 이를 이해하기 위해서는 Job의 목적을 다시 상기시킬 필요가 있다. 

 

다시 한번 이야기하지만, Job의 목적은 파드가 정상 실행되고 '정상 종료'되는 것을 목표로 한다. 따라서, 정상 종료됨에도 다시 재시작하도록 명시하는 Always를 사용해서는 안되는 것이다. 

 

그리고 args 인자에서 보다 시피 파드 컨테이너의 init 프로세스 마지막에 종료 코드를 0을 반환함으로써 잘 종료되도록 해주었다.

 

이렇게 Job은 보통 배치(Batch) 작업을 위해 주로 사용되곤 한다. 크롤링이나 데이터 ETL, 프레임 렌더링, 파일 인코딩 등과 같이 한 번 수행하고 종료되면 되는 작업들에 주로 사용된다. 주의할 점으로 Job은 동시성을 엄격하게 지키고 보장해야 하는 병렬 처리를 위해 사용하는 것은 아니라는 점을 알아두자. 그리고 Job이 실행하는 파드가 실패하면 restartPolicy에 따라 재시작될 수도 있으니 Job이 처리하는 로직은 멱등성(연산을 여러 번 적용해도 결과가 달라지지 않는 특성)을 가지는 것이 좋다.

 

Job을 좀 더 세밀하게 사용하는 방법에 대해서 알기 위해 Job의 옵션에 대해서 알아보도록 하자. 크게 2가지가 존재한다. 방금 살펴본 매니페스트에 옵션 2가지를 추가해보았다.

 

apiVersion: batch/v1
kind: Job
metadata:
  name: zedd-hello-job
spec:
  completions: 3
  parallelism: 1
  template:
    spec:
      restartPolicy: OnFailure
      containers:
        - image: busybox
          args: ["sh", "-c", "echo Hello, World && exit 0"]
          name: zedd-hello-job

 

첫번째로는 spec.completions 이다. 이 값은 Job이 성공했다고 여겨지려면 몇 개의 파드가 성공 즉, 몇 개의 파드가 정상 종료되어야 하는지를 설정한다. 기본 값은 1이다. 다시 말해, 위 Job 매니페스트를 apply 하면 파드 템플릿에 명시되어 있는 busybox 파드 컨테이너가 순차적으로 3개 생성이 되고, 3개 모두 정상 종료되면 Job이 성공했다고 여겨진다는 뜻이다.

 

그런데 방금 busybox 파드 컨테이너가 '순차적으로' 3개 생성이 된다고 했다. 꼭 이렇게 1개가 생성 및 종료가 되고 난 다음 다른 1개가 생성되어야 할까? 이유는 바로 spec.parallelism 값이 1이기 때문이다. spec.parallelism는 동시에 생성될 파드의 개수를 설정하는 값이다. 이 값도 디폴트 값이 1이다. 따라서 위 매니페스트에서는 spec.parallelism에 1을 명시했기 때문에 '순차적으로' 파드가 1개씩 생성 및 종료되는 것이다.

 

만약 spec.parallelism을 3으로 바꾸면 어떻게 될까? 3개의 파드가 동시에 생성되고 종료되는 것을 볼 수 있다.

 

추가로 알아둘 점은 Job의 파드가 실패하면 restartPolicy에 명시된 정책에 의해 파드가 재시작(OnFailure)되거나 아니면 새로운 파드를 다시 생성(Never)한다고 했다. 이 때, Job에서는 파드가 실패할 시 최대 6번까지 재시도를 수행한다. 물론 이 재시도 최대 횟수도 spec.backoffLimit 값으로 커스터마이징 할 수 있다. 또한 Job의 파드가 모종의 이유로 작업이 진행되지 않고 계속 펜딩되는 경우, Job은 성공도 실패도 아닌 중간의 상태로 오랜시간 머무를 수가 있다. 이러한 상황에서 빠져나오기 위해 Job의 파드가 실행될 수 있는 최대 시간을 spec.activeDeadlineSeconds 옵션으로 제한할 수도 있다. 해당 시간보다 더 오래 중간 상태로 머무른다면 파드는 강제 종료되며 파드의 상태는 비정상 종료로 여겨진다.

2. Jobs에 주기적인 반복을 더하다: CronJobs

다음으로 알아볼 리소스 오브젝트는 Jobs의 자매품 격이라고 할 수 있는 크론잡(Cronjobs)이다. Cronjobs는 Jobs를 주기적인 간격으로 실행하는 리소스 오브젝트인데, 특히 Unix 계열 OS에서의 Cron 스케쥴링을 사용해본 사람이라면 매우 익숙할 것이다. 실제로 Cron 스케쥴링 규칙을 그대로 사용하기 때문에 더 이해하기 쉽다. 예시 매니페스트는 다음과 같다.

 

apiVersion: batch/v1
kind: CronJob
metadata:
  name: zedd-cronjob
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: zedd-cronjob
              image: busybox
              args: ["sh", "-c", "echo Hello World && exit 0"]

 

추가된 내용은 spec.schedule 과 spec.jobTemplate 영역이다. spec.schedule 에는 해당 CronJob을 어느 간격으로 실행할지를 명시한다. 그리고 spec.jobTemplate 영역에는 직전 목차에서 본 Job 매니페스트에서 spec.template 영역 즉, 파드 템플릿을 명시해주면 된다.

(참고로 의도하는 주기를 Cron 스케쥴링로 어떻게 규칙화시키는지 헷갈린다면 여기를 참조해보자. 마이너하게 유용하다)

 

그리고 매니페스트에 kind가 Job과 달리 CronJob으로 명시되어 있지만 쿠버네티스 상에서 리소스를 조회할 때는 jobs로 두 개 모두 조회가 된다. 그리고 조회할 때 기본적으로는 성공한 잡의 기록은 최대 3개까지, 실패한 잡의 기록은 최대 1개까지만 기록되지만, 이 설정 값도 Job 또는 CronJob 매니페스트에 spec.successfulJobsHistoryLimit 과 spec.failedJobsHistoryLimit 값으로 커스터마이징 할 수 있다.

3. 모든 노드에 파드를 하나씩 할당하자: DaemonSets

다음으로 알아볼 리소스 오브젝트는 데몬셋(DaemonSets)이다. DaemonSets은 동일한 파드를 쿠버네티스 클러스터 내의 모든 노드에 하나씩 생성하는 것을 목적으로 한다. 그래서 DaemonSets은 주로 로깅, 모니터링, 네트워킹 등을 위한 에이전트를 각 노드에 생성해야 할 때 주로 사용한다. 단적인 예로, 쿠버네티스 네트워킹을 위한 kube-proxy 나 calico 네트워크 플러그인, 그리고 매니지드 모니터링 시스템인 데이터독의 datadog-agent 등이 있다. DaemonSets을 생성하는 예시 매니페스트를 살펴보자.

 

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: zedd-daemonset
spec:
  selector:
    matchLabels:
      name: zedd-daemonset-pod
  template:
    metadata:
      labels:
        name: zedd-daemonset-pod
    spec:
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule
      containers:
        - name: busybox-pod
          image: busybox
          args: ["tail", "-f", "/dev/null"]
          resources:
            limits:
              cpu: 100m
              memory: 200Mi

 

DaemonSets 매니페스트도 Deployment 매니페스트랑 유사하다. 특히, Deployment에서 라벨 셀렉터를 이용해 특정 라벨을 갖는 파드들을 관리할 수 있도록 한 것처럼 DaemonSets도 라벨 셀렉터를 이용해 특정 라벨을 갖는 파드를 관리한다. DaemonSets에서 라벨 셀렉터도 spec.selector.matchLabels 영역에 명시한 레이블이 파드 템플릿 영역 즉, spec.template.metadata.labels 영역과 일치시켜주어야 한다.

 

추가로, 마스터 노드에도 해당 파드가 할당될 수 있도록 tolerations을 추가했다. 이 부분은 필수적인 것은 아니다. 또한 위 매니페스트에서 resources 영역을 보면 파드의 리소스를 Guaranteed 클래스로 설정했다. 즉, requests 와 limits 값이 모두 동일하게 한 것이다.(위 매니페스트에서는 requests 영역이 생략되어 있지만 이렇게 하면 명시된 limits의 값을 requests와 동일하게 자동설정한다) 

 

이렇게 Gruaranteed 클래스로 설정한 것은 데몬셋이라는 것이 보통 모든 노드에 대한 에이전트 역할을 하기 때문에 중요한 역할을 할 것임을 의미한다. 따라서 리소스 부족으로 인해 데몬셋 파드들이 종료되는 것을 막고자 Guaranteed 클래스로 설정하도록 하는 것이 권고된다.

4. 상태(State)를 갖는 파드를 관리한다: StatefulSets

일반적으로 쿠버네티스에서는 상태를 갖지 않는 즉, Stateless한 애플리케이션을 다루는 경우가 많다. 이를 위해서는 그동안 우리가 알아보았던 디플로이먼트와 같은 리소스 오브젝트를 이용해서 관리하면 된다. 하지만 데이터베이스 서버와 같이 상태를 갖는 즉, Stateful한 애플리케이션을 쿠버네티스에서 실행하고 관리하는 것은 꽤나 복잡한 일이 된다. 왜냐하면 '상태'를 갖는다는 것은 곧 '상태'를 나타내는 '데이터'를 파드 내부에서 어떻게 관리할지, 또 외부에서 상태를 갖는 파드들에 어떻게 접근할지 등에 대해서 고려해야 하기 때문이다.

 

쿠버네티스에서는 상태를 갖는 파드를 위해 StatefulSets 이라는 리소스 오브젝트를 제공해서 상태를 갖는 파드를 완벽히는 아니지만, 어느정도 관리할 수 있도록 기능을 제공해준다. 

 

먼저 상태를 갖는 파드와 상태를 갖지 않는 파드 간의 차이점이 무엇인지 이해하기 위해 실제 쿠버네티스에서 비유를 들어보자. 먼저 상태를 갖지 않는 Stateless 파드를 '가축'이라고 할 수 있다. 가축이라는 단어의 사전적 의미는 '집에서 기르는 짐승. 소, 말, 돼지, 개 닭, 등. 잡짐승' 이다. 여기서 우리가 주목할 부분은 이 가축에 속하는 짐승들은 언제든지 대체될 수 있고 각각을 고유한 존재로 여기지 않는다는 것이다. 이를 쿠버네티스 디플로이먼트로 연결시켜보면, 디플로이먼트가 관리하는 파드들은 언제든지 대체될 수 있다. 일례로, 이미 Running 중인 파드를 재시작하면 새로 생성되는 파드는 이전에 실행되고 있던 파드랑은 다른 존재이다. 다른 존재임을 어떻게 알 수 있냐고? 파드 이름 끝에 붙는 해쉬값이 달라짐으로써 인식할 수 있다. 실제 파드가 재시작되면 끝에 해쉬값이 변경되어 새로운 파드가 생성되는 것을 볼 수 있다. 따라서 우리는 Stateless 파드를 이른바 '가축'이라고 비유하는 셈이다.

 

반면에 상태를 갖는 Stateful 파드는 '애완동물'이라고 할 수 있다. 반려견 또는 반려묘 등 어떠한 동물을 애완동물로서 키우는 사람들을 보면 그 동물 한 마리마다 고유한 이름을 붙여준다.(ex. 호두, 흰둥이, 누렁이, .... 등등..) 이렇게 고유한 이름을 붙여준다는 것은 대체 불가능한 존재라는 걸 의미하며, 고유한 식별자를 갖는다는 것을 의미한다. 쿠버네티스에서는 이러한 역할을 StatefulSets 리소스 오브젝트가 한다. 그래서 StatefulSets은 디플로이먼트와 달리 재시작해도 동일한 파드 이름으로 생성이 된다. 여담이지만, StatefulSets은 쿠버네티스 1.5 이전 버전에는 실제로 'PetSets' 라는 이름이었다.

 

StatefulSets가 어떤 개념인지 이론적으로 이해해보았다. 그러면 이제 StatefulSets에 대한 매니페스트 예시를 하나 살펴보자. 

 

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: example-statefulsets
spec:
  serviceName: statefulsets-svc
  selector:
    matchLabels:
      name: zedd-statefulsets
  replicas: 3
  template:
    metadata:
      labels:
        name: zedd-statefulsets
    spec:
      containers:
        - name: statefulsets-container
          image: alicek106/rr-test:echo-hostname
          ports:
            - containerPort: 80
              name: web
---
apiVersion: v1
kind: Service
metadata:
  name: statefulsets-svc
spec:
  ports:
    - port: 80
      name: web
  clusterIP: None
  selector:
    name: zedd-statefulsets

 

위 매니페스트의 의미를 하나씩 살펴보자. 먼저 StatefulSet 이라는 kind를 명시함으로써 스테이트풀셋이라는 리소스 오브젝트를 생성한다. 이 매니페스트는 디플로이먼트 매니페스트랑 거의 유사하다. 다만 한 가지 차이점이 있는데 바로 spec.serviceName 항목이다. 해당 항목에는 스테이트풀셋의 파드로 접근할 수 있는 서비스 이름을 입력해야 한다. 즉, 위 예시로 따지면 kind에 Service를 명시한 서비스 리소스 오브젝트의 이름인 "statefulsets-svc" 라는 값을 그대로 명시해주어야 한다.

 

그러면 이 spec.serviceName 항목을 정의함으로써 어떤 효과가 발생하는 걸까? 우선 해당 항목을 정의하지 않는 디플로이먼트의 경우 서비스로 요청이 전달되면 서비스는 랜덤한 파드를 선택해서 특정 파드로 트래픽을 전달한다. 그림으로 도식화해보면 다음과 같다.

 

디플로이먼트에 서비스를 붙혔을 때 트래픽 전달 방식

 

하지만 스테이트풀셋을 사용한다면 파드가 상태를 갖고 있기 때문에 서비스가 랜덤하게 요청을 전달하는 게 아닌 파드의 식별자를 직접 지정해서 요청을 전달할 수 있게 한다. 그림은 아래와 같다.

 

스테이트풀셋에 서비스를 붙혓을 때 트래픽 전달 방식

 

위와 같이 파드의 식별자를 직접 지정해서 요청을 전달할 수 있도록 해주는 서비스를 헤드리스(Headless) 서비스라고 하고, 스테이트풀셋은 이러한 헤드리스 서비스를 이용한다. 매니페스트 상에서는 Service 매니페스트의 spec.clusterIP에 None 값을 명시함으로써 사용이 가능하다. 참고로 헤드리스 서비스의 이름은 SRV 레코드로 쓰이기 때문에 이로 인해 헤드리스 서비스의 이름을 통해 파드에 접근할 수 있는 IP를 반환하게 된다. 

 

추가적으로, StatefulSets은 주로 PV(Persistent Volume)과 자주 사용된다. 왜냐하면 PV를 이용하면 StatefuleSets이 내부에서 관리하는 데이터를 영속적(persistent)으로 보관할 수 있기 때문이다. 보통 StatefuleSets도 여러 개의 파드로 운영하기 때문에 StatefulSets가 생성하는 각 파드마다 PVC(Persistent Volume Claim)를 별도로 생성해주어야 하는 번거로움이 있다. 물론 이를 위해 StatefulSets 리소스 오브젝트 매니페스트에서 스테이트풀셋을 생성할 때 파드마다 PVC를 자동으로 생성함으로써 PV도 그 순간 동적으로 같이 생성되는 다이나믹 프로비져닝 기능을 사용할 수 있도록 지원한다. 자세한 사용법은 공식문서를 참조해보도록 하자. 

 

참고로 스테이트풀셋을 삭제한다고 해도 PVC와 다이나믹 프로비져닝된 PV도 같이 삭제되는 것은 아님을 알아두자.