DIABOLIKSS
Rehberler›Kubernetes Persistent Storage Seçimi: Longhorn vs Rook-Ceph vs Portworx Karşılaştırması
Teknik Rehber · Kubernetes Storage

Kubernetes Persistent Storage: Longhorn vs Rook-Ceph vs Portworx

Kubernetes 1.25+ Seviye: İleri Haziran 2026 ~35 dk okuma

Kubernetes'te kalıcı depolama (persistent storage) seçimi, kümenizin kararlılığını ve veritabanı iş yüklerinizin performansını doğrudan etkiler. Bu rehber; CNCF tabanlı Longhorn, production-grade Rook-Ceph ve kurumsal Portworx çözümlerini teknik derinlikte karşılaştırır; kurulum YAML'larıyla, performans verileriyle ve senaryo bazlı önerilerle.

// İçindekiler
01

Kubernetes'te Kalıcı Depolama: Temel Kavramlar

Kubernetes'te pod'lar doğası gereği geçicidir; öldüğünde içindeki veri de gider. Kalıcı depolama için Kubernetes, PersistentVolume (PV) ve PersistentVolumeClaim (PVC) adlı iki temel nesne tanımlar. Uygulamalar PVC talep eder, cluster yöneticisi (ya da bir storage provisioner) eşleşen PV'yi otomatik olarak oluşturur.

Kubernetes Storage Katmanı
Pod / Uygulama volumeMounts tanımı
→
PVC PersistentVolumeClaim
→
StorageClass CSI Driver seçimi
→
CSI Driver Longhorn / Ceph / PX
PV PersistentVolume (fiziksel)
→
Disk / NVMe Node yerel disk

CSI: Container Storage Interface

CSI (Container Storage Interface), Kubernetes'in depolama sürücüleriyle konuştuğu standart arayüzdür. Kubernetes 1.13'ten itibaren GA olan bu arayüz sayesinde Longhorn, Ceph ve Portworx gibi çözümler aynı API'yi kullanarak PV oluşturabilir, snapshot alabilir ve volume'ları yeniden boyutlandırabilir. CSI'den önce her storage çözümü Kubernetes core'una yamalar göndermek zorundaydı.

Access Mode'lar

Mod Açıklaması Tipik Kullanım
RWO — ReadWriteOnce Tek node okuma+yazma Veritabanları (MySQL, PostgreSQL)
ROX — ReadOnlyMany Birden fazla node okuma Statik içerik, config dağıtımı
RWX — ReadWriteMany Birden fazla node okuma+yazma Paylaşımlı dosya sistemleri (NFS tabanlı)
ℹ️
RWX desteği kritik bir seçim kriteridir. Longhorn RWX'i NFS v4 üzerinden, Rook-Ceph ise CephFS üzerinden native olarak sağlar. Portworx ise "sharedv4" volume konseptiyle bu ihtiyacı karşılar. Eğer uygulamanız (örn. WordPress çok replikalı) aynı volume'a birden fazla pod'dan yazmak istiyorsa bu özelliği mutlaka sorgulayın.

VolumeSnapshot API

Kubernetes 1.17'de beta, 1.20'de GA olan VolumeSnapshot API, PVC'lerin point-in-time kopyalarının alınmasını standartlaştırır. Bu üç çözümün tamamı VolumeSnapshot API'yi destekler; ancak uygulama detayları farklıdır. Longhorn ve Ceph kendi snapshot mekanizmalarını CSI arayüzüne bağlarken, Portworx 3D snapshot adını verdiği uygulama tutarlı (application-consistent) snapshot özelliğini sunar.

02

Seçim Kriterleri: Hangi Sorular Sorulmalı?

Her üç çözüm de teknik olarak sağlam olsa da yanlış seçim; operasyonel karmaşıklık, beklentinin altında performans veya gereksiz lisans maliyeti doğurabilir. Aşağıdaki sorular seçiminizi netleştirecek çerçeveyi sunar.

