Deployment ve ReplicaSet: Kubernetes'te Uygulamayı Ayakta Tutan İkili

Deployment ve ReplicaSet nedir?

Deployment, bir uygulamayı Kubernetes kümesinde nasıl çalıştırmak istediğinizi bildirimsel olarak yazdığınız nesnedir. İçinde Pod şablonu (hangi konteyner imajı, hangi portlar, hangi ortam değişkenleri), istenen kopya sayısı ve güncelleme stratejisi yer alır. Siz "istediğim durum bu" dersiniz, Kubernetes mevcut durumu bu hedefe yaklaştırmak için sürekli çalışır.

ReplicaSet ise daha alt düzeyde bir denetleyicidir. Tek görevi, etiket seçicisine uyan Pod'ların sayısını istenen değerde tutmaktır. Bir Pod çökerse ya da düğüm kaybolursa yenisini oluşturur, fazla Pod varsa fazlalığı siler. ReplicaSet kendi başına sürüm geçişi bilmez; imajı değiştirdiğinizde ne yapacağını bilen katman Deployment'tır.

Birlikte nasıl çalışırlar?

Zincir şöyle işler: Deployment bir ReplicaSet oluşturur, ReplicaSet de Pod'ları oluşturur. Deployment'taki Pod şablonu değiştiğinde (örneğin yeni bir imaj etiketi yazıldığında) Deployment yeni bir ReplicaSet açar ve eskisini kademeli olarak küçültürken yenisini büyütür. Her ReplicaSet, şablonun özetinden türetilen bir etiketle (pod-template-hash) kendi Pod'larını ayırt eder; böylece eski ve yeni sürümün Pod'ları karışmaz.

Bu mantığın temelinde uzlaştırma döngüsü (reconciliation loop) vardır. Denetleyici istenen durumla gerçek durumu karşılaştırır, fark varsa düzeltir. Bu yüzden bir Pod'u elle silseniz bile ReplicaSet kısa sürede yerine yenisini koyar. Eski ReplicaSet'ler sıfır kopyayla saklanır; bu kayıtlar geri alma işleminin dayanağıdır.

Küçük bir örnek: web uygulamasını güncelleme

Örneğin bir sipariş arayüzünü çalıştıran Deployment'ınız var ve yeni sürümü yayınlayacaksınız. Komut satırından kubectl set image ile imaj etiketini değiştirirsiniz. Kubernetes yeni bir ReplicaSet oluşturur, yeni Pod'lar hazır duruma geldikçe eski Pod'ları kapatır. İlerlemeyi kubectl rollout status deployment/siparis-arayuzu komutuyla izlersiniz.

Yeni sürümde hata çıkarsa kubectl rollout undo deployment/siparis-arayuzu komutu bir önceki ReplicaSet'e döner. Kopya sayısını değiştirmek için kubectl scale kullanılır ya da manifestteki replicas alanı güncellenir. Güncelleme geçmişi kubectl rollout history ile listelenir.

Güncelleme stratejileri: RollingUpdate ve Recreate

Varsayılan strateji RollingUpdate'tir. Eski Pod'lar yeni Pod'larla kademeli değiştirilir ve uygulama kesintisiz kalmaya çalışır. Şu ayarlar davranışı belirler: maxSurge, istenen kopya sayısının üzerinde geçici olarak kaç ek Pod açılabileceğini; maxUnavailable ise güncelleme sırasında kaç Pod'un hizmet dışı kalabileceğini söyler. Her ikisi de mutlak sayı ya da oran olarak verilebilir.

Recreate stratejisi önce tüm eski Pod'ları kapatır, sonra yenilerini açar. Kısa bir kesinti oluşur; ancak aynı anda eski ve yeni sürümün birlikte çalışmaması gereken durumlarda (örneğin veri şemasını uyumsuz biçimde değiştiren uygulamalarda) tercih edilir. Kademeli güncellemenin güvenli olması için konteynere readiness probe tanımlamak şarttır; probe yoksa Kubernetes henüz isteklere hazır olmayan Pod'u hazır sayabilir.

ReplicaSet'i neden doğrudan kullanmayız?

ReplicaSet'i elle oluşturmak mümkündür, ancak sürüm geçişi, geri alma ve güncelleme geçmişi sunmaz. Bu nedenle uygulamada neredeyse her zaman Deployment yazılır ve ReplicaSet'ler arka planda otomatik yönetilir.

Her iş yükü Deployment'a uymaz. Kimliği ve kalıcı diski olması gereken veritabanı benzeri uygulamalar için StatefulSet, her düğümde bir kopya çalışması gereken ajanlar için DaemonSet, bir kez çalışıp biten işler için Job kullanılır. Deployment, durumsuz (stateless) uygulamaların varsayılan seçimidir.

Sık yapılan hatalar

• Selector ile Pod şablonundaki etiketlerin uyuşmaması: Deployment seçicisi şablon etiketleriyle eşleşmezse nesne oluşturulamaz. Seçici alanı sonradan değiştirilemez, bu yüzden baştan dikkatli yazılmalıdır.
• latest imaj etiketi kullanmak: Hangi sürümün çalıştığını izlemek ve geri dönmek zorlaşır. Sürüme özgü etiket kullanın.
• Readiness probe yazmamak: Kademeli güncelleme hazır olmayan Pod'a trafik gönderebilir.
• Kaynak istekleri ve sınırlarını tanımlamamak: Pod'lar düğümde kaynak çekişmesine girer.
• Otomatik ölçekleyici varken manifestte sabit kopya sayısı tutmak: Manifestteki sabit değer, ölçekleyicinin kararını her uygulamada ezebilir.

Beklediğiniz Pod'lar gelmiyorsa kubectl describe deployment ve kubectl describe replicaset çıktıları, olaylar (events) bölümünde nedeni gösterir.

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

Konteyner Orkestrasyonu ile Kubernetes (CKAD Hazırlık) programındaki "Deployment ve Güncelleme Stratejileri" modülü, uygulama geliştiricilerin kendi servislerini kümeye nasıl dağıtacağını ve güncelleyeceğini ele alır. Kubernetes ile Orkestrasyon programının "İş Yükü Kaynakları" ve "Ölçekleme ve Kaynak Yönetimi" modülleri aynı nesneleri işletme tarafından işler.

Kurumsal ekipler açısından en çok yazılım geliştirme, DevOps ve platform ekipleri bu konudan yararlanır: geliştirici sürüm yayınını kendisi güvenle yapabilir, operasyon tarafı geri alma ve ölçekleme süreçlerini ortak bir dille tanımlar.