"Ứng dụng đang chạy ổn định. Bạn sửa một lỗi nhỏ và cần cập nhật phiên bản mới. Liệu có phải xóa Pod cũ rồi tạo Pod mới?"

Đó chính là vấn đề mà Deployment được tạo ra để giải quyết.

---

Ôn lại bài trước

Ở bài trước, chúng ta đã biết ReplicaSet có nhiệm vụ đảm bảo luôn có đúng số lượng Pod đang chạy.

Ví dụ:

ReplicaSet
    │
    ├── Pod
    ├── Pod
    └── Pod

Nếu một Pod bị xóa, ReplicaSet sẽ tạo Pod mới ngay lập tức.

Rất tuyệt!

Nhưng bây giờ hãy tưởng tượng...

---

Một vấn đề mới xuất hiện

Website của bạn đang chạy phiên bản v1.

Pod (v1)
Pod (v1)
Pod (v1)

Một ngày nọ, bạn sửa xong một lỗi và build image mới:

my-app:v2

Làm thế nào để cập nhật toàn bộ hệ thống sang phiên bản mới?

---

Cách đơn giản nhất

Bạn nghĩ:

"Xóa hết Pod cũ rồi tạo Pod mới."

Delete Pod
↓
Create Pod v2

Nghe có vẻ hợp lý.

Nhưng chuyện gì xảy ra trong vài giây giữa lúc xóa và tạo?

👉 Người dùng không còn Pod nào để truy cập.

Website bị gián đoạn.

Đây gọi là Downtime.

Trong môi trường Production, chỉ vài giây downtime cũng có thể ảnh hưởng đến hàng nghìn người dùng.

---

1. Deployment xuất hiện

Deployment giúp cập nhật ứng dụng mà không làm gián đoạn dịch vụ.

Thay vì xóa toàn bộ Pod cùng lúc, Deployment sẽ thay thế từng Pod một.

Pod v1           Pod v2           Pod v2           Pod v2
Pod v1     →     Pod v1     →     Pod v2     →     Pod v2
Pod v1           Pod v1           Pod v1           Pod v2

Trong suốt quá trình này, luôn có Pod đang phục vụ người dùng.

Người dùng gần như không nhận ra hệ thống đang được cập nhật.

Đây được gọi là Rolling Update.

---

2. Deployment quản lý ai?

Deployment không trực tiếp quản lý Pod.

Nó quản lý ReplicaSet, còn ReplicaSet quản lý Pod.

Deployment
      │
      ▼
 ReplicaSet
      │
      ▼
    Pods

Khi bạn cập nhật image từ v1 lên v2, Deployment sẽ:

• Tạo một ReplicaSet mới.
• Từ từ tạo các Pod mới.
• Dần dần xóa các Pod cũ.
• Khi hoàn tất, ReplicaSet cũ sẽ không còn Pod nào.

Nhờ vậy, việc cập nhật diễn ra an toàn và mượt mà.

---

Một ví dụ YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3

  selector:
    matchLabels:
      app: my-app

  template:
    metadata:
      labels:
        app: my-app

    spec:
      containers:
      - name: app
        image: nginx:1.27

So với ReplicaSet, Deployment có cấu trúc gần như giống hệt.

Điểm khác biệt là Deployment mang đến nhiều tính năng mạnh mẽ hơn như:

• Rolling Update
• Rollback
• Quản lý phiên bản
• Scale ứng dụng

Trong thực tế, bạn gần như luôn sử dụng Deployment thay vì tạo ReplicaSet trực tiếp.

---

Deployment hay ReplicaSet?

Bạn có thể xem Deployment như một "người quản lý", còn ReplicaSet là "người thực thi".

ReplicaSet	Deployment
Giữ đúng số lượng Pod	Quản lý toàn bộ vòng đời ứng dụng
Không hỗ trợ cập nhật phiên bản thuận tiện	Hỗ trợ Rolling Update
Không rollback	Có Rollback
Ít khi dùng trực tiếp	Được sử dụng phổ biến nhất

---

Tổng kết

Trong bài trước, chúng ta học được cách giữ cho ứng dụng luôn hoạt động bằng ReplicaSet.

Trong bài này, chúng ta tiến thêm một bước: cập nhật ứng dụng mà không làm gián đoạn người dùng.

Đó chính là vai trò của Deployment.

Deployment quản lý ReplicaSet, còn ReplicaSet quản lý Pod.

Nhờ cơ chế Rolling Update, Kubernetes có thể triển khai phiên bản mới một cách an toàn và gần như không gây downtime.

---

Bài tiếp theo

Đến đây, ứng dụng của chúng ta đã có 3 Pod chạy ổn định.

Nhưng lại xuất hiện một câu hỏi mới:

Mỗi Pod đều có một địa chỉ IP riêng, vậy người dùng sẽ kết nối vào Pod nào?

Đó chính là lúc chúng ta cần đến Service – "người điều phối giao thông" trong Kubernetes.