Hướng dẫn cấu hình Cilium CNI: Tối ưu hiệu năng & bảo mật eBPF cho VPS Kubernetes

Tác giả: Trần Thảo 05 tháng 08, 2026

Cụm Kubernetes của bạn đang vận hành mượt mà ở quy mô vài chục container, nhưng ngay khi ứng dụng bùng nổ traffic và bạn scale lên hàng nghìn Pod/Service, những triệu chứng kỳ lạ bắt đầu xuất hiện: độ trễ mạng (latency) giữa các microservices tăng vọt, tình trạng CPU của VPS thỉnh thoảng chạm ngưỡng 100% không rõ lý do, và tồi tệ nhất là các request kết nối database bị drop (rớt gói tin) ngẫu nhiên. Nguyên nhân cốt lõi không nằm ở code của ứng dụng, cũng không phải do VPS yếu, mà nằm ngay tại kiến trúc mạng vật lý: iptables và kube-proxy đã chạm ngưỡng giới hạn chịu đựng.

Đó là lúc các Sysadmin và DevOps engineer phải tìm đến một kỷ nguyên định tuyến mới. Thay vì nhồi nhét hàng trăm nghìn rule tường lửa vào Netfilter khiến hệ thống ì ạch, chúng ta sẽ chuyển giao toàn bộ quyền kiểm soát xuống tầng hạt nhân (kernel) với tốc độ chớp nhoáng của eBPF. Bài viết này sẽ hướng dẫn bạn chi tiết từ A đến Z cách thay thế hoàn toàn CNI cũ bằng Cilium, tối ưu băng thông với thuật toán EDT, và đặc biệt là cách thiết lập bảo mật eBPF cho VPS một cách triệt để, an toàn nhất theo chuẩn công nghệ năm 2026.

Bạn đã sẵn sàng gỡ bỏ hoàn toàn cổ chai mạng và đưa tốc độ cụm K8s lên ngang tầm bare-metal chưa?

Tại sao iptables trở thành cổ chai và sức mạnh tra cứu O(1) của eBPF

Để hiểu tại sao chúng ta cần khai tử kube-proxy trên các cụm Kubernetes quy mô lớn, bạn cần nhìn sâu vào cách gói tin (packet) di chuyển (Data Path) và cách hệ thống cập nhật cấu hình (Control Plane).

Nỗi ám ảnh mang tên duyệt tuyến tính O(n)

Trong mô hình mạng truyền thống (như Calico ở chế độ mặc định hoặc Flannel), thành phần kube-proxy dịch mỗi Service và Endpoint thành các quy tắc (rules) tường lửa iptables. Hãy làm một bài toán nhỏ: Nếu cụm K8s của bạn có 10.000 Service, và mỗi Service gắn với khoảng 10 Backend Pod, kube-proxy sẽ phải sinh ra và nạp vào Kernel khoảng 420.000 dòng quy tắc iptables.

Khi một request HTTP đi qua mạng, nó không đi thẳng đến đích. Nó phải duyệt tuần tự từ trên xuống dưới chuỗi 420.000 quy tắc này cho đến khi tìm thấy rule khớp (mô hình độ phức tạp O(n)). Việc ép Kernel thực hiện hàng ngàn phép so sánh chuỗi liên tục khiến CPU tiêu tốn tới ~2.700 CPP (CPU Cycles Per Packet).

Tồi tệ hơn, ở Control Plane, iptables không hỗ trợ cập nhật một phần (incremental updates). Bất cứ khi nào một Pod bị xóa hoặc tạo mới do Auto-scaling, kube-proxy lại phải khóa luồng và ghi đè (re-programming) lại toàn bộ bảng quy tắc trên mọi Node. Hệ quả là CPU spikes (tăng vọt) cục bộ, gây nghẽn cổ chai và làm rớt các kết nối đang xử lý dang dở.

Giải pháp O(1) từ BPF Maps của Cilium

Cilium giải quyết bài toán này không phải bằng cách tối ưu iptables, mà bằng cách vứt bỏ nó hoàn toàn. Cilium nạp trực tiếp các đoạn mã eBPF (đã được JIT compile thành mã máy) vào Kernel Linux thông qua các Hook cực sớm như XDP, TC (Traffic Control), và Socket.

