Blog
Thoughts on engineering, design, and building great products.
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.
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.
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.
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.
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.
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.
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.