[Kubernetes 입문] 6-2. 컨트롤러 (DemonSet, StatefulSet, Job, CronJob)

데몬셋 (DemonSet) - 공식문서

• 클러스터 전체 노드에 특정 파드를 실행할 때 사용
  • 노드가 클러스터에 추가되면, 파드도 추가됨
  • 노드가 클러스터에서 제거되면, 데몬셋이 실행한 파드가 가비지(garbage)로 수집됨
• 데몬셋의 대표적인 용도
  • 모든 노드에서 클러스터 스토리지 데몬 실행
  • 모든 노드에서 로그 수집 데몬 실행
  • 모든 노드에서 노드 모니터링 데몬 실행

# daemonset-example.yaml (데몬셋 예시)

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: fluent/fluentd-kubernetes-daemonset:elasticsearch
        env:
        - name: testenv
          value: value
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi

• .spec.updateStrategy : 데몬셋의 파드를 업데이트 하는 전략 (자세한 내용은 공식 문서 참고) 
  • 2가지 타입이 존재 ( OnDelete, RollingUpdate ) 
  • OnDelete : 데몬셋 템플릿 업데이트 후, 데몬셋 파드를 수동으로 삭제할 때만, 새로운 데몬셋 파드가 생성됨 (쿠버네티스 1.5 버전 이하에서는 기본 값)
  • RollingUpdate : 데몬셋 템플릿 업데이트 후, 오래된 데몬셋 파드가 종료되고 새로운 데몬셋 파드가 자동으로 생성됨 (1.5 이상 버전에서 기본 값)
    • .spec.updateStrategy.rollingUpdate.maxUnavailable: 업데이트 도중 사용할 수 없는 최대 DaemonSet 파드 수 (기본값 1)
    • .spec.updateStrategy.rollingUpdate.maxSurge: DaemonSet 파드가 업데이트 중에 기존의 사용 가능한 DaemonSet 파드가 존재할 수 있는 최대 수 (기본 값 0)
    • .spec.minReadySeconds: 새로 생성된 DaemonSet 파드가 사용 가능한 것으로 간주되기 위해 컨테이너 충돌 없이 준비돼야 하는 최소 시간 (기본값 0)

# DaemonSet 적용
$ kubectl apply -f {데몬셋 템플릿 이름}

# Example
$ kubectl apply -f daemonset-example.yaml

# DaemonSet 확인해보기
$ kubectl get darmonset -n {네임스페이스}

---

스테이트풀셋 (StatefuleSet)

• 상태가 있는 파드들을 관리하기 위한 컨트롤러
• 여러 파드 사이에 순서를 지정해서 실행하는 것이 가능
• Deployment와 동일하게 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 각 파드의 독자성을 유지한다는 것이(상태가 있다는 것) 차이점
• 스토리지 볼륨을 사용할 때, 재시작 시 데이터 유지가 필요할 때 사용 가능
• 다음의 항목이 필요한 애플리케이션에 유용함
  • 안정된, 고유한 네트워크 식별자
  • 안정된, 지속성을 갖는 스토리지
  • 순차적인, 정상 배포(graceful deployment)와 스케일링
  • 순차적인, 자동 롤링 업데이트
• StatefulSet을 삭제 또는 스케일 다운해도 StatefulSet과 관련된 볼륨은 삭제되지 않음
  • StatefulSet과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함

# StatefulSet 예시 (statefulset-example.yaml)

apiVersion: v1
kind: Service
metadata:
  name: nginx-statefulset-service
  labels:
    app: nginx-statefulset-service
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx-statefulset-service
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx-statefulset # .spec.template.metadata.labels 와 일치해야한다.
  serviceName: "nginx-statefulset-service"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx-statefulset
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx-statefulset  # .spec.selector.matchLabels 와 일치해야한다.
        image: nginx
        ports:
        - containerPort: 80
          name: web

• 위의 Service 는 StatefulSet 에서 serviceName 에서 사용하기 위해 정의되는 것
  • 서비스 이름과 스테이트풀셋에서 만들어진 파드 이름을 조합하면 쿠버네티스 클러스터 안에서 사용하는 도메인을 만들 수 있음
  • 파드이름.서비스이름 형식 (nginx-statefuleset.nginx-statefuleset-service)