🏗️
Küme Büyüklüğü
Kaç node, ne kadar disk?
3 node: Longhorn ideal. 10+ node: Ceph veya Portworx
📊
İş Yükü Tipi
Block mi, file mi, object mi?
DB: block. CMS: RWX file. Backup: object (S3)
👥
Operasyon Kapasitesi
Ceph uzmanı var mı?
Ceph öğrenim eğrisi diktir; Longhorn çok daha kolay
💶
Bütçe
Open-source mu, enterprise mi?
Longhorn/Ceph ücretsiz. Portworx lisans ücretli
🔄
DR Gereksinimi
Cross-cluster replikasyon lazım mı?
Synchronous DR: Portworx lider. Async: Longhorn de
📈
Compliance
KVKK, SOC2, HIPAA zorunlu mu?
Portworx enterprise güvenlik & audit log sunar
⚠️
Pilot test olmadan production'a geçmeyin. Her üç çözüm de kendi cluster kaynağını (CPU, memory, ağ bant genişliği) tüketir. Yük testini gerçek iş yükleriyle yapın; özellikle Ceph OSD'leri beklenmedik disk I/O ve ağ trafiği yaratabilir. Üretim geçişi öncesi en az 2 haftalık pilot süresi önerilir.
03

Longhorn: CNCF Tabanlı Dağıtık Block Storage

Longhorn, Rancher/SUSE tarafından geliştirilen ve CNCF Incubating statüsünde bulunan açık kaynak, dağıtık block storage çözümüdür. Her Kubernetes node'unda çalışan Longhorn Manager ve Longhorn Engine pod'larıyla oluşan mimari, basit kurulum ve görsel dashboard sayesinde küçük-orta ölçekli kümelerde popülerdir.

Mimari Özellikleri

🔧
Protokol
iSCSI tabanlı block storage
Sparse file kullanımı, thin provisioning
🔁
Replikasyon
Synchronous, node bazlı
Varsayılan: 3 replika; per-volume ayarlanabilir
🌐
RWX
NFS v4 Share Manager pod
Her RWX volume için ayrı share-manager pod
🖥️
Dashboard
Built-in Web UI
Volume yönetimi, snapshot, backup tek ekranda

Minimum Gereksinimler

  • ✓ En az 3 Kubernetes worker node
  • ✓ Her node'da open-iscsi kurulu ve aktif
  • ✓ jq, bash, findmnt araçları
  • ✓ Kubernetes 1.21+
  • ✓ Node'lar arasında 10 GbE ağ önerilir (minimum 1 GbE)
  • ✓ NFSv4 kernel desteği (RWX kullanacaksanız)

StorageClass Örneği

# longhorn-storageclass.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: longhorn annotations: storageclass.kubernetes.io/is-default-class: "true" provisioner: driver.longhorn.io allowVolumeExpansion: true reclaimPolicy: Delete volumeBindingMode: Immediate parameters: numberOfReplicas: "3" staleReplicaTimeout: "2880" # dakika (2 gün) fromBackup: "" fsType: "ext4" dataLocality: "disabled" # "best-effort" ile pod ile replika eş düşer diskSelector: "" # disk etiketiyle filtreleme nodeSelector: ""

PVC Örneği

# longhorn-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: postgres-data namespace: production spec: accessModes: - ReadWriteOnce storageClassName: longhorn resources: requests: storage: 50Gi

Backup ve DR

Longhorn, S3 uyumlu nesne depolama (AWS S3, MinIO, Backblaze B2) veya NFS hedeflerine periyodik backup gönderebilir. Cross-cluster replikasyon da desteklenir: kaynak volume snapshot'ı hedef cluster'daki S3'e aktarılır ve orada yeni bir volume olarak oluşturulur. Bu mekanizma tam synchronous DR değildir; RPO beklentinizi buna göre belirleyin.

ℹ️
Longhorn ne zaman doğru seçim? 3-20 node arası kümeler, DevOps ekibinin Ceph uzmanlığı olmadığı durumlar, hızlı kurulum gereksinimleri ve Rancher ile entegre çalışan ortamlar için güçlü bir tercih. Büyük veri setlerinde (100+ TB) Ceph'in gerisinde kalabilir.
04

Rook-Ceph: Production-Grade Ceph Operatörü

Rook, CNCF Graduated statüsünde bir Kubernetes operatörüdür; görevi Ceph'i Kubernetes içinde orkestre etmektir. Rook olmadan Ceph kurulumu elle yapılması gereken karmaşık bir süreçtir. Rook, bu süreci CRD (Custom Resource Definition) tabanlı YAML tanımlarına indirir. Ceph ise dünyanın en olgun açık kaynak dağıtık depolama sistemlerinden biridir; block (RBD), dosya (CephFS) ve nesne (RGW/S3) depolamayı tek cluster'dan sunar.

