Cấu hình và Triển khai Cilium với chế độ eBPF
Chúng ta sẽ bắt đầu bằng việc thêm repository Helm chính thức của Cilium vào môi trường Kubernetes. Bước này là tiền đề để tải xuống các manifest cần thiết cho việc cài đặt agent.
Thực thi lệnh sau để thêm Helm Chart Repository:
helm repo add cilium https://helm.cilium.io/
Kết quả mong đợi: Thông báo "repository 'cilium' has been added" xuất hiện, xác nhận repository đã được ghi nhận.
Tiếp theo, chúng ta cần tạo file cấu hình giá trị (values.yaml) để kích hoạt chế độ eBPF. File này sẽ cấu hình Cilium sử dụng backend eBPF thay vì iptables, đồng thời bật tính năng XDP (eXpress Data Path) để tăng tốc độ chuyển tiếp gói tin.
Đường dẫn file: ./cilium-values.yaml
Nội dung hoàn chỉnh:
ipam:
mode: "kubernetes"
kubeProxyReplacement: "strict"
kubeProxyReplacementHealthCheckNodePort: 9999
bpf:
masquerade: true
xdp:
mode: "auto"
cgroup:
hostCgroup2Path: /sys/fs/cgroup
l7:
policy:
enabled: true
ingress:
enabled: true
egress:
enabled: true
logs:
defaultAction:
log: true
deny: true
hubble:
enabled: true
metrics:
enabled:
- "dns"
- "http"
- "k8s"
- "tls"
relay:
enabled: true
ui:
enabled: true
tls:
auto: true
Kết quả mong đợi: File được tạo thành công, chứa cấu hình bật IPAM Kubernetes, thay thế kube-proxy, kích hoạt XDP mode auto và bật chính sách L7 cùng Hubble cho giám sát.
Thư mục cài đặt Cilium vào cluster thông qua Helm với file cấu hình vừa tạo. Lệnh này sẽ deploy các resource bao gồm DaemonSet, CRDs và ConfigMaps cần thiết.
Thực thi lệnh cài đặt:
helm install cilium cilium/cilium --namespace kube-system --create-namespace -f ./cilium-values.yaml --wait --timeout 10m
Kết quả mong đợi: Quá trình deploy hoàn tất, hiển thị trạng thái "STATUS: deployed" và không có lỗi liên quan đến CRD hoặc RBAC.
Kiểm tra trạng thái Pod và tính sẵn sàng của Agent
Sau khi Helm hoàn thành việc deploy, chúng ta cần xác minh rằng các Pod của Cilium Agent đã chạy trên tất cả các Node và đã sẵn sàng xử lý lưu lượng.
Liệt kê các Pod trong namespace kube-system để kiểm tra trạng thái của Cilium:
kubectl get pods -n kube-system | grep cilium
Kết quả mong đợi: Các Pod hiển thị trạng thái Running và số lần restart là 0. Số lượng Pod phải tương ứng với số lượng Node trong cluster.
Cilium cung cấp công cụ CLI riêng là cilium status để kiểm tra sâu hơn về tính tương thích của kernel và trạng thái của các thành phần eBPF. Đây là bước quan trọng nhất để đảm bảo eBPF đã hoạt động.
Thực thi lệnh kiểm tra trạng thái chi tiết:
kubectl -n kube-system exec -it $(kubectl get pods -n kube-system -l k8s-app=cilium -o jsonpath='{.items[0].metadata.name}') -- cilium status
Kết quả mong đợi: Màn hình hiển thị bảng trạng thái với các dòng sau:
- Default Identity: 1
- Pod Protected: Hiển thị số lượng Pod được bảo vệ (phải > 0)
- Policy Enforcement: Enabled
- BPF Program: Enabled
- XDP Mode: auto (hoặc native)
Nếu thấy dòng "Policy Enforcement: Disabled" hoặc "BPF Program: Disabled", hãy kiểm tra lại kernel module và config file ở bước trước.
Hiểu cơ chế hoạt động của BPF XDP và Cgroup L7
Trong kiến trúc eBPF của Cilium, XDP (eXpress Data Path) là cơ chế xử lý gói tin ngay tại lớp Network Driver, trước khi gói tin vào vào stack mạng của kernel. Điều này cho phép Cilium thực hiện các thao tác như chuyển tiếp, drop hoặc forward cực nhanh với chi phí CPU thấp nhất.
Kiểm tra xem các chương trình BPF XDP đã được load vào kernel như thế nào:
sudo cilium bpf ls | grep xdp
Kết quả mong đợi: Danh sách hiển thị các map và program có tên chứa "xdp", ví dụ: xdp_proxy, xdp_redirect. Điều này xác nhận XDP đã được kích hoạt.
Cơ chế Cgroup L7 (Layer 7) hoạt động ở lớp ứng dụng, sử dụng eBPF để intercept các cuộc gọi hệ thống (syscalls) như connect(), sendmsg(), accept(). Khi gói tin HTTP hoặc gRPC đi qua, Cgroup L7 sẽ phân tích header và so sánh với CiliumNetworkPolicy để quyết định cho phép hay chặn.
Để xác minh cơ chế này, chúng ta cần kiểm tra xem Cilium có đang theo dõi các socket trong cgroup2 hay không:
sudo cilium bpf ls | grep "sock_ops"
Kết quả mong đợi: Xuất hiện các map liên quan đến socket operations, chứng tỏ Cilium đã sẵn sàng để can thiệp vào lưu lượng L7.
Cấu hình file /sys/fs/cgroup trên node host là bắt buộc. Nếu host chưa mount cgroup2, Cilium sẽ không thể kích hoạt L7 policy. Kiểm tra mountpoint:
mount | grep cgroup2
Kết quả mong đợi: Dòng output hiển thị type cgroup2 được mount tại /sys/fs/cgroup. Nếu không thấy, cần cấu hình lại systemd hoặc fstab của host trước khi triển khai lại Cilium.
Xác minh khả năng chuyển tiếp gói tin bằng eBPF
Bước cuối cùng là tạo một luồng lưu lượng thực tế để xác minh rằng Cilium đang sử dụng eBPF để chuyển tiếp gói tin thay vì iptables truyền thống.
Đầu tiên, tạo một Pod nguồn (client) và một Pod đích (server) trong cùng một namespace để đơn giản hóa kiểm tra. Chúng ta sẽ dùng image nginx đơn giản.
Tạo Pod server:
kubectl run server --image=nginx:alpine -n default --port=80
Tạo Pod client:
kubectl run client --image=busybox:latest -n default --rm -i --tty
Trong Pod client, thực hiện lệnh curl để truy cập Pod server. Lưu ý: Busybox không có curl mặc định, ta sẽ dùng wget hoặc cấu hình sẵn curl nếu có. Ở đây dùng wget -qO-:
wget -qO- http://server.default.svc.cluster.local
Kết quả mong đợi: Xuất hiện nội dung HTML của trang mặc định nginx, chứng minh kết nối thành công.
Quan trọng nhất, chúng ta cần xem log của Cilium để xác nhận gói tin được xử lý bởi eBPF (cụ thể là XDP hoặc Cgroup).
Xuất log của Cilium Agent tương ứng với Node mà Pod client đang chạy:
kubectl logs -n kube-system $(kubectl get pods -n kube-system -l k8s-app=cilium -o jsonpath='{.items[0].metadata.name}') | grep "to-identity" | grep "client"
Kết quả mong đợi: Các dòng log xuất hiện với thông tin direction: ingress hoặc egress, và quan trọng hơn là dòng via: bpf hoặc via: xdp. Nếu thấy via: iptables, có nghĩa cấu hình eBPF chưa đúng hoặc fallback xảy ra.
Để kiểm tra sâu hơn về hiệu năng của XDP, sử dụng lệnh cilium stats để xem số lượng gói tin đã được xử lý bởi eBPF:
kubectl -n kube-system exec -it $(kubectl get pods -n kube-system -l k8s-app=cilium -o jsonpath='{.items[0].metadata.name}') -- cilium stats
Kết quả mong đợi: Bảng thống kê hiển thị số lượng packets và bytes đã tăng lên tại các mục bpf_redirect, xdp_redirect hoặc sock_redirect sau khi thực hiện lệnh wget ở trên. Điều này khẳng định lưu lượng đang đi qua đường truyền eBPF.
Điều hướng series:
Mục lục: Series: Xây dựng nền tảng Secure Service Mesh với eBPF, Cilium và Policy Engine
« Phần 1: Chuẩn bị môi trường và kiến thức nền tảng cho Service Mesh
Phần 3: Thiết lập chính sách bảo mật mạng (Network Policy) với Cilium »