문서 목차
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-provisionerDeployment(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에 마운트한 것입니다.