[k8s] 쿠버네티스 컨트롤러에 대해 알아보자

개요

이전에 쿠버네티스의 오브젝트에 대해 학습했었다.

쿠버네티스는 크게 오브젝트와 오브젝트를 관리하는 컨트롤러로 나뉜다고 했었는데 이번엔 컨트롤러에 대해 정리하고자 한다.

 

https://dgjinsu.tistory.com/68

[k8s] 쿠버네티스의 기본 오브젝트 (Pod, Service, Volume, Namespace)

 

 

 

 

 

 

 

컨트롤러란?

쿠버네티스의 컨트롤러는 쿠버네티스 클러스터의 상태를 관리하고 원하는 상태로 유지하기 위한 중요한 구성 요소이다. 현재 클러스터의 상태를 지속적으로 모니터링하고, 사용자가 원하는 상태와 비교하여 차이를 조정한다. 

 

컨트롤러의 기능들은 다음과 같다.

• Autho Healing
• Software Update
• Auto Sacling
• Job

 

 

컨트롤러에는 여러가지가 있지만 이들 중 4가지만 알아볼 예정이다. 

• ReplicaSet
• Deployment
• DaemonSet
• Job / CronJob

 

 

 

 

1. ReplicaSet

레플리카셋(ReplicaSet)은 파드(Pod) 집합의 실행을 안정적으로 유지하는데 목적을 갖춘 쿠버네티스 워크로드이다. 레플리카셋은 사용자가 지정한 개수만큼 복제 파드를 생성해주고 컨트롤러를 이용해 해당 개수의 복제 파드가 정상 실행 중인지 항상 감시한다. 파드 하나에 문제가 생겨 다운되면 이를 감지해 새 파드를 바로 생성해다.

 

즉, Pod의 복제본 수를 유지하고 관리하는 컨트롤러이다. 지정된 수의 Pod 본제본을 유지하고, Pod가 삭제되거나 장애가 발생한 경우새로운 Pod를 자동으로 생성한다.

 

 

ReplicaSet이 해주는 몇 가지 기능들이다. 

 

먼저 Pod가 죽으면 이를 감지하고 Pod를 재생성 해준다. 

 

이를 활용하여 만약 Pod의 Version Upgrade를 하고싶다면 Pod의 Template을 수정하고 기존의 떠있는 Pod를 제거한다면 재생성할 때 새 버전의 Pod를 띄울 수 있다. 

 

 

 

 

ReplicaSet은 replicas의 수 만큼 Pod를 유지하려고 한다.

따라서 단순히 replicas의 값을 변경하는 것 만으로도 Sacle Out을 진행할 수 있다. 

 

보통 따로 controller와 Pod를 만들지 replicas를 이용해 Controller만 만들곤 한다. 

 

 

아래는 예제 yml이다.

apiVersion: v1
kind: ReplicationController
metadata:
 name: replication-1
spec:
 replicas: 1
 selector:
   type: web
 template:
   metadata:
     name: pod-1
     labels:
       type: web
   spec:
     containers:
     - name: container
       image: tmkube/app:v2

 

 

 

 

ReplicaSet에선 Pod를 Select할 때 matchExpressions 또한 가능하다. 

보통 Selector은 key와 value모두 동일할 때 Pod를 선택하는데 matchExpressions를 사용하면 그림과 같이 옵션을 지정하여 조금 더 유연하게 사용할 수 있다. 

 

아래와 같이 yml을 생성하면서 selector를 지정할 수 있다. 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: replica-1
spec:
 replicas: 3
 selector:
   matchLabels:
     type: web
   matchExpressions:
   - {key: ver, operator: Exists}
 template:
   metadata:
     name: pod
...

 

위 예시 yml에선 operator 값으로 Exists를 지정했는데 이는 key가 ver을 가지는 Label을 가진 Pod들은 전부 선택하겠다는 뜻이다. 

 

operator의 종류는 아래와 같다.

 

 

 

 

 

 

 

 

2. Deployment

프로덕션 환경에서는 제품을 개발해 배포하고 방치해두고만 있지는 않는다. 고객의 니즈에 따라, 버그와 같은 새로운 이슈가 뜰 때마다 제품을 업데이트하는데, 이를 재배포하기 위해 서버를 중단하는 것은 큰 반발을 가져온다.

 

디플로이먼트(Deployment)는 파드 또는 레플리카셋의 선언적 업데이트를 제공하는 워크로드이다.

 

 

배포 전략에는 Recreate, Rolling Update, Blue/Green, Canary 정도가 있다. 

 

쿠버네티스의 디플로이먼트에선 기본적으로 Rolling Update 방식의 전략을 갖는다. 

 

Recreate

 

Recreate는 기존 버전의 Pod들을 내리고 새로운 버전의 Pod들을 올리는 방식이기 때문에 다운타임이 발생한다. 

 

그림과 같이 Deployment의 template을 업데이트 하게되면 먼저 기존의 ReplicaSet(왼쪽)의 replicas값을 0으로 변경하게 된다. 이후 새로운 ReplicaSet을 만들고 여기엔 새롭게 변경된 V2의 Pod Template이 들어가게 된다. 

 

위 그림에 해당하는 yml 파일은 아래와 같다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-1
spec: 
  selector:
    matchLabels:
      type: app
  replicas: 2 
  strategy:
    type: Recreate
  revisionHistoryLimit: 1
template:
    metadata:
      labels:
        type: app
    spec:
      containers:
      - name: container
        image: tmkube/app:v1

 

 

 

 

Rolling Update (Default)

그림과 같이 우선 ReplicaSet을 만드는데 처음엔 replicas의 값은 1이다. 이 상황에선 v1 2개와 v2 1개의 Pod로 트래픽이 분산된다. 

 

 

v2 1개 새롭게 잘 떴다면 v1의 replica는 1로 줄게 되고 위 과정을 계속 반복해 하나씩 하나씩 새 버전으로 update해나간다. 

 

 

위 그림에 해당하는 yml 파일은 아래와 같다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-2
spec: 
  selector:
    matchLabels:
      type: app
  replicas: 2 
  strategy:
    type: RollingUpdate
  minReadySeconds: 10
  template:
    metadata:
      labels:
        type: app
    spec:
      containers:
      - name: container
        image: tmkube/app:v1

 

 

 

 

 

 

 

3. DaemonSet

DaemonSet은 클러스터 내의 각 노드에서 특정 파드가 실행되도록 보장하는 리소스이다. 

 

이는 로그 수집, 모니터링 에이전트, 네트워크 플러그인 등 시스템 수준의 서비스를 배포할 때 유용하다. 

 

DaemonSet은 클러스터의 모든 (또는 선택된) 노드에 파드를 배포하고, 새로운 노드가 클러스터에 추가될 때마다 자동으로 파드를 생성한다.

 

 

DaemonSet은 selector로 Node를 연결한다. 만약 centos에서만 돌아가는 애플리케이션을 구동해야할 때 ubuntu os를 갖고 있는 Node는 제외하고 선택해야 한다. 

 

그럴땐 아래와 같이 nodeSelector를 사용해서 Node1, Node2에 대해서만 Pod를 생성할 수 있다. 

 

아래 코드에서 hostPort를 보면 Pod가 돌아가는 Host에 18080으로 접근하면 8080 컨테이너로 연결해준다. 

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: tmkube/app
       ports:
       - containerPort: 8080
         hostPort: 18080

 

 

 

 

 

 

 

4. Job / CronJob

 

 

Job

Job은 내부적으로 Pod를 생성하여 작업을 수행하게 되는데, Pod의 상태가 Running이 아닌 Completed가 되는 것이 최종상태이다. 

실패 시 재시작, 작업 수행 횟수 지정, 동시 실행 작업 수 지정 등의 세부 옵션도 제공한다.

 

 

 

Job엔 몇 가지 옵션을 줄 수 있다. 

 

• completions:
  • Job이 완료되기 위해 필요한 파드의 성공 횟수를 지정

• parallelism:
  • 동시에 실행할 파드의 최대 수를 지정
• activeDeadlineSeconds:
  • Job이 완료되기 전까지의 최대 시간을 초 단위로 지정

 

 

 

 

CronJob

CronJob은 주기적으로 특정 동작을 수행하고 종료하는 작업(배치 작업)을 정의하기 위한 리소스이다. 

리눅스 크론(Cron) 스케쥴링 방법을 그대로 사용한다. 

내부적으로 Job을 생성하여 작업을 수행한다. (그리고 Job은 내부적으로 Pod를 만든다.) 주기적으로 데이터를 백업하거나 데이터 점검 및 알림 전송 등의 목적으로 사용한다.

 

 

 

위 사진에선 1분 마다 Job이 생성되고 Job들은 각각 정의된 동작을 수행한다. 

 

 

아래는 CronJob을 정의하는 yml 예시이다. 

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cron-job
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: container
            image: tmkube/app

 

여기서 살펴볼 건 concurrencyPolicy 옵션인데 이는 스케줄된 작업이 아직 실행 중인 상태에서 새로운 작업이 시작될 때의 동작 방식을 정의한다. 

 

concurrencyPolicy 옵션엔 3가지가 있다.

 

• Allow
  • 기본값
  • 동시에 여러 작업이 실행될 수 있도록 허용
  • 즉, 이전 작업이 아직 종료되지 않았더라도 새로운 작업이 시작됨
• Forbid
  • 이전 작업이 아직 실행 중인 경우, 새로운 작업이 시작되지 않는다.
  • 이전 작업이 완료된 후에만 새로운 작업이 시작
  • 작업이 겹치지 않도록 보장
• Replace
  • 이전 작업이 아직 실행 중인 경우, 실행 중인 작업을 중단하고 새로운 작업으로 교체