Thay vì duy trì danh sách tuyến tính, Cilium lưu trữ các policy và thông tin định tuyến vào các BPF Maps (bảng băm Hash Tables hoạt động trực tiếp trong RAM của Kernel). Một gói tin khi đi qua chỉ cần thực hiện một phép tra cứu duy nhất (O(1)) để biết chính xác nó cần đi đâu, kéo lượng CPU Cycles xuống chỉ còn ~1.280 CPP (giảm hơn một nửa so với iptables).

Đặc biệt, đối với lưu lượng East-West (nội bộ giữa các Pod trên cùng hoặc khác Node), Cilium thực hiện DNAT (Dịch địa chỉ mạng) ngay tại lệnh gọi connect() ở cấp độ Socket. Nghĩa là, gói tin khi vừa chui ra khỏi Socket của ứng dụng đã mang sẵn IP đích thực tế, bỏ qua hoàn toàn sự phức tạp của tầng xử lý mạng bên dưới.

Sơ đồ so sánh hiệu năng xử lý mạng giữa iptables duyệt tuyến tính và eBPF BPF Maps của Cilium CNI.

Sơ đồ minh họa Data Path: Cơ chế tra cứu tuyến tính O(n) chậm chạp của iptables (trái) so với tra cứu Hash map O(1) siêu tốc của eBPF ngay tại tầng Socket (phải).

Identity-based Security: Dẹp bỏ sự phụ thuộc vào IP tĩnh

Trong thế giới Cloud-Native, IP của Pod là một thứ vô giá trị vì nó liên tục thay đổi (IP Churn). Nếu bạn viết rule tường lửa chặn theo IP 10.42.0.15, rule đó sẽ vô dụng ngay khi Pod bị restart và nhận IP mới.

Cilium giải quyết triệt để vấn đề này bằng khái niệm Security Identity. Mỗi nhóm Pod sẽ được cấp một mã định danh duy nhất (dạng số) dựa trên metadata (như labels app=payment-api, namespace=prod). Dù hệ thống có auto-scale lên 1.000 Pod với 1.000 IP khác nhau, Security Identity vẫn là duy nhất. Khi cấu hình bảo mật, eBPF sẽ chặn/mở kết nối dựa trên Identity này, giúp hệ thống tường lửa đứng vững như bàn thạch trước sự biến động hạ tầng.

Tối kỵ khi chọn VPS chạy eBPF: Cảnh báo về ảo hóa và Kernel

Đây là bước mà rất nhiều kỹ sư ôm hận khi setup K8s trên các gói VPS giá rẻ. eBPF là công nghệ can thiệp cực kỳ sâu vào hệ thống lõi, do đó nó vô cùng kén hạ tầng nền tảng.

Tử huyệt mang tên OpenVZ/LXC (Shared Kernel)

Nếu bạn thuê VPS sử dụng công nghệ ảo hóa chia sẻ nhân (như OpenVZ hay LXC), việc cài đặt Cilium sẽ chắc chắn thất bại 100%.

Lý do bắt nguồn từ kiến trúc bảo mật của Kernel: Các chương trình eBPF được thiết kế để chạy trực tiếp trên Kernel vật lý. Nếu nhà cung cấp VPS cho phép nạp eBPF, một tiến trình độc hại từ VPS của bạn có thể nghe lén hoặc thao túng toàn bộ lưu lượng mạng của các khách hàng khác nằm chung trên máy chủ đó.

Để ngăn chặn thảm họa này, các nhà cung cấp OpenVZ/LXC luôn khóa cứng quyền CAP_SYS_ADMIN và CAP_BPF trên VPS của bạn. Không có quyền hạn tối cao này, Cilium không thể nạp bytecode vào kernel, và hệ thống tập tin đặc biệt /sys/fs/bpf cũng không thể được mount.

Nguyên tắc sống còn: BẮT BUỘC phải sử dụng VPS ảo hóa toàn phần (KVM hoặc Xen). Với KVM, bạn sở hữu một Kernel Linux độc lập tuyệt đối, có trọn quyền root thực sự và thoải mái thao tác ở Kernel Space mà không lo bị nhà cung cấp giới hạn.

Tiêu chuẩn cấu hình VPS cho mạng eBPF (chuẩn 2026)

Để các tính năng mạng nâng cao của Cilium hoạt động mượt mà, hạ tầng VPS của bạn cần đáp ứng các thông số sau:

Kernel >= 6.1 LTS: Mặc dù Cilium hỗ trợ từ nhân 5.10, nhưng để dùng được các kỹ thuật tiên tiến nhất như IPv4/IPv6 BIG TCP (giảm tải CPU khi throughput cao) và thuật toán QoS mới, Kernel 6.1+ là tiêu chuẩn bắt buộc cho production.
cgroup v2: Bắt buộc phải có để eBPF can thiệp vào tầng Socket. Nếu bạn đang tham khảo các hướng dẫn cấu hình VPS Ubuntu 26.04 LTS hay Debian 12, thì cgroup v2 đều đã được kích hoạt sẵn làm mặc định. Cilium sẽ tự động mount nó tại /run/cilium/cgroupv2.
Firewall Ports: Bạn phải cấu hình Security Group/Firewall của nhà cung cấp để mở port Firewall trên VPS Linux cho các luồng nội bộ giữa các Node: TCP 4240 (health check), UDP 8472 (VXLAN), TCP 6443 (K8s API Server) và UDP 51871 (Nếu kích hoạt WireGuard).

Hướng dẫn cấu hình Cilium: Xóa sổ kube-proxy và tối ưu băng thông VPS

Khi hạ tầng đã sẵn sàng, chúng ta bắt tay vào thực hành. Mục tiêu tối thượng của bước này là gỡ bỏ hoàn toàn sự hiện diện của iptables và thiết lập một Data Path thuần eBPF.

Bước 1: Dọn dẹp CNI cũ và gỡ bỏ hoàn toàn kube-proxy

Nếu cụm K8s của bạn đang chạy kube-proxy, việc gỡ bỏ nó sẽ gây gián đoạn mạng. Hãy thực hiện việc này trong một maintenance window.

Đầu tiên, xóa tài nguyên khỏi Control Plane:

kubectl -n kube-system delete daemonset kube-proxy
kubectl -n kube-system delete configmap kube-proxy

Tiếp theo, dọn dẹp tàn dư iptables rules nằm rải rác trên từng Node. Cách sạch sẽ và an toàn nhất là Reboot lại toàn bộ các Node VPS. Nếu hệ thống không cho phép downtime để reboot, hãy SSH vào từng Node và chạy lệnh thủ công với quyền root:

Dùng chính kube-proxy để tự dọn dẹp:

kube-proxy --cleanup

Hoặc lọc và xóa thủ công:

iptables-save | grep -v KUBE- | iptables-restore

Bước 2: Triển khai Cilium qua Helm ở chế độ strict

Vì kube-proxy đã bị xóa, Cilium agent sẽ không thể tự phân giải IP nội bộ của K8s API Server. Bạn bắt buộc phải khai báo tĩnh IP vật lý của Control Plane. Chúng ta sẽ sử dụng Helm CLI với cấu hình chuẩn cho nhánh Cilium v1.19.6:

helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium --version 1.19.6 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<IP_VẬT_LÝ_CỦA_API_SERVER> \
  --set k8sServicePort=6443 \
  --set bpf.masquerade=true \
  --set bandwidthManager.enabled=true \
  --set bandwidthManager.bbr=true

(Lưu ý: Tham số kubeProxyReplacement=true trong phiên bản mới tương đương với chế độ strict cũ, nó sẽ tự động báo lỗi và dừng cài đặt nếu Kernel của VPS bị thiếu tính năng).

Tối ưu QoS (quản lý băng thông) với cơ chế EDT

Một trong những vấn đề đau đầu nhất trên VPS là hiệu ứng noisy neighbor, một Pod chạy task nặng ăn hết sạch băng thông mạng của Node, khiến các Pod khác bị timeout.

Trong câu lệnh Helm phía trên, chúng ta đã cố tình thêm cờ --set bandwidthManager.enabled=true. Đây là một bản cập nhật cực kỳ giá trị. Kể từ các phiên bản gần đây, Cilium đã loại bỏ cơ chế hàng đợi Token Bucket Filter (TBF) cũ kỹ của Linux. Thay vào đó, Bandwidth Manager sử dụng thuật toán EDT (Earliest Departure Time) chạy hoàn toàn trong eBPF kết hợp với Fair Queue (FQ).

EDT hoạt động bằng cách gắn dấu thời gian xuất phát (timestamp) vào từng gói tin ngay khi nó rời khỏi Pod. Nếu gói tin vượt quá tốc độ giới hạn, eBPF không drop nó ngay lập tức mà sẽ trì hoãn việc gửi nó ra card mạng vật lý cho đến đúng thời điểm hợp lệ. Việc chuyển từ TBF sang EDT giúp loại bỏ hoàn toàn hiện tượng khóa phần mềm (locking) ở tầng dưới, giữ cho độ trễ luôn ở mức micro-second ngay cả khi mạng đang bị bóp băng thông tối đa.