Ceph Bileşenleri

📡
MON — Monitor
Cluster haritasını yönetir
Min. 3 MON, her biri farklı node'da olmalı
📦
OSD — Object Storage Daemon
Veriyi fiziksel disklere yazar
Min. 3 OSD, tercihen NVMe SSD üzerinde
🗂️
MDS — Metadata Server
CephFS için metadata yönetimi
Yalnızca CephFS (RWX) kullanırken gerekli
🌍
RGW — RADOS Gateway
S3/Swift uyumlu nesne depolama
Uygulamaların S3 API ile kullanabileceği endpoint

StorageClass: Ceph RBD (Block)

# rook-ceph-block-storageclass.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rook-ceph-block provisioner: rook-ceph.rbd.csi.ceph.com parameters: clusterID: rook-ceph # namespace adı pool: replicapool imageFormat: "2" imageFeatures: layering csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner csi.storage.k8s.io/controller-expand-secret-namespace: rook-ceph csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph csi.storage.k8s.io/fstype: ext4 allowVolumeExpansion: true reclaimPolicy: Delete

StorageClass: CephFS (RWX)

# rook-cephfs-storageclass.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rook-cephfs provisioner: rook-ceph.cephfs.csi.ceph.com parameters: clusterID: rook-ceph fsName: myfs pool: myfs-replicated csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph reclaimPolicy: Delete allowVolumeExpansion: true
⚠️
Dedicated storage node'lar önerilir. Ceph OSD'leri, workload pod'larıyla aynı node'larda çalıştırıldığında disk I/O ve ağ bant genişliği için rekabete girerler. Production ortamlarda nodeSelector ve tolerations kullanarak OSD'leri ayrı node'lara atayın; bu node'lara başka pod schedule'ı engellemek için taint ekleyin.
05

Portworx: Kurumsal Düzey Enterprise Storage

Portworx (PX-Enterprise), Pure Storage bünyesinde geliştirilen, Kubernetes native kurumsal depolama platformudur. 2020'de Pure Storage tarafından satın alınan Portworx, özellikle büyük ölçekli production ortamlar, strict RPO/RTO gereksinimleri ve çok-cluster DR senaryoları için tasarlanmıştır.

Öne Çıkan Enterprise Özellikler

🤖
Autopilot
Otomatik PVC kapasitesi yönetimi
Kullanım oranına göre PVC'yi otomatik resize eder; insan müdahalesi gerekmez
🔁
Synchronous DR
İki cluster arası sıfır RPO replikasyon
Metro-DR ve Async-DR seçenekleri de mevcut
🛡️
PX-Security
RBAC, encryption, audit log
Volume düzeyinde şifreleme; cluster bazlı güvenlik politikaları
📸
3D Snapshots
Uygulama tutarlı snapshot
Kubernetes CRD + uygulama hook entegrasyonu

Lisanslama

Lisans Ücret Kısıtlamalar
PX-Essentials Ücretsiz Max 5 node, max 5 volume, Autopilot yok, DR yok
PX-Enterprise Node başı yıllık ücret (Pure Storage ile anlaşma) Tüm özellikler, destek dahil
PX-Backup Ayrı lisans Multi-cluster backup yönetim platformu

StorageClass Örneği

# portworx-storageclass.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: portworx-sc provisioner: kubernetes.io/portworx-volume parameters: repl: "3" # senkron replika sayısı io_priority: "high" # high / medium / low snap_interval: "70" # dakika aralıklarla otomatik snapshot aggregation_level: "1" ephemeral: "false" allowVolumeExpansion: true reclaimPolicy: Retain

Sharedv4 (RWX) StorageClass

# portworx-rwx-storageclass.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: portworx-shared provisioner: kubernetes.io/portworx-volume parameters: repl: "3" sharedv4: "true" # RWX aktif sharedv4_svc_type: "ClusterIP" # veya NodePort allowVolumeExpansion: true reclaimPolicy: Retain
06

Kurulum Karşılaştırması

Longhorn Kurulumu (Helm)

