Deployment கள் மற்றும் ReplicaSet கள் என்ன, மற்றும் rolling update கள் மற்றும் rollback கள் எவ்வாறு செயல்படுகின்றன?

Question

IT Interview Practice · Accepted Answer

ஒரு **Deployment** என்பது stateless app களை இயக்குவதற்கான standard controller. அது **ReplicaSet களை** நிர்வகிக்கிறது, மேலும் ஒரு ReplicaSet குறிப்பிட்ட எண்ணிக்கையிலான ஒரே மாதிரியான Pod களை இயங்க வைக்கிறது. நீங்கள் Deployment ஐ edit செய்கிறீர்கள்; அது உங்களுக்காக **rolling update கள்** மற்றும் **rollback களை** orchestrate செய்கிறது.

## படிநிலை (hierarchy)

```text
Deployment  → declares desired state + update strategy (the thing YOU manage)
   └── ReplicaSet  → ensures N identical Pods exist (one per app version)
          └── Pod  → Pod → Pod ...  (the actual running copies)

On each new version, the Deployment creates a NEW ReplicaSet and shifts Pods over.
```

## ஒரு Deployment manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # at most 1 Pod down during the update
      maxSurge: 1            # at most 1 extra Pod above desired count
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: zero-downtime version மாற்றம்

```bash
kubectl set image deployment/web web=myapp:2.0   # trigger a rolling update
kubectl rollout status deployment/web            # watch progress
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (start: 4 old Pods)
      █████       spin up 1 new (v2), now 5 total (surge)
      ███ █       old down to 3, new is Ready
      ...gradually shift...
  v2: ████        (end: 4 new Pods, old ReplicaSet scaled to 0)
Traffic only goes to Pods that pass their readiness probe → no downtime.
```

## ஒரு release மோசமாகும்போது rollback

```bash
kubectl rollout history deployment/web       # list revisions
kubectl rollout undo deployment/web          # roll back to previous revision
kubectl rollout undo deployment/web --to-revision=3
```

பழைய ReplicaSet வைத்திருக்கப்படுவதால் (0-க்கு scale செய்யப்பட்டது), ஒரு rollback வேகமானது: Kubernetes வெறுமனே முந்தைய ReplicaSet ஐ மீண்டும் scale up செய்து புதியதை scale down செய்கிறது.

## Scaling

```bash
kubectl scale deployment/web --replicas=10   # change desired count
```

## இது ஏன் முக்கியம்

Deployment கள் Kubernetes-இல் stateless application களை இயக்குவதற்கான உழைப்பாளி, எனவே அவற்றையும் ReplicaSet களுடனான அவற்றின் உறவையும் புரிந்துகொள்வது அத்தியாவசியமான, தினசரி அறிவு. அடுக்கமைப்பு (layering) தான் முக்கிய நுண்ணறிவு: நீங்கள் ஒரு **Deployment** ஐ நிர்வகிக்கிறீர்கள், அது **ReplicaSet களை** (version-க்கு ஒன்று) சொந்தமாக்குகிறது, மேலும் ஒவ்வொரு ReplicaSet உம் குறிப்பிட்ட எண்ணிக்கையிலான ஒரே மாதிரியான Pod கள் இயங்குகின்றன என்பதற்கு உத்தரவாதம் அளிக்கிறது — சேர்ந்து self-healing மற்றும் நிலையான replica எண்ணிக்கையை வழங்கும் reconciliation loop களின் ஒரு சங்கிலி. உண்மையான சக்தி Deployment மாற்றத்தை எப்படிக் கையாளுகிறது என்பதில் உள்ளது: ஒரு **rolling update** ஒரு புதிய ReplicaSet ஐ உருவாக்கி, `maxSurge` மற்றும் `maxUnavailable` ஆல் ஆளப்பட்டு Pod களை பழையதிலிருந்து புதியதற்கு படிப்படியாக நகர்த்துகிறது, எனவே capacity பாதுகாக்கப்படுகிறது — மேலும் எந்த Pod கள் traffic ஐப் பெறுகின்றன என்பதைக் கட்டுப்படுத்தும் readiness probe களுடன் இணைந்து — release **zero downtime** உடன் நடக்கிறது. முந்தைய ReplicaSet தக்கவைக்கப்படுவதால் (delete செய்யப்படாமல் பூஜ்ஜியத்திற்கு scale செய்யப்படுகிறது), ஒரு **rollback** வேகமானது மற்றும் பாதுகாப்பானது: `kubectl rollout undo` வெறுமனே பழைய version ஐ மீண்டும் scale up செய்து மோசமானதை scale down செய்கிறது, ஒரு release தவறாக நடந்துகொள்ளும்போது நீங்கள் எட்டுவது இதுதான். இந்த mechanics ஐப் புரிந்துகொள்வது — scale செய்வது (`kubectl scale`) மற்றும் முன்னேற்றத்தை ஆய்வு செய்வது (`kubectl rollout status/history`) எப்படி என்பதுடன் — Kubernetes-இல் software ஐ பாதுகாப்பாக ship செய்வதற்கு அடிப்படை, மேலும் platform production-இல் எவ்வாறு இயங்குகிறது என்பதை வரையறுக்கும் declarative, controller-driven model ஐ பிரதிபலிக்கிறது.

படிநிலை (hierarchy)

ஒரு Deployment manifest

Rolling update: zero-downtime version மாற்றம்

ஒரு release மோசமாகும்போது rollback

Scaling

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்