SIG Storage'ı Tanımak: Kubernetes'te Veri Kalıcılığının Mutfağı

⏱️ 6 dk okuma📅 18 Haziran 2026👁️ görüntülenme

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 Microsoft Build 2026: Liderlerin Bilmesi Gereken 3 Kritik Çıkarım yazımıza bakabilirsiniz.

Kurumsal ekiplerde bu özellik son zamanlarda baya konuşuluyor. Mesela PostgreSQL + WAL ayrı volume’lerde tutuluyorsa veya Kafka brokerları için ayrı log dizinleri varsa, group snapshot olmadan tutarlı yedek almak gerçekten zordu; açık konuşayım, çoğu zaman uygulama tarafında quiesce yapmak zorunda kalıyorduk. Bu da sistemi kısa süreliğine yavaşlatıyordu. Evet, biraz zahmetliydi.

İşte tam da bu noktada devreye giriyor.

Araya gireyim: Peki neden önemli? Çünkü tutarlılık bozulunca geri dönüş de sıkıntıya giriyor. Neyse, çok dağıtmayayım; yukarıda bahsettiğim o olay var ya, işte onun çözümü bu. Daha fazla bilgi için EWS Bildirimlerinden Microsoft Graph’a Geçiş: Sessiz Ama Büyük Değişim yazımıza bakabilirsiniz.

Changed Block Tracking (CBT)

Bir diğer can alıcı özellik CBT. Adı üstünde: değişen blokları izliyor — itiraz edebilirsiniz tabi — (ben de ilk duyduğumda şaşırmıştım). Full backup yerine sadece değişen blokları yedeklemek, hem disk I/O’yu hem ağ trafiğini hem de yedek storage maliyetini aşağı çekiyor; nasıl desem, kağıt üstünde küçük duran ama sahada baya fark ettiren işlerden biri bu. .NET Haziran 2026 Servis Güncellemesi: 3 CVE ve Bilmeniz Gerekenler yazımızda bu konuya da değinmiştik.

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. Bu konuyla ilgili Azure Cosmos DB’ye Immutable Backup Geldi: Ne Değişiyor? yazımıza da göz atmanızı tavsiye ederim.

Durun, bir saniye. Daha fazla bilgi için Azure Cosmos DB’de Partition Key Değiştirmek: Artık Daha Az Acı Veriyor yazımıza bakabilirsiniz.

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.

💡 Bilgi: Eğer AKS kullanıyorsanız Azure Disk CSI ve Azure File CSI driver’ları zaten önceden kurulu geliyor. Ama CBT veya Volume Group Snapshot gibi yeni özellikler için driver sürümünün K8s sürümünüzle uyumlu olduğundan emin olun. Bu uyumsuzluk en sık karşılaştığım sorunlardan biri.

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

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102