CNCF, 10 Eylül 2026'da, yalnızca yedeklemenin Completed durumuyla sona erdiğini gözlemlemekle yetinmeyip durum bilgisi taşıyan Kubernetes uygulamalarında felaket kurtarma sürecini test etmeyi amaçlayan, yeniden üretilebilir üç arıza senaryosuna dayalı bir rehber yayımladı. Laboratuvar deposundan bir dizüstü bilgisayarda çalıştırılabilen deneylerde, sonucu genel durum göstergelerine güvenmek yerine gerçek kurtarma sonucunu doğrulayabilmek için dört satırdan oluşan bilinen içeriğe sahip bir PostgreSQL uygulaması kullanıldı.
Materyal, her ikisi de CNCF elçisi olan Saiyam Pathak ve Saloni Narang tarafından hazırlandı. Kapsamı, Kubernetes içindeki uygulama durumunun geri yüklenmesiyle sınırlıdır; uyumluluk çerçevelerini, ürün karşılaştırmasını, temel bulut veya veri merkezi altyapısının kurtarılmasını ele almaz. Velero ve CSI Snapshot arayüzleri senaryolar için referans uygulamalar olarak kullanılırken, arıza kalıpları aynı rolleri yerine getiren araçlar için de geçerlidir.
Tamamlanan yedekleme, geri yüklenebilirliği kanıtlamaz
İlk senaryoda Kubernetes yedeğinin bileşenleri YAML biçimindeki kaynak tanımlarına ve kalıcı depolama birimlerinin verilerine ayrıldı. Laboratuvar, iki kümenin dışındaki S3 uyumlu bir nesne deposuna veri aktarım mekanizmasıyla birlikte Velero kullandı. DataUpload nesnelerinin incelenmesi, depolama birimindeki 47.989.888 bayt verinin gerçekten harici depoya aktarıldığını gösterdi.
PVC de dahil olmak üzere ad alanı silindikten sonra kurtarma, aynı dört satırı yaklaşık iki dakika içinde geri getirdi. Ancak CNCF, depolama birimi verilerinin korunmasının veritabanı kopyasını otomatik olarak uygulama açısından tutarlı hâle getirmediği konusunda uyarıyor; uygulamalar flush veya quiesce işlemlerine ihtiyaç duyabilir. Farklı bir altyapıya kurtarma yapılması, ekibin tasarlayıp test etmesi gereken StorageClass eşleştirmesi ve başka dönüşümler de gerektirebilir.
Daha da önemlisi, yedekleme araçları kaynakları önceden mevcut bir kümeye geri yükler; düğümleri, ağı, yük dengeleyicileri veya DNS'i oluşturmaz. Bu nedenle kurtarma planı, yedeği kabul edecek ortamı açıkça tanımlamalı; gerektiğinde Kubernetes'in geri yüklenmesi Infrastructure as Code'a veya Cluster API'ye devredilmelidir.
Git niyeti geri getirir, depolanan durumu değil
İkinci senaryoda üretim kümesi durduruldu; kurtarma kümesi ise önceden mevcut olup bir Git deposuna bağlı GitOps denetleyicisi ve paylaşılan depoya bağlı bir yedekleme aracı içeriyordu. Uygulama senkronizasyonu başarılı oldu, StatefulSet çalışır duruma geldi ve gösterge paneli sağlıklı göründü; ancak veritabanına yapılan sorgu şu hatayı döndürdü: relation "attendees" does not exist.
Sorun Kubernetes veya GitOps arızası değildi. Depo yalnızca tanımları içerdiğinden denetleyici StatefulSet'i, Service'i ve yeni, boş bir depolama birimini yeniden oluşturdu. Pratikte Git, bildirilen durumu veya ekibin niyetini depolarken yedekler gerçek verileri depolar; bunların hiçbiri tek başına uygulamanın tamamını geri getiremez.
Laboratuvardaki kurtarma yöntemi, önce senkronizasyonun oluşturduğu boş uygulamanın kaldırılmasını, ardından uygulamanın birimleriyle birlikte yedek deposundan geri yüklenmesini ve son olarak verilerin beklenen içerikle karşılaştırılmasını içeriyordu. Üretimin durdurulmasından doğrulanmış verilerin görünmesine kadar geçen süreç canlı deneyde dört dakika, yeniden testte ise iki dakikadan biraz kısa sürdü. CNCF, bu sayıların yalnızca otomatikleştirilen bölümü kapsadığını; olayın tespit edilmesi, karar verilmesi, trafiğin yönlendirilmesi ve özgün ortama geri dönülmesi aşamalarını içermediğini belirtiyor.
Tekil anlık görüntüler hiç var olmamış bir kurtarma noktası oluşturabilir
Üçüncü senaryo, birbiriyle ilişkili iki depolama birimi kullanan bir uygulamayı test etti: biri siparişler, diğeri ödemeler için. Laboratuvar, her ödemenin bir siparişle eşleşmesi koşuluyla saniyede beş kez eşleşen çift yazıyordu. Beş saniye arayla iki ayrı anlık görüntü alındığında her bir anlık görüntü tek başına hazır ve sağlıklı görünüyordu; ancak kurtarma, kaydedilen son siparişin 108352, ödeme sayısının ise 108377 olduğunu ortaya çıkardı; yani eşleşen siparişleri olmayan 25 ödeme vardı.
Sonuç, her bir depolama işleminin başarılı olmasının çoklu depolama birimlerine sahip uygulamanın tutarlılığını garanti etmediğini gösteriyor; iki anlık görüntü birlikte gerçekte hiç var olmamış bir zaman anını temsil edebilir. Materyal, yedekleme aracı çok sayıda PVC üzerinde sırayla ilerlediğinde üretimde farkın büyüyebileceğini belirtiyor.
Kubernetes 1.36'da GA durumuna gelen VolumeGroupSnapshot, depolama birimlerini tek bir etiketle belirlemek ve CSI üzerinden tutarlı bir kurtarma noktası talep etmek için bir mekanizma sunuyor. Koordineli deneyde siparişlerin ve ödemelerin son numarası 109169'da eşleşti ve aralarındaki ilişkinin doğrulanması başarılı oldu. Ancak destek sürücüye bağlıdır; normal VolumeSnapshots desteği, grup anlık görüntülerinin desteklendiğini kanıtlamaz. Ayrıca laboratuvar için incelenen büyük bulut sağlayıcılarının sürücülerinin çoğu, 2026'nın ortasına kadar bunları uygulamıyordu. CRD'ler, anlık görüntü özelliği ve ilgili eklentiler de açıkça etkinleştirilmelidir.
Kurtarma testi neyi ölçmelidir?
- Daha önce hiç çalıştırılmamış temiz bir hedefe uygulamanın tamamının geri yüklenmesi; yalnızca bir Pod'un silinip yeniden oluşturulmasının izlenmemesi.
- Yalnızca kaynakların durumuna veya gösterge panellerinin renklerine güvenmek yerine beklenen içerikle verilerin ve kullanıcı erişim yolunun doğrulanması.
- Sürecin tamamının saatle ölçülmesi; gerçek kurtarma süresinin tespit, karar, trafiğin yönlendirilmesi ve muhtemelen özgün ortama geri dönülmesini içerdiğinin kabul edilmesi.
- Üretim kümesi ile kurtarma kümesi gibi bağımsız iki arıza alanının kullanılması ve yedekleme deposunun her ikisinin dışında tutulması.
Editoryal değerlendirme: Araçlar ile kurtarma sıralaması arasındaki boşluk
Bu deneylerin öne çıkardığı pratik değişim, başarı ölçütünü “yedekleme tamamlandı”dan “doğru veriler geri geldi ve bunlara erişilebiliyor”a taşımaktır. Daha geniş kısıt ise temel Kubernetes'in veri, uygulama, küme, trafik ve kimlik koordinasyonu için ortak bir sözleşme tanımlamaması ve uygulamanın tamamını ve harici bağımlılıklarını açıklayan sürdürülebilir, standart bir kurtarma kaynağı sunmamasıdır. Bu nedenle her katman için olgun araçlar mevcut olsa bile GitOps, yedekleme, altyapı ve kullanıcı yolu arasındaki sınırlar ekibin sorumluluğunda kalır. CNCF, CNCF TAG Operational Resilience bünyesindeki Cloud Native Business Continuity girişiminin ekosistem boşluklarının analizi, kurtarma rehberleri ve referans mimariler üzerine katkıları bir araya getirmeyi amaçladığını belirtiyor.