Kubernetes kümelerinde bir Pod silindiğinde ona bağlı PersistentVolumeClaim (PVC) çoğu zaman otomatik silinmez. Bu davranış veri kaybını önlemek için güvenlidir; ancak aylar içinde sahibi bilinmeyen, kullanılmayan diskler birikerek maliyeti ve operasyon karmaşasını artırabilir. Güvenli çözüm “boş görünen her PVC’yi silmek” değil; kullanım sinyali, sahiplik, retention, yedek ve geri yükleme kanıtını bir karar akışında birleştirmektir.

Kullanılmayan PVC neden otomatik olarak gereksiz değildir?

Bir PVC o anda çalışan Pod tarafından referans edilmiyor olabilir; fakat StatefulSet ölçek düşürme sonrası tekrar kullanılacak veri, geçici olarak durdurulmuş bir ortam, migration öncesi kopya veya olay incelemesi için tutulan disk olabilir. Kubernetes kaynak ilişkisi teknik kullanımı gösterir, iş değerini göstermez.

• StatefulSet replica sayısı azaltıldığında eski ordinal’e ait PVC korunmuş olabilir.
• CronJob veya batch işinin çalışma aralığında disk uzun süre boş görünebilir.
• Uygulama devre dışı bırakılmış ama yasal/işletimsel retention süresi dolmamış olabilir.
• Snapshot alınmış olsa bile geri yükleme testi yapılmamış olabilir.
• PersistentVolume üzerindeki Retain reclaim policy, PVC silinse bile altyapı diskini koruyabilir.

Bu nedenle “Pod bağlı değil” yalnızca inceleme adaylığıdır; silme onayı değildir.

Kubernetes 1.37 ile Unused condition ne sağlıyor?

Kubernetes 1.37’de PersistentVolumeClaimUnusedSinceTime özelliği Beta seviyesine yükseldi ve varsayılan olarak etkinleştirildi. PVC protection controller, PVC durumuna Unused condition ekleyerek çalışan veya pending durumdaki terminal olmayan bir Pod’un claim’i referans edip etmediğini gösterir. Condition’ın lastTransitionTime alanı PVC’nin ne zaman kullanılmayan duruma geçtiğini anlamaya yardım eder.

Buradaki önemli ayrıntı şudur: pending bir Pod henüz çalışmıyor olsa bile PVC’yi kullanma niyeti taşıdığı için claim kullanılmıyor sayılmaz. Succeeded veya Failed durumundaki tamamlanmış Pod’lar ise kullanım işareti oluşturmaz. Özellik, önceki özel script ihtiyacını azaltır; fakat sahiplik ve backup kararını sizin yerinize vermez.

Kullanılmayan PVC’leri bulma

Önce tüm namespace’lerde PVC ve condition bilgisini dışa aktarın. Kubernetes 1.37’de aşağıdaki örnek yalnızca inceleme listesi üretir; silme yapmaz:

kubectl get pvc -A -o json | jq -r '
  .items[]
  | select(.status.conditions[]? |
      select(.type=="Unused" and .status=="True"))
  | [.metadata.namespace,
     .metadata.name,
     (.status.capacity.storage // "unknown"),
     (.status.conditions[] |
       select(.type=="Unused") | .lastTransitionTime)]
  | @tsv'

Daha eski kümelerde Pod spec’leri ile PVC listesini çapraz kontrol eden envanter gerekir. Her iki yöntemde de controller owner, label, annotation, StorageClass, bağlı PV, reclaim policy ve gerçek altyapı diski birlikte incelenmelidir. CSV benzeri bir listeyi tek başına silme girdisine dönüştürmeyin.

Maliyet görünürlüğü nasıl kurulmalı?

PVC kapasitesi ile gerçek maliyet birebir aynı olmayabilir. StorageClass türü, performans seviyesi, provisioned IOPS/throughput, snapshot ve replika politikası faturayı etkiler. Raporu namespace, ekip, uygulama, ortam ve maliyet merkezi etiketleriyle gruplandırın. Etiketsiz storage kaynaklarını ayrı bir “sahipsiz” kuyruğuna alın.

• Toplam provisioned kapasite ve son 30/60/90 gün kullanım durumu.
• Aktif Pod’a bağlı olmayan PVC kapasitesi.
• StorageClass ve performans katmanına göre aylık tahmini maliyet.
• Sahibi, uygulaması veya retention etiketi eksik kaynak sayısı.
• Snapshot sayısı, yaşı ve doğrulanmış restore durumu.

Dosya sistemi doluluk metriğini de ekleyin; ancak “yalnızca yüzde 2 dolu” ifadesi silme gerekçesi değildir. Küçük ama kritik bir veritabanı dosyası iş açısından yüksek değere sahip olabilir.

Güvenli temizlik akışı: keşif, karantina, doğrulama, silme

1. Keşif: Belirli bir eşikten uzun süredir kullanılmayan PVC’leri aday listeye alın. Eşik ortam bazında değişmelidir; development için 14–30 gün, production için daha uzun ve iş onaylı süre gerekebilir.

2. Sahiplik: Uygulama sahibi, namespace sorumlusu ve değişiklik kaydı bulunmadan ilerlemeyin. StatefulSet volumeClaimTemplates, GitOps manifestleri ve helm release geçmişiyle ilişkisini kontrol edin. Claim başka adla yeniden oluşturulsa bile eski verinin rollback için gerekli olup olmadığını sorun.

3. Karantina: Adayı etiketleyin ve silmeden önce bekleme süresi tanımlayın. Örneğin cleanup-candidate=true, cleanup-after ve owner gibi organizasyonunuza ait etiket/annotation standardı kullanın. Karantina sırasında alarm üretin; uygulama geri dönerse adaylığı otomatik kaldırın.

4. Yedek doğrulama: Snapshot’ın “Completed” görünmesi yeterli değildir. Ayrı bir test alanında restore edin, dosya sistemi/veritabanı bütünlüğünü ve uygulamanın okuyabildiğini doğrulayın. Snapshot ile bağımsız yedeği eş anlamlı saymayın; aynı hesap, cluster veya yetki alanındaki snapshot fidye yazılımı ya da yetkili kullanıcı hatasına karşı yeterli izolasyon sağlamayabilir.

5. Onay ve silme: Production verisi için en az iki kişi/onay kapısı, değişiklik numarası ve geri dönüş planı kullanın. Önce PVC, sonra reclaim policy sonucuna göre PV ve altyapı diskini doğrulayın. “PVC silindi” ile “maliyet durdu” aynı sonuç olmayabilir.

Reclaim policy ve StatefulSet tuzakları

Delete reclaim policy genellikle PVC silindiğinde dinamik oluşturulan altyapı diskini de siler. Retain ise PV’yi ve alttaki veriyi manuel işlem için bırakır. Politikayı silme anında değiştirmek beklenmedik sonuç verebilir; cluster ve CSI davranışını test ortamında doğrulayın.

StatefulSet PVC’leri özellikle dikkat ister. Replica küçültüldüğünde claim’ler varsayılan davranışla korunabilir ve daha sonra aynı ordinal geri geldiğinde yeniden kullanılabilir. StatefulSet PVC retention policy ayarını, Kubernetes sürüm desteğini ve GitOps kaynağını incelemeden claim silmeyin. Operator tarafından yönetilen veritabanlarında operator’ın kendi backup/restore prosedürü önceliklidir.

Otomasyon için güvenlik bariyerleri

• İlk aşamada yalnızca rapor üretin; otomatik silmeyi kapalı tutun.
• Production namespace’lerini varsayılan olarak hariç bırakın.
• Minimum kullanım dışı süre, owner ve retention alanlarını zorunlu kılın.
• StatefulSet/operator sahipli claim’leri otomatik süreçten çıkarın.
• Doğrulanmış restore kanıtı ve değişiklik onayı olmadan silmeyin.
• Dry-run çıktısı ile gerçek işlem listesinin aynı olduğunu imzalayın.
• Her silmeyi merkezi audit log ve ticket numarasıyla kaydedin.
• Temizlik sonrası PV, disk ve fatura etkisini read-back ile doğrulayın.

Kubernetes admission policy veya policy-as-code ile owner, environment, retention ve data-class etiketlerini PVC oluşturulurken zorunlu kılmak, aylar sonra sahipsiz kaynak araştırmaktan daha ucuzdur. Ayrıca quota yalnızca tüketimi sınırlar; sahiplik ve veri yaşam döngüsü politikasının yerini tutmaz.

Operasyon kontrol listesi

• PVC kullanım condition’ı ve son geçiş zamanı kaydedildi.
• Pod, StatefulSet, operator ve GitOps ilişkisi kontrol edildi.
• Owner, data class, retention ve ortam bilgisi doğrulandı.
• Reclaim policy ve alttaki disk davranışı biliniyor.
• Snapshot dışında bağımsız yedek ve başarılı restore kanıtı var.
• Karantina süresi boyunca yeniden kullanım izleniyor.
• Production için çift onay ve değişiklik kaydı mevcut.
• Silme sonrası PV/disk/maliyet sonucu yeniden okundu.

Kubernetes storage maliyetini veri güvenliğiyle birlikte yönetin

Atıl storage temizliği, yalnızca maliyet optimizasyonu değil veri yaşam döngüsü operasyonudur. Narweb’in Kubernetes Cluster Hosting yaklaşımını inceleyebilir; mevcut cluster’ınızda PVC envanteri, storage kararı, yedek ve güvenli bakım akışını değerlendirmek için teknik ekiple iletişime geçebilirsiniz.