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