Kubernetes volumes dünyasında container storage’ı anlamak bazen kafa karıştırıcı olabiliyor. Özellikle verilerinizi kaybolmadan nasıl saklayacağınızı öğrenmeye çalışırken.

Kubernetes dünyasında, container orchestration genelde sihir gibi hissettiriyor. Uygulamalarınız otomatik scale oluyor, servisler birbirini bulabiliyor ve her şey (çoğunlukla) düzgün çalışıyor. Ama data persistence konusuna gelince işler biraz daha karmaşık.

Kubernetes varsayılan olarak container’ları ephemeral olarak değerlendiriyor. Bu demek oluyor ki pod restart olduğunda veya terminate edildiğinde, içindeki veriler kayboluyor. Peki log’ları, database’leri veya restart’ları atlatması gereken application state’i nasıl saklıyoruz?

İşte burada devreye giriyor: Kubernetes Volumes. Daha spesifik olarak: Persistent Volumes, Persistent Volume Claims ve Storage Classes – Kubernetes’te persistent storage’ın kutsal üçlüsü.

kubernetes volumes

Kubernetes Volumes Neden Bu Kadar İyi?

Basit terimlerle, Kubernetes’te bir volume, pod içindeki container’ların erişebildiği bir directory’dir. Veri persist etmek veya container’lar arasında veri paylaşmak için kullanılıyor.

Kubernetes farklı volume türlerini destekliyor – emptyDir, hostPath, configMap gibi – ama bunlar çoğunlukla ephemeral. Pod çöktüğünde, veriler de onunla birlikte çöküyor.

Pod lifecycle’ının ötesinde veri saklamak için şunları kullanıyoruz:

  • Persistent Volumes (PVs)
  • Persistent Volume Claims (PVCs)
  • Storage Classes (SCs)

Persistent Volumes Nasıl Çalışır?

Persistent Volume’ü cluster’ınızdaki fiziksel storage parçası gibi düşünün. Bu AWS EBS’te provision edilmiş bir disk, Azure Disk, NFS share, hatta local diskiniz olabilir.

Kubernetes admin’leri veya dynamic provisioner’lar PV’leri oluşturuyor ve pod’ların kullanması için hazır hale getiriyor.

Örnek PV YAML

Basit bir Persistent Volume tanımını inceleyelim:

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

Yukarıdaki örnekte:

  • 5Gi storage allocate ediyoruz
  • Access mode ReadWriteOnce (aynı anda sadece bir node yazabilir)
  • hostPath kullanıyoruz, local test için harika (production’da tavsiye edilmiyor)

Persistent Volume Claims ile Storage Talep Etme

PVC’yi bir uygulamadan gelen storage talebi gibi düşünebilirsiniz.

Pod’lar CPU ve memory gibi compute resource’ları talep ettiği gibi, PVC de storage talep ediyor. Kubernetes sonra bu talebi uygun bir PV ile eşleştiriyor.

Örnek PVC YAML

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

PVC storage ve access gereksinimlerini karşılayan bir PV’ye bind olacak.

Önemli Noktalar

  • PVC’ler gerçek storage implementation’dan ayrıştırılmış
  • Developer’ların nasıl provision edildiğini düşünmeden storage talep etmesini kolaylaştırıyor

Storage Classes İle Otomatik Provisioning

Şimdi her seferinde manuel olarak PV oluşturmak istemediğinizi düşünün. PVC oluşturulduğunda Kubernetes’in otomatik olarak storage provision etmesini istiyorsunuz.

İşte burada Storage Classes devreye giriyor.

Storage Class, volume’ün nasıl provision edileceğini tanımlıyor (disk türü, IOPS, zone, reclaim policy gibi).

Örnek StorageClass YAML

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2

Sonra PVC’nizde bu storage class’ı referans edebilirsiniz:

spec:
  storageClassName: standard

Bu PVC’yi apply ettiğinizde, Kubernetes şunları yapacak:

  • Eşleşen StorageClass’ı bulacak
  • O class’ı kullanarak dinamik olarak PV oluşturacak
  • Yeni PV’yi PVC’ye bind edecek

Hokus pokus ^_^

Gerçek Hayat Use Case’leri

Database Storage

Kubernetes üzerinde MySQL/PostgreSQL deploy ediyorsunuz. Pod restart olduğunda, veriler persist etmeli. Şunları yapıyorsunuz:

  • 20Gi için PVC tanımlıyorsunuz
  • Kubernetes dinamik olarak EBS volume provision ediyor (StorageClass ile)
  • MySQL data file’ları saklamak için PVC kullanıyor
  • Database’iniz restart’ları ve hatta pod migration’ları atlatıyor

Log Aggregation

Microservice’leriniz Fluentd veya log forwarder tarafından toplanması gereken log’lar üretiyor. Container’lar reschedule edildiğinde bile log’ları saklayan shared persistent volume mount edebilirsiniz.

Machine Learning Jobs

Uzun ML training job’ları çalıştırdığınızı düşünün. Geçici sonuçlar, intermediate model’ler ve final artifact’lar job restart olsa bile saklanmalı. PVC’ler tüm bu verilerin korunmasını sağlıyor.

CI/CD Build Artifacts

CI/CD pipeline’ları için Kubernetes kullanıyorsanız (Jenkins veya GitLab runner’ları gibi), PVC’ler şunları persist etmeye yardım ediyor:

  • Build cache’leri
  • Stage’ler arası artifact’lar
  • Shared workspace’ler

Sonuç

Kubernetes, Persistent Volumes, Claims ve Storage Classes ile data persistence’ı yönetmek için esnek ve güçlü bir yol sunmak amacıyla storage’ı abstract ediyor.

En İyi Pratikler

  • Scalability için StorageClasses ile dynamic provisioning kullanın
  • Production’da hostPath kullanmaktan kaçının
  • Uygun accessMode’ları tanımlayın:
    • ReadWriteOnce: bir node read/write mount edebilir
    • ReadOnlyMany: birçok node read-only mount edebilir
    • ReadWriteMany: birçok node read/write mount edebilir (NFS gibi)
  • Data güvenlik ihtiyaçlarınıza göre reclaimPolicy ayarlayın (Retain, Delete, Recycle)
  • StorageClasses kullanmıyorsanız PVC’leri PV’lere match etmek için label ve selector kullanın

Kubernetes data management’ı esnek hale getiriyor – ama yine de architect gibi düşünmeniz gerekiyor. PV’leri, PVC’leri ve StorageClasses’ı anlamak, pod’lar yok olduğunda uygulamalarınızın kritik verilerini kaybetmemesini sağlamanıza yardım ediyor.

Çünkü Kubernetes’te… pod’lar ephemeral

İlginizi çekerse Kubernetes vs Ingress Api yazımı da okuyabilirsiniz.