1
Ön koşulları her node'da kurun
# Ubuntu/Debian tabanlı node'larda apt-get install -y open-iscsi nfs-common jq # iSCSI servisini başlatın ve boot'ta otomatik başlamasını sağlayın systemctl enable --now iscsid
2
Helm ile Longhorn kurun
helm repo add longhorn https://charts.longhorn.io helm repo update helm install longhorn longhorn/longhorn \ --namespace longhorn-system \ --create-namespace \ --set defaultSettings.defaultReplicaCount=3 \ --set defaultSettings.backupTarget=s3://my-bucket@us-east-1/ \ --set defaultSettings.backupTargetCredentialSecret=s3-secret \ --version 1.7.2
3
Kurulumu doğrulayın
kubectl get pods -n longhorn-system # Tüm pod'lar Running olmalı # Longhorn UI: kubectl port-forward -n longhorn-system svc/longhorn-frontend 8080:80

Rook-Ceph Kurulumu (Helm)

1
Rook Operator'ı kurun
helm repo add rook-release https://charts.rook.io/release helm repo update helm install rook-ceph rook-release/rook-ceph \ --namespace rook-ceph \ --create-namespace \ --set csi.enableRbdDriver=true \ --set csi.enableCephfsDriver=true
2
CephCluster CRD oluşturun
# cluster.yaml (minimal production örneği) apiVersion: ceph.rook.io/v1 kind: CephCluster metadata: name: rook-ceph namespace: rook-ceph spec: dataDirHostPath: /var/lib/rook mon: count: 3 allowMultiplePerNode: false mgr: count: 2 storage: useAllNodes: false nodes: - name: storage-node-1 devices: - name: nvme0n1 - name: storage-node-2 devices: - name: nvme0n1 - name: storage-node-3 devices: - name: nvme0n1
3
Cluster sağlığını kontrol edin
# Rook toolbox pod'unu başlatın kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/deploy/examples/toolbox.yaml # Ceph sağlık durumunu görüntüleyin kubectl exec -n rook-ceph deploy/rook-ceph-tools -- ceph status # "health: HEALTH_OK" görmelisiniz

Portworx Kurulumu

Portworx kurulumu, PX-Central üzerinden spec generator kullanılarak yapılır. Generator, cluster boyutunuza ve kullandığınız Kubernetes dağıtımına (EKS, GKE, AKS, on-prem) göre özelleştirilmiş DaemonSet YAML'ı üretir. Temel adımlar:

# PX-Central spec URL'sini kendi ortamınıza göre oluşturun # https://central.portworx.com/specGen adresinden spec alın kubectl apply -f 'https://install.portworx.com/<version>?mc=false&kbver=1.28.0&b=true&c=px-cluster&stork=true&csi=true' # Kurulum durumunu izleyin kubectl get pods -n kube-system -l name=portworx -w # PX cluster durumu PX_POD=$(kubectl get pods -l name=portworx -n kube-system -o jsonpath='{.items[0].metadata.name}') kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl status
ℹ️
Kurulum karmaşıklığı sıralama: Longhorn < Portworx (iyi dokümantasyon) < Rook-Ceph. Rook-Ceph ile ilk production cluster'ı kurmak, Ceph kavramlarına hakim bir mühendis olmadan haftalar sürebilir. Longhorn ise çoğu ekibin birkaç saat içinde ayağa kaldırabileceği bir karmaşıklık seviyesindedir.
07

Performans ve Ölçeklenebilirlik

Ham disk performansı, depolama katmanından geçerken kayıplara uğrar. Her çözüm farklı miktarda overhead getirir ve bu overhead; replikasyon mekanizmasına, kullanılan protokole ve ağ gecikmesine göre değişir.

Metrik Longhorn Rook-Ceph (RBD) Portworx
Sıralı Okuma (3 replika, NVMe) ~1.5 GB/s ~2.5 GB/s ~2.2 GB/s
Sıralı Yazma (3 replika, NVMe) ~800 MB/s ~1.8 GB/s ~1.6 GB/s
Rastgele 4K IOPS (Okuma) ~40K IOPS ~100K IOPS ~90K IOPS
Gecikme (p99 yazma) ~3 ms ~1.5 ms ~1.2 ms
CPU Overhead (OSD/replica) Orta Yüksek (Ceph OSD yoğun) Orta-Düşük
Max ölçek (node) ~100 node pratik limit 1000+ node 1000+ node
⚠️
Bu rakamlar referans değerlere dayanmaktadır. Gerçek performans; ağ topolojinize, disk tipinize (HDD/SSD/NVMe), replikasyon sayısına ve Kubernetes cluster kaynaklarınıza göre önemli ölçüde farklılaşabilir. Mutlaka kendi ortamınızda fio veya sysbench ile benchmark alın.

