1. GİRİŞ

Konteynerlaşmanın yaygınlaşmasıyla birlikte, uygulamaların sadece compute değil, kalıcı depolama gereksinimleri de kritik hâle geldi. Kubernetes, stateless uygulamaları yönetmede güçlüdür ancak stateful (veri tutan) uygulamaların güvenli ve performanslı çalışması için doğru depolama stratejileri gerekir. Bu makale Kubernetes üzerinde depolama sistemlerinin temellerini, teknik mimarisini, performans ve dayanıklılık konularını, üretimde sık karşılaşılan senaryoları ve en iyi uygulamaları derinlemesine ele alır.

Bu konu neden konuşuluyor?

• Kubernetes ile veritabanı, mesaj kuyruğu, dosya paylaşımları ve ML veri iş yükleri gibi stateful servislerin yönetimi artıyor.
• Bulut ve on‑prem altyapılarda depolama çeşitliliği (block, file, object) ve performans gereksinimleri farklılaşıyor.
• CSI standardı, dinamik provisioning ve container‑native storage çözümlerinin olgunlaşmasıyla depolama artık daha esnek yönetilebiliyor.

Kimler için önemli?

• Platform mühendisleri ve SRE ekipleri
• Veri tabanı mühendisleri ve MLOps ekipleri
• Bulut mimarları ve altyapı yöneticileri

Hangi problemleri çözüyor?

• Depolama provision süreçlerini otomatikleştirir ve sürümlendirilebilir hâle getirir.
• Pod yeniden başlatma veya node failure durumlarında veri sürekliliğini sağlar.
• Farklı performans, dayanıklılık ve maliyet gereksinimlerine uygun storage sınıfları sunar.

2. KAVRAMSAL TEMELLER

2.1 Temel kavramlar

• PersistentVolume (PV): Cluster seviyesinde yönetilen kalıcı depolama kaynağı (ör. cloud disk, NFS share).
• PersistentVolumeClaim (PVC): Pod'un ihtiyaç duyduğu depolama talebini (kapasite, erişim modu) tanımlayan nesne.
• StorageClass: Dinamik provisioning için depolama profilini (provisioner, rekalkulasyon, reclaim policy) tanımlar.
• CSI (Container Storage Interface): Kubernetes'in depolama sağlayıcılarıyla (provisioner, attacher, mounter) standart şekilde entegrasyonunu sağlayan API standardı.
• Access Modes: Podların PV'yi hangi erişim biçimiyle kullanacağını belirler (ReadWriteOnce, ReadOnlyMany, ReadWriteMany).
• VolumeMode: 'Filesystem' (dosya sistemi) veya 'Block' (ham blok cihaz) seçimlerini ifade eder.

2.2 Depolama türleri

• Block Storage: VM diskleri veya cloud block storage (EBS, Azure Disk). Yüksek IOPS/throughput sağlar, genelde tek yazma (RWO) senaryolarında kullanılır.
• File Storage: NFS, SMB veya cloud file services (EFS, Azure Files). Birden fazla tüketiciye (RWX) uygun paylaşılmış dosya sistemi sağlar.
• Object Storage: S3 uyumlu depolar; genelde doğrudan pod volume olarak kullanılmaz, uygulama aracılığıyla erişilir ve büyük veri, arşiv için uygundur.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ

3.1 PV/PVC akışı ve dinamik provisioning

Kullanıcı bir PVC oluşturduğunda Kubernetes şu adımları takip eder: PVC storageClass referansına göre uygun provisioner'ı belirler; eğer dinamik provisioning açıksa provisioner arka planda bir PV oluşturur ve PVC'yi bağlar. Pod, PVC'yi talep ettiğinde kubelet ilgili CSI driver ile volume'u ilgili node'a attach ve mount eder. Dinamik provisioning, altyapı kaynaklarını kodla yönetmeyi ve self‑service deneyimini mümkün kılar.

3.2 CSI bileşenleri

CSI, üç ana fonksiyon sunar: provisioner (PV oluşturma), attacher (volume attach/detach), ve node plugin (mount/format işlemleri). CSI driver'ları genelde controller ve node komponentleri olarak çalışır. Operator veya helm chart ile kurulan CSI çözümleri cluster yönetimiyle entegre edilir.

3.3 Access modes ve multi‑attach senaryoları

Access mode seçimi uygulamanın gereksinimlerine göre belirlenmelidir. Örneğin veritabanları genelde ReadWriteOnce ile çalışır; birden fazla pod'un aynı veritabanı dosyalarını eş zamanlı yazması verify edilmelidir. ReadWriteMany (RWX) sağlayabilen çözümler (NFS, Azure Files, EFS, CephFS) yatay ölçek gerektiren paylaşımlı dosya senaryolarında tercih edilir.

3.4 StatefulSet ve PersistentVolumeClaimTemplate

StatefulSet, stateful uygulamalar için sabit ağ kimliği ve sıra garantisi sağlar. volumeClaimTemplates kullanılarak her bir replica için ayrı PVC oluşturulur; böylece pod ölçeği arttığında yeni kalıcı diskler dinamik olarak provision edilir. Bu mekanizma veritabanı replikasyonu ve veri izolasyonu için önemlidir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — Büyük ölçekli veri işleme

Netflix benzeri firmalar, medya içeriklerini ve telemetri verilerini yönetirken yüksek throughput ve dayanıklılık gerektirir. Bu tür organizasyonlarda S3/objekt depolama, HDFS benzeri çözümler ve performans odaklı block storage kombinasyonu ile pipeline'lar kurulur. Kubernetes genelde inference ve iş yükleri için ephemeral infra sağlar; büyük veri depoları ise dış sistemlerde tutulur.

4.2 Uber — Low latency ve geo‑distributed storage

Uber tipi uygulamalar için veri lokalitysi, düşük gecikme ve bölgesel replikasyon önemlidir. Kubernetes üzerinde çalışan mikroservisler, veri kaynaklarına en yakın replica'ları kullanarak latency'yi düşürür; bu amaçla multi‑region storage ve edge‑caching çözümleri uygulanır.

4.3 Amazon / AWS — EBS, EFS, FSx ve CSI

AWS ortamında EBS (block), EFS (file) ve FSx (performant file) gibi hizmetlerle Kubernetes storage entegrasyonu CSI driver'ları ile sağlanır. EBS yüksek IOPS gereken tek‑yazma senaryoları için uygundur; EFS RWX gerektiren paylaşımlar için tercih edilir.

4.4 OpenAI / MLOps — Büyük veri ve model serving

MLOps senaryolarında training verileri genelde objekte (S3) veya yüksek performanslı shared file sistemine alınır. Model serving aşamasında düşük latency ile erişim için fast storage cache'leri veya local NVMe disk kullanımı yaygındır. GPU node'lar lokal disk ile temp data tutarak I/O darboğazını azaltır.

4.5 Stripe — Fintech ve tutarlılık

Fintech uygulamalarında veri bütünlüğü ve uyumluluk birincil önceliktir. Stateful uygulamalar için storage replication, snapshot ve point‑in‑time restore mekanizmaları, encryption at rest ve audit log'ları zorunludur.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Dinamik provisioning ile altyapı self‑service ve reproducible hâle gelir.
• StorageClass ile performans ve maliyet profilleri ayrıştırılabilir.
• CSI standardı ile çok çeşitli depolama cihazları ve servisleri Kubernetes'e entegre edilebilir.

Sınırlamalar

• Block storage'ın multi‑writer kısıtları: bazı veritabanı replikasyon modelleri zorlaşır.
• Performans garanti seviyeleri (IOPS/throughput) donanım ve cloud sağlayıcıya bağlıdır.
• Snapshot, restore ve cross‑region replication çözümlerinin uygulanması operasyonel karmaşıklık yaratabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• StorageClass profillerini performans, dayanıklılık ve maliyet ekseninde tanımlayın (gold/silver/bronze).
• StatefulSet kullanırken volumeClaimTemplates ile her replica için izolasyon sağlayın.
• Snapshot ve backup süreçlerini otomatikleştirin; restore senaryolarını düzenli test edin.
• Encryption at rest ve in transit sağlayın; KMS entegrasyonları kurun.

Performans optimizasyonu

• IOPS/throughput gereksinimlerini ölçün ve storageClass seçimlerini buna göre yapın.
• Local NVMe cache veya ephemeral disk kullanarak OK oluşturma/okuma yoğunluğu azaltılabilir.
• Volume resizing ve thin provisioning özelliklerini kullanın; capacity planning yapın.

Güvenlik

• Role‑based erişim ile PVC/PV yönetimini sınırlandırın; secret'ları kullanarak storage credential'larını yönetin.
• Snapshot/backup verilerini şifreleyin ve erişimi sınırlayın.

Ölçeklenebilirlik

• Cluster‑level storage çözümlerinde (Ceph, Longhorn) replikasi ve failover stratejilerini planlayın.
• Object storage için lifecycle polices (transition, expire) ile maliyet yönetimi yapın.

