Deployment & ReplicaSet

Herkese merhaba! Bu dokümanda, mevcut kubernetes ortamımız üzerinde Deployment konusuna değineceğiz. Bununla birlikte deployment ile replica set arasındaki farklara , deployment stratejilerine ve rollut komutlarının da yardımlarıyla sürüm yükseltmesi , sürüm kontrolü kontrolü ve geri alma konularına da göz atacağız.

Kubernetes’e yeni adım atan birçok kişi için Pod kavramı yeterli gibi görünse de, gerçek dünya senaryoları çok daha fazlasını gerektirir. Sadece pod’ların neden yeterli olmadığını biraz açıklayacak olursak,

Podlar:

• Silindiğinde/kapandığında yeniden ayağa kalkmaz (eğer bir controller yoksa)
• Yük altında kapanabilir, yedeği yoktur
• Update sürecini yönetemez (versiyonlama/rollback desteği yoktur)

İşte bu yüzden devreye ReplicaSet ve Deployment girer.

ReplicaSet ve Deployment Farkları

Bu iki tanım yer yer birbiri ile karıştırılabiliyor. Bu ikili birbirlerinden tamamen bağımsız da değildir ama aynı yapı da değildir. farklarından biraz bahsedecek olursak

ReplicaSet: Aynı pod’dan belirli sayıda ayağa kaldırılmasını sağlar. Örneğin 3 kopya istiyorsak, ReplicaSet bu sayıyı her zaman korur.

Deployment: ReplicaSet’in de üzerinde yer alır. Bir veya daha fazla ReplicaSet’i yönetir.

Deployment sayesinde:

• Güncelleme (update)
• Geri alma (rollback)
• Versiyon kontrolü
• Sıfır kesintili geçiş (rolling update)

gibi hayati işlemler yapılabilir.

Özetleyecek olursak : ReplicaSet sadece “kaç adet?” sorusuna cevap verir. Deployment ise “hangi versiyon? nasıl geçilecek? ne zaman dönecek?” gibi sorulara cevap verir.

Gerekli tanımlamaları ve açıklamaları yaptıktan sonra artık ilk deployment’ımızı bu komut ile oluşturabiliriz

kubectl create deployment nginx-deployment --image=nginx:1.21 --replicas=3 --dry-run=client -o yaml > nginx-deploy.yaml

Bu komutu parça parça inceleyecek olursak

kubectl create deployment → Bir deployment oluşturmak için bu komut kullanılır

--image=nginx:1.21 → Burada nginx image’inin belirli bir versiyonunu (1.21) kullanıyoruz. latest gibi dinamik tag’ler belirsiz davranışlara yol açabilir. Örneğin her kubectl apply'da beklenmedik bir güncelleme alabiliriz. Bu sayede sabit bir versiyon kullanmak operasyonel süreçlerde kontrolü tamamen bizde tutar.

--dry-run=client → Kubernetes'e hiçbir şey göndermez, sadece çıktıyı üretir. Gerçek sistemde bir şey oluşturmaz.

Bu komut ile oluşturduğumuz yaml dosyamız bu şekilde olacaktır

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx-deployment
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deployment
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-deployment
    spec:
      containers:
      - image: nginx:1.21
        name: nginx
        resources: {}
status: {}

Buradaki yaml dosyamızı biraz açıklamak gerekirse

metadata.labels: Oluşturulacak deployment’ın label’ıdır. (pod’lardan bağımsızdır. Burada istediğimiz değeri verebiliriz)

metadata.name: Oluşturulacak deployment’ın adıdır

replicas: Kaç tane pod oluşturulacağının tanımıdır.

spec.matchLabels: Bu deployment’ın hangi label'lı pod'ları izleyeceğinin tanımıdır. (Bu tanım template.metadata.labels ile aynı olmalıdır)

template: Pod şablonudur.

template.metadata.labels : oluşturulacak pod’ların label’ıdır. (Bu tanım spec.matchLabels ile aynı olmalıdır)