• (StatefulSet을 정의한 부분에서) .metadata.name 필드 값으로 StatefulSet 의 이름을 지정
• .spec.template.spec.terminationGracePeriodSeconds 필드는 graceful의 대기 시간을 설정
• .spec.selector 필드는 .spec.template.metadata.labels 레이블과 일치하도록 설정해야함. 해당하는 파드 셀렉터를 찾지못하면 StatefulSet 생성 과정에서 검증 오류가 발생

# StatefulSet 적용
$ kubectl apply -f {StatefulSet 템플릿 명}

# 조회
$ kubectl get svc,statefulset,pods

• Pod 명을 보면 Deployment 에서 봤을 때와 다르게, StatefulSet 에서는 스테이트풀셋이름.번호순 으로 생성된것을 볼 수 있다.
  • pod/web-0 , pod/web-1 , pod/web-2
  • 이것은 실행된 순서대로 번호가 붙은 것
• Pod가 삭제 될때는 생성된 것의 역순으로 제거됨 ( 2 -> 1 -> 0 )
  • Pod 개수를 줄일 때도 역순으로 제거.
  • 지금 상황에서 2개로 줄인다면, pod/web-2 가 우선적으로 제거됨

 

StatefulSet 에서 Pod 를 순서 없이 실행하거나 종료하기

• StatefulSet 의 기본 동작은 Pod 를 순서대로 관리하는 것
• .spec.podManagementPolicy 필드를 이용해 순서를 없앨 수도 있음
  • 기본값이 OrderedReady 로 파드를 순서대로 관리한다는 뜻
  • Parallel로 변경하면 파드들이 순서 없이 병렬로 실행

# Pod 생성 병렬 실행 예시

# Service 부분은 생략
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web-parallel # 확인을 편하게 하기위해 이름 변경
spec:
  podManagementPolicy: Parallel # 병렬 생성 정책으로 변경
  selector:
    matchLabels:
      app: nginx-statefulset
  serviceName: "nginx-statefulset-service"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx-statefulset
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx-statefulset
        image: nginx
        ports:
        - containerPort: 80
          name: web

StatefulSet 로 파드 업데이트

• .spec.updateStrategy.type 필드에 설정 RollingUpdate 와 OnDelete가 존재 (DaemonSet 에서 설명한 것과 같은 옵션)
• 기본 값은 RollingUpdate (자동으로 예전 Pod를 삭제하고 새로운 Pod를 실행)
• .spec.updateStrategy.rollingUpdate.partition 필드 값을 지정하면, StatefulSet 에 변경사항이 있을 때 지정된 값보다 큰 번호를 가진 Pod들을 업데이트 함

아래는 .spec.updateStrategy.rollingUpdate.partition을 1로 설정하고 StatefulSet 설정에 env 값을 추가한 뒤 Pod 의 상태

• web-1, web-2 만 새로 생성된 것을 확인할 수 있다. (AGE 값 확인)
• env 값을 조회했을 때, web-1, web-2 만 env가 업데이트 됨

• .spec.updateStrategy.type을 OnDelete 로 설정하면 StatefulSet 의 템플릿을 수정해도 바로 반영되지 않음
• StatefulSet 에 속한 Pod를 수동으로 삭제했을 때만, 수정된 설정이 반영된 Pod 가 생성됨

---

Job - 공식문서

• 하나 이상의 Pod 를 생성하고 지정된 수의 Pod 가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도함
• 실행된 후 종료해야 하는 성격의 작업을 실행시킬 때 사용할 수 있음

# Job 예시 (job-example.yaml)

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

• .spec.template.spec.containers[].command : 실행할 명령어 지정
  • 위 예시는 파이(π)의 2000자리까지 계산해서 출력
• .spec.template.spec.restartPolicy : 파드 실행 실패 시 재시작 정책을 지정
  • Always (기본 값) : 정상적으로 종료(0 exit code)된 상태라도 재시작
  • OnFailure : 비정상적으로 종료된 경우에만 재시작
  • Never : Container의 exit code 와 관계없이 재시작하지 않는 정책
