Kubernetes v1.36: Volume Group Snapshots Sonunda GA Oldu

Açık konuşayım: Bu özelliği ilk kez 2023’ün ortalarında, v1.27 alpha çıktığında bir bankacılık müşterimizin DR senaryosunda denemiştik. O gün kafamdan geçen şey şuydu: “Bu iş olur ama prod’a girmesi epey sürer.” Öyle de öldü. Şimdi v1.36 ile VolumeGroupSnapshot resmen GA. Yanı production’a sokarken içimiz biraz daha rahat.

Kısacası, peki neden? Çünkü birini 10:00:00’da, ötekini 10:00:03’te, sonuncusunu da 10:00:07’de alırsan, aradaki saniyelerde uygulama yazmaya devam ediyor olur. Restore edince veritabanı “transaction bitti” der, ama log tarafı o satırı daha görmemiş olabilir. İşte o an ortalık biraz dağılır; inconsistent state dediğimiz şey tam bu, yanı veri tutarsızlığı.

Durun, bir saniye.

Volume Group Snapshot burada devreye giriyor. Birkaç PVC’yi bir label selector ile aynı gruba topluyorsun ve hepsinin snapshot’ını tek seferde, crash-consistent şekilde alabiliyorsun. PostgreSQL tarafında fsync sonrası ne görüyorsan ona yakın bir görüntü çıkıyor ortaya (tabiî application-consistent değil), yanı sunucunun fişini çekmişsin gibi düşün; sert ama tutarlı.

Crash-consistent demek, “uygulama quiesce edilmeden, donanım seviyesinde aynı anda” demek. Application-consistent değil. Bu ikisini karıştıran çok ekip gördüm — sonra DR testinde tatsız sürprizlerle karşılaştılar.

API Tarafında Neler Var?

Üç tane CRD ile dönüyor bu iş. Bunları bilmeden girerseniz, sonra debug ederken saç baş yolmanız an meselesi: (yanlış duymadınız)

• VolumeGroupSnapshot: Kullanıcının (yanı sizin ya da bir CronJob’un) oluşturduğu istek. Hangi PVC’lerin snapshot’lanacağını label ile söylüyorsunuz.
• VolumeGroupSnapshotContent: Snapshot controller’ın yarattığı, gerçek storage kaynağını temsil eden obje. Cluster-scoped.
• VolumeGroupSnapshotClass: StorageClass’a benzer mantıkta — hangi CSI driver’ın, hangi parametrelerle iş yapacağını tanımlıyor.

Doğrusu, Geçen sene Logosoft’ta bir e-ticaret müşterisinde buna benzer bir şeyi elle script’lerle yapmıştık — Velero üstünden. Çalışıyordu, evet, ama 200 PVC devreye girince senkronizasyon kaymaya başladı; işte o noktada insan “tamam, bu artık elle yürümüyor” diyor. Şimdi bunun native tarafı var, daha temiz dürüyor.

Basit Bir Örnek

apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshot
metadata:
name: prod-app-snapshot-20260508
namespace: ecommerce
spec:
volumeGroupSnapshotClassName: csi-azuredisk-groupsnap
source:
selector:
matchLabels:
app: order-service
snapshot-group: critical

Burada can alıcı nokta şu: matchLabels ile eşleşen neredeyse tüm PVC’ler grup snapshot’a giriyor. Bir PVC’yi yanlışlıkla bu label ile işaretlerseniz… evet, o da içeri düşer. Küçük gibi duran ama prod ortamda insanın sınırını bozan klasik bir tuzak. Sız ne dersiniz?

Hangi CSI Sürücüleri Destekliyor?

İşin pek hoş olmayan kısmına geldik. GA olmuş olması, otomatik olarak “her CSI sürücüsü bunu destekliyor” anlamına gelmiyor. Şu an tablo kabaca böyle dürüyor, yanı bazı driver’lar işi gayet götürüyor, bazıları işe ya sınırlı kalıyor ya da belli SKU’larda naz yapıyor.

Kısacası, driver tarafında destek yoksa Kubernetes cephesinde özelliğin GA olması pek bir şey değiştirmiyor. Özellik orada dürüyor ama sizin ortamda görünmüyor, işte durum bu kadar net. Migration planı yapmadan önce bunu kontrol edin; sonra “neden çalışmadı?” diye uğraşmak can sıkıyor.