containers.image: Kullanılacak imaj’ın tanımıdır.

Deployment’ın yaml’ını düzenledikten sonra deployment’ı oluşturmak için kubectl apply komutunu kullanmamız gerekmektedir

kubectl apply -f dosyaadi.yaml

Oluşturduğumuz deployment’ları görüntülemek için ise kubectl get deploy komutunu kullanmamız gerekmektedir

kubectl get deploy

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           5s

Bu komut ile mevcutta çalışan deployment’ları , kaç adet pod’un oluşturulduğunu ve bu podların kaç tanesinin ayakta olduğu gibi bilgileri görebiliriz

Deployment Stratejileri

Kubernetes’te bir uygulamanın yeni versiyonuna geçerken hangi strateji ile geçileceği çok kritiktir. Bu aşamada kullanacağımız strateji; trafik kesintisine tahammül , sahip olduğumuz kaynaklar , hatayla karşılaştığımızda ne kadar hızlı toparlayabileceğimiz gibi birçok etkene bağlı olabilir.

Get Mustafa Bora’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Temelde 5 adet deployment stratejisi mevcuttur. Bunlara biraz daha detaylı değinecek olursak:

1️⃣ Rolling Update (Varsayılan)

• Kubernetes’in varsayılan stratejisidir ve çoğu uygulama için idealdir.
• Yeni sürüm pod’lar kademeli olarak ayağa kalkar.
• Aynı anda eski pod’lar kademeli olarak silinir.
• Kullanıcı açısından kesinti yaşanmaz.
• Her şey otomatik gerçekleştiği için ekstra yönetim gerekmez.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 2
    maxUnavailable: 1

maxSurge → Yeni versiyondan ekstra kaç pod geçici olarak açılabilir.
maxUnavailable → Güncelleme sırasında kaç eski pod devre dışı kalabilir.

2️⃣ Recreate

• En basit ama en riskli stratejidir.
• Tüm eski pod’lar aynı anda silinir.
• Ardından yeni pod’lar başlatılır.
• Kesinti kaçınılmazdır.
• uygulamanın aynı anda iki versiyonunun çalışmasının mümkün olmadığı durumlarda tercih edilebilir.

strategy:
  type: Recreate

3️⃣ Blue/Green

• İki ayrı versiyonun aynı anda sistemde var olmasını sağlar.
• V1 (blue) ve V2 (green) paralel çalışır.
• Yönlendirme servisi/IngreSS ile yapılır.
• Geri dönüş (rollback) sadece trafik yönünü eskiye çevirmek kadar basittir.
• Sıfır kesinti sunar, ama sistem kaynaklarını ikiye katlar.
• Kaynak yoğun bir stratejidir. Üretim ortamında dikkatli planlanmalıdır.

4️⃣ Canary

• Kullanıcı trafiğinin küçük bir kısmı yeni sürüme yönlendirilerek risk azaltılır.
• İlk adımda yeni sürüm sadece %10 kullanıcıya açılır.
• Sistem davranışı ve hatalar gözlemlenir.
• Sorun yoksa %50 → %100 şeklinde trafik artışı yapılır.
• Rollback hızlıdır çünkü eski sürüm zaten aktif olarak sistemdedir.
• Bu strateji gerçek trafik yönlendirme gerektirir. Servis veya Ingress seviyesinde ayarlama yapmak gerekir.

5️⃣ A/B Testing (Paralel Versiyon Karşılaştırma)

• Aynı anda birden fazla versiyon yayındadır (örneğin A ve B).
• Kullanıcılar farklı versiyonlara yönlendirilir (IP, cookie, header).
• Amaç: Hangi versiyonun kullanıcılar tarafından daha çok tercih edildiğini ölçmek.
• Yönlendirme genellikle Ingress Controller (NGINX, Istio) üzerinden yapılır.
• Trafik yüzdesi değil, kullanıcı kimliği baz alınır.

Deployment stratejileri arasında A/B ile canary stratejileri yer yer karıştırılabilir. Aralarındaki farkı şu şekilde özetleyebiliriz:

A/B Testing, farklı kullanıcı gruplarına aynı anda farklı uygulama versiyonları sunarak hangisinin daha etkili olduğunu anlamaya çalışır. Canary Deployment ise yeni versiyonu kademeli şekilde herkese yaymadan önce küçük bir kullanıcı kitlesi üzerinde denemeyi hedefler. Yani canary daha çok “bu versiyon sorun çıkarıyor mu?” sorusunu yanıtlamaya çalışırken, A/B “hangisi daha iyi çalışıyor?” sorusuna odaklanır.

Rolling update kullanarak sürüm güncelleme ve geri alma

Bu örneğimizde yukarıda gördüğümüz deployment stratejilerinden rolling update’i kullanarak pod’larımızın nginx sürümlerini güncelleyeceğiz ve sonrasında eski sürüme geri alacağız. Bu işlem için deployment oluştururken yarattığımız yaml dosyasına strategy: bloğu eklememiz gerekmektedir.

strategy: alanı sadece pod'ların nasıl güncelleneceğini belirler. RollingUpdate ve Recreate bu yüzden doğrudan YAML'da tanımlanabilir. Ancak Blue/Green, Canary ve A/B testing gibi stratejilerde asıl odak, güncellenmiş pod'lara trafiğin nasıl yönlendirileceği olduğu için bu kontrol YAML’dan değil, servis veya ingress yapılandırmasından yapılır. Bu yüzden bu üç strateji genellikle manuel olarak uygulanır.

Rolling update’in deployment’ın yaml’ına eklenmesi bu şekildedir:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx-deployment
  name: nginx-deployment
spec:
  replicas: 3
# Rolling update
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
# Rolling update
  selector:
    matchLabels:
      app: nginx-deployment
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-deployment
    spec:
      containers:
      - image: nginx:1.21
        name: nginx
        resources: {}
status: {}

Yaptığımız değişikliğin uygulanması için apply komutunu tekrardan çalıştırmamız gerekmektedir.

kubectl apply -f dosyaadi.yaml

strategy bloğunu ekledikten sonra image versiyon yükseltme işlemine başlayabiliriz.

Podlarımızın image’larını set imagekomutu ile güncelliyoruz

kubectl set image deployment/nginx-deployment nginx=nginx:1.25 --record

rollout statuskomutu ile rollout durumunu kontrol edebiliriz

kubectl rollout status deployment/nginx-deployment

deployment "nginx-deployment" successfully rolled out

Geçmiş işlemleri görmek için rollout historykomutunu kullanırız

kubectl rollout history deployment/nginx-deployment

kubectl set image deployment/nginx-deployment nginx=nginx:1.25 --record=true

Bu süreçte kubectl describe podkomutu ile pod’ların image bilgileri de kontrol edilebilir

kubectl describe pod podadi | grep "Image:"

Image:          nginx:1.25

Yapılan değişikliği geri almak için rollout undokomutunu kullanırız

kubectl rollout undo deployment/nginx-deployment

Bu bölümde yalnızca bir Deployment nesnesi oluşturmakla kalmadık; Kubernetes dünyasında uygulama güncellemelerinin nasıl kontrollü, kesintisiz ve geri alınabilir şekilde yönetildiğini de tüm boyutlarıyla ele aldık. ReplicaSet ve Deployment farklarını netleştirdik, rollout stratejilerini teoriden pratiğe taşıdık, farklı geçiş senaryolarını (Rolling Update, Recreate, Blue/Green, Canary, A/B) hem teknik hem operasyonel açıdan değerlendirdik. Son olarak, kubectl üzerinden versiyon yükseltme ve rollback süreçlerini adım adım uygulayarak güncelleme güvenliği kavramını pekiştirdik.

Vakit ayırıp okuduğunuz için teşekkürler. Bu dokümanın Kubernetes’e giriş sürecinizde katkı sağlamasını umuyorum. Bir sonraki modülde görüşmek üzere!