Volumes و PV و PVC

الهدف من الدرس

ستتعلم الفرق بين volume مؤقت و Persistent Volume، وكيف يطلب التطبيق مساحة تخزين باستخدام PVC، وكيف تشخص مشاكل binding و mount.

الفكرة ببساطة

Pod مؤقت، لذلك أي ملفات داخله تضيع عند حذف Pod. لو التطبيق يحتاج بيانات تبقى، مثل PostgreSQL، نستخدم PersistentVolumeClaim. PVC هو طلب تخزين، و StorageClass يحدد من يوفر هذا التخزين.

الصورة الكبيرة

flowchart LR
  P[Pod] --> PVC[PersistentVolumeClaim]
  PVC --> PV[PersistentVolume]
  PV --> SC[StorageClass]
  SC --> Disk[Disk أو CSI Provider]

متى أستخدم ماذا؟

النوع	مناسب لـ	يبقى بعد حذف Pod؟
`emptyDir`	cache مؤقت داخل Pod	لا
`configMap` volume	ملفات إعدادات	يعاد من ConfigMap
`secret` volume	ملفات سرية	يعاد من Secret
`PersistentVolumeClaim`	database أو uploads	نعم، حسب policy

YAML كامل: PVC و Pod يستخدمه

pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
  labels:
    app: storage-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

pod-with-pvc.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: storage-demo
  labels:
    app: storage-demo
spec:
  containers:
    - name: app
      image: busybox:1.37
      command: ["sh", "-c", "while true; do date >> /data/out.txt; sleep 5; done"]
      volumeMounts:
        - name: app-data
          mountPath: /data
      resources:
        requests:
          cpu: "20m"
          memory: "32Mi"
        limits:
          cpu: "100m"
          memory: "64Mi"
  volumes:
    - name: app-data
      persistentVolumeClaim:
        claimName: data-pvc

أوامر kubectl

kubectl apply -f pvc.yaml
kubectl apply -f pod-with-pvc.yaml
kubectl get pvc
kubectl get pod storage-demo
kubectl exec storage-demo -- tail -n 5 /data/out.txt

Expected output:

NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES
data-pvc   Bound    pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   1Gi        RWO

Access Modes

الوضع	المعنى العملي
`ReadWriteOnce`	volume يركب read/write على Node واحدة
`ReadOnlyMany`	أكثر من Node تقرأ فقط
`ReadWriteMany`	أكثر من Node تقرأ وتكتب، يحتاج storage provider يدعم ذلك
`ReadWriteOncePod`	volume يركب read/write على Pod واحد فقط

أخطاء شائعة

المشكلة	التشخيص	الحل
PVC يظل `Pending`	`kubectl describe pvc data-pvc`	لا توجد StorageClass أو provisioner
Pod يظل `ContainerCreating`	`kubectl describe pod storage-demo`	فشل mount أو volume غير جاهز
permission denied	logs داخل التطبيق	اضبط securityContext أو permissions
فقدت البيانات بعد delete	reclaimPolicy أو نوع volume مؤقت	استخدم PVC وتأكد من سياسة الحذف

Lab: PVC يحتفظ بالبيانات بعد إعادة إنشاء Pod

المستوى: مبتدئ الوقت: 45 دقيقة الأدوات: kubectl

الهدف: كتابة ملف داخل PVC، حذف Pod، إنشاء Pod جديد، والتأكد أن البيانات ما زالت موجودة.

Prerequisites

Cluster يدعم dynamic provisioning، مثل minikube أو kind مع StorageClass.
تحقق من:

kubectl get storageclass

Steps

طبق PVC و Pod:

kubectl apply -f pvc.yaml
kubectl apply -f pod-with-pvc.yaml
kubectl wait --for=condition=Ready pod/storage-demo --timeout=90s

اقرأ الملف:

kubectl exec storage-demo -- tail -n 3 /data/out.txt

احذف Pod فقط:

kubectl delete pod storage-demo
kubectl apply -f pod-with-pvc.yaml
kubectl wait --for=condition=Ready pod/storage-demo --timeout=90s

اقرأ الملف مرة أخرى:

kubectl exec storage-demo -- tail -n 5 /data/out.txt

Expected output

سترى تواريخ قديمة وحديثة في نفس الملف، وهذا يعني أن PVC احتفظ بالبيانات.

Fri May  8 10:00:05 UTC 2026
Fri May  8 10:00:10 UTC 2026
Fri May  8 10:01:20 UTC 2026

Cleanup

kubectl delete -f pod-with-pvc.yaml
kubectl delete -f pvc.yaml

الربط بالمشروع النهائي

Project 3 سيستخدم PostgreSQL مع PVC. الهدف ليس فقط تشغيل database، بل فهم ماذا يحدث للبيانات عندما يقع Pod أو ينتقل إلى Node أخرى.