본문 바로가기
문서 목차
ORKESTRIX설치

Local Path 프로비저너

파드가 스케줄된 노드의 로컬 디스크를 그대로 사용하는 경량 스토리지 프로비저너입니다. 별도의 스토리지 클러스터나 raw 디스크 준비 없이 바로 사용할 수 있습니다.

QUANTUM C&S

파드가 스케줄된 노드의 로컬 디스크를 그대로 사용하는 경량 스토리지 프로비저너입니다. 별도의 스토리지 클러스터나 raw 디스크 준비 없이 바로 사용할 수 있습니다.

Ceph처럼 여러 노드에 분산 · 복제되는 스토리지가 아니라, 파드가 뜬 그 노드의 디스크에 평범한 폴더로 데이터를 저장합니다. 파드가 다른 노드로 이동하면 데이터를 가져가지 못하므로, 캐시 · 임시 데이터 · 개발/테스트용 등 노드 이동이 필요 없는 가벼운 워크로드에 적합합니다.
iaas.yaml/k8s.yaml 등 어떤 번들 플레이북에도 포함되어 있지 않습니다 — 아래 플레이북을 직접 실행해야만 설치됩니다. Ceph/CSI와는 완전히 독립적이라 순서 상관없이 언제든 설치해도 됩니다.

사전 준비 — 설정 변수 확인

플레이북 실행 전에 inventory/qks/group_vars/all/all-k8s.yaml의 값을 확인합니다. 기본값 그대로도 동작하지만, 바꿔야 하는 상황이면 미리 여기서 조정합니다.

변수 기본값 설명
qks_local_provisioner_namespace qks-system 프로비저너 Pod가 뜨는 네임스페이스
qks_local_provisioner_path /data/pv 각 노드의 로컬 디스크에서 실제 데이터를 저장할 경로
qks_local_provisioner_replicas 2 프로비저너 컨트롤러 Pod 복제 수
qks_local_provisioner_storageclass_name qks-local 생성되는 StorageClass 이름
qks_local_provisioner_storageclass_reclaimpolicy Delete PVC 삭제 시 실제 데이터도 같이 지울지(Delete) 남길지(Retain)
qks_local_provisioner_version 0.0.37 설치할 차트 버전 — CSI처럼 자동 계산되지 않는 고정값

StorageClass 이름을 바꾸는 경우 kube_default_storage_class_name도 같이 맞춰야 기본 StorageClass로 지정됩니다(Ceph를 함께 쓰는 이 환경에서는 기본값이 qks-ceph-block으로 유지되고, qks-local은 선택 가능한 추가 옵션으로만 생성됩니다).

플레이북 실행

./install.sh ubuntu plays/qks-local-provisioner.yaml

설치 흐름

1. 차트 위치 결정   공식 OCI 차트(oci://ghcr.io/rancher/local-path-provisioner/charts/...) 참조
2. Helm 차트 배포   local-path-provisioner 차트 설치
3. K8s 리소스 생성  StorageClass(qks-local) 생성
4. 기본 StorageClass 지정 여부 결정

설치 내용

  • StorageClass qks-local (VOLUMEBINDINGMODE: WaitForFirstConsumer)
  • qks-system 네임스페이스에 qks-local-provisioner Deployment(2개 복제)
VOLUMEBINDINGMODE가 Ceph(Immediate)와 달리 WaitForFirstConsumer입니다 — 로컬 디스크 특성상 "어느 노드의 디스크를 쓸지"가 파드 스케줄링 결과에 따라 정해지기 때문에, 파드가 실제로 배치되기 전까지 PVC는 Pending 상태로 대기합니다. PVC만 먼저 적용하면 잠깐 Pending으로 보일 수 있으니, Pod까지 같이 적용해야 정상적으로 Bound로 넘어갑니다.

설치 확인

드라이버 Pod 상태와 StorageClass 등록 여부를 먼저 확인합니다.

kubectl get pods -n qks-system | grep local-provisioner
kubectl get storageclass qks-local

실제 PVC 생성 + 파드 마운트 테스트

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-local-pvc
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: qks-local
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: test-local-pod
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sh", "-c", "echo hello-local > /mnt/test.txt && sleep 3600"]
    volumeMounts:
    - {name: data, mountPath: /mnt}
  volumes:
  - name: data
    persistentVolumeClaim: {claimName: test-local-pvc}
kubectl get pvc test-local-pvc      # STATUS: Bound 이어야 함
kubectl get pod test-local-pod      # READY: 1/1, STATUS: Running 이어야 함
kubectl exec test-local-pod -- cat /mnt/test.txt   # hello-local 출력되어야 함

확인 후 정리:

kubectl delete pod test-local-pod
kubectl delete pvc test-local-pvc

PVC가 Bound되고 Pod가 파일을 정상 읽고 쓰면, 프로비저너가 해당 노드의 로컬 디스크에 실제 볼륨 디렉터리를 만들고 Pod에 마운트한 것입니다.

다음 단계