# 🎯 nodeSelector, affinity và taint/toleration
Bài trước bạn đã học requests/limits và QoS class: đó là cách nói với scheduler "pod này cần bao nhiêu tài nguyên". Bài này là mảnh ghép còn lại: nói với scheduler **pod phải nằm ở đâu** và **node nào được phép nhận pod**. Đây là dạng bài xuất hiện gần như chắc chắn trong đề CKA, và cũng là chỗ nhiều người mất điểm oan vì làm đúng cú pháp nhưng sai logic.
> [!NOTE]
> Kiến thức cần nhớ từ bài trước: nếu pod không có node nào đủ CPU/memory theo `requests`, scheduler sẽ để pod ở trạng thái `Pending`. Bài này thêm một lý do nữa khiến pod `Pending`: label/affinity không khớp hoặc node bị taint. Khi troubleshoot, luôn đọc dòng `Events` của `kubectl describe pod` trước.
## 1. Mục tiêu bài học
Sau bài này, bạn phải làm được 4 việc trong khoảng 35 phút, không cần tra Google:
- Dùng `nodeSelector` để ghim pod vào node có label chỉ định.
- Viết `nodeAffinity` dạng `required` (bắt buộc) và `preferred` (ưu tiên) bằng `matchExpressions`.
- Gắn và gỡ `taint` trên node, thêm `toleration` vào pod.
- Phân biệt được 3 effect `NoSchedule`, `PreferNoSchedule`, `NoExecute` và biết khi nào đề bài muốn cái nào.
## 2. Ví dụ có hướng dẫn (worked example)
**Đề bài kiểu CKA:** Cluster có `node01` và `node02`. Hãy tạo pod tên `ssd-pod`, image `nginx`, chỉ chạy trên node có label `disk=ssd`. Node `node02` phải bị chặn để pod thường không vào được, chỉ pod có toleration phù hợp mới vào.
**Bước 1. Khảo sát hiện trạng trước khi sửa bất cứ thứ gì.**
```bash
kubectl get nodes --show-labels
kubectl describe node node01 | grep -iA3 taints
```
`--show-labels` cho bạn thấy toàn bộ label hiện có, tránh ghi đè nhầm. Trong thi, đây là bước 10 giây nhưng cứu bạn khỏi việc tạo label trùng key.
**Bước 2. Gắn label cho node.**
```bash
kubectl label node node01 disk=ssd
kubectl get node node01 --show-labels
```
Nếu label đã tồn tại với giá trị khác, `kubectl` sẽ báo lỗi và yêu cầu `--overwrite`. Đây là chi tiết nhỏ nhưng hay xuất hiện trong đề.
**Bước 3. Tạo pod bằng dry-run rồi sửa YAML (mẹo ăn điểm).**
```bash
kubectl run ssd-pod --image=nginx --dry-run=client -o yaml > ssd-pod.yaml
```
Mở file và thêm `nodeSelector`:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: ssd-pod
spec:
nodeSelector:
disk: ssd
containers:
- name: web
image: nginx
```
```bash
kubectl apply -f ssd-pod.yaml
kubectl get pod ssd-pod -o wide
```
Cột `NODE` phải là `node01`. Nếu là `node02` thì bạn gắn label sai node; nếu `Pending` thì đọc `kubectl describe pod ssd-pod`.
**Bước 4. Gắn taint lên `node02`.**
```bash
kubectl taint nodes node02 env=prod:NoSchedule
kubectl describe node node02 | grep -i taint
```
Kết quả mong đợi: `Taints: env=prod:NoSchedule`.
**Bước 5. Kiểm chứng logic toleration.** Tạo một pod không có toleration và một pod có toleration, sau đó xem pod nào vào được `node02`:
```yaml
spec:
nodeSelector:
kubernetes.io/hostname: node02
tolerations:
- key: env
operator: Equal
value: prod
effect: NoSchedule
```
Pod không có `tolerations` sẽ `Pending` với event dạng `1 node(s) had untolerated taint {env: prod}`. Pod có toleration sẽ vào được. Đây chính là điểm mấu chốt của bài: ==toleration chỉ mở cửa, không kéo pod vào trong==.
**Bước 6. Nếu đề yêu cầu "ưu tiên" thay vì "bắt buộc"**, dùng `preferred` thay cho `nodeSelector`:
```yaml
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: disk
operator: In
values: ["ssd"]
```
Với `preferred`, nếu `node01` hết tài nguyên, pod vẫn có thể chạy trên `node02`. Với `nodeSelector` hoặc affinity `required`, pod sẽ nằm `Pending` thay vì chọn node khác.
```mermaid
flowchart TD
Start["🚀 Pod được tạo"] --> NS{"Có nodeSelector?"}
NS -->|Có| Filter["🔎 Scheduler lọc node theo label"]
NS -->|Không| Aff{"Có required nodeAffinity?"}
Aff -->|Có| Filter
Aff -->|Không| Taint{"Node còn taint mà pod không tolerate?"}
Filter --> Taint
Taint -->|Có| Skip["⛔ Loại node đó"]
Taint -->|Không| Bind["✅ Bind pod vào node"]
Skip --> Pending["⏳ Hết node thì Pod Pending"]
```
## 3. Luyện tập có hướng dẫn
Chuẩn bị: cluster có ít nhất 2 node. Nếu bạn lab bằng cluster 1 node, dùng `control-plane` làm node đích và nhớ nó đã có taint sẵn.
Bài tập dưới đây được thiết kế đúng thứ tự khó tăng dần. Làm xong mỗi bài, ghi lại lệnh kiểm chứng bạn đã dùng.
### Bài 1. nodeSelector cơ bản
Gắn label `tier=frontend` cho node bất kỳ có hostname `node01`, tạo pod `web-frontend` image `nginx` chỉ chạy trên node đó bằng `nodeSelector`.
Xem gợi ý
```bash
kubectl label node node01 tier=frontend
kubectl run web-frontend --image=nginx --dry-run=client -o yaml > web.yaml
```
Thêm vào `spec`:
```yaml
nodeSelector:
tier: frontend
```
```bash
kubectl apply -f web.yaml
kubectl get pod web-frontend -o wide
```
Xem gợi ý
```yaml
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: tier
operator: In
values: ["frontend"]
```
Lưu ý cấu trúc: `nodeSelectorTerms` là **list**, bên trong mỗi term là `matchExpressions` cũng là **list**. Sai một cấp lồng nhau là `kubectl apply` báo lỗi ngay.
Xem gợi ý
```bash
kubectl label node node01 disk-
kubectl get pod prefer-ssd -o wide
```
Với `preferred`, scheduler bỏ qua tiêu chí không khớp và vẫn đặt pod. Đây là cách phân biệt nhanh `required` và `preferred` khi làm bài.
Xem gợi ý
```bash
kubectl taint nodes node02 env=prod:NoSchedule-
kubectl taint nodes node02 env=prod:NoExecute
kubectl get pods -o wide --field-selector spec.nodeName=node02
```
Với `NoExecute`, pod không tolerate bị **đuổi khỏi node** (terminated) chứ không chỉ bị chặn như `NoSchedule`. Đây là điểm khác biệt hay bị hỏi.
Xem gợi ý
```bash
kubectl create deployment api --image=nginx --replicas=2 --dry-run=client -o yaml > api.yaml
```
Sửa file, thêm cả `nodeSelector` và `tolerations` vào `spec.template.spec`, rồi:
```bash
kubectl apply -f api.yaml
kubectl get pods -l app=api -o wide
kubectl describe pod -l app=api | grep -i -A2 "Node-Selectors\|Tolerations"
```
`describe` in ra cả `Node-Selectors` và `Tolerations`, đây là cách tự chấm điểm nhanh trong phòng thi.