[Kubernetes] 워크로드 리소스 (ReplicaSet, Deployment .etc)

앞서 쿠버네티스의 전체적인 아키텍처와 클러스터, 노드, 파드를 알아보았다.

이번에는 쿠버네티스의 워크로드 리소스들을 정리해보고자한다.

 

먼저 쿠버네티스에서 워크로드는 클러스터에서 실행되는 Application을 의미하며, 이러한 하나의 워크로드는 파드 집합으로 구성된다.

주요 워크로드 리소스에는 ReplicaSet(레플리카셋), Deployment(디플로이먼트), StatefulSet(스테이트풀셋), DaemonSet(데몬셋)이 존재한다.

 

ReplicaSet

레플리카셋은 파드의 수를 일정하게 유지시키는 데에 목적을 둔 워크로드 리소스이다. 그렇기 때문에 파드에 대한 가용성(Avability)을 보장한다고 볼 수 있다.

 

 

다음은 레플리카셋을 정의하는 매니페스트 파일이다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: example-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: nginx
        image: nginx:latest

 

+) 매니페스트 파일에 대한 것은 이쪽을 먼저 읽고 오자

[Kubernetes] Manifest 파일과 구조 & 작성방법

 

 

위 매니페스트 파일에 따르면, 이 레플리카셋은 nginx 컨테이너를 구동시키는 파드를 3개 유지하도록 설정되어 있는 것을 확인할 수 있다. spec의 replicas 구문에서의 숫자를 변경해 유지할 파드의 갯수를 조절할 수 있다.

이 레플리카셋은 주로 이렇게 단일로만 사용하지 않고, 보통 디플로이먼트를 사용함으로써 레플리카셋을 사용한다고 한다.

 

Deployment

디플로이먼트는 파드와 레플리카셋에 대한 선언문으로, Application의 배포와 업데이트를 관리하는 리소스로 레플리카셋을 기반으로 한다. 

 

다음은 디플로이먼트를 정의하는 매니페스트 파일이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: nginx
        image: nginx:latest

 

코드를 보면 알 수 있듯이, 디플로이먼트는 레플리카셋을 내부적으로 사용하고 있는것을 볼 수 있다. 레플리카셋에서와 마찬가지로 replicas의 숫자를 변경해 유지할 파드의 숫자를 조절할 수 있다.

또한 Application의 롤링 업데이트와 롤백을 지원한다.

• 롤링 업데이트 : 배포한 서비스가 업데이트되어 새 버전을 배포해야하는 경우, 롤링 업데이트를 통해 새 버전의 파드를 배포할 수 있다.
• 롤백 : 새롭게 배포한 이미지 등에 문제가 생겨 롤백을 해야하는 경우, 디플로이먼트 롤백을 이용할 수 있다.

이러한 롤링 업데이트를 진행하는 방법에 따라 다양한 전략이 존재한다. 이 부분은 추후에 따로 포스팅을 통해 알아보도록 한다.

 

StatefulSet

스테이트풀셋은 Application의 상태를 저장하고 관리하는 리소스이다. 디플로이먼트와 동일한 특성을 가지지만, StatefulSet에서는 각 파드에 고유한 식별자를 부여해서, 순차적으로 파드를 실행 / 배치된다는 점을 가진다.

 

왜 이런 StatefulSet이 필요한가?

기본적으로 Application은 Stateless와 Stateful로 나누어볼 수 있다. Stateless Application은 상태를 저장하지 않으며 각 요청을 독립적으로 처리한다. 즉, 웹 서버(Apache, Nginx 등)와 같은 Application이 여기에 속한다고 볼 수 있다. 

더불어 Stateless Application은 수평적 스케일링(Scaling)에 용이하고 Application을 상태를 저장하지 않기에 재시작하거나 업데이트에도 용이하다.

(App이 죽어도 재시작만 해주면 되기 때문이다.)

 

이러한 Stateless Application과는 달리, 상태를 저장해야만 하는 Application들이 있다. 이들을 Stateful Application이라고 하며, 대표적으로 DB(데이터베이스)가 여기에 속한다.

Stateful Application은 반드시 그 상태를 유지(볼륨의 연결)해야만 하며, 각각 고유한 네트워크 식별자를 가져야한다.

 

 

 

즉, StatefulSet은 상태를 저장할 필요가 있는 DB와 같은 Application을 배포하는데에 사용할 수 있다.

StatefulSet의 매니페스트 파일 작성은 아래와 같다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql-statefulset
spec:
  serviceName: mysql-service
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql-container
        image: mysql:latest
        env:
          - name: MYSQL_ROOT_PASSWORD
            value: "your-root-password"
          - name: MYSQL_DATABASE
            value: "your-database-name"
          - name: MYSQL_USER
            value: "your-username"
          - name: MYSQL_PASSWORD
            value: "your-password"
        ports:
          - containerPort: 3306
        volumeMounts:
          - name: mysql-persistent-storage
            mountPath: /var/lib/mysql

 

위 파일은 MySQL 기반의 StatefulSet을 생성하는 매니페스트 파일이다. 물론 실제로 MySQL StatefulSet을 구성하기 위해서는 볼륨과 외부에 오픈하는 서비스의 연결도 필요하나, StatefulSet만 집중적으로 보기 위해 생략을 한 부분이 있다.

 

DaemonSet

모든/특정 레이블의 노드에서 하나의 파드를 배치/실행하도록 하는 리소스이다. 각 노드에 백그라운드 프로세스(Daemon)를 배포하는데에 효과적이다. (분산배치)

데몬셋은 노드에 단 하나만의 파드만 배치함으로 인해 따로 레플리카 설정을 하지 않는다.

데몬셋은 각 노드에 모니터링이나 로그 수집용 에이전트를 추가하고자 할때에 이용할 수 있을 것으로 보인다.

 

 

이렇게 쿠버네티스의 워크로드 리소스들 중 ReplicaSet, Deployment, StatefulSet, DaemonSet을 알아보았다.

다음으로 쿠버네티스의 스토리지 관리에 대해 알아보도록 한다.