StatefulSet ile Kubernetes'te veritabanı ve durumlu uygulama çalıştırma

Durumlu uygulama neden ayrı bir iş yüküdür?

Bir Deployment'ın pod'ları birbirinin yerine geçer: biri silinirse yenisi başka bir adla ve başka bir düğümde gelir, kimse farkı anlamaz. Web ön yüzü ve durumsuz API'ler için bu mükemmel bir modeldir. Veritabanı, mesaj kuyruğu ya da dağıtık bir depolama kümesi gibi uygulamalar için ise yetersizdir; çünkü bu uygulamalarda her örneğin kimliği, kendi verisi ve diğer örneklerle ilişkisi vardır. Her örnek aynı şey değildir; biri lider, diğeri takipçi olabilir.

StatefulSet, bu ihtiyaç için tasarlanmış denetleyicidir. Resmî belgenin ifadesiyle, bir grup pod'u çalıştırır ve her birine kalıcı bir kimlik sağlar. Pod'lar aynı şablondan üretilir ama birbirinin yerine geçmez; her biri yeniden zamanlansa bile kimliğini korur. Belge kullanım nedenlerini şöyle sıralar: kararlı ve benzersiz ağ kimliği, kararlı kalıcı depolama, sıralı ve düzenli dağıtım ile ölçekleme, sıralı otomatik güncelleme.

StatefulSet'in verdiği güvenceler

Kimlik. StatefulSet pod'ları adlarına sıra numarası eklenerek oluşturulur; örneğin veritabani-0, veritabani-1. Pod silinse de yeniden aynı adla gelir. Bu ad, uygulamanın yapılandırmasında güvenle kullanılabilir.

Ağ adı. StatefulSet, pod'ların ağ kimliğinden sorumlu bir headless Service'e ihtiyaç duyar ve belge bu Service'i sizin oluşturmanız gerektiğini belirtir. Headless Service, clusterIP alanı None olan Service'tir; tek bir sanal adres yerine her pod için ayrı bir DNS kaydı sunar. Böylece küme üyeleri birbirine kararlı adlarla ulaşabilir.

Depolama. volumeClaimTemplates alanı, her pod için ayrı bir PersistentVolumeClaim oluşturur. Pod yeniden zamanlandığında aynı talep ona yeniden bağlanır; veri pod'la birlikte yok olmaz. Belgeye göre bu, ilgili StorageClass dinamik provizyon için yapılandırılmışsa ya da kümede uygun bir PersistentVolume zaten varsa çalışır.

Sıra. Varsayılan olarak pod'lar sırayla oluşturulur ve bir sonraki, öncekinin hazır olmasını bekler. Bu, lider seçimi ya da küme kurulumu gibi sıralı başlatma gerektiren uygulamalar için doğal bir davranıştır.

Adım adım: minimal bir StatefulSet kurmak

Önce headless Service tanımlanır, sonra StatefulSet yazılır. Aşağıdaki örnek kurguseldir ve uygulama ayrıntıları size göre değişir:

apiVersion: v1 kind: Service metadata: name: veritabani spec: clusterIP: None selector: app: veritabani ports: - name: sorgu port: <uygulama-portu> --- apiVersion: apps/v1 kind: StatefulSet metadata: name: veritabani spec: serviceName: veritabani selector: matchLabels: app: veritabani template: metadata: labels: app: veritabani spec: containers: - name: sunucu image: kayit.ornek.com/veritabani:etiket ports: - name: sorgu containerPort: <uygulama-portu> volumeMounts: - name: veri mountPath: /var/lib/veri volumeClaimTemplates: - metadata: name: veri spec: accessModes: ["ReadWriteOnce"] storageClassName: <sınıf-adı> resources: requests: storage: <boyut>

Kurallar: selector alanı, şablondaki etiketlerle eşleşmelidir; belge eşleşmezse doğrulama hatası alacağınızı belirtir. serviceName, oluşturduğunuz headless Service'in adıdır. Replika sayısı belirtilmezse varsayılan değer kullanılır. Kurulumdan sonra kubectl get pods komutu pod'ların sırayla geldiğini gösterir; kubectl get pvc ile her pod için ayrı talep oluştuğunu görürsünüz.

Pod'lara kararlı adlarıyla ulaşım şu biçimdedir: pod adı, Service adı ve ad alanından oluşan bir DNS adı. Uygulamanızın üyelik listesini bu adlarla yapılandırın.

Silme, ölçekleme ve güncelleme davranışı

StatefulSet'in en çok yanlış anlaşılan yönü silme davranışıdır. Belgeye göre bir StatefulSet'i silmek ya da küçültmek, ona bağlı hacimleri silmez; bu, veri güvenliğinin otomatik temizlikten genellikle daha değerli olduğu düşünülerek yapılır. Yani kaynak silinse bile PersistentVolumeClaim'ler kalır. Gereksiz hacim maliyeti bırakmamak için bunların bilinçli olarak temizlenmesi gerekir; yanlış temizlik de veri kaybıdır, bu yüzden dikkatli olun.

Ayrıca belge, StatefulSet silindiğinde pod'ların sonlandırılması konusunda söz vermediğini söyler. Düzenli ve sıralı kapanış istiyorsanız, silmeden önce StatefulSet'i sıfır replikaya küçültmeniz önerilir.

Güncellemede varsayılan pod yönetim politikasıyla sıralı güncelleme sırasında bozuk bir duruma düşmek mümkündür ve bu durumda elle müdahale gerekebilir; belge bunu açıkça uyarır. Yani Deployment'taki gibi "yanlış sürüm yayınladım, geri alırım" rahatlığı StatefulSet'te yoktur. Büyük değişiklikleri önce test kümesinde deneyin, yedeğinizi alın ve kademeli güncelleme seçeneklerini (bölümlü güncelleme gibi) belgeden inceleyin.

Veritabanını Kubernetes'te çalıştırmak her zaman iyi fikir mi?

StatefulSet bir veritabanını çalıştırmak için gereken altyapıyı sağlar, ama veritabanını yönetmeyi sağlamaz. Üretim kalitesinde bir veritabanı için yedekleme ve geri yükleme, yük devretme, sürüm yükseltme, yapılandırma yönetimi ve izleme gerekir. Düz bir StatefulSet bunların hiçbirini sizin yerinize yapmaz.

Bu işleri üstlenen yaklaşımlar vardır: veritabanı sağlayıcılarının operatörleri bu yaşam döngüsünü otomatikleştirir ve StatefulSet'i kendileri yönetir. Ya da veritabanını kümenin dışında, yönetilen bir hizmet olarak çalıştırır ve uygulamaları ona bağlarsınız. Karar için şunları tartın: ekibinizde veritabanı operasyon deneyimi var mı, kurtarma hedefleriniz nelerdir, depolama katmanı güvenilir ve yeterince hızlı mı, kümede ağ ve depolama arızasına nasıl dayanılıyor?

Geliştirme, test ve çok kopyalı tolerans gösteren uygulamalar için StatefulSet pratik ve yeterlidir. Kritik tek kaynak veriyi barındıran bir veritabanı için ise operatör ya da yönetilen hizmet çoğu zaman daha güvenli bir seçimdir. Bu bir yasak değil, bir risk dengesidir.

Sık hatalar ve kontrol listesi

• Headless Service'i unutmak: serviceName tanımlı olsa bile Service yoksa pod kimlikleri çözümlenmez.
• Etiket uyumsuzluğu: selector ile şablon etiketleri farklıysa nesne reddedilir.
• Depolama sınıfını doğrulamamak: Dinamik provizyon yapılandırılmamışsa PVC bekleyen durumda kalır ve pod hiç başlamaz.
• Silince verinin de gittiğini sanmak ya da tersi: Hacimler kalır; siz temizlemedikçe maliyet sürer, yanlış silerseniz veri kaybolur.
• Tek bölgede kalmak: Depolama ve pod'lar aynı bölgeye bağlıysa o bölgenin kaybı kümeyi durdurur. Dağıtım ve yedekleme planı yapın.
• Yedeksiz çalışmak: StatefulSet yedek değildir. Hacim anlık görüntüsü ya da uygulama düzeyi yedek şarttır.
• Hazır olma kontrolünü atlamak: Sıralı başlatma, bir önceki pod'un hazır olmasına bağlıdır; readiness probe doğru değilse sıra tıkanır.

Kontrol listesi: headless Service var mı, depolama sınıfı doğrulandı mı, readiness probe uygulamanın gerçek hazır olma durumunu yansıtıyor mu, yedek ve geri yükleme denendi mi, silme ve küçültme prosedürü yazıldı mı, güncelleme önce test ortamında denendi mi?

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

Durumlu iş yükleri, ağ ve depolama bilgisini birlikte gerektirir. Mindset kataloğundaki "Kubernetes Ağ ve Depolama Yönetimi" programı, "Depolama Temelleri ve Kalıcı Hacimler", "Durumlu İş Yükleri" ve "Yedekleme, Kurtarma ve İşletim" modülleriyle bu konunun merkezindedir; veri hizmetlerini kümede işletecek platform ve veri mühendisleri için uygundur. "Kubernetes ile Orkestrasyon" programındaki "Depolama ve Kalıcılık" modülü ise temel kavramları verir ve konuya sıfırdan giren ekipler için başlangıç noktası olabilir.