Ölçeklenebilirlik Notları

Longhorn her volume için ayrı engine process çalıştırır; yüzlerce volume'da bu durum node başına yüksek process sayısına yol açabilir. Büyük kümeler için Longhorn v1.6+ ile gelen "V2 Volume" (SPDK tabanlı) özelliği bu sorunu ele alır ancak henüz production-ready değildir.

Rook-Ceph, petabayt ölçeğinde kanıtlanmış bir performans geçmişine sahiptir. OSD sayısını artırmak hem kapasiteyi hem IOPS'u genişletir; yatay ölçekleme açısından en esnek çözümdür.

Portworx, storage pool konseptiyle node'lardaki diskleri bir havuzda birleştirir ve IO'yu bu havuz üzerinde dengeler. Autopilot özelliği, kapasite yönetimi operasyon yükünü önemli ölçüde düşürür.

08

Yüksek Erişilebilirlik ve Disaster Recovery

Longhorn HA ve DR

Longhorn, her volume için yapılandırılan replika sayısı kadar veri kopyası tutar. Bir node düştüğünde Longhorn Engine kalan replikalara yazma/okuma yapmayı sürdürür. Düşen node geri geldiğinde ya da yeni bir node eklendiğinde, Longhorn otomatik olarak replika rebuildini başlatır.

Cross-cluster DR için Longhorn, kaynak cluster'dan bir S3 hedefine periyodik backup gönderir. Hedef cluster bu S3'ten restore yaparak volume'u oluşturur. Bu yapı asenkron DR'dır; RPO, backup sıklığına bağlıdır (minimum ~5 dakika).

Rook-Ceph HA ve DR

Ceph'in CRUSH map algoritması, veri parçalarını (PG — Placement Group) fiziksel olarak farklı node veya rack'lere dağıtır. 3 OSD ile 1 OSD kaybında veri bütünlüğü korunur; failure domain "host" olarak ayarlandığında 3 farklı sunucu kaybına kadar dayanıklılık sağlanabilir. Ceph, kendi içinde self-healing mekanizmasına sahiptir: bozulan PG'ler otomatik olarak yeniden dengelenir.

Cross-cluster DR için RBD Mirroring (async) veya CephFS mirroring kullanılabilir. Stretch cluster modu ile iki datacenter arasında aktif-aktif Ceph cluster kurulumu mümkündür; ancak bu kurulum oldukça karmaşıktır.

Portworx HA ve DR

Portworx, yazma işlemlerini node'lar arasında synchronous olarak replike eder. 3 replika ile 2 node kaybında bile cluster veriyi sağlıklı tutar. Synchronous DR özelliği ise iki farklı Kubernetes cluster'ı arasında gerçek zamanlı veri kopyalaması sağlar; RPO hedefi sıfıra yakındır.

HA / DR Özelliği Longhorn Rook-Ceph Portworx
Node kaybında otomatik iyileşme ✓ Evet ✓ Evet (CRUSH) ✓ Evet
Cross-cluster DR ~ Async (S3) ~ RBD Mirror (async) ✓ Sync veya Async
RPO hedefi Dakika (backup aralığı) Saniyeler (mirror) Sıfıra yakın (sync)
Rack-aware dağıtım ~ Sınırlı ✓ CRUSH failure domain ✓ Topology-aware
Otomatik failover ✓ ✓ ✓ + Stork scheduler
💡
Portworx Stork (Storage Orchestrator Runtime for Kubernetes), uygulama pod'larını veri lokasyonuna göre schedule eden özel bir Kubernetes scheduler'dır. Pod'un her zaman verisine en yakın node'da çalışmasını sağlayarak storage I/O gecikmesini minimize eder; özellikle stateful uygulamalarda belirgin fark yaratır.
09

Maliyet Analizi

Yazılım lisans maliyeti sıfır olsa bile bir depolama çözümünün toplam sahip olma maliyeti (TCO) farklıdır. Operasyon, eğitim, donanım boyutlandırma ve olası destek sözleşmeleri hesaba katılmalıdır.

