Kalıcı Birimler ve Talepler

Pod'lar oluşturulur ve sonlandırılır, ancak uygulamanızın verilerinin çoğu zaman varlığını sürdürmesi gerekir. Bir veritabanını veya kullanıcıların yüklediği dosyaları düşünün.

• Bir Pod yeniden başlatıldığında veya başka bir yerde yeniden zamanlandığında, doğrudan kapsayıcının dosya sisteminde saklanan tüm veriler kaybolur.
• Bu geçici yapı durumsuz uygulamalar için uygundur, ancak kritik veriler kalıcı bir çözüm gerektirir.
• Kubernetes, Pod yaşam döngülerinden bağımsız olarak varlığını sürdüren kalıcı depolamayı yönetmek için güçlü bir sistem sağlar.

PersistentVolume (PV), Kubernetes kümenizdeki bir depolama alanıdır.

• Küme kapsamlı bir kaynaktır; yani belirli bir ad alanına ait değildir.
• PVs bir yönetici tarafından veya StorageClass aracılığıyla dinamik olarak sağlanır.
• Altta yatan depolama teknolojisinin ayrıntılarını soyutlar (ör. Google Persistent Disk, AWS EBS, NFS paylaşımı).

PVs; kapasite, erişim kipleri ve depolama türü gibi ayrıntılarla tanımlanır. Bu YAML, 5 Gigabayt depolama içeren bir hostPath (yerel test için) kullanan bir PV'yi açıklar.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

Not: hostPath genellikle tek düğümlü geliştirme için kullanılır ve üretim ortamı için önerilmez.

PersistentVolumeClaim (PVC), belirli bir ad alanındaki bir kullanıcı veya uygulama tarafından yapılan depolama isteğidir.

• Pod'lar PV'leri doğrudan kullanmaz; depolamayı bir PVC aracılığıyla ister.
• PVCs ad alanı kapsamındadır; bu nedenle belirli bir projenin veya ekibin alanında bulunur.
• İstenen boyutu, erişim kiplerini ve isteğe bağlı olarak bir depolama sınıfını belirtir.

Kubernetes, bağlama adı verilen bir işlemle bir PVC'yi kullanılabilir bir PV ile otomatik olarak eşleştirir.

• Bir PVC oluşturulduğunda Kubernetes, PVC'nin gereksinimlerini (boyut, erişim kipleri, depolama sınıfı) karşılayan bir PV arar.
• Uygun bir PV bulunduğunda ikisi bire bir ilişkiyle birbirine "bağlanır".
• Bu bağlama, PVC'nin istediği belirli depolama alanını almasını sağlar.

Erişim kipleri, depolamanın Pod'lar tarafından nasıl bağlanıp kullanılabileceğini tanımlar. Bu kipler PVCs tarafından istenir ve PVs tarafından desteklenir:

• ReadWriteOnce (RWO): Birim, tek bir düğüm tarafından okuma-yazma modunda bağlanabilir.
• ReadOnlyMany (ROX): Birim, birçok düğüm tarafından yalnızca okuma modunda bağlanabilir.
• ReadWriteMany (RWX): Birim, birçok düğüm tarafından okuma-yazma modunda bağlanabilir.

Bu kiplerin kullanılabilirliği, belirli depolama sağlayıcısına bağlıdır.

StorageClass, yöneticilerin depolama "sınıflarını" (ör. "fast-ssd", "slow-hdd") tanımlamasını sağlar.

• PV'leri elle oluşturmak yerine bir StorageClass, PVC istediğinde bir PV'yi dinamik olarak sağlayabilir.
• Bu işlem, önceden tanımlanmış şablonlara göre PV'lerin oluşturulmasını otomatikleştirir.
• Depolama sağlama işlemini depolamanın kullanımından ayırarak kullanıcıların işini kolaylaştırır.

ReadWriteOnce erişimiyle 1 Gigabayt depolama isteyen bir PVC oluşturalım. Bu PVC, mevcut bir PV arayacak veya bir StorageClass aracılığıyla dinamik sağlama işlemini tetikleyecektir.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard # Optional: if you have a 'standard' StorageClass

Bunu pvc.yaml olarak kaydedin ve kubectl apply -f pvc.yaml ile uygulayın.

Bir PVC bağlandıktan sonra Pod, birim yapılandırmasında PVC'nin adına başvurarak onu kullanabilir. Pod'un altta yatan PV hakkında bilgi sahibi olması gerekmez; yalnızca PVC'yi bilmesi yeterlidir.

apiVersion: v1
kind: Pod
metadata:
  name: my-data-pod
spec:
  containers:
    - name: data-container
      image: busybox
      command: ["/bin/sh", "-c", "echo 'Hello from CoddyKit!' > /mnt/data/hello.txt && sleep 3600"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /mnt/data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: my-app-pvc

Bu Pod, bağlanmış kalıcı birime bir dosya yazacaktır.

Kalıcı depolama kaynaklarınızın durumunu kubectl kullanarak izleyebilirsiniz:

• Tüm PV'leri görmek için: kubectl get pv
• Ad alanınızdaki tüm PVC'leri görmek için: kubectl get pvc
• Durum ve olaylar dâhil ayrıntılı bilgi almak için:
• kubectl describe pv <pv-name>
• kubectl describe pvc <pvc-name>

PVs'lerin Bound olduğundan ve PVCs'lerin doğru PV'ye Bound durumuyla bağlandığından emin olun.

Bir kullanıcı, 50GB kalıcı depolama gerektiren bir veritabanı dağıtmak istiyor. Hangi Kubernetes kaynağı, kullanıcının uygulamasının bu depolama için yaptığı isteği doğrudan temsil eder?

Kubernetes'in uygulamalarınız için kalıcı depolamayı nasıl yönettiğini ele aldık:

• PersistentVolumes (PVs), gerçek depolamayı temsil eden küme kaynaklarıdır.
• PersistentVolumeClaims (PVCs), kullanıcıların depolama istekleridir.
• Kubernetes, gereksinimlere göre PVCs'leri uygun PVs'lere bağlar.
• Erişim Kipleri, depolamanın nasıl kullanılabileceğini tanımlar (RWO, ROX, RWX).
• StorageClass, PV'lerin dinamik olarak sağlanmasını mümkün kılar ve kurulumu otomatikleştirir.

Bu sistem, Pod'lar gelip gitse bile uygulama verilerinizin varlığını sürdürmesini sağlayarak durum bilgisi taşıyan uygulamalar için güvenilirlik sunar.