Blog
Thoughts on engineering, design, and building great products.
Hubble Bên Trong: Từ Sự Kiện eBPF Tới Luồng Mạng Toàn Cụm
Hubble cho ta xem mọi kết nối trong cụm Kubernetes theo tên pod, service, verdict policy — mà không cài sidecar vào pod nào. Bài này mổ cơ chế: datapath eBPF của Cilium (74 chương trình sched_cls ở Bài 12) gọi bpf_perf_event_output đẩy sự kiện vào một perf ring buffer tên cilium_events; cilium-agent đọc ra (cilium monitor cho thấy sự kiện thô với identity dạng số); rồi Hubble giàu hóa — biến identity 18203 thành kube-system/coredns — bằng cách tra kho identity-nhãn. Ta xem cả ba tầng chạy thật.
Kiểu Tetragon: Từ Quan Sát Đến Cưỡng Chế Bằng bpf_send_signal
Tetragon là công cụ an ninh runtime của hệ Cilium: nó quan sát bằng kprobe/tracepoint (đúng những hook Part II dùng) rồi cưỡng chế ngay trong nhân. Cơ chế cưỡng chế thật của nó là hai helper — bpf_send_signal gửi SIGKILL giết tiến trình, và bpf_override_return ghi đè giá trị trả về syscall. Bài này tự dựng đúng cơ chế đó: một tracepoint exec gọi bpf_send_signal(SIGKILL) để giết một tiến trình ngay khi nó chạy — binary cấm nhận exit 137, binary thường vẫn chạy. Không cần LSM hay reboot.
LSM BPF: Cưỡng Chế An Ninh Ngay Trong Nhân
Tới giờ eBPF của ta chỉ quan sát. LSM BPF thì cưỡng chế: gắn vào các điểm kiểm soát an ninh của nhân (Linux Security Modules) mà SELinux, AppArmor dùng, và một chương trình trả về 0 cho qua hay -EPERM để chặn. Bài này viết một chương trình LSM chặn mở file, và gặp một bài học thật: lần đầu nó nạp và gắn được nhưng không chặn gì — vì bpf chưa nằm trong danh sách LSM hoạt động. Bật bpf bằng tham số boot rồi reboot, cùng chương trình đó chặn thật — cat và python đều nhận Operation not permitted.
Tự Viết Một Chương Trình tc: __sk_buff và Chuỗi tcx
Bài 12 đọc datapath tc của Cilium từ ngoài. Bài này tự viết một chương trình tc — đếm và phân loại gói egress theo giao thức — để nắm __sk_buff từ trong ra. Điểm khác cốt lõi với XDP: tc thấy sk_buff với metadata đã điền sẵn (skb->protocol, skb->len), không phải gói thô. Ta gắn nó bằng tcx trên một interface thật, chạy ra số đếm đúng, rồi gặp một bài học thật: cùng chương trình đó gắn sau Cilium trên card mạng lại không chạy lần nào, vì cách chuỗi tcx kết thúc.
Verifier: Vì Sao eBPF Không Sập Nhân
Bài 1 nói thiết kế máy ảo eBPF cho phép verifier chứng minh an toàn. Bài này thấy nó làm thật: ta biên dịch một chương trình XDP đọc byte đầu của gói tin mà quên kiểm giới hạn, nạp vào nhân — verifier từ chối với log chỉ đích danh thanh ghi và lý do. Thêm đúng một câu kiểm data_end, verifier cho qua. Verifier là bộ chứng minh an toàn chạy lúc nạp, theo dõi trạng thái từng thanh ghi trên mọi nhánh — thứ khiến eBPF nạp được mã lạ vào nhân mà không như kernel module.
eBPF Từ Số Không: Chạy Chương Trình Trong Nhân Linux
Ngay lúc này, trên một worker của cụm Kubernetes ta dựng ở series trước, có 140 chương trình eBPF đang chạy bên trong nhân Linux — định tuyến từng gói tin, kiểm soát quyền truy cập thiết bị, gom metric. eBPF cho phép nạp mã vào nhân và chạy an toàn tại các điểm móc, không sửa mã nguồn nhân, không nạp module. Bài mở đầu series giải thích eBPF là gì, vì sao nó đổi cách mở rộng nhân, và một chương trình đi từ code tới mã máy chạy trong nhân ra sao.
Capstone: Tự Viết connmon — Monitor Kết Nối TCP Toàn Node
Bài cuối: ghép mọi thứ đã học thành một công cụ thật. connmon gắn kprobe vào tcp_connect trong nhân, đẩy mỗi kết nối TCP mới qua ring buffer, và một loader Go in chúng ra theo thời gian thực — pid, tiến trình, đích IP:port. Chỉ hơn trăm dòng, một binary tĩnh, chạy trên cụm thấy ngay coredns, kubelet, curl đang kết nối đi đâu. Kèm một cái bẫy build thật của kprobe. Rồi nhìn lại toàn bộ hành trình eBPF từ số không.