So sánh cilium CILium, Calico và Flannel

Phạm Đăng Sa

1872

06-08-2026

So sánh CILium, Calico và Flannel: Kubernetes CNI cho năm 2026

Lựa chọn Container Network Interface (CNI) là một trong những quyết định quan trọng nhất khi triển khai Kubernetes vì nó ảnh hưởng trực tiếp đến hiệu năng mạng, mô hình bảo mật, khả năng giám sát và độ phức tạp trong vận hành. Việc thay đổi CNI sau khi cluster đi vào hoạt động thường rất khó và có thể phải xây dựng lại toàn bộ cluster.

Đến năm 2026, ba CNI phổ biến nhất là Cilium, Calico và Flannel. Mỗi giải pháp hướng đến một nhu cầu khác nhau: Cilium nổi bật với eBPF, hiệu năng cao và nhiều tính năng nâng cao; Calico phù hợp với môi trường doanh nghiệp nhờ khả năng định tuyến và quản lý network policy mạnh mẽ; Flannel tập trung vào sự đơn giản, dễ triển khai và vận hành.

Tóm tắt: Chọn Cilium nếu cần hiệu năng cao, eBPF, L7 Network Policy và Service Mesh; Calico nếu cần network policy toàn diện và khả năng mở rộng cho doanh nghiệp; Flannel nếu ưu tiên cấu hình đơn giản. Hiện nay, phần lớn các cluster Kubernetes production mới đều lựa chọn Cilium hoặc Calico.

Tiêu chí quan trọng khi lựa chọn CNI

Trước khi so sánh các tính năng, cần xác định những tiêu chí chính ảnh hưởng đến quyết định lựa chọn CNI:

• Hiệu năng mạng: Nếu ứng dụng yêu cầu kết nối giữa các pod với độ trễ thấp và thông lượng cao, các CNI dựa trên eBPF như Cilium sẽ mang lại hiệu năng tốt hơn nhờ giảm chi phí xử lý ở tầng kernel.

• Yêu cầu về Network Policy: Nếu chỉ cần các chính sách mạng ở L3/L4, hầu hết CNI đều đáp ứng được. Tuy nhiên, nếu cần L7 Network Policy (như lọc theo HTTP header hoặc DNS), Cilium là lựa chọn phù hợp, trong khi Calico và Flannel không hỗ trợ gốc.

• Độ phức tạp trong vận hành: Cilium cung cấp nhiều tính năng nhưng yêu cầu đội ngũ có chuyên môn cao hơn để triển khai và quản lý. Ngược lại, Flannel đơn giản, dễ cấu hình và vận hành nhất.

• Khả năng tương thích nền tảng: Cần xem xét CNI có hỗ trợ tốt trên managed Kubernetes hay Kubernetes cluster tự triển khai, vì mỗi giải pháp có mức độ tương thích khác nhau.

• Khả năng thay thế Service Mesh: Nếu cần các tính năng như quan sát lưu lượng (observability) hoặc mTLS, Cilium với Hubble và chế độ mTLS có thể đáp ứng một số trường hợp mà trước đây cần đến Service Mesh.

Cilium: eBPF-Native, tính năng đa dạng

#1 Cilium - Network, observability và bảo mật được hỗ trợ bởi eBPF

Kiến trúc

Dựa trên eBPF — bỏ qua kernel iptables path để giảm độ trễ đáng kể

CNCF Status

Graduated, là một trong những dự án Kubernetes trưởng thành nhất của CNCF.

Network Policy

L3/L4 và L7 (HTTP, gRPC, Kafka, DNS) - cung cấp khả năng kiểm soát lưu lượng chi tiết hơn hầu hết các CNI khác.

Observability

Hubble: khả năng hiển thị real-time network, hiển thị mối quan hệ giữa các service và ghi log truy vấn DNS.

Service Mesh

Cilium Service Mesh thay thế sidecar Envoy bằng eBPF cho mTLS và L7 load balancing 

Performance

Latency thấp hơn đáng kể so với các CNI iptables-based, đặc biệt trong môi trường có số lượng kết nối lớn.

Complexity

Cao nhất trong ba CNT - yêu cầu kernel Linux hỗ trợ eBPF (từ phiên bản 4.19 trở lên) và đội ngũ có kinh nghiệm triển khai.

