Blog
Thoughts on engineering, design, and building great products.
LB IPAM và Traffic Policy
Bài 48 và 49 đều dừng ở chỗ Service LoadBalancer và Gateway treo external-IP <pending> — cụm tự dựng không có ai cấp địa chỉ. Bài này lấp chỗ đó bằng LB IPAM của Cilium: định nghĩa một dải IP, để Cilium gán cho Service, và Gateway của bài trước chuyển sang Programmed=True. Sau đó là externalTrafficPolicy — Cluster hay Local quyết định địa chỉ nguồn của client còn nguyên hay bị thay. Test thật trên cụm EC2, kèm phần nói rõ ranh giới giữa cấp IP và quảng bá IP.
Gateway API: Kế Nhiệm Của Ingress
Ingress đóng băng ở những tính năng cơ bản. Gateway API là API mới của Kubernetes cho lưu lượng vào, tách vai trò hạ tầng và ứng dụng thành các object riêng, và làm được những thứ Ingress không làm: chia lưu lượng theo trọng số, khớp theo header, định tuyến nhiều giao thức. Bài này bật Gateway API trên Cilium, dựng một Gateway với HTTPRoute định tuyến theo host/path, rồi chia traffic 80/20 giữa hai phiên bản — test thật trên cụm EC2.
Ingress: Đưa HTTP Từ Ngoài Vào (Bằng Cilium)
NetworkPolicy lo lưu lượng pod-với-pod ở trong. Bài này mở mép cluster cho HTTP từ ngoài vào, định tuyến theo host và path tới đúng Service — bằng Ingress controller có sẵn của Cilium, không cài thêm phần mềm. Quan trọng không kém phần kỹ thuật là một quyết định thật: Ingress NGINX đã bị khai tử tháng 3/2026 và API Ingress đã đóng băng, nên ta chọn controller đang được bảo trì và soi cách Cilium dịch một Ingress thành cấu hình Envoy chạy trên eBPF.
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.
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.