Blog
Thoughts on engineering, design, and building great products.
RBAC: Biến Danh Tính Thành Quyền
Bài 51 dừng ở chỗ API server biết bạn là ai. RBAC trả lời câu còn lại: bạn được làm gì. Bài này dựng một ServiceAccount chỉ đọc được pod trong một namespace, kiểm chứng bằng kubectl auth can-i lẫn token thật — thấy nó list pod được nhưng đọc secret hay tạo pod thì bị 403. Rồi xem cách một RoleBinding trỏ vào ClusterRole có sẵn để cấp quyền gói gọn trong một namespace, và vì sao ClusterRole view cố tình không cho đọc secret.
Authentication và Đường Vào API Server
Mỗi lệnh kubectl là một request HTTPS tới API server, và trước khi chạm được dữ liệu nó phải qua ba chặng: authentication, authorization, admission. Bài này mở Part XI bằng chặng đầu — API server nhận ra bạn là ai. Ta soi ba cách cụm tự dựng chứng thực một request: client certificate (cái admin.kubeconfig đang dùng), token của ServiceAccount, và request ẩn danh — bằng kubectl auth whoami và lệnh thật trên cụm.
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ỡ.