Longhorn: Kubernetes Ortamları İçin Devrimsel Depolama Çözümü

Yol haritasının 7. başlığı depolamaydı; bu yazı onun uygulamalı kısmı. Kümeyi kurduğumuz yazıda argo-cp01, argo-w01 ve argo-w02 düğümlerinden oluşan üç düğümlü bir küme ayağa kaldırmıştık — Longhorn’u onun üzerine kuracağız.

Bir pod’u öldürüp yeniden başlattığınızda Kubernetes onu başka bir düğüme yerleştirebilir. Uygulama sorunsuz açılır, sağlık kontrolünden geçer — ama veritabanı boştur. Kubernetes’in en sık yeni gelenleri şaşırtan davranışı budur: zamanlayıcı pod’u taşır, veriyi taşımaz.

Bu yazıda o boşluğu Longhorn’un nasıl kapattığını göreceğiz: kurulumdaki tek gerçek ön koşulu, ilk PVC’yi ve üç düğümlü bir kümede neredeyse herkesin düştüğü kopya sayısı tuzağını.

Komutlar gerçektir; düğüm adları ve adresler kurgusal lab ortamına aittir. Sürüm olarak Longhorn v1.9.1, küme v1.33.4 kullanılmıştır.

Sorun: Pod Taşınınca Veri Taşınmaz

Bir pod’a disk vermenin en kolay yolu emptyDir‘dir ve tam olarak adının söylediği şeyi yapar: pod silindiğinde dizin de silinir. Bir adım ötesi hostPath‘tir — düğümün diskindeki bir yolu pod’a bağlar. Veri pod’dan uzun yaşar, ama düğüme çivilenmiştir: pod argo-w02‘ye zamanlanırsa argo-w01‘de bıraktığı veriye ulaşamaz.

Kubernetes bu yüzden depolamayı pod’dan ayırır:

• PersistentVolume (PV) — kümedeki gerçek depolama birimi.
• PersistentVolumeClaim (PVC) — uygulamanın “şu boyutta, şu erişim modunda bir disk istiyorum” talebi.
• StorageClass — talebi karşılayacak birimi kim ve nasıl üretecek. Dinamik sağlama budur: PVC yazarsınız, PV’yi sürücü kendisi oluşturur.

Eksik parça StorageClass’ın arkasındaki sürücüdür. Bulutta bunu sağlayıcı verir (EBS, Persistent Disk). Kendi donanımınızda ya bir SAN/NAS bağlarsınız ya da düğümlerin kendi disklerini kümeye depolama olarak sunan bir çözüm kurarsınız. Longhorn ikincisidir.

Longhorn Ne Yapıyor: Düğüm Disklerinden Dağıtık Blok Depolama

Longhorn, düğümlerin yerel disklerini toplayıp Kubernetes’e blok depolama olarak sunan, CNCF’in incubating seviyesindeki bir projesidir (Rancher tarafından başlatıldı, bugün SUSE tarafından sürdürülüyor). Ayrı bir depolama sunucusu gerektirmediği için homelab ve küçük kümelerdeki asıl çekiciliği budur.

Çalışma mantığı üç parçadır:

• Engine — her birim için ayrı çalışan, o birimin okuma/yazmasını yöneten süreç. Longhorn’un “her birime kendi denetleyicisi” tasarımı, tek bir merkezi depolama sürecinin tüm kümeyi etkilemesini önler.
• Replica — birimin bir düğüm diskindeki fiziksel kopyası. Varsayılan olarak üç kopya tutulur ve kopyalar farklı düğümlere dağıtılır.
• Manager — her düğümde bir DaemonSet olarak çalışır, birimleri ve kopyaları yönetir.

Veri düğümlerde varsayılan olarak /var/lib/longhorn altında durur. Bir düğüm kaybedildiğinde pod, kalan kopyalardan biri üzerinden çalışmaya devam eder ve Longhorn eksilen kopyayı başka bir düğümde yeniden üretir.

Kurmadan Önce: open-iscsi Her Düğümde Olmalı

Longhorn birimi pod’a bir iSCSI aygıtı olarak bağlar. Bu yüzden her düğümde iSCSI initiator’ının kurulu ve çalışıyor olması gerekir. Kurulumun en sık burada takıldığını söylemek abartı değil — eksikse Longhorn kurulur, arayüz açılır, ama her pod MountVolume.SetUp failed ile ContainerCreating durumunda asılı kalır.

# Debian / Ubuntu — her düğümde
sudo apt-get install -y open-iscsi
sudo systemctl enable --now iscsid
sudo modprobe iscsi_tcp

# RHEL / Rocky / AlmaLinux
sudo yum install -y iscsi-initiator-utils

Doğrulama, kurulumdan önce yapılır:

systemctl is-active iscsid    # active
lsmod | grep iscsi_tcp        # modül yüklü mü

RWX (ReadWriteMany) birim kullanacaksanız ayrıca NFS istemcisi gerekir; Longhorn bu tür birimleri bir share-manager pod’u üzerinden NFS ile paylaştırır:

sudo apt-get install -y nfs-common     # RHEL ailesinde: nfs-utils

Kurulum ve İlk PVC

