[Kubernetes] 쿠버네티스 컨트롤러: Pod를 동적으로 관리

컨트롤러는 파드의 설정과 배포를 조금 더 편리하게 관리하기 위해 사용하는 개념입니다. 컨트롤러를 이용하면 일일이 파드를 하나씩 실행시키지 않아도 되며, 컨트롤러에 지정된 숫자만큼 항상 파드를 유지하기 때문에, 장애로 인해 일부 파드가 비정상적으로 종료되더라도 다른 노드에 새롭게 파드를 추가한다는 것과 같이 동적으로 파드들을 관리할 수 있습니다. 컨트롤러 종류에는 Replication Controller(RC), Replica Set, DaemonSet, Job, StatefulSet, Deployment들이 있습니다.

 

Replication Controller(RC)

레플리케이션 컨트롤러는 쿠버네티스 프로젝트의 초기부터 있었던 가장 기본적인 컨트롤러입니다. 지정한 숫자만큼의 파드가 항상 클러스터 안에서 실행되도록 관리합니다. RC는 크게 3가지 파트로 구성되는데, Replica의 수, Pod Selector, Pod Template로 구성됩니다.

 

• Pod Selector : Pod Selector는 라벨을 기반으로 하여 RC가 관리한 Pod를 가져오는 데 사용합니다.
• Replica 수 : RC에 의해서 관리되는 파드의 수인데, 그 숫자만큼 파드의 수를 유지합니다. 예를들어 replica의 수가 2라면 2개의 파드만 띄우고, 만약 장애가 생기거나 변경 사항으로 파드가 부족하면 부족한 수만큼 추가적으로 파드를 추가하고, 이보다 수가 많으면 파드를 삭제합니다.
• Pod Template : 파드를 새로 만들 때 어떤 파드를 만들지에 대한 정보가 필요한데 (도커 이미지, 포트, 라벨 등) 이에 대한 정보를 정의한 템플릿입니다.

 

Replica Set

레플리카세트는 기존의 RC의 새로운 버전입니다. RC와 기본적으로 같은 동작을 하지만 다른 점은 RC는 등호 기반의 셀렉터를 사용하지만 (=, !=만 확인하지만) 레플리카세트는 집합 기반의 셀렉터를 지원해서 in, notin, exists와 같은 연산자를 사용할 수 있습니다.

 

 

Deployment

디플로이먼트는 Replication Controller와 Replica Set을 좀 더 상위 추상화 개념으로 실제 운영환경에서 더 많이 사용되는 컨트롤러입니다.디플로이먼트는 쿠버네티스에서 상태가 없는(stateless)앱을 배포할 때 사용하는 가장 기본적인 컨트롤러입니다. 기본적으로 레플리카 셋과 유사하지만 단순히 실행시켜야 할 파드 개수를 유지하는 것뿐만 아니라 앱을 배포할 때 롤링 업데이트나 앱 배포 도중 잠시 멈췄다가 다시 배포할 수 있습니다. 또한 앱을 배포한 이후에 롤백을 할 수도 있습니다.

※ 롤링 업데이트란?

업데이트 해야 할  Pod를 모두 생성한 후 한 번에 트래픽을 변경하는 방법이 아니라(블루/그린 배포 방식) Pod를 하나씩 업그레이드 해가는 방식입니다.

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: sisko-deployment
spec:
  selector:
    matchLabels:
      app: sisko
  replicas: 2
  template:
    metadata:
      labels:
        app: sisko
    spec:
      containers:
      - name: sisko
        image: idock.daumkakao.io/cruise/sisko:1.1.1
        imagePullPolicy: Always
        resources:
          requests:
            cpu: 0.25
            memory: 512Mi
        ports:
        - containerPort: 8080
          protocol: TCP
...

 

 

Daemon Set

