볼륨 & 스테이트풀셋 (Persistence Volme)

 

---

Pod는 Stateless 하다

파드는 일시적이며, 언제나 삭제될 수 있음
파드 그 자체는 Stateless 하며 파드의 교체와 배치를 담당하는 것이 디플로이먼트임

 

 

Pod가 사라져도 데이터 남기기

파드 자체에 상태를 남겨야 하는 Stateful App
   => MYSQL, mongoDB, redis 와 같은 데이터베이스가 있을 수 있음
   => 데이터 베이스 어플리케이션이 담긴 파드가 사라질때, 데이터가 같이 사라지면 안됨

 

 

---

Kubernetes 에도 영속적인 (Persistence) 데이터 저장을 위해 볼륨을 연결할 수 있음

Q. 볼륨과 퍼시스턴스 볼륨(Persistence Volume)은 어떤 차이가 있나요?
(AWS EC2에도 비슷한 개념이 있습니다. EBS와 인스턴스 스토어 볼륨의 차이점과 연결해서 설명해주세요.)

=> 볼륨(Volume)은 Kubernetes 클러스터 내에서 컨테이너의 데이터를 저장할 수 있는 추상적인 개념입니다. 즉, 컨테이너의 파일 시스템과 같은 것으로 생각할 수 있습니다.

퍼시스턴스 볼륨(Persistence Volume)은 Kubernetes에서 지원하는 스토리지 솔루션과 연결하여, 컨테이너의 데이터를 클러스터 외부에 저장하는 Kubernetes Volume의 일종입니다. 따라서, 컨테이너가 삭제되더라도 데이터를 보존할 수 있습니다.

따라서, 볼륨과 퍼시스턴스 볼륨의 주요 차이점은 데이터의 보존 여부입니다. 일반적인 Kubernetes 볼륨은 컨테이너가 삭제되면 데이터가 삭제되지만, 퍼시스턴스 볼륨은 클러스터 외부에 데이터를 보존할 수 있으므로 데이터가 보존됩니다.

 

 

---

Stateful한 어플리케이션을 관리하려면

Q. 퍼시스턴스  볼륨에 파드를 직접 연결하는 것은 좋은 방법이 아님

1. 볼륨 재사용 불가: 파드를 퍼시스턴스 볼륨에 직접 연결하면 해당 볼륨을 사용하는 파드가 삭제되어도 데이터가 보존됩니다. 하지만 이러한 볼륨은 해당 파드에만 연결되어 있으므로 다른 파드에서는 사용할 수 없습니다. 따라서, 효율적인 리소스 활용을 위해 퍼시스턴스 볼륨을 별도로 관리하고, 필요할 때마다 파드에 연결해야 합니다.

2. 보안 이슈: 퍼시스턴스 볼륨에 직접 연결하면 해당 볼륨을 사용하는 파드에 대한 접근 권한을 가진 모든 사용자가 데이터에 접근할 수 있습니다. 하지만 별도의 퍼시스턴스 볼륨을 사용하면 해당 볼륨에 대한 접근 권한을 제어할 수 있습니다.

3. 관리의 용이성: 퍼시스턴스 볼륨을 별도로 관리하면 다양한 파드에서 사용할 수 있으며, 필요할 때마다 쉽게 볼륨을 생성하고, 삭제하거나 크기를 변경할 수 있습니다. 이러한 유연성을 통해 볼륨 관리 및 운영이 용이해집니다.

따라서, 파드를 퍼시스턴스 볼륨에 직접 연결하지 않고, 퍼시스턴스 볼륨을 별도로 생성하고 필요할 때마다 파드에 연결하는 것이 일반적인 사용 방법입니다.

의존도를 줄이기 위해 퍼시스턴스 볼륨 클레임 (Persistence Volume Claim) 을 이용하여 PV와 연결한다.

**PV는 실제로 데이터가 저장되는 공간임
**PVC는 PV를 선택, 연결해주는 요청 그 자체임


Q. PVC는 어떻게 작동하나요?

PVC(Persistent Volume Claim)는 Kubernetes에서 제공하는 추상적인 볼륨 개념입니다. PVC는 실제 스토리지 자원이 아니며, 퍼시스턴스 볼륨(Persistent Volume)을 요청하기 위한 객체입니다.

PVC를 사용하여 파드(Pod)에서 사용할 퍼시스턴스 볼륨을 동적으로 요청하고 할당할 수 있습니다. PVC는 다음과 같은 단계를 거쳐 동작합니다.