Phù hợp nhất cho

Các Kubernetes production cluster yêu cầu Network Policy nâng cao, observability hoặc service mesh mạnh mẽ

Điểm nổi bật năm 2026

• Cilium 1.16 bổ sung nhiều tính năng mới như BGP dual-stack, cải thiện hỗ trợ Gateway API và tích hợp Tetragon để tăng cường bảo mật thời gian chạy (runtime security).

• Điểm mạnh cốt lõi của Cilium nằm ở eBPF. Thay vì sử dụng iptables như các CNI truyền thống, Cilium lập trình trực tiếp vào kernel Linux thông qua eBPF, giúp loại bỏ chi phí xử lý của hàng nghìn quy tắc iptables trên mỗi gói tin. Nhờ đó, Cilium mang lại độ trễ thấp hơn khoảng 20–30% trong môi trường có lưu lượng kết nối lớn, và lợi thế này càng rõ khi quy mô cluster tăng.
• Ngoài ra, Hubble – nền tảng quan sát của Cilium – cung cấp khả năng giám sát luồng mạng theo thời gian thực giữa các pod và giữa pod với các dịch vụ bên ngoài. Thông tin được hiển thị qua Prometheus, CLI và giao diện web, giúp đội ngũ SRE nhanh chóng xác định nguyên nhân của các sự cố kết nối mạng. Có thể xem Hubble như việc chạy tcpdump trên toàn bộ cluster nhưng gần như không ảnh hưởng đến hiệu năng.

# Install Cilium (Helm)

helminstallciliumcilium/cilium--version1.16.0\

--namespace kube-system \

 --setkubeProxyReplacement=true\

 --sethubble.relay.enabled=true\

 --set hubble.ui.enabled=true

# Verify Cilium status

ciliumstatus--wait 

# L7 NetworkPolicy example (HTTP-aware)

apiVersion:cilium.io/v2

kind:CiliumNetworkPolicy

metadata:

 name:payments-l7

spec:

 endpointSelector:

   matchLabels:{ app:payments}

 ingress:

 -fromEndpoints:

   -matchLabels:{ app:checkout }

   toPorts:

   -ports:[{port:'8080', protocol:TCP}]

     rules:

       http:

       -method:POST

         path:/v1/charge  # Only allow specific endpoint!

Calico: BGP doanh nghiệp, Policy toàn diện

#2 Calico - Mạng doanh nghiệp với BGP routing và policy đa dạng

Kiến trúc

iptables/eBPF (có thể cấu hình) - native routing với các tùy chọn BGP hoặc overlay

CNCF status

Không phải CNCF; mà duy trì bởi Tigera, được triển khai rộng rãi 

Network Policy

 L3/L4 với Global Network Policy; Calico Enterprise bổ sung L7 (yêu cầu Envoy)

Observability

Calico Enterprise: low logs, policy audit; OSS: hạn chế

Hỗ trợ BGP

Kết nối BGP gốc - route các pod trực tiếp trên physical network (không có overlay)

Độ phức tạp 

Trung bình - nhiều tùy chọn cấu hình hơn Flannel, nhưng dễ hơn Cilium 

Phù hợp nhất cho

Môi trường doanh nghiệp yêu cầu BGP, môi trường lớn, yêu cầu tuân thủ cao

Điểm nổi bật năm 2026 

eBPF dataplane ổn định, WireGuard encryption (Enterprise), cải thiện hỗ trợ Windows

# Install Calico

kubectlapply-fhttps://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico.yaml 

# GlobalNetworkPolicy: block metadata service access from all pods

apiVersion:projectcalico.org/v3

kind:GlobalNetworkPolicy

metadata:

 name:block-metadata

spec:

 order:0 # Applied before namespace policies

 selector:all()

 egress:

 -action:Deny

   destination:

     nets: ['169.254.169.254/32']  # AWS/GCP metadata service

 -action:Allow # Allow all other egress

Flannel: Overlay Networking đơn giản, đáng tin cậy

#3 Flannel - CNI đơn giản nhất - networking không có phức tạp

Kiến trúc

VXLAN overlay - mã hóa UDP đơn giản giữa các node

CNCF status

Không phải CNCF; mà duy trì bởi cộng đồng CoreOS/Red Hat

Network Policy