데몬셋은 클러스터 전체 노드에 특정 파드를 실행할 때 사용하는 컨트롤러입니다. 즉 전체 노드에 하나씩 꼭 있어야 하는 파드를 실행시키는 컨트롤러로 보통 로그 수집기를 실행하거나 노드를 모니터링하는 모니터링용 데몬 등을 실행시킵니다. 그런데 데몬셋은 특이한 특징이 하나 있는데, 모든 노드에 균등하게 하나씩 배포되지만, 특정 노드에만 파드가 하나씩 배포되도록 설정이 가능합니다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
  namespace: my-namespace
  Labels:
    key: value
spec:
  template:
    metadata:
      labels:
        name: my-daemonset-container
    ...
  selector:
    matchLabels:
      name: my-daemonset-container 

 

앞서 언급한 로그나 모니터링 시나리오에서 특정 장비에 대한 모니터링을 하고자 할 때 이런 시나리오가 유효합니다.

 

 

Stateful Set

지금까지 살펴봤던 컨트롤러는 모두 상태가 없는 파드들을 관리하는 용도였습니다. 상태가 없다는 것은 컨테이너에 문제가 있거나, 노드에 장애가 밠생해서 컨테이너를 새로 실행했을 때 다른 노드로 자유롭게 옮길 수 있다는 뜻입니다. 이것은 컨테이너의 장점 중 하나이지만, 어떤 이유에서든 컨테이너가 삭제된다면 현재까지 컨테이너에 저장된 데이터가 삭제된다는 특성이 있습니다.

 

하지만 때때로 앱의 특성상 컨테이너에 문제가 생기더라도 데이터를 유지해야할 때가 있습니다. 대표적인 예가 MySQL과 같은 데이터베이스입니다. 이러한 문제점을 해결하기 위해 쿠버네티스에서는 스테이트풀 세트를 이용하여 불륨을 실행시켜 특정 데이터를 저장한 후 파드를 재시작하더라도 해당 데이터를 유지하게 됩니다. 

 

※ 볼륨에 관해서는 다른 포스팅에서 다룰 예정입니다.

 

스테이트풀 세트를 이용해 실행시킨 파드는 특이하게 파드 이름 뒤에 UUID 형식의 접미사가 아니라 0, 1, 2와 같은 정수가 순서대로 붙습니다. 이와 같이 정수가 접미사로 붙는 이유는 스테이트풀 셋으로 만들어지는 파드는 실행될 때 작은 숫자부터 순서대로 실행이 되기 때문입니다. 순서대로 실행이 되어야 하기 때문에 만약 1번이 정상적으로 실행되지 않는다면 2번은 실행되지 않게 됩니다.

 

파드가 삭제될 때 역시 순서대로 삭제가 되는데, 이번에는 반대로 큰 숫자가 붙은 파드붙어 삭제되게 됩니다. 이러한 옵션은 .spec.podManagemetPolicy: Parallel 옵션을 이용해서 파드를 순서없이 병렬로 실행되거나 종료할 수 있습니다.

 

 

Job

잡은 실행된 후 종료해야 하는 성격의 작업을 실행시킬 때 사용하는 컨트롤러입니다. 대표적인 예로 주기적으로 배치 작업을 하는 경우 웹서버처럼 계속해서 파드가 떠 있을 필요가 없습니다. 이러한 경우 Job을 이용해서 필요할 수 있는데, Job은 특정 개수의 파드만큼을 정상적으로 실행하고 종료까지 보장하게 됩니다.

 

 

Cron Job

Job과 같은 배치성 작업들은 메뉴얼로 실행하는 것이 아니라, 주기적으로 자동화할 필요가 있는데, 이러한 때에 사용할 수 있는 것이 크론잡입니다. 크론잡은 정해진 스케줄에 따라 시간 기준으로 Job컨트롤러에 의해 작업을 실행시켜주는 컨트롤러입니다. 크론잡 컨트롤러는 시간에 따른 실행 조건을 정의해두고 이에 따라 Job컨트롤러를 실행해 정의된 파드를 실행시켜 Job을 수행하게 됩니다.