Deployment ve ReplicaSet nedir ve rolling update ile rollback nasıl çalışır?

Question

IT Interview Practice · Accepted Answer

Bir **Deployment**, stateless uygulamaları çalıştırmak için standart controller'dır. **ReplicaSet**'leri yönetir ve bir ReplicaSet, belirtilen sayıda birbirinin aynı Pod'u çalışır tutar. Siz Deployment'ı düzenlersiniz; o sizin için **rolling update**'leri ve **rollback**'leri düzenler.

## Hiyerarşi

```text
Deployment  → arzu edilen durumu + güncelleme stratejisini bildirir (SİZİN yönettiğiniz şey)
   └── ReplicaSet  → N tane aynı Pod'un var olmasını sağlar (her app sürümü için bir tane)
          └── Pod  → Pod → Pod ...  (gerçek çalışan kopyalar)

Her yeni sürümde, Deployment YENİ bir ReplicaSet oluşturur ve Pod'ları ona kaydırır.
```

## Bir Deployment manifest'i

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # güncelleme sırasında en fazla 1 Pod kapalı
      maxSurge: 1            # istenen sayının üstünde en fazla 1 fazladan Pod
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: sıfır kesintili sürüm değişikliği

```bash
kubectl set image deployment/web web=myapp:2.0   # bir rolling update tetikle
kubectl rollout status deployment/web            # ilerlemeyi izle
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (başlangıç: 4 eski Pod)
      █████       1 yeni (v2) başlat, şimdi toplam 5 (surge)
      ███ █       eski 3'e düşer, yeni Ready oldu
      ...kademeli kaydır...
  v2: ████        (bitiş: 4 yeni Pod, eski ReplicaSet 0'a ölçeklendi)
Trafik yalnızca readiness probe'unu geçen Pod'lara gider → kesinti yok.
```

## Bir sürüm bozulduğunda rollback

```bash
kubectl rollout history deployment/web       # revision'ları listele
kubectl rollout undo deployment/web          # önceki revision'a geri dön
kubectl rollout undo deployment/web --to-revision=3
```

Eski ReplicaSet korunduğu için (0'a ölçeklenir), rollback hızlıdır: Kubernetes sadece önceki ReplicaSet'i tekrar yukarı, yenisini aşağı ölçekler.

## Ölçekleme (scaling)

```bash
kubectl scale deployment/web --replicas=10   # istenen sayıyı değiştir
```

## Neden önemli

Deployment'lar, Kubernetes'te stateless uygulamalar çalıştırmanın beygir gücüdür; bu yüzden onları ve ReplicaSet'lerle ilişkilerini anlamak elzem, günlük bir bilgidir. Katmanlama, kilit içgörüdür: siz bir **Deployment** yönetirsiniz, o **ReplicaSet**'lere sahiptir (her sürüm için bir tane) ve her ReplicaSet belirtilen sayıda aynı Pod'un çalışmasını garanti eder — birlikte kendini iyileştirme ve kararlı bir replica sayısı sağlayan bir uzlaştırma döngüleri zinciri. Asıl güç, Deployment'ın değişimi nasıl ele aldığındadır: bir **rolling update** yeni bir ReplicaSet oluşturur ve Pod'ları eskiden yeniye `maxSurge` ve `maxUnavailable` tarafından yönetilerek kademeli olarak kaydırır; böylece kapasite korunur ve — hangi Pod'ların trafik alacağını denetleyen readiness probe'larla birleşince — sürüm **sıfır kesinti** ile gerçekleşir. Önceki ReplicaSet korunduğu için (silinmek yerine sıfıra ölçeklenir), bir **rollback** hızlı ve güvenlidir: `kubectl rollout undo` basitçe eski sürümü tekrar yukarı, bozuk olanı aşağı ölçekler; bir sürüm hata yaptığında tam da başvuracağınız şeydir. Bu mekanikleri anlamak — artı nasıl ölçekleneceğini (`kubectl scale`) ve ilerlemeyi nasıl inceleyeceğinizi (`kubectl rollout status/history`) — Kubernetes'te yazılımı güvenle yayınlamanın temelidir ve platformun production'da nasıl çalıştığını tanımlayan bildirimsel, controller güdümlü modeli yansıtır.

Hiyerarşi

Bir Deployment manifest'i

Rolling update: sıfır kesintili sürüm değişikliği

Bir sürüm bozulduğunda rollback

Ölçekleme (scaling)

Neden önemli

İlgili sorular