Helm ile kurulum tek komuttur:

helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system --create-namespace \
  --version 1.9.1

Kurulum bittiğinde longhorn adında bir StorageClass gelir:

kubectl get storageclass
# NAME       PROVISIONER          RECLAIMPOLICY   ALLOWVOLUMEEXPANSION
# longhorn   driver.longhorn.io   Delete          true

Üç ayrıntı burada okunur: sürücü driver.longhorn.io, geri kazanım politikası Delete (PVC silinince birim de silinir) ve birim genişletmeye izin var. Varsayılan kopya sayısı ise sınıfın parametrelerindedir:

kubectl get storageclass longhorn -o jsonpath='{.parameters}'
# {"fromBackup":"","numberOfReplicas":"3","staleReplicaTimeout":"30"}

Artık bir PVC yazıp bağlayabiliriz:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: veri-pvc
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: longhorn
  resources:
    requests:
      storage: 2Gi

kubectl apply -f veri-pvc.yaml
kubectl get pvc veri-pvc
# NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS
# veri-pvc   Bound    pvc-3f8a1c22-9d47-4e6b-b0a5-7c21e4d95f38   2Gi        RWO            longhorn

Bound görüyorsanız dinamik sağlama çalıştı: siz yalnızca talebi yazdınız, PV’yi Longhorn üretti.

Üç Düğümlü Kümede Kopya Sayısı Tuzağı

Yukarıdaki PVC Bound oldu, pod çalışıyor, her şey yolunda görünüyor. Ama Longhorn arayüzünde birimin durumu Degraded ve öyle kalıyor:

kubectl -n longhorn-system get volumes.longhorn.io
# NAME                                       STATE      ROBUSTNESS   SCHEDULED   SIZE
# pvc-3f8a1c22-9d47-4e6b-b0a5-7c21e4d95f38   attached   degraded     False       2147483648

Sebep aritmetiktir. StorageClass üç kopya istiyor, kopyalar varsayılan olarak farklı düğümlere yerleşmek zorunda (replicaSoftAntiAffinity kapalı) ve kümemizde kopya alabilecek iki düğüm var: argo-w01 ve argo-w02. Kubeadm ile kurulan argo-cp01 üzerinde control-plane taint’i durduğu için oraya yerleşilemiyor. Üçüncü kopya hiçbir zaman zamanlanamaz, birim de hiçbir zaman healthy olmaz.

Bu bir uyarı değil, kalıcı bir durumdur — ve tehlikeli yanı çalışıyor görünmesidir: uygulama sorunsuz okur yazar, siz üç kopyanız olduğunu sanırsınız, gerçekte ikisi vardır.

İki çözümü var. Birincisi kümeye uygun bir StorageClass tanımlamak:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-2kopya
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
parameters:
  numberOfReplicas: "2"
  staleReplicaTimeout: "30"

İkincisi kopya alabilecek üçüncü bir düğüm eklemek. kubectl get nodes çıktısındaki düğüm sayısı değil, o düğümlerden kaçının taint’siz olduğu belirleyicidir.

Kopya sayısını düğüm sayısına göre seçin, tersini değil. Üç kopya iyi bir varsayılandır ama üç schedulable düğüm ister; iki düğümlü bir kümede numberOfReplicas: "2" doğru cevaptır.

Snapshot Yedekleme Değildir

Longhorn iki ayrı şey sunar ve isimleri benzediği için karıştırılır:

• Snapshot — birimin belirli bir andaki hâli, aynı disklerde, kopyaların yanında durur. Anlıktır ve ucuzdur, ama disk ya da düğüm kaybında snapshot da gider.
• Backup — snapshot’ın küme dışındaki bir hedefe (S3 uyumlu depolama ya da NFS paylaşımı) kopyalanmış hâli. Yedekleme dediğimiz şey budur ve ayrıca yapılandırılması gerekir: Longhorn ayarlarındaki backupTarget alanı boş bırakıldığı sürece hiçbir yedek alınmaz.

Replikasyon da yedekleme değildir: kopyalar donanım arızasına karşıdır, DROP TABLE‘a karşı değil. Yanlışlıkla silinen veri üç kopyanın üçünden birden silinir. Ayrımın ayrıntısı veri merkezi yedekliliği yazısında.

Sonuç

• Longhorn kalıcı depolamayı kümenin içine taşır. Ayrı bir SAN ya da NAS olmadan, düğümlerin kendi diskleriyle blok depolama sunar; homelab ve küçük kümelerdeki asıl çekiciliği budur.
• Replikasyon yedekleme değildir. Düğüm arızasına karşı tutulan kopyalar, yanlışlıkla silinen bir veriyi geri getirmez; snapshot ve dış hedefe yedekleme ayrıca yapılandırılır — ayrımın ayrıntısı veri merkezi yedekliliği yazısında.
• Kopya sayısı düğüm sayısından bağımsız değildir. Üç kopya isteyip iki düğüm çalıştırırsanız birim hiçbir zaman tam sağlıklı duruma gelmez, sürekli Degraded kalır.

Serinin tamamı için Kubernetes Öğrenme Yolculuğu sayfasına bakabilirsiniz.