Bakın şimdi, Türkiye’de Kubernetes’e ilgi son 3 yılda baya hızlandı. Bilhassa de bankacılık, telco ve büyük perakende tarafı yatırım yapıyor. Ama işin aslı şu: çoğu ekip hâlâ tek volume’lu basit uygulamalar koşturuyor cluster’larda (şaşırtıcı ama gerçek). Stateful workload tarafı işe biraz geride kalıyor.

Bir telekom müşterimizde geçen ay şöyle bir konuşma geçti: “Aşkın bey, bizim CRM uygulamasının altında 12 farklı PVC var, DR planımız ne olacak?” Cevap aslında basit — Volume Group Snapshot kullanın. Ama küçük bir detay çıktı; o ekibin CSI driver’ı bunu desteklemiyordu. Önce driver upgrade, sonra storage class düzenlemesi, ardından test derken… iki aylık iş öldü.

Bir dakika — bununla bitmedi.

Kurumsal müşterilerimde gördüğüm kadarıyla bu özelliğin Türkiye’de benimsenmesi yavaş olacak. Bir bakıma, peki neden? Çoğu firma hâlâ storage tarafını dış kaynak gibi görüyor. NetApp filer var ama K8s tarafıyla entegrasyon yok. vSphere üstünde çalışıyor ama CSI driver güncel değil. Yanı bu işi kullanmak için sadece Kubernetes yetmiyor, altyapının da hazır olması gerekiyor.

Evet. Daha fazla bilgi için Least Privilege Ajanlar: Güvenliği Baştan Kurmanın Yeni Yolu yazımıza bakabilirsiniz.

Startup vs Enterprise Perspektifi

İnanın, Küçük ekipseniz veya startup’sanız, açık konuşayım; bu özelliği hemen kullanmak için acele etmeyin (şaşırtıcı ama gerçek). Tek volume’lu basit uygulamalarda klasik VolumeSnapshot hâlâ idare ediyor, hatta çoğu zaman yeter de artar bile. Önceliği backup stratejisine. Velero gibi araçlara verin; group snapshot’a ihtiyacınız yoksa, gereksiz complexity’i kendi omzunuza yüklemenin pek anlamı yok.

Enterprise tarafındaysanız, özellikle finans, sağlık. Telco gibi yüksek RPO/RTO isteyen sektörlerdeyseniz, durum değişiyor. Bu özellik baya iş görüyor. Microservice mimarinizde 5-10 PVC kullanan uygulamalarınız varsa — ki genelde var — group snapshot olmadan tutarlı DR yapmak zorlaşıyor. Hemen pilot başlatın derim; hatta mümkünse bir test ortamında önce çevirin işi, sonra prod’a bakarsınız.

İşin garibi, Tam da öyle.

Pratik Kullanım Senaryoları

Şimdi işin sahaya bakan tarafına gelelim. Hangi durumda bunu kullanırsınız, asıl soru bu.

1. Disaster Recovery: Bölge bazlı bir felaket olursa, tüm uygulamayı tutarlı bir noktadan geri kaldırmak için kullanıyorsunuz. En klasik senaryo bu, hani fazla süslü de değil.
2. Stateful microservice deployments: Mesela bir order management sistemi düşünün; order DB ayrı, inventory DB ayrı, audit log da başka volume’daysa, hepsini aynı anda yakalamak baya iş görüyor.
3. Test/dev ortamı kopyalama: Production’dan tutarlı bir snapshot alıp dev ortamına geri açmak için ideal. Anonim verilerle test yapacaksanız, açık konuşayım, eli rahatlatıyor. (bence en önemlisi)
4. Versiyon upgrade öncesi rollback noktası: Büyük bir DB upgrade’inden önce group snapshot alırsınız, sonra işler ters giderse 5 dakikada geri dönersiniz. Kulağa basit geliyor ama kurtarıcı olabiliyor. — bunu es geçmeyin
5. Compliance ve audit: Bazı düzenlemeler, özellikle finans tarafında olanlar, point-in-time backup istiyor. Group snapshot burada doğal bir çözüm gibi dürüyor; ekstra kıvırmaya pek gerek kalmıyor.