Maliyet Kalemi Longhorn Rook-Ceph Portworx Enterprise
Yazılım Lisansı Ücretsiz (Apache 2.0) Ücretsiz (Apache 2.0) Node başı yıllık ücret
Kurulum ve Yapılandırma Düşük (1-2 gün) Yüksek (1-4 hafta) Orta (3-5 gün, iyi dokümantasyon)
Operasyon / Yönetim Düşük (UI var) Yüksek (Ceph uzmanlığı) Düşük-Orta (Autopilot ile otomasyon)
Donanım Overhead Orta (volume başı engine process) Yüksek (OSD per disk + MON + MDS) Orta (storage pool)
Destek Topluluk / SUSE ücretli Topluluk / Red Hat ücretli Dahil (enterprise SLA)
Eğitim Maliyeti Düşük Yüksek (Ceph admin sertifikası) Orta

Büyük bir ekipte Ceph yönetimi için tam zamanlı bir SRE'nin maliyeti, Portworx lisans ücretini geçebilir. Tersine, küçük bir startup için Portworx lisans maliyeti bütçe kısıtı oluşturabilir. TCO hesabı yaparken insan zamanını da dahil edin.

10

Senaryo Bazlı Öneri Matrisi

Aşağıdaki matris, yaygın Kubernetes ortamları için hangi çözümün öne çıktığını özetler. Her senaryo tek bir "doğru" cevaba sahip değildir; ikincil seçenek de parantez içinde belirtilmiştir.

Senaryo Önerilen Alternatif Neden?
3-10 node küçük küme, az kaynak Longhorn Rook-Ceph (küçük) Düşük overhead, basit kurulum ve UI
20+ node, veritabanı ağırlıklı iş yükü Rook-Ceph (RBD) Portworx RBD IOPS avantajı, ücretsiz lisans
RWX gerektiren çok replikalı uygulama Rook-Ceph (CephFS) Longhorn (NFS) Native CephFS RWX daha stabil
Synchronous cross-cluster DR zorunlu Portworx Enterprise — Tek çözüm synchronous DR sunar
Rancher / RKE2 tabanlı küme Longhorn Rook-Ceph SUSE/Rancher native entegrasyon
Petabayt ölçekli on-premises depolama Rook-Ceph Portworx Ceph 1000+ node ölçeğinde kanıtlanmış
Maliyet bütçesi kısıtlı startup Longhorn Rook-Ceph Sıfır lisans, kolay operasyon
Enterprise destek + Autopilot gereksinimi Portworx Enterprise — Tek platform Autopilot ve SLA sunar
Hem block hem object (S3) aynı cluster'dan Rook-Ceph (RBD + RGW) — Ceph native S3 gateway (RGW) mevcuttur
Longhorn Seçin
  • ✓ 3-20 node küme
  • ✓ Hızlı kurulum öncelikli
  • ✓ Ceph uzmanlığı yoksa
  • ✓ Rancher ekosistemi
  • ✓ Görsel yönetim şart
  • ✓ Dev/staging ortamları
Rook-Ceph Seçin
  • ✓ 10+ node ve büyük ölçek
  • ✓ Yüksek IOPS veritabanı
  • ✓ Block + File + Object aynı cluster
  • ✓ Petabayt hedefi
  • ✓ Ceph admin uzmanlığı var
  • ✓ Ücretsiz enterprise ihtiyaç
Portworx Seçin
  • ✓ Synchronous DR zorunlu
  • ✓ Autopilot kapasitesi
  • ✓ Enterprise SLA gerekli
  • ✓ Compliance odaklı (SOC2)
  • ✓ Multi-cloud portabilite
  • ✓ Operasyon ekibi küçük
💡
Birden fazla StorageClass kullanabilirsiniz. Aynı Kubernetes cluster'ında farklı iş yükleri için farklı storage çözümleri tercih etmek mümkündür; örneğin veritabanları için Ceph RBD StorageClass, paylaşımlı dosya sistemi ihtiyaçları için CephFS StorageClass ve geliştirme ortamı pod'ları için Longhorn kullanılabilir. Bir arada çalışmalarında teknik engel yoktur; ancak operasyon karmaşıklığı artar.
11

Kaynaklar ve Referanslar

Aşağıdaki resmi kaynaklar, bu rehberde anlatılan teknik detayların doğrulanmasında kullanılmıştır ve derinlemesine inceleme için referans alınabilir.

kubernetes storage longhorn ceph portworx csi devops altyapi
↑ Başa Dön
diabolikss.com — Kubernetes & Cloud Altyapı Rehberleri
Haziran 2026 · İleri Seviye · 35 dk okuma