SIG Storage’ı Tanımak: Kubernetes’te Veri Kalıcılığının Mutfağı
Açık konuşayım: Kubernetes tarafında o “stateless” masalı artık pek yürümüyor. Bir zamanlar konteyner deyince akla daha çok gelip geçen işler gelirdi, hani at gitsin, sil baştan kur gelsin kafası. Şimdi öyle mi? Pek sayılmaz. Veritabanı var, kuyruk var, AI model checkpoint’i var, vektör indeksleri var… Hepsi cluster içinde dürüyor ve hepsi disk istiyor. İşin altyapısını sırtlayan ekip de SIĞ Storage.
İtiraf edeyim, Kubernetes’in son birkaç sürümünü izliyorsanız, storage tarafında sessiz ama epey köklü değişiklikler döndüğünü görmüşsünüzdür. CSI sidecar’lardan Volume Group Snapshot’a, Changed Block Tracking’den AI iş yüklerine dönük volume tiplerine kadar ortalık hareketli. Ben de burada hem SIĞ Storage’ın ne yaptığını, hem de Türkiye’deki kurumsal müşterilerde bunun nasıl karşılık bulduğunu anlatmak istiyorum (ki bu çoğu kişinin gözünden kaçıyor). Evet.
SIĞ Storage Tam Olarak Ne Yapıyor?
Hani, İşin özü şu: Kubernetes çekirdeği storage tarafında tek başına pek bir şey yapmıyor. Pod’a disk bağlamak, snapshot almak, volume’u büyütmek gibi işler standart arayüzler üzerinden, dışarıdaki sürücülerle konuşularak çözülüyor. SIĞ Storage da tam burada devreye giriyor; hem bu arayüzlerin yönünü belirliyor, hem de referans implementasyonları ayakta tutuyor. Kısacası, işin mutfağı burada dönüyor.
Pratikte en çok gördüğüm yanlış anlaşılma şu: İnsanlar PVC (PersistentVolumeClaim) yazınca her şeyin Kubernetes tarafından halledildiğini sanıyor. Halbuki perde arkasında CSI driver, csi-provisioner, csi-attacher, csi-resizer. csi-snapshotter gibi bir sürü sidecar birlikte çalışıyor. Biri tökezlerse volume mount olmaz, pod CrashLoopBackOff’a düşer, sız de logların içinde “bu disk niye gelmedi” diye dolaşıp durursunuz. Evet, baya böyle.
SIĞ Storage’ın temel yaklaşımı şu: “Storage vendor bir driver yazsın, Kubernetes de önü standart bir arayüzle kullansın.” Böyle olunca hem on-prem SAN sistemleri, hem hyperscaler bulut diskleri, hem de yazılım tanımlı çözümler aynı API ile iş görüyor.
Container Storage Interface (CSI): Sessiz Kahraman
Yanı, CSI, Kubernetes’in storage tarafında bence en iyi oturan soyutlamalardan biri. Eskiden her storage entegrasyonu in-tree, yanı doğrudan Kubernetes ağacının içine kod olarak giriyordu. Yanı vendor kendi sürücüsünü eklemek için PR açacak, K8s sürüm döngüsünü bekleyecek, sonra bug fix için yine aynı döngünün içinde debelenecek… Açık konuşayım, pek keyifli bir model değilmiş.
Kısa bir not düşeyim buraya.
CSI bunu tersine çevirdi. Driver artık Kubernetes’in dışında kalıyor — pod olarak deploy ediliyor, bağımsız sürüm alıyor, kendi hızında ilerliyor. Kubernetes işe sadece standart sözleşmeye uyuyor. Bak şimdi, Azure Disk var, Azure Files var, AWS EBS var, GCP PD var; üstüne NetApp geliyor, Pure Storage geliyor, Ceph geliyor, Longhorn geliyor… Hepsi aynı dili konuşuyor. Sız hiç denediniz mi? Garip ama işe yarıyor.
Son Sürümlerde Gelen Önemli Özellikler
Şunu fark ettim: Şimdi gelelim işin sahadaki kısmına (ben de ilk duyduğumda şaşırmıştım). SIĞ Storage altında bir Data Protection Working Group var, SIĞ Apps ile birlikte ortak yürütülüyor; hani bazen dokümanda küçük görünen şeyler vardır ya, işte bu grup tam oradan çıkıp pratikte can yakmayan çözümler üretmeye çalışıyor. Bu WG’den çıkan iki özellik özellikle dikkat çekici:
Şimdi gelelim işin can alıcı noktasına.
Volume Group Snapshot
Diyelim elinizde bir uygulama var, 3 farklı PV kullanıyor: biri veritabanı için, biri log için, biri de cache için. Bunların snapshot’ını ayrı ayrı alırsanız ne olur? Araya milisaniyeler girer ve crash-consistent bir yedek elde edemezsiniz. Volume Group Snapshot tam da burada devreye giriyor; birden fazla volume’u tek bir tutarlı noktada dondurabiliyorsunuz,. Işin aslı şu: tek tek uğraşmak yerine hepsini aynı anda yakalıyorsunuz. Daha fazla bilgi için
Bir hesap yapalım. 1 TB’lık bir volume düşünün. Günlük değişim oranı %2 olsun. Full backup günlük 1 TB demek. CBT ile? Sadece ~20 GB. Bunu Azure Blob Storage cool tier’da bir ay tuttuğunuzda aradaki maliyet farkı küçük bir cluster için bile hissediliyor — büyük kurumsal yapılarda işe iş iyice büyüyor ve rakamlar altı haneyi rahat geçebiliyor. Tam da öyle.
Durun, bir saniye.
Aslında, Emin değilim ama sanırım en sevilen tarafı da şu: operasyonda “bir şeyler değişmiş mi?” diye tahmin yürütmek zorunda kalmıyorsunuz. Sistem zaten söylüyor. Bu kadar mı? Değil tabiî; ama başlangıç için fena değil.
Türkiye Perspektifinden Bakınca
İlginç olan şu ki, Bunu Türkiye’deki şirketler açısından ele alınca tablo biraz karışıyor, yanı tek bir kalıba sokmak zor. Sahada ben genelde şunu görüyorum: Buluta geçen kurumların çoğu hâlâ “lift and shift” kafasında ilerliyor. Yanı on-prem’deki VM’leri alıp Azure’a koyuyorlar, sonra Kubernetes tarafında stateful iş yüklerini yine managed servislere bırakıyorlar (Azure SQL, Cosmos DB, Database for PostgreSQL gibi),. Açık konuşayım, ilk etapta bu daha az yoruyor.
Bu yaklaşım bir yere kadar idare eder. Ama veri hacmi büyüyünce, hele AI/ML iş yükleri de devreye girince, işler biraz yön değiştiriyor. Vektör veritabanları, feature store’lar, model artefaktları… Bunlar çoğu zaman Kubernetes içinde, CSI üzerinden mount edilmiş volume’lerde dürüyor; hani o görünmeyen ama başınız ağrıdığında ilk akla gelen katman var ya, işte orası. İşin aslı burada SIĞ Storage’ın sunduğu özellikler baya iş görüyor (en azından benim deneyimim böyle)
Durun, bir saniye.
Startup mı, Enterprise mı? Stratejiniz Farklı Olmalı
Küçük bir ekipseniz ya da startup tarafındaysanız, bence CSI konusunda fazla derine dalmaya gerek yok. Bulut sağlayıcınızın varsayılan driver’ı ile başlayın, dynamic provisioning kullanın, snapshot işini de mümkünse bulut servisinin native yedekleme aracına bırakın. Karmaşıklık bazen gereksiz yük oluyor; hatta bazen sırf “ileri seviye” görünsün diye eklenen şeyler sonra kimsenin dokunmak istemediği bir köşeye dönüşüyor.
Bi saniye — Ama büyük kurumsal yapılarda hikâye başka yere gidiyor. Multi-cluster, multi-region, regülasyon yüzünden on-prem’de kalması gereken veriler, hibrit senaryolar… Böyle durumlarda CSI driver seçimi artık teknik bir detay değil, direkt stratejik karar oluyor. Hangi vendor’un driver’ı hangi K8s sürümünü destekliyor, snapshot sizin RPO hedefinizi karşılıyor mu, encryption-at-rest hangi anahtar yönetim sistemiyle konuşuyor — bunları en başta masaya koymak lazım. Burada, peki neden? Çünkü sonradan düzeltmek hem pahalıya patlıyor hem de operasyonu gereksiz yoruyor.
Pratik Bir CSI Driver Karşılaştırması
Sahada en sık karşılaştığım driver’lar için kaba bir karşılaştırma yapayım. Kısa tutacağım. Çünkü tabloyu uzatınca iş biraz dağılıyor, ama yine de birkaç can alıcı noktayı araya serpiştireceğim; özellikle snapshot, resize. RWX tarafında ufak farklar var, işte asıl mevzu da orada dönüyor.
| Driver | Snapshot | Resize | RWX | Tipik Kullanım |
|---|---|---|---|---|
| Azure Disk CSI | ✅ | ✅ | ❌ | Tekil pod, veritabanı |
| Azure Files CSI | ✅ | ✅ | ✅ | Paylaşımlı dosya, ML datasets |
| Azure Blob CSI | — | — | ✅ | Objesel, büyük data lake |
| Longhorn | ✅ | ✅ | Sınırlı | |
| Rook/Ceph | ✅ | ✅ | ✅ | On-prem, kendi storage’ı olanlar |
| Rook/Ceph | ✅ | ✅ | ✅ | On-prem, kendi storage’ı olanlar |
| Rook/Ceph✅✅✅On-prem, kendi storage’ı olanlar | ✅✅✅On-prem, kendi storage’ı olanlar | ✅✅On-prem, kendi storage’ı olanlar | ✅On-prem, kendi storage’ı olanlar | On-prem, kendi storage’ı olanlar |
| ? maybe not |
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments