Kubernetes: execution labs

Lab A · Probe và rollout

Objective

Chứng minh readiness/startup gating, rolling update và graceful termination bằng traffic liên tục, Deployment conditions, ReplicaSets, EndpointSlices và events.

Prerequisites

• Một cluster có quyền tạo Deployment/Service và xem events.
• Một image/app trả về version hoặc request ID và có thể mô phỏng startup delay/readiness failure.
• Một traffic generator chạy liên tục trong suốt rollout.

Baseline rollout policy

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0
minReadySeconds: 10
progressDeadlineSeconds: 300

Steps

1. Deploy v1 với ba replicas và tạo continuous traffic có version/request ID.
2. Rollout v2 với startup delay; readiness chỉ true sau initialization.
3. Inject v2 readiness failure; quan sát Deployment condition, ReplicaSets, EndpointSlices và events.
4. Sửa readiness rồi rollout lại; assert không có response từ unready pod.
5. Delete một pod giữa request; kiểm tra preStop, termination grace và request drain.

Failure injection

Làm readiness của v2 thất bại đủ lâu để rollout không tiến triển, sau đó xóa một pod đang phục vụ traffic. Không dùng liveness để mô phỏng lỗi readiness vì liveness có semantics restart khác.

Verification

• Pod chưa Ready không nhận Service traffic; EndpointSlice phản ánh trạng thái endpoint.
• Deployment condition và ReplicaSet count giải thích tại sao rollout đang tiến hoặc bị kẹt.
• Trong graceful termination, endpoint bị loại khỏi traffic và request đang xử lý có đủ thời gian hoàn tất trong grace window.

Expected evidence

• Timeline traffic ghi version/request ID trước, trong và sau rollout.
• `kubectl get deploy,rs,pod`, events và EndpointSlice snapshots.
• Không có response từ pod chưa Ready; ghi rõ nếu có lỗi do app/load balancer behavior ngoài Kubernetes.

Lab B · Requests, limits và scheduling

Objective

Nối resource requests/limits với scheduler placement, QoS, CPU throttling, OOMKilled và application latency thay vì chỉ nhìn trạng thái Pod.

Prerequisites

• Metrics hoặc observability đủ để thấy CPU/memory và latency.
• Quyền tạo workload với requests, limits và affinity.
• Một workload có thể chủ động tăng CPU hoặc memory.

Steps

1. Đặt requests/limits khác nhau; xem scheduler placement và QoS class.
2. Tạo pod unschedulable do CPU, memory hoặc affinity; chẩn đoán bằng events.
3. Gây CPU throttling và memory OOMKilled; nối container state với app latency/log.
4. Không sửa bằng cách tăng limit mù; ghi capacity model giải thích resource budget.

Failure injection

Tạo ít nhất một case scheduler không tìm được node phù hợp, một CPU-bound case chạm limit, và một memory-bound case bị OOMKilled.

Verification

• Scheduling failure được giải thích bằng request/constraint cụ thể, không chỉ “Pending”.
• CPU throttling được đối chiếu với latency/throughput; OOMKilled được xác nhận qua container state/restart reason.
• Capacity model nêu steady load, burst, headroom và tác động khi mất node.

Expected evidence

• Events cho unschedulable pod và snapshot node allocatable/requests.
• Container state/log cho OOMKilled; metric/log minh họa throttling.
• Bảng hoặc ghi chú capacity model trước khi đề xuất thay requests/limits.

Lab C · HPA và burst

Objective

Đo toàn bộ autoscaling lag từ metric detection đến pod Ready, kiểm tra HPA trong burst ngắn và ràng buộc scale-out bằng downstream budget.

Prerequisites

• Metrics Server hoặc metrics pipeline tương ứng.
• Workload có CPU request hợp lệ cho CPU-based HPA.
• Nếu dùng custom metric, adapter/pipeline phải truy cập được concurrency hoặc backlog metric.

Steps

1. Cấu hình HPA theo CPU, sau đó thử custom concurrency/backlog metric.
2. Gửi burst ngắn hơn startup time; đo detection, scheduling, image pull và readiness.
3. Quan sát tương tác giữa HPA và rolling update, đồng thời ghi scale-in stabilization.
4. Tính `replicas × DB pool`; cap scaling theo downstream budget.

Failure injection

Dùng burst ngắn nhưng đủ lớn để tải tăng nhanh hơn khả năng pod mới trở thành Ready. Có thể lặp lại khi một phần node capacity không còn để thấy scheduler delay.

Verification

• Phân tách được metric lag, HPA decision lag, scheduler/image pull lag và readiness lag.
• Scale-out không làm vượt DB connection pool, queue consumer budget hoặc dependency rate limit.
• Scale-in không tạo oscillation rõ rệt trong cửa sổ quan sát.

Expected evidence

• HPA status/conditions và replica timeline.
• Timestamp từ burst bắt đầu đến pod mới Ready.
• Phép tính `replicas × DB pool` và ngưỡng maxReplicas được chọn từ downstream budget.

Lab D · Disruption và storage

Objective

Phân biệt voluntary disruption với node failure, xác minh phạm vi bảo vệ của PDB và chứng minh recovery của stateful workload qua PVC/attach/topology cùng backup/restore thật.

Prerequisites

• Cluster nhiều node; tốt hơn nếu có nhiều zone để quan sát topology.
• Workload replicated có PDB.
• StorageClass/PVC cho một stateful workload và quyền drain node.

Steps

1. Tạo PDB rồi drain node; quan sát voluntary eviction.
2. Mô phỏng node failure để thấy PDB không bảo đảm mọi availability.
3. Với stateful workload, delete/reschedule pod; kiểm tra PVC attach và zonal constraints.
4. Thực hiện backup/restore data thay vì gọi PVC là backup.

Failure injection

So sánh hai failure path: drain qua eviction API và mất node/involuntary disruption. Với storage, buộc pod reschedule sang nơi có thể làm lộ topology/attach constraint.

Verification

• PDB giới hạn voluntary evictions nhưng không ngăn node failure hay mọi kiểu pod deletion.
• Stateful pod chỉ phục hồi khi volume có thể attach/mount theo storage topology và access semantics.
• Backup được xác minh bằng restore sang target sạch và kiểm tra dữ liệu, không chỉ bằng việc PVC vẫn tồn tại.

Expected evidence

• `kubectl drain`/eviction result, PDB status và events.
• Timeline node failure → replacement pod → volume attach/mount → Ready.
• Backup artifact/snapshot reference, restore steps và data verification.