Pod ephemeral است؛ دیسک داخل container با مرگ Pod می‌میرد. برای داده پایدار، کوبرنتیز مدل PersistentVolume را دارد و امروز تقریباً همهٔ provisioning پویا از مسیر CSI (Container Storage Interface) می‌گذرد.

طبق مستندات Volumes، انواع volume زیادند؛ اما برای production مدرن، تمرکز روی CSI + StorageClass است — نه hostPath یا درایورهای in-tree منسوخ.

این مقاله deep dive همهٔ گزینه‌های مهم CSI، تفاوت‌ها و use caseهاست — با لینک به Longhorn و CubeFS.

CSI چیست؟

CSI قرارداد استاندارد بین Kubernetes و سیستم‌های storage است (مشابه نقش CNI برای شبکه — مقاله CNI).

اجزای رایج یک درایور CSI:

CSI Controller (provision / snapshot / expand)
CSI Node plugin (mount / stage روی نود)
External-provisioner / attacher / resizer / snapshotter (sidecars)

بدون CSI سازگار، StorageClass پویا و قابلیت‌هایی مثل VolumeSnapshot کار نمی‌کنند (یا ناقص‌اند).

مدل ذهنی: PVC · PV · StorageClass

Developer:
  PersistentVolumeClaim (درخواست: ۱۰Gi، RWO، کلاس X)
        │
        ▼  dynamic provisioning
StorageClass → CSI Driver → PersistentVolume
        │
        ▼
Pod.spec.volumes.persistentVolumeClaim

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com          # یا driver.longhorn.io و ...
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Delete
parameters:
  type: gp3

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-data
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 20Gi

Access Modes و نوع داده — قبل از انتخاب برند

قانون طلایی: PostgreSQL/MySQL روی EFS/NFS معمولاً اشتباه است؛ برای اشتراک چندwriter به RWX واقعی نیاز دارید نه «چند Pod روی یک RWO».

قابلیت‌های CSI که همه ندارند

جدول مقایسه کلان

Deep Dive هر خانواده

۱. CSIهای ابری (مدیریت‌شده)

AWS EBS / GCE Persistent Disk / Azure Disk

• Block با IOPS قابل تنظیم (مثلاً gp3)
• تقریباً همیشه RWO و مقید به zone
• volumeBindingMode: WaitForFirstConsumer الزامی در عمل

AWS EFS / Azure Files / Filestore

• RWX برای چند Pod روی چند نود
• عالی برای محتوا اشتراکی؛ ضعیف برای OLTP DB

Use case: cluster روی همان cloud — اول درایور رسمی provider، مگر نیاز replication بین‌نودی خارج از مدل ابری داشته باشید.

۲. Longhorn — block ساده برای Kubernetes

• CNCF Graduated
• volume به‌صورت replica روی دیسک نودها
• UI داخلی، backup به S3/NFS
• نصب نسبتاً آسان (اغلب Helm)
• مناسب ۳–۲۰ نود؛ تیم K8s بدون تخصص Ceph

جزئیات: مقاله Longhorn.

Use case: bare metal / K3s / on-prem که EBS ندارید و می‌خواهید PVC replicated.

۳. Rook + Ceph — پلتفرم storage

• Rook = Operator؛ Ceph = موتور
• RBD (block)، CephFS (RWX)، RGW (S3)
• مقیاس petabyte-class؛ ops سنگین (OSD، CRUSH، mon، …)
• CNCF / اکوسیستم بسیار بالغ

Use case: یک مجموعه دیسک برای block + file + object؛ تیم storage دارید؛ خوشه بزرگ پایدار.

۴. OpenEBS — چند موتور

Use case: Mayastor وقتی IOPS/latency سخت است؛ LocalPV برای Redis/Kafka که خودشان replicate می‌کنند یا داده دورریختنی.

۵. Portworx

• تجاری، پشتیبانی enterprise، ابزار مهاجرت چندابری
• وقتی قرارداد پشتیبانی/compliance ارزش license دارد

۶. CubeFS

• فایل و شیء cloud-native در مقیاس
• وقتی الگوی دسترسی فراتر از یک PVC ساده block است

مقاله: CubeFS.

۷. NFS CSI (csi-driver-nfs و مشابه)

• به یک NFS server موجود وصل می‌شود
• RWX آسان اگر NAS دارید
• SPOF = خود NFS مگر NAS HA باشد

Use case: سازمان با NetApp/TrueNAS؛ بدون ساخت Ceph.

۸. local-path / Hostpath CSI

