# 📦 Pod, ReplicaSet, Deployment: cơ chế điều khiển, scheduling và rollout
> Sign in to view the full content of this lesson.
## Mục tiêu học tập
- Viết được manifest Deployment đầy đủ và giải thích được vai trò của `replicas`, `selector`, `template`, `strategy`.
- Mô tả được chuỗi sở hữu Deployment → ReplicaSet → Pod và vòng lặp reconcile đứng sau nó.
- Giải thích được scheduler chọn node như thế nào, và vì sao một Pod rơi vào trạng thái `Pending`.
- Theo dõi, dừng và rollback một lần rollout bằng `kubectl` mà không đoán mò.
## Ôn tập nhanh
Bài trước bạn đã đi hết đường đi: `kubectl` → API server → `etcd` → controller tạo Pod → scheduler gán node → kubelet start container. Điểm cần nhớ: API server chỉ ghi trạng thái mong muốn vào `etcd`, còn **controller manager** mới là thứ liên tục nhìn trạng thái thực tế và sửa cho khớp. Bài này chính là mổ xẻ mấy controller đó.
## Lý thuyết
### Pod: đơn vị nhỏ nhất, không phải container
Pod là một nhóm 1 hoặc nhiều container dùng chung network namespace (chung IP, chung port space) và có thể dùng chung volume. Bạn không tạo container trực tiếp, bạn tạo Pod. `restartPolicy` mặc định là `Always`, nên container chết sẽ được kubelet restart tại chỗ. Pod có các phase: `Pending`, `Running`, `Succeeded`, `Failed`.
Mẹo thực chiến: hãy tạo Pod trực tiếp một lần để hiểu, rồi **đừng bao giờ làm vậy nữa** trong môi trường thật. Pod trần không được ai giám sát, chết là mất.
```mermaid
flowchart TD
D["🚀
Deployment web"] --> R1["📦
ReplicaSet web-7d9f (rev 2)"]
D --> R0["🗄️
ReplicaSet web-5c2a (rev 1, đã scale 0)"]
R1 --> P1["🟢
Pod web-7d9f-x1"]
R1 --> P2["🟢
Pod web-7d9f-x2"]
```
### ReplicaSet: giữ đúng số lượng
ReplicaSet (RS) đảm bảo luôn có đúng `replicas` Pod khớp `selector.matchLabels` đang tồn tại. Hai field phải khớp nhau: label trong `spec.template.metadata.labels` và `spec.selector.matchLabels`. Lệch nhau thì API server từ chối manifest, đây là lỗi newcomer hay gặp nhất.
RS nhận nuôi Pod qua `ownerReferences`. Khi bạn xóa Deployment, garbage collector đi theo chuỗi owner và dọn luôn RS cùng Pod. Đó là lý do `kubectl get pods` sạch bóng sau khi xóa.
### Deployment: quản lý RS, không quản lý Pod
Deployment là lớp trên RS. Mỗi khi `spec.template` thay đổi (image, env, label trong template...), Deployment controller tạo một RS mới với hash mới, rồi scale RS mới lên và RS cũ xuống theo `strategy`. RS cũ được giữ lại với `replicas: 0` để làm bản rollback.
Hai chiến lược:
| Strategy | Hành vi | Downtime |
| --- | --- | --- |
| `RollingUpdate` (mặc định) | Thay Pod dần, tôn trọng `maxSurge` và `maxUnavailable` | Không, nếu có readinessProbe |
| `Recreate` | Tắt hết Pod cũ rồi mới tạo mới | Có |
`maxSurge: 1` cho phép tạo thêm 1 Pod vượt số replica. `maxUnavailable: 0` cấm mất Pod Ready nào trong lúc rollout. Với `replicas: 3`, cấu hình này nghĩa là tối đa 4 Pod tồn tại, tối thiểu 3 Pod Ready. ==Rollout không bao giờ vượt quá `replicas + maxSurge` và không bao giờ xuống dưới `replicas - maxUnavailable`.==
### Vòng lặp reconcile: level-triggered
Controller không phản ứng kiểu "có event thì làm một lần rồi quên". Nó liên tục: đọc trạng thái mong muốn, đọc trạng thái thực tế, tính hiệu, rồi hành động. Vì vậy nếu bạn xóa tay một Pod của RS, RS sẽ tạo lại ngay, và nếu ai đó sửa tay, controller vẫn kéo về đúng số.
### Scheduler chọn node thế nào
Scheduler chạy hai pha:
1. **Filtering**: loại node không hợp lệ. Lý do thường gặp: không đủ `resources.requests`, `nodeSelector`/`nodeAffinity` không khớp, `taints` mà Pod không có `tolerations`, node `NotReady` hoặc đang cordon.
2. **Scoring**: chấm điểm các node còn lại (ví dụ cân bằng tải theo mức sử dụng, ưu tiên node đã có image). Điểm cao nhất thắng.
Nếu mọi node bị loại ở pha 1, Pod nằm `Pending` và `kubectl describe pod` sẽ in ra lý do trong phần Events. Đặt `nodeName` trực tiếp trong spec sẽ bỏ qua scheduler hoàn toàn, chỉ dùng khi debug.
## Ví dụ có hướng dẫn
Manifest dưới đây đủ dùng cho 90% workload stateless:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
revisionHistoryLimit: 5
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.27.1
ports:
- containerPort: 80
resources:
requests:
cpu: 100m
memory: 128Mi
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 3
periodSeconds: 5
```
Đọc từ trên xuống: `replicas: 3` là trạng thái mong muốn. `selector` và label `app: web` trong template phải khớp. `maxUnavailable: 0` chỉ an toàn khi có `readinessProbe`, vì nếu không có probe, Pod được coi là Ready ngay khi container start, dù app chưa sẵn sàng nhận traffic. `resources.requests` là con số scheduler dùng để lọc node, thiếu nó thì mọi Pod đều "vừa" mọi node cho tới khi node hết tài nguyên thật.
Rollout và rollback:
```bash
kubectl apply -f web.yaml
kubectl rollout status deployment/web
kubectl set image deployment/web web=nginx:1.27.2
kubectl rollout history deployment/web
kubectl rollout undo deployment/web
```
`rollout undo` không "chạy lại lệnh cũ". Nó tìm RS của revision trước và scale RS đó lên lại, scale RS hiện tại xuống 0. Vì vậy manifest cũ phải còn trong lịch sử, đừng đặt `revisionHistoryLimit: 0`.
## Thực hành có hướng dẫn
**Bài 1.** Viết `web.yaml` như ví dụ trên nhưng đổi image thành `nginx:1.27.0` và thêm label `tier: frontend` cho cả `selector` lẫn template. Apply, kiểm tra `kubectl get rs` và `kubectl get pods -l app=web`.
Gợi ý và đáp án
Nhớ sửa label ở **hai chỗ** trong cùng một lần apply, nếu chỉ sửa một chỗ API server báo `selector does not match template labels`. Sau khi apply, bạn sẽ thấy đúng 1 RS và 3 Pod. Chạy `kubectl get pods -o wide` để xem scheduler đặt chúng lên node nào.
Đáp án
Tối đa 4 Pod (3 + `maxSurge: 1`), và không lúc nào dưới 3 Pod Ready vì `maxUnavailable: 0`. Bạn sẽ thấy RS mới được tạo với hash khác, RS cũ tụt dần về 0. Nếu thấy 6 Pod cùng lúc, bạn đang dùng giá trị mặc định `maxSurge: 25%`, tức Deployment chưa nhận `strategy` của bạn.
Đáp án
Pod mới ở trạng thái `ImagePullBackOff`, nhưng vì `maxUnavailable: 0`, 3 Pod cũ vẫn chạy phục vụ traffic. `kubectl get pods` cho thấy cả Pod cũ lẫn Pod lỗi. `rollout undo` đưa bạn về revision trước và dọn Pod lỗi. Đây là lý do `maxUnavailable: 0` đáng giá: rollout hỏng không kéo sập dịch vụ.
Đáp án
Pha filtering loại mọi node vì không node nào còn đủ 4 CPU khả dụng. `kubectl describe pod` sẽ in `0/3 nodes are available: 3 Insufficient cpu`. Xóa hoặc giảm request rồi apply lại, Pod sẽ được schedule.