Không tích hợp sẵn - kết hợp với Calico policy engine (Canal) để hỗ trợ NetworkPolicy

Observability

Tối thiểu - hoàn toàn dựa vào các observability tool bên ngoài

Performance

Đủ tốt cho hầu hết các workload; có thêm chi phí đóng gói VXLAN ở high throughput 

Độ phức tạp

Thấp nhất - chỉ cần cấu hình tối thiểu, hoạt động ngay sau khi cài đặt trên hầu hết nền tảng.

Phù hợp nhất cho

Các development cluster, các proof-of-concept environment, các team ưu tiên sự đơn giản.

Điểm nổi bật năm 2026

Flannel ổn định nhưng không tích cực bổ sung tính năng; Canal (kết hợp Flannel + Calico policy) ngày càng được sử dụng nhiều hơn

Giá trị cốt lõi của Flannel nằm ở sự đơn giản: nó đã hoạt động trong nhiều năm và hầu như không yêu cầu chuyên môn cụ thể nào về CNI để vận hành. Đối với các team muốn giải quyết vấn đề Kubernetes network thay vì phải quan tâm nhiều đến kỹ thuật, Flannel đáp ứng được điều đó. Hạn chế chính là thiếu hỗ trợ Network Policy - hầu hết các môi trường production đều yêu cầu ít nhất là network segmentation cơ bản, điều này có nghĩa là phải kết hợp Flannel với policy engine của Calico (sự kết hợp Canal).

Năm 2026, Flannel ngày càng hiếm gặp trong các production deployment mới ở quy mô lớn. Các team vẫn sử dụng chủ yếu là: các development cluster nhỏ không yêu cầu network policy, các cluster cũ đã có trước khi Cilium và Calico đạt đến độ chín muồi hiện tại, và trong các doanh nghiệp, tổ chức mà sự đơn giản trong vận hành là ưu tiên hàng đầu.

So sánh trực tiếp

Quyết định lựa chọn

Chọn Cilium nếu:

• Bạn đang bắt đầu triển khai một cụm production mới năm nay và không có ràng buộc nào từ hệ thống cũ
• Cluster chạy ở quy mô lớn, tại đó lợi thế về hiệu suất của eBPF có thể đo lường được
• Bạn cần các network policy L7 cho bảo mật cấp độ HTTP/gRPC
• Bạn muốn có thể hiển thị network flow của Hubble mà không cần service mesh
• Team của bạn có thể đầu tư vào chuyên môn về eBPF/Cilium

Chọn Calico nếu:

• Bạn đã có các Calico deployment từ trước đó và chuyên môn vận hành công cụ này
• Bạn cần kết nối BGP với mạng data center vật lý
• Bạn có các multi-tenant cluster yêu cầu quản trị Global Network Policy
• Bạn đang hoạt động trong môi trường cần tuân thủ chặt chẽ và đang cân nhắc các tính năng Calico Enterprise compliance

Chọn Flannel nếu:

• Bạn đang xây dựng development cluster hoặc CI cluster mà không cần network policy i
• Cần ưu tiên khả năng vận hành đơn giản và quy mô ở mức vừa phải
• Bạn đang chuyển đổi từ một setup cơ bản và chưa sẵn sàng cho mức độ phức tạp của Cilium/Calico

Khuyến nghị năm 2026

Đối với mọi cụm Kubernetes production mới được triển khai trong năm 2026, Cilium là lựa chọn được khuyến nghị mặc định, trừ khi bạn có yêu cầu cụ thể về BGP routing (nên chọn Calico) hoặc ưu tiên tối đa sự đơn giản trong vận hành (nên chọn Flannel).

Với CNCF Graduated, cùng những lợi thế về hiệu năng nhờ eBPF và khả năng quan sát hệ thống thông qua Hubble, Cilium là lựa chọn mạnh mẽ nhất về mặt kỹ thuật cho các môi trường production.

Mặc dù cần đầu tư thời gian để làm chủ Cilium, nhưng chi phí này sẽ mang lại lợi ích lâu dài về hiệu năng, bảo mật và khả năng giám sát hệ thống.

Độc giả có thể trải nghiệm MIỄN PHÍ BKE và hệ tính năng được cập nhật thường xuyên tại: https://bizflycloud.vn/kubernetes-engine