8. SIK YAPILAN HATALAR

• PVC için uygun storageClass seçmeden RWO block disk kullanmak ve replica gereksinimlerini gözardı etmek.
• Snapshot'ları ve restore prosedürlerini test etmeden üretime geçirmek.
• Default storageClass kullanmak ve performans/maliyet trade‑offs'u değerlendirmemek.
• Volume lifecycle yönetimini (reclaimPolicy) ve garbage collection stratejisini planlamamak.

9. GELECEK TRENDLER

1. Container‑native dağıtık storage: OpenEBS, Longhorn gibi projelerle daha fazla uygulama diske dayanarak çalışacak; storage kontrolünü Kubernetes layer'ına taşır.
2. CSI genişlemesi: Daha fazla provider CSI desteği sunacak; cross‑cloud storage orchestration çözümleri artacak.
3. Edge storage ve tiering: Edge site'larda lokal cache + cloud tiering modelleri yaygınlaşacak.
4. AI‑driven storage optimization: ML modelleri ile I/O pattern'leri analiz edilip otomatik tier ve cache kararları alınacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. PVC ile PV arasındaki fark nedir?

   PV fiziksel veya cloud tabanlı gerçek depolama kaynağını temsil eder; PVC ise pod'un ihtiyacını tarif eden talep nesnesidir. PVC, uygun bir PV ile bağlanır.

2. 2. Hangi durumlarda ReadWriteMany (RWX) gerekir?

   Birden çok pod'un aynı dosya sistemine eş zamanlı yazma/okuma yapması gereken paylaşımlı dosya senaryolarında (ör. CMS, shared cache) RWX gereklidir.

3. 3. CSI neden önemli?

   CSI, depolama sağlayıcılarının Kubernetes ile tutarlı ve standart biçimde entegre olmasını sağlar; dinamik provisioning, snapshot ve clone gibi modern özellikleri destekler.

4. 4. StatefulSet ile Deployment arasındaki fark nedir?

   StatefulSet, her replica için kalıcı kimlik ve kalıcı disk sağlayarak stateful uygulamaları destekler; Deployment ise stateless veya paylaşımsız state gerektiren uygulamalar için uygundur.

5. 5. Volume snapshot performansı nasıl etkiler?

   Snapshot işlemleri storage vendor'a göre değişir; bazı snapshot'lar hızlı (copy‑on‑write), bazıları ise yoğun I/O anlarında performans etkileyebilir. Snapshot schedule ve retention planlaması önemlidir.

6. 6. Local PV kullanmalı mıyım?

   Local PV yüksek performans ve düşük latency sağlar fakat node failure durumlarında verinin taşınması zordur. Kritik veriler için replikasyon veya distributed storage tercih edilmelidir.

7. 7. Backup stratejisinde nelere dikkat etmeliyim?

   RPO/RTO hedefleri, snapshot frequency, offsite replica, encryption ve restore testleri backup stratejisinin temel bileşenleridir.

8. 8. Cross‑region replication mümkün mü?

   Evet, bazı storage sistemleri cross‑region replicate destekler; latency, consistency ve maliyet trade‑offs'ları dikkatlice değerlendirilmelidir.

Anahtar Kavramlar

PersistentVolume (PV)

Cluster tarafından yönetilen fiziksel veya cloud depolama kaynağı.

PersistentVolumeClaim (PVC)

Pod'un talep ettiği depolama kaynağı; PVC PV ile eşleşir.

StorageClass

Dinamik provisioning için depolama profil tanımı (provisioner, parameters).

CSI

Kubernetes ile storage sağlayıcıları arasındaki standart arayüz.

StatefulSet

Stateful uygulamalar için replica kimliği ve volume template desteği sağlayan kontrolör.

Öğrenme Yol Haritası

1. 0–1 ay: PV/PVC/StorageClass temel kavramlarını öğrenin; küçük bir NFS veya cloud disk ile pratik yapın.
2. 1–3 ay: CSI driver kurulumları, StatefulSet ve volumeClaimTemplates üzerinde deneyimler kazanın; snapshot/restore işlemlerini uygulayın.
3. 3–6 ay: Performance tuning (IOPS/throughput), local PV, ephemeral disk kullanımı ve distributed storage (Ceph, Longhorn) deneyimi edinin.
4. 6–12 ay: Cross‑region replication, backup/restore otomasyonu, disaster recovery planları ve storage governance uygulamalarını hayata geçirin.