Kubernetes'te kalıcı depolama nasıl kurulur: PV, PVC ve StorageClass

Pod geçicidir, veri kalıcı olmalıdır: kaynakların işbölümü

Bir pod silindiğinde ya da başka düğüme taşındığında kapsayıcı dosya sistemindeki veri kaybolur. Veritabanı, dosya yükleme alanı ya da mesaj kuyruğu gibi durum tutan iş yükleri için Kubernetes birbirini tamamlayan kaynaklarla kalıcı depolama sunar. PersistentVolume (PV), kümeye ayrılmış gerçek depolama parçasıdır: bulut diski, ağ paylaşımı ya da yerel disk olabilir. PersistentVolumeClaim (PVC), bir kullanıcının "şu boyutta, şu erişim biçiminde depolama istiyorum" talebidir. StorageClass ise bu talebe karşılık gelen depolamanın hangi türde, hangi kurallarla otomatik oluşturulacağını tarif eden şablondur.

İş bölümü şöyledir: küme yöneticisi depolama sınıflarını hazırlar; uygulama geliştirici yalnızca PVC yazar ve pod'a bağlar. Disk oluşturmak için bulut paneline gitmek gerekmez; dinamik sağlama (dynamic provisioning) devredeyken PVC oluşturulduğunda uygun PV kendiliğinden yaratılır ve talebe bağlanır.

StorageClass yazmak

StorageClass, sağlayıcıyı (provisioner) ve davranış ayarlarını tanımlar. Sağlayıcı genellikle bulut ya da depolama üreticisinin CSI sürücüsüdür. Aşağıdaki örnek, kavramları göstermek için kurgusal bir sürücü adı kullanır:

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: hizli-ssd provisioner: csi.example.com reclaimPolicy: Retain allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer

Bazı alanlar sıkça gözden kaçar. reclaimPolicy, PVC silindiğinde arkada kalan PV'nin ve gerçek diskin akıbetini belirler; belirtilmezse varsayılan Delete'tir, yani PVC ile birlikte veri de gider. allowVolumeExpansion, sonradan boyut büyütmeye izin verir. volumeBindingMode ise WaitForFirstConsumer olduğunda PV'nin yaratılması, PVC'yi kullanan pod zamanlanana kadar ertelenir. Bu, diskin pod'un çalışacağı bölgede (zone) oluşmasını sağlar; aksi halde disk bir bölgede, pod başka bir bölgede kalabilir ve pod zamanlanamaz.

Bir sınıf varsayılan olarak işaretlenebilir (storageclass.kubernetes.io/is-default-class ek açıklaması). storageClassName belirtmeyen PVC'ler bu sınıfı kullanır. Kümede birden fazla varsayılan sınıf bırakmak belirsizliğe yol açar.

PVC oluşturma ve pod'a bağlama

Uygulama tarafı talep ve bağlama parçalarından oluşur.

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: veri-pvc spec: accessModes: - ReadWriteOnce storageClassName: hizli-ssd resources: requests: storage: 10Gi

Pod içinde talebe hacim olarak başvurulur ve kapsayıcıya bağlanır:

spec: containers: - name: uygulama image: registry.example.com/uygulama:surum volumeMounts: - name: veri mountPath: /var/lib/uygulama volumes: - name: veri persistentVolumeClaim: claimName: veri-pvc

Durumu şu komutlarla izlersiniz:

kubectl get pvc,pv kubectl describe pvc veri-pvc

PVC Bound olduğunda bir PV'ye bağlanmıştır. Pending kalırsa describe çıktısındaki olaylar nedeni söyler. Birden çok kopyalı durumlu uygulamalarda (veritabanı kümeleri gibi) her kopyaya ayrı disk gerekir; bu durumda PVC'yi elle yazmak yerine StatefulSet içindeki volumeClaimTemplates alanı her kopya için talebi otomatik üretir.

Erişim kipleri: diski kaç pod, hangi biçimde kullanabilir?

Erişim kipi, diskin düğümlere ve pod'lara nasıl bağlanabileceğini söyler. Seçim, sağlayıcının neyi desteklediğine bağlıdır; her depolama türü her kipi sunmaz.

• ReadWriteOnce: Disk tek bir düğüme okuma-yazma bağlanır. Çoğu blok disk bu kipi sunar ve veritabanları için tipik seçimdir. Aynı düğümdeki birden çok pod yine de kullanabilir.
• ReadOnlyMany: Birçok düğüm diski yalnızca okuma amaçlı bağlayabilir.
• ReadWriteMany: Birçok düğüm aynı anda okuma-yazma bağlayabilir. Dosya paylaşımı (ağ dosya sistemi gibi) gerektirir; blok diskler genelde desteklemez.
• ReadWriteOncePod: Disk tek bir pod tarafından okuma-yazma kullanılabilir; tek yazıcı kuralı istenen durumlarda uygundur.