1. PVC 생성: 먼저, PVC를 생성하고 필요한 스토리지 용량과 접근 모드, 볼륨 타입 등을 지정합니다.
2. PVC 바인딩: 생성된 PVC는 클러스터 내의 퍼시스턴스 볼륨 중에서 요청 사항과 일치하는 것을 찾아 바인딩합니다. 즉, 요청한 용량, 접근 모드, 볼륨 타입 등이 일치하는 퍼시스턴스 볼륨을 찾습니다.
3. 파드와 PVC 연결: 바인딩된 퍼시스턴스 볼륨을 파드에 연결합니다. 파드에 연결된 PVC는 해당 볼륨을 마운트하여 데이터를 읽고 쓸 수 있습니다.
4. PVC 삭제: PVC를 삭제하면 해당 PVC가 사용하는 퍼시스턴스 볼륨이 반납되고 다른 PVC에서 사용할 수 있습니다.

PVC는 스토리지에 대한 추상화를 제공하여 파드와 스토리지의 종속성을 줄이고, 스토리지의 재사용성과 유연성을 높여줍니다. 이를 통해 클러스터에서 스토리지 리소스를 보다 효율적으로 관리할 수 있습니다.

 

 

 

---

Stateful한 어플리케이션 수평 확장

- 여러 파드가 PVC를 통해 연결되는 볼륨은 하나이기 때문에 같은 스토리지를 연결하는 모양새가 됨

 

 

 

- 파드마다 별도의 데이터를 저장할 수 있게 만드려면 수평 확장되는 파드에 서로 다른 PV가 연결되어야 하며

파드가 PV를 동적으로 요청해서 그때그때 볼륨이 생성되게 하여야함

- 스토리지 클래스 (StorageClass) 리소스는 사용자가 요청할 때, 자동으로 PV를 프로비저닝 할 수 있게 도움

  (프로비저닝 : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것)

스토리지 클래스 참고 링크

https://kubernetes.io/ko/docs/concepts/storage/dynamic-provisioning/

 

 

 

---

스테이트풀셋

- 파드를 복제하더라도 스토리지 클래스를 이용해 파드가 필요로 하는 볼륨을 자동으로 프로비저닝하여 연결함

- 디플로이먼트와 스테이트풀셋 둘 다 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리

- 스테이트풀셋은 파드의 순서와 고유성을 보장함

  => 스테이트풀셋이 생성한 파드는 상호 대체할 수 없는 파드임

 

 

 

---

스테이트풀셋 사용 시 주의사항

- 파드에 지정된 스토리지는 관리자에 의해 퍼시스턴트 볼륨 프로비저너를 기반으로 하는 Storage class 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 함

퍼시스턴트 볼륨 프로비저너 참고링크

https://github.com/kubernetes/examples/blob/master/staging/persistent-volume-provisioning/README.md

 

- 헤드리스 서비스가 필요함

 

Q. 네트워크 트래픽에 따라 요청이 랜덤하게 분산되는 일반적인 서비스에 비해, 헤드리스 서비스는
특정 스테이트풀셋에게 트래픽을 보냅니다. 왜 그렇게 해야 하나요?

 

 

---

Q. 애플리케이션에 HTTP 500과 같은 에러가 발생한 경우, 컨테이너를 다시 실행해야 할 것 입니다. HTTP 에러가 발생했다는 것을 어떻게 알 수 있을까요? 어떻게 해야 쿠버네티스가 에러가 발생한 컨테이너를 자동으로 재시작하게 만들 수 있을까요? (힌트: liveness probe)

=>

Kubernetes에서 Liveness Probe는 컨테이너의 상태를 확인하고, 컨테이너가 정상적으로 실행 중인지 여부를 확인하는 기능이다

이 기능을 활용하면, HTTP 에러가 발생한 컨테이너를 자동으로 재시작하도록 구성할 수 있다

Liveness Probe를 구성하려면, 먼저 컨테이너에서 실행 중인 애플리케이션의 상태를 확인할 수 있는 endpoint를 정의해야 한다.

예를 들어, HTTP 서버를 실행하는 경우, "/health"와 같은 엔드포인트를 정의할 수 있습니다. 이 엔드포인트를 통해 컨테이너의 상태를 확인할 수 있다.

다음으로, Kubernetes Pod에서 Liveness Probe를 정의한다. Liveness Probe는 컨테이너의 상태를 확인할 때 사용하는 방법을 지정하는 구성 요소이다 

HTTP 엔드포인트를 사용하는 경우의 Liveness Probe 구성 예

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    livenessProbe:
      httpGet:
        path: /health
        port: 80

위의 예제에서는 "/health" 엔드포인트를 사용하여 Liveness Probe를 구성하고 있다.
이를 통해, Kubernetes는 "/health" 엔드포인트로 HTTP GET 요청을 보내고, 응답 코드를 확인한다.

응답 코드가 200-399 범위 내에 있으면 컨테이너가 정상적으로 실행 중으로 간주된다. 그러나 응답 코드가 이 범위를 벗어나면, Kubernetes는 컨테이너가 실패한 것으로 간주하고, 컨테이너를 재시작한다.

이와 같이 Liveness Probe를 구성하면, HTTP 에러가 발생한 컨테이너를 자동으로 재시작할 수 있다. 이를 통해 서비스의 가용성을 향상시킬 수 있다.