개념이해(2/2) -컨트롤러

이현우·2022년 4월 18일

쿠버네티스

목록 보기

3/11

1. 컨트롤러

앞에서 소개한 4개의 기본 오브젝트로 애플리케이션을 설정하고 배포하는 것이 가능한데 이를 조금 더 편리하게 관리하기 위해서 쿠버네티스는 컨트롤러라는 개념을 사용한다.

컨트롤러는 Replication Controller(aka RC), Replication Sec, DaemonSet, Job, StatefulSEt, Deployment들이 있다.

1-1. Replication Controller (aka RC)

Replication Controller(이하 RC)는 Pod를 관리해주는 역할을 하는데 지정된 숫자로 Pod를 기동 시키고 관리하는 역할을 한다.

RC는 크게 3가지 파트로 구성되는데 Replica의 수, Pod Selector, Pod Template 3가지로 구성된다.

Selector : 먼저 Pod selector는 라벨을 기반으로 하여 RC가 관리한 Pod를 가지고 오는데 사용
Replica 수 : RC에 의해서 관리되는 Pod의 수. 그 숫가만큼 Pod의 수를 유지하도록 한다.
- ex) Replica 수가 3이면, 3개의 Pod만 띄우도록 하고 이보다 Pod가 모자르면 새로운 Pod를 띄우고, 많으면 남는 Pod를 삭제한다.
Pod를 추가로 기동할 때 어떻게 Pod를 만들지 Pod에 대한 정보(도커 이미지, 포트, 라벨 등)가 필요한데 이는 Pod template이라는 부분에 정의 한다.

주의사항

이미 돌고 있는 Pod가 있는 상태에서 RC 리소스를 생성하면 그 Pod의 라벨이 RC의 라벨과 일치하면 새롭게 생성된 RC의 컨트롤을 받는다.
만약 Pod들이 RC에서 정의한 replica 수보다 많으면 수에 맞게 추가분의 pod를 삭제하고 모자르면 template에 정의된 Pod 정보에 따라서 새로운 Pod를 생성하는데
기존에 생성되어 있는 Pod가 template에 정의된 스펙과 다를지라도 그 Pod를 삭제하지 않는다.
ex) 기존에 아파치 웹서버로 기동중인 Pod가 있고, RC의 template은 nginx로 Pod를 실행하게 되어 있다하더라도 기존에 돌고 있는 아파치 웹서버 기반의 Pod를 삭제하지 않는다.

RC 예시

nginx라는 이름의 RC를 정의한 것으로 label이 "app:nginx"인 Pod들을 관리하고 3개의 Pod가 항상 운영되도록 설정한다.
Pod는 app:nginx 라는 라벨을 가지면서 이름이 nginx이고 nginx 이미지를 사용해서 생성하고 컨테이너의 포트는 80번 포트를 이용해서 서비스를 제공한다.

1-2. ReplicaSet

ReplicaSet은 Replication Controller의 새버전으로 생각하면 된다.

큰 차이는 없고 RC는 Equality 기반 Selector를 이용하는데 반해 Replica Set은 Set기반의 Selector를 이용한다.

1-3. Deployment

Deployment는 Replication Controller와 Replica Set의 좀 더 상위 추상화 개념이다

실제 운영에서는 ReplicaSet이나 RC를 바로 사용하는 것보다 좀 더 추상화된 Deplyment를 사용하게 된다.

1-3-1. 쿠버네티스 배포에 대한 이해

쿠버네티스에서 Deployment 없이 어떻게 배포를 하는지에 대해 이해를 하면 Deployment를 이해할 수 있다.

위와 같은 Pod와 RC가 있다 하자.

애플리케이션이 업데이트되서 새로운 버전으로 컨테이너를 굽고 이 컨테이너를 배포하는 시나리오에 대해 알아보자

여러가지 배포 전략이 있겠지만 많이 사용하는 블루/그린 배포와 롤링 업데이트 방식 두가지 방법에 대해서 설명한다.

1-3-2. 블루/그린 배포

블루(예전) 버전으로 서비스 하고 있던 시스템을 그린(새로운) 버전을 배포한 후 트래픽을 블루에서 그린으로 한번에 돌리는 방식
여러가지 방법이 있지만 가장 손쉬운 방법으로는

새로운 RC를 만든다
새로운 템플릿으로 Pod를 생성
Pod 생성이 끝나면 서비스를 새로운 Pod로 옮긴다.
후에 배포가 완료되고 문제가 없으면 예전 버전의 RC와 Pod를 지워준다.

1-3-3. 롤링 업그레이드

Pod를 하나씩 업그레이드 해가는 방식

