PV, PVC ve Veri Gerçekten Nerede Saklanıyor?
Bu yazıda şu konuları inceleyeceğim:
- PV (Persistent Volume) nedir?
- PVC (Persistent Volume Claim) nedir?
- StorageClass ne işe yarar?
- Static ve Dynamic provisioning farkı nedir?
- Disk gerçekte nerede? (Local PV, NFS, Cloud Storage)
- Object storage (S3) nedir? MinIO ne işe yarar?
- Distributed storage örnekleri: Ceph ve Longhorn
- MariaDB / PostgreSQL gibi uygulamalarda disk nerede?
Storage Akışının Mantığı
Öncelikle Kubernetes'te storage zinciri şu şekildedir:
Pod -> PVC -> StorageClass -> PV -> Physical Storage
Persistent Volume (PV)
PV, cluster içindeki gerçek disk kaynağını temsil eder.
Bu kaynak şunlardan birisidir:
- Node üzerindeki local disk
- NFS share
- Cloud block storage (AWS EBS, GCE PD, Azure Disk)
- Distributed storage
Yani aslında PV, storage'ın kendisidir.
Persistent Volume Claim (PVC)
PVC ise uygulamanın disk talebidir.
Örneğin:
- 10Gi storage
- Access mode: ReadWriteOnce
- storageClass: fast-storage
PVC diski oluşturmaz, bir disk talep eder.
StorageClass Nedir?
StorageClass, PVC oluşturulduğunda disk'in nasıl sağlanacağını belirler.
Yani, disk local mi olacak? NFS mi olacak? Cloud block storage mı olacak? Otomatik mi üretilecek? Hangi performans sınıfı kullanılacak? Gibi sorulara cevap veren bir policy katmanıdır.
Static ve Dynamic Provisioning
Static Provisioning
Static provisioning modelinde PV manuel olarak oluşturulur. Yani önce storage kaynağı tanımlanır, ardından PVC bu PV'ye bağlanır.
Bu yöntem daha fazla kontrol sağlar ancak her yeni disk ihtiyacında manuel işlem gerektirir. Genellikle test ortamlarında veya local/NFS kurulumlarında tercih edilir.
Dynamic Provisioning
Dynamic provisioning modelinde ise sadece PVC oluşturulur.
Bağlı olduğu StorageClass, arka planda otomatik olarak uygun bir PV üretir ve PVC'ye bağlar.
Bu süreç CSI (Container Storage Interface) driver'ları sayesinde çalışır.
Production ortamlarında genellikle dynamic provisioning tercih edilir çünkü daha otomatik ve ölçeklenebilirdir.
Disk Gerçekte Nerede?
Bu sorunun cevabı PV tanımındadır.
Local PV
PV şu path'i gösteriyorsa: /mnt/k8s/data, disk node üzerindedir. Node arızalanırsa veri kaybedilebilir. Pod başka node'a taşınırsa diske erişilemez.
NFS
PV şu şekilde tanımlanmışsa:
nfs:
server: 192.168.1.10
path: /srv/nfs/share
Disk NFS server üzerindedir. Pod hangi node'da olursa olsun aynı veriye erişebilir.
Cloud Storage
PV bir cloud volume'a bağlıysa, disk cloud provider tarafındadır.
Object Storage (S3) ve MinIO
Şimdiye kadar bahsettiğim storage türleri çoğunlukla disk mantığında (block/file) çalışıyordu. Ancak pratikte sıkça kullanılan bir model daha var: Object storage. S3/MinIO genellikle database'in primary storage'ı olarak kullanılmaz; daha çok backup, log ve dosya arşivi gibi senaryolarda tercih edilir.
S3 (Simple Storage Service) Nedir?
S3 bir object storage yaklaşımıdır. Dosyalar filesystem gibi "klasör/dosya" mantığından ziyade "object" olarak saklanır. Genellikle şu senaryolarda kullanılır:
- Dosya yükleme (upload)
- Log arşivleme
- Backup (özellikle database backup)
- Media saklama (image/video)
S3 çoğunlukla PV/PVC gibi mount edilerek kullanılmaz. Uygulama S3 API üzerinden erişir.
MinIO Nedir?
MinIO, S3 uyumlu bir object storage çözümüdür. Özellikle cloud'dan bağımsız (on-premise) ortamlarda veya Kubernetes içinde S3 benzeri bir servis ihtiyacında kullanılır.
MinIO genellikle PV üzerinde çalışır. Yani MinIO'nun kendi datası için altında yine PV/PVC bulunabilir. Uygulamalar ise MinIO’ya S3 API ile erişir.
Distributed Storage: Ceph ve Longhorn
Distributed storage, veriyi tek bir node'a bağımlı bırakmak yerine birden fazla node'a yayarak (replication) daha dayanıklı bir yapı sunmayı hedefler. Ceph/Longhorn gibi çözümler Kubernetes'e genellikle CSI driver ile entegre olur ve StorageClass üzerinden dynamic provisioning sağlar.
Ceph
Ceph yaygın bir distributed storage sistemidir. Kubernetes ortamında çoğunlukla Rook-Ceph gibi operatörlerle yönetilir. Ceph ile farklı storage tipleri sağlanabilir:
- Block storage
- File storage
- Object storage (S3-compatible)
Ceph'in temel avantajı, verinin birden fazla node'a replike edilebilmesi ve node kayıplarında veri kaybı riskinin azalmasıdır.
Longhorn
Longhorn, Kubernetes-native bir distributed block storage çözümüdür. Longhorn tarafında öne çıkan özellikler:
- Volume replication
- Snapshot / backup mekanizmaları
Longhorn genellikle küçük veya orta ölçekli cluster'larda veya daha hızlı kurulup yönetilmesi gereken ortamlarda tercih edilir.
Access Modes
RWO (ReadWriteOnce) -> Sadece tek node yazabilir
RWX (ReadWriteMany) -> Birden fazla node yazabilir
ROX (ReadOnlyMany) -> Birden fazla node sadece okuyabilir
Reclaim Policy
PVC silindiğinde disk'in nasıl davranacağını reclaim policy belirler. Kubernetes'te 3 farklı reclaim policy vardır (1 tanesi eski).
- Retain -> PVC silinse bile PV ve içindeki veri korunur.
- Delete -> PVC silindiğinde PV ve arkasındaki storage kaynağı silinir.
- Recycle (Deprecated) -> PV içindeki veriyi basitçe temizleyip tekrar kullanılabilir hale getirirdi.
Örneğin: MariaDB ve PostgreSQL Verisi Nerede?
Bir database container'ı çalıştırdığınızda veri her zaman belirli bir data directory içine yazılır. Önemli olan, bu klasör container içinde mi kalıyor, yoksa bir PVC üzerinden gerçek diske mi bağlanıyor?
MariaDB
MariaDB'nin varsayılan veri dizini: /var/lib/mysql
Eğer persistence yapılandırılmadıysa bu dizin container filesystem'i üzerindedir. Pod silindiğinde veri kaybolur.
Eğer persistence enabled ise bu path bir volumeMount ile bir PVC'ye bağlanır.
PVC -> PV -> Physical storage
Pod silinse bile veri korunur.
Pod içinden mount durumunu görmek için:
kubectl describe pvc -n <namespace> <pvc-ismi>
Mount edilen path'leri burada görebilirsiniz.
PostgreSQL
PostgreSQL’in varsayılan veri dizini: /var/lib/postgresql/data
Mantık MariaDB ile aynıdır. Persistence yoksa veri geçicidir. Pod restart edildiğinde veri kaybolabilir.
Persistence varsa bu dizin bir PVC'ye mount edilir. Gerçek disk PV tarafındadır.
Gerçek Disk Yeri Nasıl Bulunur?
kubectl get pvc -n <namespace> # PVC'yi bul
kubectl describe pvc <pvc-ismi> # Bağlı olduğu PV'yi bul
kubectl describe pv <pv-ismi> # PV detayını incele
Burada şunu görürüz: Local path mi? NFS server mı? Cloud volume mu? Distributed storage mı?
Kısaca, gerçek disk yeri PV tanımında yazar.
Top comments (0)