• پیش‌فرض ساده K3s (local-path)
• داده روی همان نود؛ با رفتن Pod به نود دیگر داده «نمی‌آید» مگر sticky / replica اپ

Use case: lab، CI، توسعه؛ نه HA production بدون آگاهی.

۹. Gluster و میراث

• زمانی محبوب برای RWX
• امروز معمولاً CephFS / NFS / EFS جایگزین greenfield می‌شوند

VolumeSnapshot و DR

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: db-snap
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: db-data

پیش‌نیازها:

1. snapshot-controller در cluster
2. CSI driver با capability snapshot
3. VolumeSnapshotClass

Backup کامل اپ اغلب Velero (+ snapshot یا restic/kopia) است — فقط snapshot دیسک کافی نیست (ترتیب، چند PVC، DB consistency).

Topology، Expansion، Binding

درخت تصمیم

روی AWS/GCP/Azure؟
  ├─ فقط یک Pod/نود writer (DB)؟ → Disk/EBS/PD CSI
  └─ چند نود اشتراک فایل؟ → EFS / Azure Files / Filestore

Bare metal / VPS / K3s؟
  ├─ فقط lab؟ → local-path
  ├─ PVC replicated ساده + UI؟ → Longhorn
  ├─ latency شدید NVMe؟ → OpenEBS Mayastor
  ├─ Block + CephFS + S3 یکجا؟ → Rook-Ceph
  ├─ NAS از قبل دارید؟ → NFS CSI
  └─ object/file مقیاس ابری؟ → CubeFS / Ceph RGW

اپ خودش replicate می‌کند (Cassandra، Raft، …)؟
  → LocalPV اغلب درست‌تر از double-replication است

CSI در برابر «دیسک داخل Pod» و emptyDir

ارتباط با بقیه stack

App Pod
  └── PVC
        └── StorageClass → CSI Driver
              ├── Cloud disk/file
              ├── Longhorn / Ceph / Mayastor
              └── NFS / local-path

Backup: VolumeSnapshot + Velero
Registry لایه‌های ایمیج: Harbor (جدا از PVC اپ)
شبکه نود: CNI جداست

روی K3s می‌توانید local-path را با Longhorn عوض/مکمل کنید — مقاله K3s.

اشتباهات رایج

Best practices

1. برای هر کلاس کاری یک StorageClass واضح (db-ssd, shared-nfs, scratch-local)
2. در cloud همیشه WaitForFirstConsumer برای block zone-attached
3. Retain برای داده‌های غیرقابل‌جایگزین تا pipeline backup ثابت شود
4. قابلیت snapshot/expand را در POC تست کنید نه در حادثه
5. منابع نود (دیسک، CPU، شبکه) را برای Longhorn/Ceph جدا مانیتور کنید
6. mon/OSD Ceph را روی همان نودهای اپ شلوغ بدون طراحی نگذارید
7. در GitOps، StorageClass را versioned نگه دارید؛ Secretهای CSI را امن
8. قبل از حذف PVC در prod، snapshot یا backup بگیرید
9. برای RWX فقط وقتی واقعاً چندwriter لازم است هزینه بپردازید
10. ماتریس «درایور × قابلیت» داخلی تیم را document کنید

جمع‌بندی

مثل CNI، همه درایورهای جدی «دیسک به Pod می‌چسبانند». تفاوت در access mode، replication، عملیات، snapshot و هزینه تیمی است. کوتاه‌ترین راهنما: cloud → CSI رسمی provider؛ on-prem ساده → Longhorn؛ پلتفرم چندپروتکل → Ceph؛ latency شدید → Mayastor؛ اشتراک فایل آماده → NFS/EFS.

قدم بعدی

1. kubectl get sc,pvc,pv و provisionerها را ببینید
2. یک PVC RWO با درایور فعلی بسازید و expand/snapshot را امتحان کنید
3. اگر K3s/local-path دارید، POC Longhorn روی سه نود
4. نیاز RWX را صریح بنویسید — قبل از انتخاب CephFS/NFS/EFS
5. مقاله CNI را کنار این یکی بگذارید: شبکه و storage دو ستون جدا ولی هم‌طراحی

منابع

• Volumes — Kubernetes
• Persistent Volumes
• Storage Classes
• Volume Snapshots
• CSI documentation
• Longhorn (مقاله P30Light)
• CubeFS (مقاله P30Light)
• CNI comparison (مقاله P30Light)
• K3s (مقاله P30Light)

منتشر شده در P30Light — بخش زیرساخت و سرور.