Kubernetes Từ Số Không
Dựng một cluster Kubernetes hoàn chỉnh bằng tay — không kubeadm, không script — từ certificate đầu tiên tới một cluster HA chạy thật, rồi dùng chính nó làm phòng thí nghiệm để deep-dive toàn bộ concept của Kubernetes. Phần một: PKI/TLS, etcd, control plane, worker, mạng pod, CoreDNS. Phần hai: Pods, workload controllers, scheduling, storage, networking nâng cao (Cilium eBPF), bảo mật, mở rộng API, vận hành. Mỗi thành phần vừa được giải thích cơ chế bên trong, vừa tự dựng/cấu hình tay. Test thật trên AWS EC2 với Kubernetes v1.36, manifest/script lưu tại github.com/nghiadaulau/kubernetes-from-scratch. Bám docs chính thức kubernetes.io.
Deployment: rollout và rollback
Tới giờ ta toàn tạo Pod trần. Production thì không ai làm vậy — pod được giao cho Deployment quản, và Deployment không quản pod trực tiếp mà qua một lớp giữa: ReplicaSet. Bài này mở Part IV bằng cách đào đúng cơ chế đó: đổi image sinh ra ReplicaSet mới, rolling update nâng cái mới lên hạ cái cũ xuống, ReplicaSet cũ được giữ ở 0 để rollback một lệnh. Test thật từng bước trên cluster, soi cả chuỗi sở hữu Pod → ReplicaSet → Deployment.
StatefulSet: danh tính ổn định và thứ tự
Deployment coi mọi pod như đàn cá vô danh — thay con nào cũng được. Nhưng database, message queue, etcd thì không: mỗi node cần một danh tính cố định và dữ liệu riêng. StatefulSet sinh ra cho đúng nhu cầu đó. Bài này đào bốn bảo đảm của nó — tên ổn định, DNS riêng từng pod qua headless service, tạo và xóa theo thứ tự — kiểm chứng từng cái trên cluster thật, và để dành phần volume cho phần Storage.
DaemonSet: một pod trên mỗi node
Deployment quản N bản sao đặt đâu cũng được; StatefulSet quản N pod có danh tính. DaemonSet là mô hình thứ ba và khác hẳn: không đếm bản sao mà bảo đảm đúng một pod trên mỗi node — thêm node thì thêm pod, bớt node thì pod biến mất. Đây là khuôn cho agent log, CNI, node exporter. Bài này đào cách DaemonSet ghim pod vào từng node, vì sao pod của nó chạy được cả trên node chưa sẵn sàng, và cách giới hạn nó vào một nhóm node — test thật trên hai worker.
Job, CronJob và TTL
Mọi controller tới giờ đều chạy mãi — Deployment, StatefulSet, DaemonSet giữ pod sống bất tận. Job đảo ngược: nó chạy một tác vụ tới khi xong rồi dừng, đúng cho migration, backup, batch. Bài này khép Part IV với Job (completions, parallelism, backoffLimit), CronJob chạy theo lịch cron, và TTL tự dọn Job đã xong — test thật từng cái trên cluster, kể cả bắt CronJob nổ đúng mốc phút.
Label, selector, namespace và annotation
Ta đã gõ -l app=web hàng chục lần mà chưa dừng lại hỏi nó hoạt động ra sao. Bài này mở Part V bằng bộ công cụ tổ chức và truy vấn đối tượng: label để gắn nhãn và chọn (equality lẫn set-based), annotation để đính metadata không-định-danh, namespace để cô lập, và field selector để lọc theo trường có sẵn. Test thật từng kiểu selector trên một rổ pod gắn nhãn.
Finalizer, ownerReferences và garbage collection
Mỗi lần xóa Deployment ở các bài trước, pod và ReplicaSet biến mất theo — ta gọi đó là garbage collection mà chưa mổ xẻ. Bài này đào cơ chế: ownerReferences nối object cha-con, garbage collector tự dọn con khi cha mất (nền, foreground, hay để mồ côi), và finalizer chặn xóa tới khi việc dọn dẹp xong. Test thật cả ba — kể cả một object kẹt ở Terminating vì finalizer.
Quản lý object, nhãn khuyến nghị và storage version
Cùng một Deployment, ta có ba cách tạo và sửa — gõ lệnh trực tiếp, create -f một file, hay apply cả thư mục — và trộn lẫn chúng là rước lỗi. Bài này khép Part V bằng ba kỹ thuật quản lý object đó (kèm vì sao apply khác create -f), bộ nhãn khuyến nghị app.kubernetes.io/* để công cụ hiểu nhau, và storage version — đào tận etcd xem một object thực sự được lưu ở phiên bản API nào.
ConfigMap và Secret
Đừng nướng cấu hình vào image — tách nó ra ConfigMap cho dữ liệu thường, Secret cho dữ liệu nhạy cảm, rồi tiêm vào pod qua biến môi trường hay file. Bài này mở Part VI bằng cả hai: bốn cách tiêu thụ, một khác biệt then chốt (file tự cập nhật khi sửa, env thì không), và sự thật phũ phàng rằng Secret chỉ base64 chứ không mã hóa — trừ khi bạn tự bật, mà cụm của ta thì đã bật từ Bài 5. Test thật, đào cả tận etcd.
Node Allocatable: tài nguyên thật pod được dùng
Bài 22 nhìn requests/limits từ phía pod. Bài này lật sang phía node: một máy 2 vCPU không cho pod xài trọn 2 vCPU đó. Kubernetes cắt bớt phần cho daemon hệ thống, cho daemon Kubernetes, và một khoản đệm chống hết RAM — phần còn lại mới là Allocatable, thứ scheduler thực sự đem chia. Bài này đào công thức Allocatable, đọc Capacity vs Allocatable trên node thật, rồi tự tay thêm reservation và xem Allocatable tụt đúng từng Ki.
LimitRange và ResourceQuota
Khi nhiều team dùng chung một cluster, không gì ngăn team A tạo 10.000 pod hay xin 64Gi RAM cho một container — trừ khi bạn đặt luật. LimitRange đặt mặc định và min/max cho từng pod trong một namespace; ResourceQuota chặn tổng tài nguyên và số object cả namespace được dùng. Bài này khép Part VI bằng cả hai: test thật cú tiêm default, cú vượt max bị 403, và cú tạo pod thứ tư bị quota chặn.
Scheduler và scheduling framework
Mỗi pod ta tạo đều có ai đó âm thầm chọn node cho nó — đó là kube-scheduler, thứ ta đã dựng ở Bài 8 mà chưa nhìn kỹ. Bài này mở Part VII bằng cách đào đúng cách nó chọn: lọc bỏ node không vừa (filter), chấm điểm node còn lại (score), rồi bind. Test thật một pod bị treo vì không node nào đủ chỗ, một pod được chọn node, và xem scoring dồn pod vào node ít tải hơn — không phải chia đều ngây thơ.
Affinity, taint và toleration
Scheduler tự chọn node, nhưng nhiều khi bạn cần can thiệp: pod này phải ở node SSD, hai bản sao đừng nằm chung một máy, node kia chỉ dành riêng cho một team. Bài này đào ba công cụ điều khiển scheduler từ phía bạn — nodeAffinity (hút pod về node có nhãn), podAntiAffinity (đẩy pod xa nhau), taint/toleration (node đẩy pod ra trừ khi pod chịu được). Test thật cả pod bị treo vì affinity, pod thứ ba không chỗ vì anti-affinity, và pod bị NoExecute đuổi khỏi node đang chạy.