Kalıcı depolama

Diskten uygulama talebine

Depolama ekranları cluster genelindeki PersistentVolume’leri (PV), namespace içindeki PersistentVolumeClaim’leri (PVC) ve StorageClass tanımlarını ayrı listeler. Kapasite, durum, erişim biçimi ve bağlanma bilgileriyle uygulamanın depolama talebini inceleyebilirsiniz.

• PV ve PVC detaylarını, YAML içeriğini ve bağlı kaynak bilgisini görüntüleme.
• PVC listesini namespace ve kaynak adına göre daraltma.
• StorageClass üzerinden provisioner ve depolama politikasını inceleme.
• İzin verilen kaynaklarda YAML düzenleme ve silme araçlarını kullanma.

Pending kalan PVC’yi inceleme

1. Uygulamanın namespace’inde PVC’yi bulun ve istediği kapasiteyi kontrol edin.
2. Seçili StorageClass’ın mevcut olduğunu ve beklenen provisioner’ı kullandığını doğrulayın.
3. PV bağlanma durumunu ve Kubernetes olaylarını inceleyin.
4. Düzeltmeden sonra PVC’nin Bound durumuna geçtiğini ve Pod’un çalıştığını kontrol edin.

Veri yaşam döngüsü

Depolama kaynağını silmenin veriye etkisi reclaim policy, CSI/provisioner ve kullanılan depolama sistemine bağlıdır. Kaynak silme işlemini bir yedekleme yöntemi olarak değerlendirmeyin.

Battani depolama kaynaklarını yönetmek için arayüz sağlar; bu görünüm otomatik disk yedeği veya tüm CSI sistemleri için snapshot desteği vaadi içermez.

PV ve PVC ekranlarının kapsamı

PersistentVolume cluster kapsamındaki depolamayı, PersistentVolumeClaim namespace içindeki talebi temsil eder. PV ve PVC sekmeleri farklı listelerdir; namespace filtresi PVC tarafında anlamlıdır.

• Ad araması ve sütun sıralamasıyla kaynağı bulun.
• Kapasite, durum, access mode ve StorageClass bilgilerini birlikte değerlendirin.
• Liste yenilenirken eski seçimin hâlâ doğru kaynağı gösterdiğini kontrol edin.

PersistentVolume detaylarını okuma

PV detayında kapasite, erişim biçimleri, reclaim policy, StorageClass ve bağlı claim bilgisi depolamanın kullanımını açıklar. Bound, Available veya Released durumlarını aynı biçimde yorumlamayın.

• Bağlı PVC’nin namespace ve adını karşılaştırın.
• Released kaynak için diskin boş veya silinebilir olduğunu varsaymayın.
• PV düzenleme/silme sistem yöneticisi yetkisi gerektirir; depolama sistemi politikası ayrıca geçerlidir.

PersistentVolumeClaim durumunu okuma

PVC listesinde talebin namespace’i, kapasitesi, access mode’u, sınıfı ve bağlandığı volume bilgisi izlenir. Pending bir claim için yalnız kapasiteye bakmak yeterli değildir.

• Talep edilen StorageClass’ın mevcut olduğunu kontrol edin.
• Access mode ve istenen kapasiteyi mevcut/provision edilen volume ile karşılaştırın.
• Pod olayları ve storage provisioner olaylarıyla bağlanma hatasını ilişkilendirin.

StorageClass provisioner ve politikaları

StorageClasses ekranında provisioner, reclaim policy, volumeBindingMode ve allowVolumeExpansion gibi alanlar görünür. Bunlar sınıfın davranışını tanımlar; her depolama arka ucu aynı özellikleri sunmaz.

• Immediate ile WaitForFirstConsumer bağlanma davranışını Pod scheduling bağlamında değerlendirin.
• Genişleme izni, kullanılan sürücünün her koşulda büyütme yapabileceğini garanti etmez.
• Cluster kapsamındaki bu kaynakların YAML düzenleme ve silme araçları sistem yöneticisi iznine bağlıdır.

Depolama YAML’ını inceleme ve düzenleme

Satır eylemlerindeki YAML araçları tanımı görüntüler ve uygun izinle değişiklik gönderir. Kaydedilebilen alanlar Kubernetes’in ilgili kaynak için kabul ettiği değişikliklerle sınırlıdır; her alan değiştirilebilir değildir.

1. Kaynağın türünü ve PVC ise namespace’ini doğrulayın.
2. Mevcut tanımı inceleyip gerekli alanı düzenleyin.
3. Sunucunun döndürdüğü immutable field veya admission hatasını okuyun.
4. İşlemden sonra bağlanma durumunu ve uygulamanın diske erişimini doğrulayın.

PV/PVC silmenin etkisi

Silme onayından önce bağlı Pod ve uygulama verisini inceleyin. PVC/PV silme ile depolama sistemindeki gerçek verinin saklanması ya da kaldırılması reclaim policy ve sürücü davranışına bağlıdır.

• Arayüzde düğmenin görünmesi backend ve Kubernetes yetkilerinin de izin vereceği anlamına gelmez.
• Silinen claim’in yeniden oluşturulması eski veriye otomatik bağlanmayı garanti etmez.
• Yedek gereksinimini kaynak silme işleminden önce ayrı olarak çözün.

Depolamada toplu seçim

PV, PVC ve StorageClass listelerinde yetkiye göre seçim kutuları ve toplu silme çubuğu bulunur. Toplu işlemde her hedef ayrı değerlendirilir; hata alan kaynaklar listede kalabilir.

• Seçili sayıyı ve görünür filtreyi karşılaştırın.
• Birden fazla namespace’te aynı PVC adına dikkat edin.
• İşlem sonrası başarı ve hata sayılarını okuyup kaynakları yeniden yükleyin.

Bekleyen veya bağlanamayan volume için akış

Depolama sorunu çoğu zaman claim, sınıf, provisioner ve Pod scheduling koşullarının birlikte incelenmesini gerektirir. Battani kaynakları görünür kılar; altyapı sürücüsünün kurulumu veya otomatik veri yedeği bu sayfanın işlemi değildir.

1. PVC’nin StorageClass, access mode ve kapasite isteğini okuyun.
2. PV ve StorageClass tanımlarını karşılaştırın.
3. Pod ve ilgili namespace olaylarında mount/provision hatalarını inceleyin.
4. Düzeltmeden sonra PVC Bound ve Pod hazır durumunu doğrulayın.