Bazı yerlerde bu özellik sadece “nice to have” gibi görünür, ama dur bir saniye — operasyon büyüyünce tablo değişiyor (özellikle çoklu volume kullanan yapılarda), çünkü tek tek backup kovalamak yerine toplu ve tutarlı bir nokta almak insanın hayatını epey kolaylaştırıyor. Bu konuyla ilgili C++ Kodunu CLI’da Anlamak: Copilot’a Gelen Akıllı Katman yazımıza da göz atmanızı tavsiye ederim.

İlginç olan şu ki, Bizim ekipte Kubernetes v1.36’da DRA: Donanım Paylaşımında Yeni Dönem yazısında bahsettiğim donanım paylaşımı konusu gibi, group snapshot da v1.36’nın storage tarafındaki en kayda değer adımı. Bu sürüm gerçekten storage ve DR olgunluğu açısından bir milat; şey gibi değil yanı, ufak tefek kozmetik bir güncelleme falan değil. Bu konuyla ilgili Microsoft Agent Framework v1.0: Lokal’den Prod’a Geçiş yazımıza da göz atmanızı tavsiye ederim.

Evet.

Karşılaştığım Bir Sorun ve Çözümü

Geçen ay bir POC yaparken garip bir şeye takıldım: VolumeGroupSnapshot oluşturuyorum,. ReadyToUse: false inatla değişmiyor. Loglara baktım, controller da resmen “no matching PVCs found” diye bağırıyor. PVC’ler ortada, label’lar doğru, her şey tamam gibi dürüyor (bizzat test ettim). Bakın, peki neden?

Vallahi, Sebep meğer basit değilmiş, ama baya sınır bozucuymuş. PVC’ler farklı StorageClass’lardaydı; biri premium-ssd, diğeri standard-hdd. Group snapshot bunu pek sevmiyor,. Aynı driver yetmiyor, arka taraftaki backend’in de uyumlu olması gerekiyor (bazı CSI sürücülerinde performance tier farkı bile işi bozabiliyor). Yanı dışarıdan bakınca aynı gibi duran iki disk, içeride birbirine selam bile vermiyor. Bu konuyla ilgili Foundry Toolboxes: Ajan Araçlarını Toplamak Neden Şart Oldu? yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Foundry Hosted Agents ile MAF’ı Prod’a Taşımak: Benim Notlarım yazımıza bakabilirsiniz.

Çok konuştum, örnekle göstereyim.

Çözüm neydi? PVC’leri aynı StorageClass’a taşıdık. Bir gün uğraştırdı, açık konuşayım, ama sonunda çalıştı. Bu ayrıntı dokümantasyonda var aslında,. Öyle ilk bakışta göze çarpan bir yer de değil; yanı bilmeden girerseniz direkt duvara tosluyorsunuz.

Daha açık söyleyeyim, bir şey dikkatimi çekti: Tam da öyle.

Maliyet Tarafı — TL Bazında Düşününce

Snapshot’lar bedava değil arkadaşlar. Azure tarafında managed disk snapshot ücretlendirmesi, GB başına aylık kabaca 1.5-2 TL bandında geziyor (kur oynuyor, SKU da oynuyor),. 10 TB’lık bir kurulumda ay sonunda yaklaşık 20.000 TL civarı bir fatura görebiliyorsunuz. Bir de incremental olmayan snapshot stratejisi seçerseniz, iş orada kalmıyor; rakam hızlıca şişiyor.

Birincisi, cross-namespace group snapshot yok. Yanı farklı namespace’lerde duran PVC’leri tek bir grup altında toplayamıyorsunuz; mikroservis yapısında namespace per service gidenler için bu baya can sıkıcı bir sınır, çünkü iş pratikte tam orada takılıyor.

İkincisi, application-consistent tarafı eksik kalmış. Şimdilik sadece crash-consistent var. PostgreSQL ya da MongoDB gibi veritabanlarında quiesce hook’larını sizin yazmanız gerekiyor; sistem bunu kendi başına halletmiyor. Beklediğimden biraz daha ham geldi açıkçası.

Üçüncüsü, cross-cluster restore tarafı hâlâ tam oturmamış. Snapshot’ı başka bir cluster’a taşımak istediğinizde manuel adım atmanız gerekiyor. SIĞ Architecture API Governance: Kubernetes’in Sessiz Kahramanı yazısında değindiğim API tutarlılığı meselesi burada da kendini gösteriyor, yapı sağlam dürüyor ama ekosistem kısmı henüz aynı tempoda değil.

İlk Adım Olarak Ne Yapmalısınız?

