რა არის Deployment-ები და ReplicaSet-ები და როგორ მუშაობს rolling update-ები და rollback-ები?

Question

IT Interview Practice · Accepted Answer

**Deployment** არის სტანდარტული კონტროლერი stateless აპლიკაციების გასაშვებად. ის მართავს **ReplicaSet-ებს**, ხოლო ReplicaSet მითითებული რაოდენობის იდენტურ Pod-ებს მუშა მდგომარეობაში ინახავს. თქვენ არედაქტირებთ Deployment-ს; ის კი თქვენ ნაცვლად **rolling update-ებსა** და **rollback-ებს** ორკესტრირებს.

## იერარქია

```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      # განახლების დროს არაუმეტეს 1 Pod გამორთული
      maxSurge: 1            # სასურველ რაოდენობაზე ზემოთ არაუმეტეს 1 დამატებითი Pod
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: ვერსიის შეცვლა downtime-ის გარეშე

```bash
kubectl set image deployment/web web=myapp:2.0   # rolling update-ის გაშვება
kubectl rollout status deployment/web            # პროგრესის თვალყურის დევნება
```

```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.
```

## Rollback, როცა გამოშვება ცუდად წავა

```bash
kubectl rollout history deployment/web       # revision-ების ჩამონათვალი
kubectl rollout undo deployment/web          # წინა revision-ზე დაბრუნება
kubectl rollout undo deployment/web --to-revision=3
```

რადგან ძველი ReplicaSet ინახება (0-მდე დაყვანილი), rollback სწრაფია: Kubernetes უბრალოდ წინა ReplicaSet-ს კვლავ ზრდის, ხოლო ახალს ამცირებს.

## მასშტაბირება (scaling)

```bash
kubectl scale deployment/web --replicas=10   # სასურველი რაოდენობის შეცვლა
```

## რატომ არის ეს მნიშვნელოვანი

Deployment-ები არის stateless აპლიკაციების Kubernetes-ზე გაშვების მთავარი სამუშაო იარაღი, ამიტომ მათი და ReplicaSet-ებთან მათი კავშირის გაგება არსებითი, ყოველდღიური ცოდნაა. მთავარი შეხედულება ფენოვნებაშია: თქვენ მართავთ **Deployment**-ს, რომელიც ფლობს **ReplicaSet-ებს** (ვერსიაზე თითო), ხოლო თითოეული ReplicaSet იძლევა გარანტიას, რომ მითითებული რაოდენობის იდენტური Pod-ი მუშაობს — შეჯერების მარყუჟების ჯაჭვი, რომელიც ერთად თვით-აღდგენას და სტაბილურ ასლების რაოდენობას აწვდის. ნამდვილი ძალა იმაშია, თუ როგორ ამუშავებს Deployment ცვლილებას: **rolling update** ქმნის ახალ ReplicaSet-ს და Pod-ებს თანდათან ძველიდან ახალზე გადაიტანს, რასაც `maxSurge` და `maxUnavailable` არეგულირებენ, ასე რომ სიმძლავრე ნარჩუნდება და — readiness probe-ებთან ერთად, რომლებიც განსაზღვრავენ რომელი Pod-ები იღებენ ტრაფიკს — გამოშვება **downtime-ის გარეშე** ხდება. რადგან წინა ReplicaSet ინახება (0-მდე დაყვანილი და არა წაშლილი), **rollback** სწრაფი და უსაფრთხოა: `kubectl rollout undo` უბრალოდ ძველ ვერსიას კვლავ ზრდის, ხოლო ცუდს ამცირებს — სწორედ ის, რასაც მიმართავთ, როცა გამოშვება ცუდად იქცევა. ამ მექანიზმების გაგება — პლუს როგორ მოახდინოთ მასშტაბირება (`kubectl scale`) და შეამოწმოთ პროგრესი (`kubectl rollout status/history`) — ფუნდამენტურია პროგრამული უზრუნველყოფის Kubernetes-ზე უსაფრთხოდ გამოშვებისთვის და ასახავს დეკლარაციულ, კონტროლერით მართულ მოდელს, რომელიც განსაზღვრავს, თუ როგორ ოპერირებს პლატფორმა production-ში.

იერარქია

Deployment-ის manifest

Rolling update: ვერსიის შეცვლა downtime-ის გარეშე

Rollback, როცა გამოშვება ცუდად წავა

მასშტაბირება (scaling)

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები