컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 Part 3.4

1. 데몬셋(DaemonSet)

데몬셋은 클러스터 전체 노드에 특정 파드를 실행할 때 사용하는 컨트롤러로, 디플로이먼트의 replicas가 노드 수만큼 정해져 있는 형태라고 할 수 있는데, 노드 하나당 파드 한 개만을 생성한다.

 

이러한 데몬셋은 Calico 네트워크 플러그인과 kube-proxy를 생성할 때, 또는 MetalLB의 스피커에서도 사용될 수 있다. 이들의 공통점은 노드의 단일 접속 지점으로 노드 외부와 통신한다는 것으로, 파드가 1개 이상 필요하지 않는다.

결국 노드를 관리하는 파드라면 데몬셋으로 만드는 게 가장 효율적이다. 또한 로그 수집, 모니터링, 네트워크 에이전트, 볼륨 관리 등과 같이 모든 노드에서 실행되어야 하는 시스템 레벨의 작업에 이상적이다.

 

 

특징

• 노드 단위 배포

데몬셋은 클러스터의 모든 노드에 동일한 파드 인스턴스를 배포한다. 따라서 각 노드에서 독립적으로 실행되는 애플리케이션이나 서비스를 구성할 때 유용하다.

• 스케줄링과 자동 복제

데몬셋은 쿠버네티스의 스케줄러를 통해 자동으로 노드에 파드 인스턴스를 배치한다. 새로운 노드가 클러스터에 추가되면 데몬셋은 해당 노드에도 파드를 자동으로 복제하여 유지한다.

• 단일 인스턴스

데몬셋은 각 노드에 하나의 파드 인스턴스만 실행되도록 보장한다. 다른 리소스 제어 개체와 달리 파드 인스턴스가 여러 개 생성되는 것을 허용하지 않는다.

 

2. 컨피그맵(ConfigMap)

설정(config)을 목적으로 하는 오브젝트로, 컨테이너에서 필요한 환경설정 내용을 컨테이너와 분리해서 제공해 주기 위한 기능이다. 컨피그맵을 컨테이너와 분리해 둠으로써 하나의 동일한 컨테이너를 가지고 환경별(개발, 스테이지, 운영)로 모두 사용하는 것이 가능해진다.

 

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-dev
  namespace: default
data:
  DB_URL: localhost
  DB_USER: myuser
  DB_PASS: mypass
  DEBUG_INFO: debug

 

컨피그맵을 컨테이너에서 사용하는 방법

• 일부 설정만 가져와 사용하기

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configapp
  labels:
    app: configapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: configapp
  template:
    metadata:
      labels:
        app: configapp
    spec:
      containers:
      - name: testapp
        image: arisu1000/simple-container-app:latest
        ports:
        - containerPort: 8080
        env:
          - name: DEBUG_LEVEL
            valueFrom:
              configMapKeyRef:
                 name: config-dev
                 key: DEBUG_INFO

• 전체 컨피그맵 데이터를 한꺼번에 가져와 사용하기

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configapp
  labels:
    app: configapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: configapp
  template:
    metadata:
      labels:
        app: configapp
    spec:
      containers:
      - name: testapp
        image: arisu1000/simple-container-app:latest
        ports:
        - containerPort: 8080
        envFrom:
        - configMapRef:
            name: config-dev

• 컨피그맵을 볼륨으로 가져와 사용하기

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configapp
  labels:
    app: configapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: configapp
  template:
    metadata:
      labels:
        app: configapp
    spec:
      containers:
      - name: testapp
        image: arisu1000/simple-container-app:latest
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
      - name: config-volume
        configMap:
          name: config-dev

 

3. PV와 PVC

쿠버네티스에서는 때때로 파드에서 생성한 내용을 기록하고 보관하거나 모든 파드가 동일한 설정 값을 유지하고 관리하기 위해 공유된 볼륨으로부터 공통된 설정을 가지고 올 수 있도록 설계해야 할 때가 존재한다. 이런 경우를 위해 쿠버네티스는 다양한 형태의 볼륨을 제공한다.

• 임시: emptyDir
• 로컬: host Path, local
• 원격: persistentVolumeClaim, cephfs, cinder, csi, fc(fibre channel), flexVolume, flocker 등
• 특수 목적: downwardAPI, configMap, secret, azureFile, prejected
• 클라우드: awsElasticBlockStore,  azureDisk, gcePersistentDist

 

쿠버네티스는 필요할 때 PVC(PersistemtVolumeClaim, 지속적으로 사용 가능한 볼륨 요청)를 요청해 사용한다. PVC를 사용하려면 PV(PersistentVolume, 지속적으로 사용 가능한 볼륨)로 볼륨을 선언해야 한다. PV는 볼륨을 사용할 수 있게 준비하는 단계이고, PVC는 준비된 볼륨에서 일정 공간을 할당받는 것이다.

 

 

PV는 볼륨 자체를 의미한다. 클러스터 안에서 자원으로 다루며, 파드와는 별개로 관리되며 별도의 생명 주기가 있다.

PVC는 사용자가 PV에 하는 요청이다. 사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등을 정해서 요청한다.

 

쿠버네티스 볼륨을 파드에 직접 할당하는 방식이 아니라 중간에 PVC를 두어 파드와 파드가 사용할 스토리지를 분리한다. 이런 구조는 파드 각각의 상황에 맞게 다양항 스토리지를 사용할 수 있게 한다. 다양한 스토리지를 PV로 사용할 수 있지만 파드에 직접 연결하는 것이 아니라 PVC를 거쳐서 사용하므로 파드는 어떤 스토리지를 사용하는지 신경쓰지 않아도 된다.

 

