Kubernetes NFS 기반 정적 프로비저닝 및 ResourceQuota 적용 실습 정리

✅ 핵심 개념 요약

📁 정적 프로비저닝(Static Provisioning)

• 관리자가 직접 PV를 생성해두고,
• 개발자가 PVC로 요청하는 방식.
• NFS 서버를 통한 외부 저장소 사용이 대표적인 예.
• Pod는 PVC를 통해 간접적으로 PV를 마운트함.

📦 NFS의 persistentVolumeReclaimPolicy

• Retain: PVC와 Pod가 삭제되어도 데이터는 남아있음.
• Recycle: 기존 데이터 삭제 후 재사용.
• Delete: PVC가 삭제되면 PV도 자동 삭제됨 (동적 프로비저닝에서 자주 사용).

💾 ResourceQuota + PVC 조합

• requests.storage: 전체 네임스페이스에서 요청 가능한 스토리지 총량.
• persistentvolumeclaims: PVC 개수 제한.

---

🧠 Quiz 정답 요약

1. Pod 삭제 후 재생성 시 index.html이 유지되는가?
   • 네! Retain 정책 덕분에 PV가 유지되어 기존 데이터도 유지됨.
2. 1Gi 제한이 있다고 했지만 실제로는 20Gi를 사용할 수 있는 이유?
   • NFS가 물리적으로 20Gi를 제공하고 있어서임.
   • PVC에서 요청한 용량은 예약용 정보일 뿐, 실제 제한 아님.
3. PVC 5개 생성 가능, 총 용량은 3Gi로 제한한 이유?
   • ResourceQuota를 통해 스토리지 남용 방지. 실제 생성은 PVC 3개까지만 성공.

---

💡 팁 & 참고사항

• **동적 프로비저닝(Dynamic Provisioning)**도 꼭 실습해보세요.
  • NFS CSI Driver 또는 AWS EBS, GCP PD 등 StorageClass 기반으로 자동 생성됩니다.
• LimitRange로 Pod 수준에서의 최소/최대 리소스 사용량도 제한할 수 있어요.
• kubectl describe quota로 현재 적용된 리소스 제한 상태를 확인할 수 있어요.

1. NFS 클라이언트 설치 (모든 노드)

각 노드는 실제 볼륨 관련 작업을 수행하므로 nfs-common 패키지를 설치해야 한다.

apt install -y nfs-common

2. NFS 서버 설정 (211.183.3.99)

systemctl disable firewalld --now
setenforce 0
dnf -y install nfs-utils

vi /etc/exports
# 내용 추가
/shared         211.183.3.0/24(rw,sync,no_root_squash)

chmod 777 /shared
systemctl enable nfs-server --now
showmount -e 211.183.3.99

3. PV (PersistentVolume) 생성

# mypv.yml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs1
  nfs:
    path: /shared
    server: 211.183.3.99

4. PVC (PersistentVolumeClaim) 생성

# mypvc.yml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  resources:
    requests:
      storage: 1Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: nfs1

5. Pod 생성 (볼륨 마운트 포함)

# mypod.yml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
  labels:
    app: web
spec:
  containers:
  - name: myctn
    image: nginx
    resources:
      limits:
        cpu: 500m
        memory: 128Mi
      requests:
        cpu: 250m
        memory: 64Mi
    ports:
    - containerPort: 80
      name: http
    volumeMounts:
    - name: myvol
      mountPath: /usr/share/nginx/html
  volumes:
    - name: myvol
      persistentVolumeClaim:
        claimName: mypvc

6. 확인 작업

k exec -it mypod -- ls /usr/share/nginx/html
k exec -it mypod -- touch /usr/share/nginx/html/index.html

NFS 서버에서 /shared/index.html 이 존재하는지 확인

7. Pod 삭제 후 재배포 (데이터 유지 확인)

k delete pod mypod
k apply -f mypod.yml
curl <mypod IP>

index.html 이 유지되는지 확인 → PV는 그대로이고, PVC 재사용이므로 데이터 보존됨

8. 실제 사용 가능한 디스크 용량은?

• PVC에는 1Gi 요청했지만 실제 NFS 공유 디렉토리는 20Gi이므로 20Gi까지 사용 가능

9. ResourceQuota 적용

• PVC 요청 수: 최대 5개
• 요청 가능 storage 총량: 3Gi

# myResourceQuota.yml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: myresourcequota
spec:
  hard:
    persistentvolumeclaims: "5"
    requests.storage: "3Gi"

10. 테스트 (mypvc1 ~ mypvc3)

• mypvc.yml 복사하여 name만 각각 mypvc1, mypvc2, mypvc3로 변경

k apply -f mypvc1.yml
k apply -f mypvc2.yml
k apply -f mypvc3.yml   # 이 시점에서 에러 발생 (3Gi 초과)

---

핵심 요약

• PV는 운영자, PVC와 Pod는 개발자가 작성
• 정적 프로비저닝에서는 개발자가 PVC로 요청 시 운영자가 만든 PV와 수동 바인딩
• Pod 삭제 후 재생성 시에도 PVC와 PV가 유지된다면 데이터는 유지됨
• 실제 스토리지 제약은 NFS 서버의 디스크 용량
• ResourceQuota를 활용해 네임스페이스 단위로 사용량 제한 가능