[kubernetes] 쿠버네티스 컨트롤러

 

[kubernetes] 쿠버네티스 목차

ㅁ 들어가며

[kubernetes] 쿠버네티스 리소스에서 리소스의 개요를 알아보았다. 이번 글에서는 리소스 중에서 Controller에 대해서 정리하였다.

 

ㅁ 컨트롤러란?

 컨트롤러(Controller)는 선언적 요구사항, desired state에 맞추기 위해 클러스터를 모니터링하고 이벤드에 응답하여 리소스를 관리 한다. 예를 들어 실내 온도 조절기에 사용자는 온도를 설정하고, 사용자가 의도한 상태를 맞추기 위해 온도 조절기는 장비를 켜고 꺼서 현재 상태를 의도한 상태에 가깝게 만들어 준다. 

 

ㅁ 쿠버네티스 배포 방식

 다양한 배포 방식

   다양한 목적에 맞게 사용할 수 있는 다양한 배포 방식을 지원한다.

 Deployment는 새로운 버전의 애플리케이션을 다양한 전략으로 무중단 배포할 수 있다.

Replicaset은 지정한 숫자만큼파드가 실행하도록 관리하는 가장 기본적인 컨트롤러이다.

StatefulSets은 실행 순서를 보장하고 호스트 이름과 볼륨을 일정하게 사용할 수 있어 순서나 데이터가 중요한 경우에 사용할 수 있다.

노드의 로그나 모니터이 필요한 경우엔 DaemonSet을 이용한다. 

배치성 작업은 Job이나 CronJob을 이용한다.

 

리소스의 상하관리 관계 

  각 리소스는 파드를 관리 최소 단위로 하여 상위 리소스가 자식 리소스를 관리한다. 예를 들어, Deployment는 ReplicaSet을 관리한고, 다시 ReplicaSet은 Pod를 관리한다. 

 

 

ㅁ Replication Controller(등가기반)

 Replication Controller는 Kubernetes의 초기 컨트롤러였다. 단순히 지정한 숫자만큼 파드를 실행하도록 관리했다. 파드에 장애가 발생해 종료되었을 때, 컨트롤러는 실행가능한 다른 노드에 다시 파드를 실행시킨다.  요즘은 다양한 배포 방식([DevOps] 청록색 배포, A/B 테스트 및 카나리아 배포)에 유용한 집합 기반의 셀렉터를 지원하는 ReplicaSet을 사용하는 추세이다.

 

ㅁ ReplicaSet(집합기반)

 Replicaset은 지정한 숫자만큼파드가 실행하도록 관리하는 가장 기본적인 컨트롤러이다. ReplicaSets는 Replication Controller의 발전된 형태이며 집합기반의 셀렉터를 지원한다. 단순히 등호기반( 같다=, 다르디!=)이 아니라 집합기반(in, notin, exists) 같은 집합연산자를 지원하여 명시된 셀렉터 조건에 맞는 새로운 파드도 직접적으로 관리한다. ReplicaSet은 셀렉터를 이용해서 필요한 새 파드를 식별하여 별도로 관리할 수 있다. 이는 카나리 배포같은 다양한 배포방식을 수행할 수 있게 한다.

레플리카셋 공식문서

 

ㅁ Deployment(배포 방법에 대한 세부적인 기능)

디플로이먼트(Deployment)는 파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공한다. 쿠버네티스에서 상태가 없는(stateless) 앱을 배포할 때 사용하는 가장 기본적인 컨트롤러이다. Replication Controller를 초기에 사용하고 최근에는  Deployment를 기본적인 앱 배포에 사용한다.

 Deployment는 유지해야할 Pod 개수만이 아니라 배포 방법에 대한 세부적인 기능을 수행할 수 있다. 앱을 배포할 때에 롤링 업데이트를 하거나, 배포 도중 Delay를 주어 배포의 안정성을 확보할 수 있다. 그리고 앱 배포 이후에 오류 발견 시 이전 버전으로 롤백이 가능하다.

디플로이먼트 공식문서

 

 

ㅁ DaemonSet

 DaemonSet은 특정 노드의 작업이 필요할 때 실행하는 Pod를 컨트롤한다. 클러스터 안에 새롭게 노드가 추가되면 DaemonSet은 자동으로 해당 노드에 파드를 실행 시킨다. 반대로 노드가 사라지면 해당 노드에 있던 Pod도 DaemonSet에 의해 삭제처리된다. 

 DaemonSet의 대표적인 용도는 다음과 같다.

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

 각 노드별로 로그를 수집하기 위해서는 노드별로 fluentd Pod가 기동되어 있어야 한다. 

관련 글 

[Elasticsearch] EFK 설치(minikube)-2
[Elasticsearch] EFK(Elasticsearch, Fluentd, kibana)란

 

ㅁ StatefulSet

 이전의 리소스들은 모두 상태가 없는(stateless) Pod를 관리하는 용도 였다. StatefulSet은 특정 볼륨을 사용해서 특정 데이터를 저장하는 경우에 필요하다.

예를 들어 Elasticsearch는 마스터 노드와 데이터 노드로 나뉘어 지고, 데이터 노드는 실제로 색인된 데이터를 저장하는 노드이다. 데이터의 안전성을 위해 Primary Shard와 Replica Shard로 나위어 데이터 손실 방지를 위해 서로 다른 노드에 하나씩 분포되어 있다. 그렇기 때문에 elasticsearch의 데이터 노드는 순서와 갯수 상태가 보존되어야 한다. 이럴 경우 statefulSet으로 배포해야한다. 

관련 글 

스테이트풀셋 공식문서

[Elasticsearch] EFK 설치(minikube)-1

 ㄴ elasticsearch를 위한 statefulSet 예시가 있음.

 

 

ㅁ Job

 Job은 실행되었다가 종료되는 말 그대로의 잡을 실행 시키기 위해 파드를 관리한다. 파드가 성공적으로 수행되는 지를 감시하며 실패 시 재시도를 수행한다. 파드가 작업이 성공적으로 완료되면 잡이 완료된다. 하나의 Job이 여러 Pod를 실행시킬 수도 있다. 

잡 공식문서

 

ㅁ CronJob

 CronJob은 Job을 반복 일정에 따라 만든다. 백업, 리포트 생성 등의 정기적 작업을 수행하기 위해 사용된다. 리눅스 cron 명령어에서 사용하는 형식을 사용하여 지정한 시간(자정 한번)에 한번만 잡을 실행하거나 지정한 시간동안(10분주기) 주기적으로 반복할 수 있다.

크론잡 공식문서

 

 

ㅁ 마무리

 리소스의 그룹 중에서 컨테이너의 실행에 관련된 Controller에 대해서 알아보았다. 다음 글에서는 컨테이너 외부에 공개하는 엔드포인트를 제공하는 Network에 관련된 리소스에 대해서 알아보도록 하겠다.