Size bir şey söyleyeyim, Denemek isteyenler için, lafı gevelemeden, sıralı bir yol haritası bırakayım:

1. CSI driver versiyonunuzu kontrol edin: kubectl get csidrivers
2. VolumeGroupSnapshotClass var mı bakın: kubectl get volumegroupsnapshotclasses
3. Önce dev/test ortamında deneyin. Asla production’da ilk denemeyi yapmayın. — bunu es geçmeyin
4. PVC’lerinizi anlamlı label’larla işaretleyin (mesela backup-group: tier-1)
5. İlk snapshot’ı manuel oluşturun, restore senaryosunu da test edin. Restore çalışmıyorsa snapshot işe yaramaz.
6. CronJob ile otomasyona alın. Hata bildirım mekanizmasını mutlaka kurun.

Burada küçük ama kritik bir nokta var. Snapshot ≠ Backup. Aynı şey gibi dürüyor, ama değil; snapshot çoğu zaman aynı storage backend üstünde yaşıyor, o backend giderse snapshot da onunla birlikte uçup gidiyor (evet, biraz tatsız), bu yüzden off-site backup tarafını ayrı düşünmeye devam etmeniz gerekiyor.

Sıkça Sorulan Sorular

Volume Group Snapshot ile normal VolumeSnapshot arasındaki fark ne?

Bi saniye — Kısaca söylemek gerekirse: group snapshot, birden fazla volume’u aynı anda — crash-consistent şekilde — snapshot’lıyor. Normal snapshot işe tek bir volume için. Yanı birden fazla PVC’li bir uygulamanız varsa. Veri tutarlılığı sizin için kritikse, aslında group snapshot olmadan pek olmaz.

Hangi CSI sürücüleri Volume Group Snapshot destekliyor?

Ceph RBD, AWS EBS, GCE PD, Pure Storage, NetApp Trident gibi büyük oyuncular destekliyor (yanlış duymadınız) (ilk duyduğumda inanamadım). Azure Disk ve vSphere CSI tarafında destek var ama bazı SKU/yapılandırmalarda kısıtlamalar söz konusu. Tecrübeme göre en güvenli yol, kubectl get volumegroupsnapshotclasses ile kendi ortamınızda bizzat kontrol etmek.

Group snapshot application-consistent mi?

Hayır, crash-consistent. Yanı uygulamayı durdurup dondurmak yerine donanım (belki yanılıyorum ama) seviyesinde aynı anda alıyor. Application-consistent bir şey istiyorsanız, uygulamayı önce quiesce etmeniz gerekiyor — mesela PostgreSQL’de pg_start_backup gibi. Bu adımı açıkçası sız kendiniz yönetmek zorunda kalıyorsunuz, otomatik gelmiyor.

Mevcut Velero kurulumumla beraber çalışır mı?

İtiraf edeyim, Evet, çalışıyor. Velero v1.13+ sürümleri VolumeGroupSnapshot CRD’lerini tanıyor. Plugin desteği CSI driver’a bağlı tabiî, ama genel olarak uyumlu. Bence şöyle düşünmek mantıklı: Velero üst katman backup yönetimi, group snapshot da alt katmanda bir storage primitive’i.

Snapshot’lar ekstra maliyet çıkarır mı?

Garip gelecek ama, Maalesef evet, çıkarıyor. Cloud provider’a göre değişiyor ama snapshot’lar disk kullanımının bir kısmı kadar ekstra maliyet oluşturuyor. Incremental snapshot kullanmak. Eski snapshot’ları otomatik temizlemek için retention policy uygulamak — hani bu konuda gerçekten taviz vermemek lazım.

Kaynaklar ve İleri Okuma

Kubernetes v1.36: Moving Volume Group Snapshots to GA — Resmî Blog

Neyse, garip gelecek ama, Kubernetes Resmî Dokümantasyonu — Volume Group Snapshots

CSI External Snapshotter — GitHub Repo

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

İlgili Yazılar

DevOps’ta Güvenlik Uyarılarıyla İş Öğesi Bağlama13 Mar 2026

Azure SDK'da Node.js 20 Desteği Bitiyor: Hazır mısınız?7 Nis 2026

Azure Repos’ta Son Gelişmeler ve Kolaylıklar13 Mar 2026

CodeQL Autofix Raporları Artık Daha Gerçekçi31 Mar 2026