[CKAD] 볼륨 문제는 무조건 나오는 듯! 최종 정리

Kubernetes 볼륨 개념과 타입 정리

Kubernetes에서 볼륨(Volume)은 컨테이너에서 사용할 수 있는 파일 시스템을 제공합니다.

볼륨은 컨테이너의 라이프사이클과 독립적이거나 컨테이너와 함께 생성 및 삭제될 수 있습니다. 이는 컨테이너가 재시작되거나 종료될 때도 데이터의 지속성을 관리하기 위한 중요한 역할을 합니다.

즉, 볼륨은 Pod에 생성되어 컨테이너들이 마운트하여 데이터를 공유하거나 유지할 수 있습니다. 컨테이너가 재시작되거나 종료되더라도 데이터를 잃지 않도록 하는 데 유용합니다.

 

그렇다면 컨테이너가 언제 재시작되는가?

 

1) CrashLoopBackOff 상태 (애플리케이션 충돌)

• 컨테이너에서 실행 중인 애플리케이션이 오류로 종료되었을 때.
• 예: 애플리케이션 코드 오류, 의존성 문제, 환경 변수 누락 등.
• Kubernetes는 restartPolicy에 따라 컨테이너를 재시작합니다.

2) restartPolicy 설정에 따른 재시작

• Pod의 restartPolicy에 따라 컨테이너의 재시작 동작이 결정됩니다:
  • Always (기본값): 컨테이너가 종료되면 항상 재시작.
  • OnFailure: 실패(exit code ≠ 0) 시에만 재시작.
  • Never: 재시작하지 않음.
• 예: 기본 설정인 Always는 컨테이너가 정상적으로 종료(exit code = 0)되더라도 재시작합니다.

3) 리소스 부족

• 노드의 리소스(CPU, 메모리 등)가 부족하면 컨테이너가 강제로 종료될 수 있습니다.
  • 예: 메모리 초과 사용 시 Out of Memory (OOM) 이벤트로 종료.
  • Kubernetes가 Pod을 우선 순위에 따라 재시작하거나 축출(Eviction)할 수 있습니다.

4) Readiness/Liveness Probe 실패

• Liveness Probe:
  • 컨테이너가 비정상적이거나 응답하지 않는 경우, Kubernetes가 컨테이너를 재시작.
• Readiness Probe:
  • 컨테이너가 서비스 요청을 처리할 준비가 안 된 경우, 트래픽 라우팅에서 제외.
  • Liveness Probe와 달리, Readiness Probe는 컨테이너를 재시작하지는 않음.

 

자 그러면 이제부터 볼륨에 대해서 개념을 정리해봅시다. 

볼륨(Volume) 개념 : 한마디로 저장 공간! 

컨테이너의 파일 시스템 문제

• 컨테이너 내부의 파일 시스템은 일시적으로, 컨테이너가 재시작되거나 삭제되면 데이터도 사라집니다.
• 데이터를 저장하거나 다른 컨테이너와 공유하려면 볼륨이 필요합니다.

볼륨의 특징 

1. Pod의 생존 기간 동안 존재.
2. Pod 내의 여러 컨테이너 간 데이터 공유 가능.
3. 다양한 스토리지 백엔드를 지원 (예: 로컬 디스크, NFS, 클라우드 스토리지).

---

볼륨 타입

Kubernetes 볼륨은 Ephemeral Volume과 Persistent Volume으로 나뉩니다.

(1) Ephemeral Volume

• Pod의 라이프사이클과 동일한 볼륨.
• Pod가 삭제되면 볼륨과 데이터도 함께 삭제됩니다.
• 주로 임시 데이터를 저장하거나, 작업 완료 후 데이터가 필요하지 않을 때 사용.

주요 Ephemeral Volume 타입

1. emptyDir : 비어있는 디렉토리 
   • Pod가 실행될 때 생성되고, Pod가 삭제되면 데이터도 삭제.
   • 컨테이너 간 임시 데이터 공유에 적합.
   • emptyDir: {} 볼륨의 기본 설정을 사용하겠다는 의미

volumes:
- name: temp-storage
  emptyDir: {}

2. configMap / secret

• ConfigMap이나 Secret 데이터를 컨테이너에 마운트.
• 애플리케이션 설정 파일이나 민감한 데이터를 제공.

volumes:
- name: config-vol
  configMap:
    name: my-config

3. downwardAPI

• Pod 메타데이터(이름, 네임스페이스, 레이블 등)를 파일 형태로 컨테이너에 전달.

4. ephemeral

• CSI 드라이버 기반으로 동적으로 생성되는 임시 볼륨.

---

(2) Persistent Volume

• Pod의 라이프사이클과 독립적으로 존재하는 볼륨.
• 데이터를 지속적으로 저장하거나 여러 Pod 간에 공유하려면 Persistent Volume을 사용.
• 두 가지 개념이 포함됨:
  1. PersistentVolume (PV): 클러스터에서 제공하는 실제 스토리지 리소스.
  2. PersistentVolumeClaim (PVC): Pod가 필요한 스토리지를 요청하는 객체.

주요 Persistent Volume 타입

1. 클라우드 스토리지
   • AWS EBS, Google Persistent Disk, Azure Disk 등.
   • 클라우드 환경에서 쉽게 스토리지를 연결하고 관리.
2. 네트워크 스토리지
   • NFS, GlusterFS 등.
   • 여러 노드에서 공유 가능한 스토리지.
3. 로컬 스토리지
   • 특정 노드에 연결된 디스크.
   • 데이터 로컬화가 필요한 워크로드에 적합.
4. Dynamic Provisioning
   • PVC 요청에 따라 스토리지가 자동으로 생성.
   • 관리가 간소화됨.

Persistent Volume의 구성 예제

1. Persistent Volume 정의:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: /data

2. Persistent Volume Claim 정의:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

3. Pod에 마운트:

volumes:
- name: data-volume
  persistentVolumeClaim:
    claimName: my-pvc

---

3. Ephemeral Volume vs Persistent Volume 비교

특성	Ephemeral Volume	Persistent Volume
데이터 지속성	Pod 삭제 시 데이터도 삭제	Pod 삭제 후에도 데이터 유지
주요 사용 사례	임시 데이터, 캐시, 설정	데이터베이스, 파일 저장, 영구 데이터
스토리지 관리 방식	Pod 정의에서 직접 관리	클러스터 관리자가 PV로 제공
공유 가능 여부	일반적으로 Pod 내에서만 공유 가능	여러 Pod 또는 워크로드 간 공유 가능

 

 

4. 요약

1. 볼륨(Volume)은 컨테이너에서 데이터를 저장하거나 공유할 때 사용.
2. Ephemeral Volume:
   • Pod의 라이프사이클에 종속.
   • 임시 데이터 저장용.
3. Persistent Volume:
   • Pod와 독립적으로 데이터 지속성 제공.
   • 데이터베이스, 영구 스토리지 등에 사용.