IT/Kubernetes

[Kubernetes] Kubernetes Study: "컨트롤러 - DaemonSet, Job, CronJob"

wookiist 2021. 7. 12. 01:10

Prologue

본 포스트는 인프런 쿠버네티스 스터디 그룹에서 진행하는 스터디 자료의 일환으로 작성하였습니다. 기본적으론 [대세는 쿠버네티스] 강의를 보고 내용을 정리합니다. 그리고 제 경험이나 이해를 곁들여 포스트를 작성했습니다. 그동안 공식 문서나 블로그 포스트, CKA 강의 등 다양한 경로로 쿠버네티스를 익혀왔지만, 한국어로 잘 정리된 강좌를 한번 듣고 깔끔하게 다듬어보는 시간을 가지면 좋겠다는 생각이 들었습니다.

강의와는 조금 다를 수 있지만, 쿠버네티스 공식 문서를 보고 내용을 정리해보겠습니다.

이번 포스트에선 지난 시간에 이어 컨트롤러의 마지막 내용. "컨트롤러 - DaemonSet, Job, CronJob"을 다뤄봅니다.

DaemonSet

데몬셋은 모든(또는 일부) 노드가 파드의 복제본을 실행하도록 하는 컨트롤러입니다. 만약 노드를 클러스터에 추가하게 되면, 데몬셋이 관리하는 파드도 추가로 늘어납니다.

데몬셋은 일반적으로 다음과 같은 용도로 사용합니다.

  • 모든 노드에서 클러스터 스토리지 데몬 수행
  • 모든 노드에서 로그 수집 데몬 수행
  • 모든 노드에서 노드 모니터링 데몬 실행

용도에서 알 수 있듯이, 모든 노드에서 수행하는 애플리케이션일 경우에 데몬셋을 활용하게 된다는 점을 파악할 수 있습니다. 제 경험상 로그 수집이나 네트워크 파드 등이 데몬셋으로 관리되는 경우를 많이 보았습니다.

강의 내용

저번 시간까지 알아보았던 디플로이먼트는 파드를 배치할 때 스케줄러가 자원 상황을 파악해서 어떤 노드에는 더 많이, 어떤 노드에는 아예 없이 파드가 배포될 수 있습니다. 이와 달리 데몬셋은 자원 상황과는 관계 없이 모든 노드에 공평하게 1개씩 배치됩니다.

강의에서 예시를 들어주신 경우를 설명드리자면,

  • Performance 수집
    • 각 노드의 성능 상태를 수집할 경우에 노드마다 Agent가 설치됩니다.
  • Logging 수집
    • 노드마다 어떤 문제가 일어났는지 등을 파악하기 위해 각 노드에 로깅 파드가 배포될 수 있습니다.
  • Storage
    • GlusterFS와 같은 솔루션을 활용하여 각각 노드의 자원을 NFS로 활용할 수 있게 도와줍니다.
  • 쿠버네티스 자체 네트워크
    • 쿠버네티스 자체적으로도 네트워크 관리를 위해서 네트워크 파드를 배치하게 되는데 이 부분은 추후 강좌에서 다루게 될 예정입니다.

또, 파드가 새로 생성되면, 쿠버네티스 클러스터에서만 접근이 가능한 IP가 하나 생성됩니다. 이 IP는 외부에서는 접근이 불가능하며, 파드가 재생성되면 IP도 변경됩니다.

이번엔 데몬셋의 매니페스트 파일을 살펴보겠습니다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-1
spec:
  selector:
    matchLabels:
      type: app
  template:
    metadata:
      labels:
        type: app
    spec:
      nodeSelector:
        os: centos
      containers:
        - name: container
          image: busybox:1.33

이전 디플로이먼트와 크게 다른 점은 없습니다만, 여기선 spec.template.spec.nodeSelector 에 주목해주세요. nodeSelector 필드가 정의되어 있다면, 해당 셀렉터 레이블이 설정된 클러스터 노드에만 데몬셋이 배포됩니다. 만약 이 필드가 없다면 이전에 말씀드린대로 모든 노드에 배포되겠죠.

Job

잡은 하나 이상의 파드를 생성하고, 지정한 수만큼의 파드가 성공적으로 종료될 때까지 계속해서 파드를 재실행하는 컨트롤러입니다. 잡을 사용하는 간단한 사례는, 잡을 하나 생성하고, 파드 하나를 안정적으로 실행하고 완료하는 작업입니다. 쿠버네티스 공식 문서에 소개된 다음의 매니페스트를 한번 보겠습니다. 다음의 예시는 파이(π)의 2000자리까지 계산해서 출력하는 잡입니다.

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

이 매니페스트에서 주목할 점은 apiVersionbatch/v1 으로 정의되어 있다는 점과 spec.backoffLimit 입니다. spec.backoffLimit 은 작업이 실패했다는 것으로 간주하기 전에 몇 번 정도의 재시도 기회를 줄지 결정하는 값이라고 보시면 됩니다. 여기서는 4 이므로, 4번 정도 작업이 재시작되면, 이 작업이 실패했다고 설정됩니다. 기본적으로 백오프 제한은 6으로 설정되어 있습니다.

CronJob

크론잡은 반복되는 일정에 맞추어 잡을 생성합니다. 우리가 크론탭을 사용해 어떤 작업을 스케줄 하듯이, 크론잡 오브젝트를 만들면 마치 크론탭에 생성한 한 줄의 스케줄과 같은 개념입니다. 크론잡은 잡을 크론 형식으로 정의된 일정에 따라 주기적으로 동작시킵니다. 이 오브젝트도 바로 매니페스트를 보겠습니다. 아래 매니페스트를 실행하면, 현재 시간과 hello 메시지를 1분마다 출력하게 됩니다.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

크론 스케줄 문법

쿠버네티스 공식 문서에 보면 크론 스케줄링을 하는 문법이 소개되어 있습니다. 크론탭 사용하듯이 사용하시면 됩니다.

# ┌───────────── 분 (0 - 59)
# │ ┌───────────── 시 (0 - 23)
# │ │ ┌───────────── 일 (1 - 31)
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │                                 특정 시스템에서는 7도 일요일)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
항목 설명 상응 표현
@yearly (or @annually) 매년 1월 1일 자정에 실행 0 0 1 1 *
@monthly 매월 1일 자정에 실행 0 0 1 * *
@weekly 매주 일요일 자정에 실행 0 0 * * 0
@daily (or @midnight) 매일 자정에 실행 0 0 * * *
@hourly 매시 0분에 시작 0 * * * *

참고

마무리

이렇게 해서 인프런 강의의 "컨트롤러"를 모두 다뤄보았습니다. 내용이 많이 부실하고, 설명이 어렵게 되어 있는 등의 문제가 있을 것으로 보입니다. 추후 수정을 통해 다듬어보겠습니다.

여기까지 따라오시느라 고생이 많으셨습니다. 만약 이 글이 도움이 되셨다면 글 좌측 하단의 하트❤를 눌러주시면 감사하겠습니다.

혹시라도 글에 이상이 있거나, 이해가 가지 않으시는 부분, 또는 추가적으로 궁금하신 내용이 있다면 주저 마시고 댓글💬을 남겨주세요! 빠른 시간 안에 답변을 드리겠습니다 😊

반응형