새로운 RC를 만든다.
기존 RC에서 replica 수를 하나 줄이고, 새로운 RC에는 replica 수를 하나만 준다.
- 라벨을 같은 이름으로 해주면 서비스는 자연히 새로운 RC에 의해 생성된 Pod를 서비스에 포함 시킨다.
기존 RC의 replica를 하나 더 줄이고 새로운 RC의 replica를 하나 더 늘린다.
마찬가지로 작업을 반복

만약 배포가 잘못되었을 경우 기존 RC의 replica 수를 원래대로 올리고 새버전의 replica 수를 0으로 만들어서 예전 버전의 Pod로 롤백이 가능하다.

이 과정은 kubectl rolling-update라는 명령으로 RC 단위 컨트롤이 가능하지만 그래도 여전히 작업이 필요하고 배포 과정을 모니터링 해야 한다.

그리고 가장 큰 문제는 kubectl rolling-update 명령은 클라이언트에서 실행 하는 명령으로 명령어 실행 중에 클라이언트의 연결이 끊어 지면 배포 작업이 비정상적으로 끊어질 수 있는 문제가 있다.

마지막으로 롤백 과정 역시 수동 컨트롤이 필요할 수 있다.

이러한 과정을 자동화하고 추상화한 개념이 Deployment라고 보면 된다.

Deployment는 Pod 배포를 위해서 RC를 생성하고 관리하는 역할을 하며 특히 롤백을 위한 기존 버전의 RC 관리 등 여러가지 기능을 포괄적으로 포함하고 있다.

2. 고급 컨트롤러

RC, RS, Deployment는 웹서버와 같은 일반적인 워크로드에 대해 Pod를 관리하기 위한 컨트롤러이다.
실제 운영환경에서는 웹서버와 같은 일반적인 워크로드 이외에 데이타베이스, 배치작업, 데본서버와 같이 다양한 형태의 워크로드 모델이 존재하는데 이를 지원하기 위해 쿠버네티스는 다양한 컨트롤러를 제공함으로써 Pod의 운영을 다양한 시나리오에 맞게 지원하고 있다.

2-1. DaemonSet

DaemonSet(이하 DS)은 Pod가 각각의 노드에서 하나씩만 돌게 하는 형태로 Pod를 관리하는 컨트롤러

RC나 RS에 의해서 관리되는 Pod는 여러 노드의 상황에 따라서 일반적으로 비균등적으로 배포가 되지만, DS에 의해 관리되는 Pod는 모든 노드에 균등하게 하나씩만 배포 된다.
이런 형태의 워크로드는 서버의 모닡커링이나 로그 수집 용도로 많이 사용되는데, DS의 다른 특징 중 하나는, 특정 Node들에만 Pod가 하나씩만 배포 되도록 설정이 가능하다.
앞에서 언급한 로그나 모니터링 시나리오에서 특정 장비에 대한 모니터링을 하고자 할 때 이런 시나리오가 유효하다.

2-2. Job

워크로드 모델 중에서 배치나 한번 실행되고 끝나는 형태의 작업이 있을 수 있다.
이런 경우 웹서버 처럼 계속 Pod가 떠 있을 필요 없이 작업을 할 때만 Pod를 띄우면 된다.
이러한 형태의 워크로드 모델을 지원하는 컨트롤러를 Job이라고 한다.

Job에 의해서 관리되는 Pod는 Job이 종료되면, Pod를 같이 종료
Job을 정의할 때는 보통 아래와 같이 컨테이너 스펙 부분에 image 뿐만 아니라, 컨테이너에서 Job을 수행하기 위한 command를 같이 입력

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

Job 컨트롤러에 의해서 실행된 Pod는 이 command의 실행 결과에 따라서Job이 실패한지 성공한지를 판단
Job이 종료되었는데 결과가 실패라면, 이 Job을 재실행할 지 또는 그냥 끝낼지를 설정에 따라서 한다.

2-3. CronJob

Job 컨트롤러에 의해서 실행되는 배치성 작업들에 대해 고려할 점 중 하나는 이런 배치성 작업을 메뉴얼로 실행하는 것이 아니라, 주기적으로 자동화해서 실행할 필요가 있는데, 이렇게 주기적으로 정해진 스케쥴에 따라 Job 컨트롤러에 의해 작업을 실행해주는 컨트롤러로 CronJob 컨트롤러가 있다.

cron jobs 컨트롤러는 Unix cron 명령어처럼, 시간에 따른 실행 조건을 정의해놓을 수 있고, 이에 따라 Job 컨트롤러를 실행하여 정의된 Pod를 실행할 수 있게 한다.

아래는 cron jobs 컨트롤러의 예제이다.

apiVersion: batch/v1beta1
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