Deployment và ReplicaSet là gì, và rolling update cùng rollback hoạt động ra sao?

Question

IT Interview Practice · Accepted Answer

**Deployment** là controller tiêu chuẩn để chạy các ứng dụng stateless. Nó quản lý các **ReplicaSet**, và một ReplicaSet giữ cho một số lượng Pod giống hệt nhau luôn chạy. Bạn chỉnh sửa Deployment; nó điều phối **rolling update** và **rollback** giúp bạn.

## Hệ thống phân cấp

```text
Deployment  → khai báo trạng thái mong muốn + chiến lược cập nhật (thứ BẠN quản lý)
   └── ReplicaSet  → đảm bảo tồn tại N Pod giống hệt nhau (mỗi phiên bản một cái)
          └── Pod  → Pod → Pod ...  (các bản chạy thật sự)

Mỗi phiên bản mới, Deployment tạo một ReplicaSet MỚI và chuyển dần Pod sang đó.
```

## Manifest của Deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # tối đa 1 Pod ngưng trong lúc cập nhật
      maxSurge: 1            # tối đa 1 Pod dôi ra so với số mong muốn
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: đổi phiên bản không downtime

```bash
kubectl set image deployment/web web=myapp:2.0   # kích hoạt rolling update
kubectl rollout status deployment/web            # theo dõi tiến trình
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (bắt đầu: 4 Pod cũ)
      █████       khởi động 1 Pod mới (v2), giờ tổng 5 (surge)
      ███ █       Pod cũ giảm còn 3, Pod mới đã Ready
      ...chuyển dần...
  v2: ████        (kết thúc: 4 Pod mới, ReplicaSet cũ giảm về 0)
Lưu lượng chỉ đến Pod nào vượt qua readiness probe → không downtime.
```

## Rollback khi một bản phát hành lỗi

```bash
kubectl rollout history deployment/web       # liệt kê các revision
kubectl rollout undo deployment/web          # quay về revision trước đó
kubectl rollout undo deployment/web --to-revision=3
```

Vì ReplicaSet cũ vẫn được giữ lại (giảm về 0), rollback rất nhanh: Kubernetes chỉ việc scale ReplicaSet trước đó lên lại và cái mới xuống.

## Mở rộng (scaling)

```bash
kubectl scale deployment/web --replicas=10   # đổi số lượng mong muốn
```

## Tại sao điều này quan trọng

Deployment là "cỗ máy chủ lực" để chạy ứng dụng stateless trên Kubernetes, nên hiểu nó và mối quan hệ với ReplicaSet là kiến thức thiết yếu, dùng hằng ngày. Sự phân tầng là điểm mấu chốt: bạn quản lý một **Deployment**, nó sở hữu các **ReplicaSet** (mỗi phiên bản một cái), và mỗi ReplicaSet đảm bảo một số lượng Pod giống hệt nhau đang chạy — một chuỗi vòng lặp hòa giải cùng nhau mang lại khả năng tự phục hồi và số replica ổn định. Sức mạnh thật sự nằm ở cách Deployment xử lý thay đổi: một **rolling update** tạo ReplicaSet mới và chuyển Pod từ cũ sang mới một cách từ từ, được điều tiết bởi `maxSurge` và `maxUnavailable`, nên năng lực phục vụ được giữ nguyên và — kết hợp với readiness probe quyết định Pod nào nhận lưu lượng — bản phát hành diễn ra **không downtime**. Vì ReplicaSet trước đó được giữ lại (giảm về 0 thay vì xóa), một **rollback** vừa nhanh vừa an toàn: `kubectl rollout undo` chỉ đơn giản scale phiên bản cũ lên lại và cái lỗi xuống, đúng thứ bạn cần khi một bản phát hành trục trặc. Hiểu các cơ chế này — cùng cách scale (`kubectl scale`) và kiểm tra tiến trình (`kubectl rollout status/history`) — là nền tảng để ship phần mềm an toàn trên Kubernetes, và phản ánh mô hình khai báo, do controller điều khiển vốn định hình cách nền tảng vận hành ở production.

Hệ thống phân cấp

Manifest của Deployment

Rolling update: đổi phiên bản không downtime

Rollback khi một bản phát hành lỗi

Mở rộng (scaling)

Tại sao điều này quan trọng

Câu hỏi liên quan