PV와 PVC는 아래와 같은 생명주기가 있다.

 

• Provisioning(프로비저닝)

PV를 만드는 단계를 말한다. 프로비저닝 방법에는 두 가지가 있는데, PV를 미리 만들어 두고 사용하는 정적(static) 방법과 요청이 있을 때 마다 PV를 만드는 동적(dynamin) 방법이 있다.

정적 프로비저닝은 PV를 프로비저닝할 때 클러스터 관리자가 미리 적정 용량의 PC를 만들어 두고 사용자의 요청이 있으면 미리 만들어둔 PV를 할당한다. 사용할 수 있는 스토리지 용량에 제한이 있는 경우 유용하다. 미리 만들어 둔 용량보다 큰 요청은 실패한다.

동적 프로비저닝을 할 때는 사용자가 PVC를 거쳐서 PV를 요청했을 때 생성해 제공한다. 사용자가 원하는 용량만큼을 생성해서 사용할 수 있다.

 

• Binding(바인딩)

바인딩은 프로비저닝으로 만든 PV를 PVC와 연결하는 단계로, PVC에서 원하는 스토리지의 용량과 접근방법을 명시해서 요청하면 거기에 맞는 PV가 할당된다. PVC에서 원하는 PV가 없다면 요청은 실패하는데, 이 때 PVC는 원하는 PV가 생길 대까지 대기하다가 바인딩한다.

PV와 PVC의 매핑은 1대1 관계로, PVC 하나가 여러 개의 PV에 할당될 수 없다.

 

• Using(사용)

PVC는 파드에 설정되고 파드는 PVC를 볼륨으로 인식해서 사용한다. 할당된 PVC는 파드를 유지하는 동안 계속 사용하며 시스템에서 임의로 삭제할 수 없다(Storage Object in Use Protection, 사용중인 스토리지 오브젝트 보호).

 

• Reclaiming(반환)

사용이 끝난 PVC는 삭제되고 PVC를 사용하던 PV를 초기화(reclaim)하는 과정을 거친다. 초기화 정책에는 Retain, Delete, Recycle이 있다.

 

Retaim - PV를 그대로 보존

Delete - PV를 삭제하고 연결된 외부 스토리지 쪽의 볼륨도 삭제

Recycel - PV의 데이터들을 삭제하고 다시 새로운 PVC에서 PV를 사용할 수 있도록 함.

 

4. 스테이트풀셋(StatefulSet)

쿠버네티스에서는 주로 레디스, 주키퍼, 카산드라, 몽고DB 등의 마스터-슬레이브 구조 시스템에서 파드가 만들어지는 이름과 순서를 예측해야 할 때가 있는데, 이런 경우 스테이트풀셋을 사용한다.

 

스테이트풀셋은 columeClaimTemplates 기능을 사용해 PVC를 자동으로 생성할 수 있고, 각 파드가 순서대로 생성되기 때문에 고정된 이름, 볼륨, 설정 등을 가질 수 있다(다만, 효울성 면에서 좋은 구조가 아니므로 요구 사항에 맞게 적절히 사용해야 한다). 또한, 일반적으로 스테이트풀셋은 volumeClaimTemplates를 이용해 자동으로 각 파드에 독립적인 스토리지를 할당해 구성할 수 있다.

 

 

즉, 스테이트풀셋은 컨테이너 애플리케이션의 상태를 관리하는 데 사용하는 컨트롤러이다. 디플로이먼트 컨트롤러와 같이 파드를 배포하고 복제본을 제공하며 스케일링을 관리할 수 있다. 그러나 디플로이먼트와 다르게 파드의 순서 및 파드의 고유성을 보장하며, 동일한 스펙으로 생성되지만 각각 고유한 볼륨을 가지고 있다.

 

사용할 때 주의사항

• 파드에 사용할 스토리지는 PVC를 통해서만 가능하다.
• 스테이트풀셋을 삭제하거나 파드를 삭제하더라도 볼륨은 삭제되지 않는다.
• 스테이트풀셋의 각 파드는 고유하게 식별되어야하며, 파드에 접근할 때에도 개별 포트에 접근해야 한다. 이처럼 파드의 고유한 네트워크를 제공하기 위해서 헤드리스 서비스가 필요하다. 

 

헤드리스 서비스(Headless Service)란?

일반적인 서비스와는 다른 방식으로 동작하는 서비스 유형으로, 일반적인 서비스는 로드 밸런서를 통해 클러스터 내부의 파드 집합에 접근할 수 있도록 하지만, 헤드리스 서비스는 개별 파드에 직접 접근할 수 있는 DNS 이름을 제공한다.

 

특징

• 개별 파드 접근: 개별 파드에 직접 엑세스할 수 있는 DNS 이름을 제공한다. 각 파드는 고유한 DNS 레코드를 가지며, 클라이언트는 이를 통해 파드에 직접 연결할 수 있다.
• 내부 서비스 검색: 클러스터 내의 파드를 검색하기 위한 내부 DNS 이름을 제공한다. 이를 통해 애플리케이션 내부에서 다른 파드를 찾고 통신할 수 있다.
• 외부로 노출 가능: 필요에 따라 외부 노출이 가능하다. 일반적인 서비스와 마찬가지로 로드 밸런서 유형을 선택하고 외부 IP 주소를 할당하여 외부 요청을 받을 수 있다.

 

 

 

참고

https://arisu1000.tistory.com/27843

https://velog.io/@1yangsh/k8s-%EC%BB%A8%ED%94%BC%EA%B7%B8%EB%A7%B5configmap

https://kimjingo.tistory.com/153

https://nearhome.tistory.com/107