• .spec.backoffLimit : 잡 실행이 실패했을 때 자동으로 재시도할 횟수를 설정 (기본값은 6)
  • 실패했을 때, 지수적으로 증가하는 백-오프 지연을 적용(10초, 20초, 40초 ... ). 실패 시 재시작 대기 시간을 늘려감 
  • 재시도 횟수는 다음 두 방법으로 계산
    • .status.phase = "Failed" 인 파드의 수
    • restartPolicy = "OnFailure" 를 사용하는 경우, .status.phase 가 Pending 이거나 Running 인 파드들이 가지고 있는 모든 컨테이너의 수

# Job 생성
$ kubectl apply -f {Job 템플릿 명}

# Job 조회
$ kubectl describe job {Job 이름}

kubectl get pods 를 사용해서 Job 이 생성한 파드의 상태를 볼 수도 있다.

출력된 로그를 확인하려면 $ kubectl logs {Pod 이름} 을 입력

Job 의 종류

• 비 병렬 잡(단일 잡)
  • 파드가 실패하지 않은 한, 하나의 파드만 시작
  • 파드가 성공적으로 종료하자마자 즉시 잡이 완료
  • .spec.comletions 과 .spec.parallelism 값을 설정하지 않음 (둘 다 기본값인 1을 유지)
• 고정적인 완료 횟수를 가진 병렬 잡
  • .spec.comletions 에 0이 아닌 양수 값을 지정
  • .spec.parallelism 을 설정하지 않음
• 작업 큐(queue) 가 있는 병렬 잡
  • .spec.completions 를 설정하지 않고, .spec.parallelism 을 0이 아닌 양수로 설정
  • Pod는 각자 또는 외부 서비스 간에 조정을 통해 각각의 작업을 결정해야 함
  • 파드 각각은 정상적으로 실행 종료됐는지를 독립적으로 판단이 가능
  • 파드 하나라도 정상적으로 실행 종료되면 새로운 파드가 실행되지 않음
  • 최소한 파드 1개가 정상적으로 종료된 후 모든 파드가 실행 종료되면, 잡이 정상적으로 종료됨
  • 성공적으로 종료된 파드가 하나라도 생긴 경우, 다른 파드들은 작업을 지속하지 않아야하고 어떠한 출력도 내지 않음. 이 때 파드들은 모두 종료되는 과정을 실행

잡 종료와 정리

• 잡이 완료되면 파드가 더 이상 생성되지도 않지만, 일반적으로는 삭제되지도 않는다.
• 잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있는것
• 잡 삭제는 사용자가 직접 해야함
  • kubectl delete job {Job 이름}
• 잡을 종료하는 방법에는
  • .spec.backoffLimit 을 설정해 일정 횟수 이상 재시도 후 모든 파드가 종료되도록 제어
  • 유효 데드라인 설정 : .spec.activeDeadlineSeconds 필드를 초 단위로 설정하면 됨
  • .spec.activeDeadlineSeconds > .spec.backoffLimit  와 같이 activeDeadlineSeconds 설정이 우선순위가 더 높다

---

크론잡 (CronJob) - 공식문서

• Job을 시간 기준으로 관리하도록 생성
• 지정한 시간에 한번만 잡을 실행하거나 지정한 시간동안 주기적으로 잡을 반복 실행 (1일 / 1주 / 1달 마다 1회)
• CronJob 이 실행된 후에는 위의 Job과 마찬가지로 동작함

# CronJob 예시 (cronjob-example.yaml)

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

• .spec.schedule : 스케줄을 지정. 리눅스 cron 명령어와 같은 형식
  • https://crontab.guru/ 를 활용해서 cron 명령어 작성이 가능
• .spec.jobTemplate : CronJob 에서 어떤 작업을 실행할지 작성

# 생성된 CronJob 정보 확인
$ kubectl get cronjobs

크론잡 설정

• .spec.startingDeadlineSeconds : 지정된 시간에 크론잡이 실행되지 못했을 때 필드값으로 설정한 시간까지 지나면 크론잡이 실행되지 않게 함
• .spec.concurrentcyPolicy : 크론잡이 실행하는 잡의 동시성을 관리
  • Allow (기본값) : 크론잡이 여러 개 잡을 동시에 실행할 수 있도록 설정
  • Forbid : 크론잡이 잡을 동시에 실행하지 않도록 설정. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론잡은 새로운 잡 실행을 건너뜀
  • Replace : 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론잡은 현재 실행 중인 잡실행을 새로운 잡 실행으로 대체