Karar ölçütü basittir: tek örnek çalışan veritabanı için ReadWriteOnce; birden çok kopyanın aynı dosyalara yazması gerekiyorsa ReadWriteMany destekleyen bir depolama. Erişim kipi uyuşmazlığı, PVC'nin Pending kalmasının yaygın nedenlerindendir.

Yaşam döngüsü: silme, koruma ve boyut büyütme

Bir PVC silindiğinde arkada kalan PV'ye ne olacağını reclaim policy belirler. Retain seçeneğinde PV kalır, veri korunur; ancak yeni bir PVC onu otomatik kullanamaz, yönetici veriyi elle temizleyip diski yeniden hazırlamalıdır. Delete seçeneğinde PV ve destekleyen sağlayıcılarda gerçek disk de silinir. Eski Recycle seçeneği kullanımdan kaldırılmıştır; yerine dinamik sağlama önerilir. Üretim verisi tutan sınıflarda Retain tercih edilir; mevcut bir PV'nin politikası da sonradan değiştirilebilir:

kubectl patch pv <pv-adi> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

Kubernetes, bir pod tarafından kullanılan PVC'yi hemen silmez; silme kullanım bitene kadar ertelenir. Bu, çalışan bir uygulamanın altından diskin çekilmesini önleyen bir korumadır.

Boyut büyütmek için sınıfta allowVolumeExpansion açık olmalıdır. Bu durumda PVC içindeki storage isteğini artırmak yeterlidir; küçültme desteklenmez. Dosya sistemi genişlemesi sürücüye bağlı olarak çalışan pod ile ya da pod yeniden başlatılınca tamamlanır.

PVC Pending kalıyorsa: kontrol sırası

Önce kubectl describe pvc çıktısındaki Events bölümünü okuyun. Yaygın nedenler ve çözümleri:

• Varsayılan sınıf yok: PVC storageClassName belirtmiyor ve kümede varsayılan StorageClass işaretli değil. Sınıf adını açıkça yazın ya da bir sınıfı varsayılan yapın.
• Sağlayıcı çalışmıyor: CSI sürücü pod'ları hata veriyorsa PV üretilemez. kube-system benzeri ad alanındaki sürücü pod'larını ve günlüklerini inceleyin.
• WaitForFirstConsumer bekleyişi: PVC, onu kullanan bir pod zamanlanana kadar Pending görünür. Bu beklenen davranıştır; pod'u oluşturun.
• Erişim kipi ya da boyut uyuşmazlığı: Statik PV kullanıyorsanız PV'nin kapasitesi ve erişim kipi talebi karşılamalıdır.
• Bölge uyuşmazlığı: Disk bir bölgede, pod'un zamanlanabileceği düğümler başka bölgede olabilir.
• Kota: Ad alanı kotası depolama isteğini engelliyor olabilir.

Statik sağlamada (yönetici PV'yi elle oluşturur) PVC ile PV'nin storageClassName değerleri eşleşmelidir. Bu yöntem eski ya da özel depolama sistemleri için hâlâ kullanılır, ama dinamik sağlama günlük işte çok daha az emek ister.

Sık yapılan hatalar ve yedekleme gerçeği

• Silme politikasını bilmeden sınıf kullanmak: Varsayılan Delete politikasıyla bir PVC'yi silmek veriyi de siler. Üretim sınıflarında Retain yazın.
• Tek disk, çok kopya: ReadWriteOnce bir diski çok kopyalı Deployment'a bağlamak, farklı düğümdeki kopyanın başlamamasına yol açar. Durumlu uygulamaları StatefulSet ile çalıştırın.
• Depolamayı yedek sanmak: Kalıcı disk, kopyalanmış veri demek değildir. Anlık görüntü (snapshot) ve düzenli yedekleme ayrıca planlanmalıdır.
• Boyutu tahmin edip büyütme iznini kapatmak: Sınıfta allowVolumeExpansion açık olmazsa disk dolduğunda yeni PVC oluşturup veriyi taşımanız gerekir.
• Düğüm yerel diskini kalıcı sanmak: Yerel depolama, düğüm kaybında veriyi kaybettirir; yalnızca tekrar üretilebilir veri için uygundur.

Geri yükleme provasını yapmak, hata durumunda güvenebileceğiniz tek kanıttır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Kalıcı depolama tasarımı, Kubernetes üzerinde durumlu uygulama işleten DevOps ve platform mühendisleri, altyapı yöneticileri ve sertifikasyon hazırlığı yapanlar için çekirdek konulardandır. Mindset kataloğunda birkaç program bu alanı farklı derinlikte ele alıyor: Kubernetes ile Orkestrasyon programında depolama ve kalıcılık, Kubernetes Ağ ve Depolama Yönetimi programında depolama temelleri ve kalıcı hacimler, durumlu iş yükleri ile yedekleme ve kurtarma, Kubernetes Administrator (CKA) Hazırlık programında ise CKA perspektifinden depolama ve kalıcılık.

Kurumsal ekipler için en somut kazanım, hangi uygulama için hangi depolama sınıfının kullanılacağı ve yedekleme sorumluluğunun kimde olduğu konusunda ortak bir standart oluşturmaktır.