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.
Topology spread, pod overhead và scheduling readiness
Anti-affinity cứng nhắc: mỗi node một pod, dư là treo. Topology spread mềm hơn — rải đều theo maxSkew mà vẫn cho nhiều pod mỗi node. Bài này đào ba cơ chế scheduling tinh: topologySpreadConstraints (rải uyển chuyển), pod overhead (tính thêm tài nguyên cho sandbox runtime), và schedulingGates (giữ pod chưa cho xếp lịch). Test thật cả ba trên cluster.
Priority và preemption
Node hết chỗ, một pod quan trọng vừa tạo. Nó chịu treo Pending sau đám pod rác, hay được quyền đá một pod kém quan trọng ra để giành chỗ? PriorityClass gán mức ưu tiên; preemption cho pod ưu tiên cao trục xuất pod thấp khi cần. Bài này lấp đầy cluster bằng pod ưu tiên thấp rồi thả một pod ưu tiên cao — xem nó đá nạn nhân ra và chiếm chỗ, đúng cái bước PostFilter mà Bài 34 bảo 'không giúp được'.
Node-pressure eviction
Ba bài qua nói về việc xếp pod. Bài này nói về việc đuổi pod — nhưng không phải preemption (scheduler, vì priority) hay OOM kill (kernel, vì vượt limit). Đây là kubelet chủ động giết pod khi node thật sự cạn RAM hoặc disk, theo ngưỡng và thứ tự xếp hạng riêng. Bài này tự tay tạo áp lực bộ nhớ thật trên một worker rồi xem kubelet trục xuất đúng pod ngốn nhất — kèm thông điệp eviction nói rõ vì sao.
Metrics Server và HorizontalPodAutoscaler
Part VIII đổi hướng: thay vì giết pod khi quá tải, ta thêm pod. Nhưng muốn autoscale theo CPU thì cluster phải biết pod đang dùng bao nhiêu CPU — mà cụm tự dựng của ta chưa có ai đo. Bài này cài add-on đầu tiên, Metrics Server, vấp đúng một cái bẫy KTHW (control plane không nói chuyện được với pod) rồi sửa nó, rồi dựng HPA và đốt CPU thật để xem nó tự nhân pod từ 1 lên 4.
Vertical Pod Autoscaler và resource manager
HPA thêm pod khi tải lên. VPA làm điều ngược: giữ nguyên số pod nhưng chỉnh đúng lượng CPU/RAM mỗi pod cần — hết cảnh đặt request bừa rồi lãng phí hoặc thiếu. Bài này cài VPA (add-on, như Metrics Server), cho nó quan sát một workload thật rồi đưa khuyến nghị, và sang phía node: CPU Manager static policy ghim hẳn lõi CPU cho pod Guaranteed — test thật, thấy pod được cấp đúng một CPU độc quyền.
Volume: ephemeral, hostPath và projected
File trong container biến mất khi container restart, và hai container trong một pod không tự thấy file của nhau. Volume giải cả hai. Bài này mở Part IX storage bằng các volume gắn thẳng vào pod: emptyDir (vùng nhớ tạm chia sẻ trong pod), hostPath (mượn thư mục của node), và projected (gộp configMap/secret/downwardAPI/token vào một chỗ) — test thật từng cái, làm rõ cái nào sống theo container, cái nào theo pod, cái nào theo node.
PersistentVolume và PersistentVolumeClaim
Volume ở Bài 41 chết theo pod. Muốn dữ liệu sống lâu hơn pod, Kubernetes tách làm hai vai: PersistentVolume là miếng lưu trữ thật (admin tạo), PersistentVolumeClaim là tờ yêu cầu lưu trữ (user tạo) — và một control loop âm thầm ghép chúng lại. Bài này dò từng bước ai-tạo-cái-gì, ai-bind-cái-gì: admin dựng PV, user xin PVC, controller bind hai chiều, pod dùng claim, xóa pod data vẫn còn, xóa claim thì PV về Released.
StorageClass, dynamic provisioning và EBS CSI
Ở Bài 42 admin phải tạo PV bằng tay trước. Không ai làm vậy ở quy mô thật. StorageClass + CSI driver lật ngược: user chỉ tạo PVC, hệ thống tự đẻ PV — và tự gọi AWS tạo hẳn một EBS volume. Bài này cài EBS CSI driver thật (kèm IAM cho node), dò từng mắt xích ai-gọi-ai từ PVC tới lúc một ổ đĩa EBS ra đời, rồi xóa PVC và xem ổ đĩa biến mất.
VolumeSnapshot và CSI snapshot
Có ổ đĩa bền rồi, làm sao sao lưu? VolumeSnapshot chụp ảnh tức thời nội dung một PVC — và với EBS CSI, nó tạo hẳn một EBS snapshot thật trên AWS. Bài này khép Part IX: cài snapshot controller, chụp một PVC, khôi phục một PVC mới từ ảnh đó — kèm một bài học xương máu về vì sao lần khôi phục đầu ra file rỗng, và phải sync trước khi chụp.
Cilium và eBPF: vì sao thay kube-proxy
Ở Part I ta dựng mạng pod bằng kube-proxy iptables và một bridge thủ công — đủ chạy, nhưng iptables phình tuyến tính theo số Service và mọi quyết định mạng nằm rải trong hàng trăm rule. Part X nâng cấp: thay cả kube-proxy lẫn bridge bằng Cilium dựa eBPF. Bài này là phần lý thuyết — eBPF là gì, vì sao nó nhanh hơn iptables, Cilium làm gì khác ở datapath — soi thẳng 74 rule iptables đang chạy để thấy thứ ta sắp bỏ đi.
Migrate sang Cilium kube-proxy-less
Lý thuyết xong, giờ làm thật: thay kube-proxy + bridge của Part I bằng Cilium 1.19 dựa eBPF, gỡ hẳn kube-proxy, bật Hubble. Bài này dò từng bước migration trên cụm đang chạy — cài Cilium, tắt kube-proxy, xác nhận Service vẫn chạy mà không còn một rule iptables nào của kube-proxy — kèm bốn cái bẫy thật mà một cụm tự dựng vấp phải (providerID, topology label, IMDS hop limit, hostNetwork) và cách gỡ.
NetworkPolicy: Tường Lửa Theo Nhãn
Mặc định mọi pod trong cluster nói chuyện tự do với nhau — phẳng và mở. Bài này dùng NetworkPolicy để khoá lại: chặn hết ingress vào một pod rồi chỉ mở cho đúng nhãn được phép, test thật trên cụm Cilium. Và vì cụm chạy eBPF, ta xem được Hubble in ra verdict DROPPED/FORWARDED cho từng gói, kèm Cilium identity chứng minh policy bám vào nhãn chứ không phải IP.