Bước 3: Quyết định sinh tử: chọn VXLAN hay Native Routing?

Rất nhiều Sysadmin quen cấu hình bare-metal thường tự tin bật chế độ Native Routing để tối ưu tốc độ, nhưng khi đem lên VPS Cloud thì toàn bộ cluster bị sập mạng nội bộ. Tại sao vậy?

Khi bạn thuê nhiều VPS (ví dụ từ DigitalOcean hay Linode) để tạo cluster, các node này thường không nằm chung một dải mạng Layer 2 (L2). Nếu dùng Native Routing, gói tin mang IP nội bộ của Pod (ví dụ: 10.244.1.5) sẽ bị đẩy thẳng ra Router L3 của nhà cung cấp Cloud. Đương nhiên, Router của nhà mạng không hề biết dải IP ảo này thuộc về ai, và nó lập tức DROP gói tin vì xem đây là traffic rác.

Giải pháp bắt buộc cho VPS Cloud là giữ nguyên cấu hình mặc định: VXLAN (Overlay Routing). VXLAN hoạt động như một lớp ngụy trang hoàn hảo. Nó sẽ đóng gói (encapsulate) gói tin của Pod vào sâu bên trong một gói tin UDP tiêu chuẩn, bên ngoài dán địa chỉ IP vật lý hợp lệ của VPS. Gói tin sẽ nhẹ nhàng đi xuyên qua Router hạ tầng Cloud, đến Node đích an toàn trước khi được Cilium eBPF giải mã và giao cho Pod tương ứng.

Mô hình hoạt động của VXLAN Overlay Routing khi cấu hình Cilium Kubernetes trên hạ tầng VPS Cloud.

Cơ chế VXLAN: Ngụy trang gói tin nội bộ của Pod bằng IP vật lý của VPS để đi xuyên qua Router L3 của nhà cung cấp Cloud mà không bị DROP.

Thực thi bảo mật eBPF cho VPS: Zero-Trust và mã hóa toàn diện

Nếu chỉ dừng lại ở tối ưu tốc độ, bạn mới chỉ khai thác được 50% sức mạnh của Cilium. Giá trị to lớn nhất nằm ở việc thiết lập một không gian bảo mật eBPF cho VPS tuân thủ nguyên lý Zero-Trust: Mọi thứ mặc định là bị từ chối (Default-Deny). Việc này giúp bảo mật VPS Linux toàn diện từ tầng sâu nhất.

Ngăn chặn C2/Malware bằng L7 Policy (và lưu ý về Overhead)

Tường lửa iptables truyền thống chỉ nhận diện được IP và Port (L3/L4). Nếu hacker nhúng mã độc vào một request HTTP POST đi qua cổng 80, tường lửa sẽ cho qua một cách mù quáng. Cilium giải quyết việc này bằng cách tích hợp L7 Policy.

Tuy nhiên, đây là lưu ý kỹ thuật chí mạng: Việc xử lý mạng ở L3/L4 bằng eBPF diễn ra hoàn toàn trong Kernel Space (cực kỳ nhanh). Nhưng eBPF không sinh ra để đọc hiểu ngữ nghĩa của giao thức HTTP. Khi bạn áp dụng rule L7, Cilium bắt buộc phải đẩy gói tin thoát khỏi Kernel Space, đưa lên proxy Envoy chạy ở User Space để phân tích nội dung, sau đó đẩy ngược lại Kernel. Việc chuyển đổi bối cảnh (context switching) này tiêu tốn rất nhiều chu kỳ CPU và làm tăng độ trễ.

Khuyến nghị: Chỉ áp dụng L7 Policy cho các Service trọng yếu (như Payment API hoặc Gateway expose ra ngoài internet), TUYỆT ĐỐI không áp dụng bừa bãi cho toàn cụm.

Ví dụ: Chỉ cho phép Frontend gọi Backend bằng phương thức GET, chặn mọi hành vi POST/DELETE:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-only-get-http
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: core-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend-client
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/public/.*"

Minh họa chính sách bảo mật eBPF L7 Policy chặn HTTP POST và cho phép HTTP GET theo mô hình Zero-Trust.

Bảo mật eBPF cho VPS với L7 Policy: Dù có IP hay Identity hợp lệ, hệ thống vẫn soi chiếu sâu vào tầng ứng dụng để chặn đứng hành vi POST/DELETE trái phép.

Giới hạn FQDN Egress: Cắt đứt đường lùi của mã độc

Một container bị chiếm quyền (compromised) sẽ luôn tìm cách kết nối ngược về máy chủ điều khiển (C2 – Command & Control) của hacker. Hãy dùng FQDN Egress để khóa chặt chiều đi ra. Cilium sẽ can thiệp vào tiến trình phân giải DNS để đảm bảo Pod chỉ được phép truy cập các tên miền (Domain) đã được phê duyệt.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: restrict-egress-fqdn
spec:
  endpointSelector:
    matchLabels:
      app: secure-app
  egress:
  # Bước 1: Cho phép Pod query DNS nội bộ để lấy IP
  - toEndpoints:
    - matchLabels:
        "k8s:io.kubernetes.pod.namespace": kube-system
        k8s-app: kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: UDP
      rules:
        dns:
        - matchPattern: "*"
  # Bước 2: Chỉ cho phép lưu lượng đi ra domain chỉ định
  - toFQDNs:
    - matchName: "api.stripe.com"
    - matchPattern: "*.aws.amazon.com"
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP

Kích hoạt Transparent WireGuard và bài toán phân mảnh MTU

Khi thuê VPS, dữ liệu giữa các Node của bạn sẽ đi qua mạng vật lý nội bộ của nhà cung cấp Cloud (ví dụ VPC của DigitalOcean/Vultr). Để tránh rủi ro bị sniff dữ liệu từ các tenant khác, bạn cần mã hóa toàn bộ lưu lượng Pod-to-Pod.

Với Cilium, bạn kích hoạt WireGuard cực kỳ dễ dàng thông qua 2 dòng lệnh Helm:

  --set encryption.enabled=true \
  --set encryption.type=wireguard

Cilium sẽ tự sinh cặp khóa, chia sẻ public key ngầm qua K8s Annotation và mã hóa toàn bộ dữ liệu qua cổng UDP 51871 một cách trong suốt. Tuy nhiên, hãy cẩn trọng với bẫy MTU (Maximum Transmission Unit).

Kích thước khung dữ liệu chuẩn của Ethernet thường là 1500 bytes. Nếu bạn dùng cấu hình mặc định (VXLAN overlay), Header của VXLAN sẽ ăn mất 50 bytes. Khi nhồi thêm WireGuard, nó sẽ cắn thêm 60 bytes (IPv4) hoặc 80 bytes (IPv6) nữa.

Lúc này, kích thước payload thực tế còn lại cho ứng dụng chỉ là: 1500 - 50 - 60 = 1390 bytes.

Nếu MTU của card mạng ảo trong Pod không được tinh chỉnh giảm xuống mức 1390, các gói tin lớn hơn sẽ bị chia nhỏ (fragmentation) hoặc bị DROP thẳng tay, gây ra lỗi timeout ngẫu nhiên. Cilium v1.19.6 thường tự động tính toán lại MTU khá tốt, nhưng nếu bạn đang triển khai trên môi trường CNI Chaining (chạy đè Cilium lên CNI của AWS/GCP), bạn bắt buộc phải chủ động khai báo cờ --set cni.enableRouteMTUForCNIChaining=true để tránh sập mạng diện rộng.

Mô phỏng cấu trúc gói tin và rủi ro phân mảnh MTU khi dùng WireGuard mã hóa cùng VXLAN trên Kubernetes.

Bài toán MTU thực chiến: Header của VXLAN và WireGuard đã cắn mất 110 bytes của gói tin. Nếu không chủ động cấu hình hạ MTU cho Pod, mạng sẽ lập tức nghẽn và timeout.

Hubble: Mắt thần giám sát mạng và Troubleshooting thực chiến

Khi áp dụng mô hình bảo mật Default-Deny, chắc chắn bạn sẽ gặp cảnh ứng dụng báo lỗi Connection Refused do cấu hình sai rule YAML. Quên lệnh tcpdump bắt IP vô hồn đi. Để xử lý sự cố chuẩn mực, Sysadmin nên ưu tiên thiết lập Grafana Dashboard đầu tiên với Prometheus để kết hợp cùng Hubble (công cụ Observability đi kèm Cilium).

Vì eBPF gắn trực tiếp với Kernel và hiểu rõ ngữ cảnh của Kubernetes, Hubble có thể dịch ngược các hành vi mạng thành tên Pod, tên Namespace và nhãn cụ thể. Để truy vết trực tiếp các request đang bị chặn theo thời gian thực, hãy mở terminal và gõ:

Lọc toàn bộ gói tin bị rớt (DROP) trong cụm:

hubble observe --type drop

Khoanh vùng sự cố, chỉ xem gói tin rớt của đích danh 1 Pod:

hubble observe --pod payment-gateway-5f7d --type drop

Xem các gói bị chặn khi cố thoát ra ngoài Internet:

hubble observe --type drop --dest-label reserved:world

Kết quả trả về không phải là những chuỗi mã Hex khó hiểu. Nó sẽ hiển thị rõ Verdict: DENIED (Phán quyết: Từ chối), kèm theo chính xác Policy Name (Tên rule YAML) đang thực thi lệnh chặn đó. Nhờ vậy, thay vì mò mẫm hàng giờ đồng hồ, bạn có thể sửa trực tiếp cấu hình firewall chỉ trong 5 phút.

Câu hỏi thường gặp (FAQ)

1. Cấu hình VPS tối thiểu để chạy Cilium CNI là gì?

Tối thiểu 2 vCPU, 2GB RAM, Kernel Linux >= 5.10 (khuyến nghị 6.1+ LTS), và bắt buộc dùng ảo hóa KVM/Xen. Nếu VPS có RAM dưới 2GB, hãy tắt tính năng Hubble UI để tránh OOM (Out of Memory).

2. Tại sao cài Cilium trên VPS OpenVZ lại báo lỗi?

Vì OpenVZ dùng chung Kernel (nhân) với máy chủ vật lý. Để bảo mật, nhà cung cấp sẽ khóa cứng quyền CAP_SYS_ADMIN và CAP_BPF của bạn. Không có quyền này, Cilium không thể nạp mã eBPF vào Kernel. Khắc phục: Bắt buộc đổi sang thuê VPS KVM.

3. Cài đặt Cilium có làm VPS tốn nhiều RAM và CPU hơn iptables không?

Về CPU: Nhẹ và xử lý mạng nhanh hơn gấp đôi iptables nhờ tra cứu $O(1)$. Về RAM: Sẽ tốn nhiều hơn một chút do tiến trình cilium-agent phải duy trì các BPF Maps trong Kernel.

4. Làm sao để sửa lỗi timeout khi dùng WireGuard với Cilium?

Lỗi này 99% do phân mảnh MTU. Header của VXLAN (50 bytes) cộng với WireGuard (60-80 bytes) làm gói tin bị phình to quá giới hạn 1500 bytes. Khắc phục: Cấu hình hạ MTU của card mạng ảo trong Pod xuống mức ~1390 bytes (có thể dùng cờ --set cni.enableRouteMTUForCNIChaining=true nếu dùng CNI Chaining).

5. Tôi có thể chạy song song Cilium với CNI cũ (như Calico/Flannel) không?

Có thể (CNI Chaining) nhưng không nên đối với VPS tự build. Việc chạy song song làm tăng overhead, tốn tài nguyên và mất đi ưu thế tốc độ mạng của eBPF. Hãy dọn sạch CNI cũ và dùng Cilium thay thế hoàn toàn.

6. Dữ liệu giám sát của Hubble được lưu ở đâu? Có làm đầy ổ cứng VPS không?

Không. Hubble lưu log mạng trong bộ đệm vòng (Ring buffer) trên RAM, tự động ghi đè dữ liệu cũ khi đầy. Ổ cứng VPS của bạn an toàn tuyệt đối. Để lưu dài hạn, bạn phải tự export ra Prometheus/Grafana.

Kết luận

Việc chuyển dịch từ hệ sinh thái Netfilter/iptables sang eBPF thông qua Cilium không chỉ đơn thuần là thay đổi một CNI, mà đó là sự lột xác hoàn toàn về mặt kiến trúc hạ tầng cho Kubernetes.

Áp dụng đúng chiến lược từ bài viết này, từ việc hiểu rõ Overhead của Layer 7, tránh bẫy phân mảnh MTU của WireGuard, cho đến việc thiết lập bảo mật eBPF cho VPS bằng mô hình Zero-Trust, hệ thống của bạn sẽ loại bỏ triệt để các đợt giật lag CPU, xử lý hàng vạn Service ở tốc độ O(1) chớp nhoáng và giám sát mọi ngóc ngách của cụm với Hubble.

Tài liệu tham khảo