So sánh Istio, Linkerd và Cilium cho Kubernetes

Sau khi quyết định cụm của mình đủ phức tạp để cần một service mesh, câu hỏi tiếp theo là chọn cái nào. Ba cái tên xuất hiện nhiều nhất là Istio, Linkerd và Cilium. Cả ba đều giải quyết cùng một vấn đề, nhưng theo những cách rất khác nhau.

Istio: nhiều tính năng nhất, cũng phức tạp nhất

Istio dùng Envoy làm proxy, và gần như không thiếu tính năng nào: định tuyến traffic theo phần trăm, canary release, mTLS mặc định, chính sách retry chi tiết đến từng route. Cái giá là bề mặt cấu hình rất lớn. Đọc tài liệu Istio lần đầu, mình mất gần một buổi chỉ để hiểu sự khác nhau giữa VirtualService và DestinationRule.

Istio phù hợp khi hệ thống đủ lớn và đủ phức tạp để thật sự cần từng tính năng đó. Nếu chỉ cần mTLS và vài số liệu cơ bản, Istio giống như dùng một chiếc xe tải để chở một túi rau.

Linkerd: chọn sự đơn giản một cách có chủ đích

Linkerd đi theo hướng ngược lại. Proxy của nó (linkerd2-proxy) viết bằng Rust, nhẹ hơn Envoy đáng kể, và số lượng tính năng được giữ ở mức tối thiểu cần thiết: mTLS tự động, retry, và một dashboard số liệu gọn gàng. Không có ngôn ngữ cấu hình traffic phức tạp như Istio.

Cài Linkerd lần đầu, mình mất khoảng mười lăm phút để có mTLS chạy giữa các service, so với gần một ngày vật lộn với Istio trước đó. Đánh đổi là khi cần một tính năng nâng cao mà Linkerd không hỗ trợ, không có cách nào khác ngoài chuyển sang mesh khác.

Cilium: bỏ hẳn sidecar

Cilium đi theo một hướng khác hẳn hai cái trên. Thay vì chạy một proxy sidecar cho mỗi pod, Cilium dùng eBPF để xử lý traffic ngay ở tầng kernel của node, không cần thêm container nào vào pod. Điều này giảm đáng kể overhead CPU và RAM so với mô hình sidecar.

Cái giá là eBPF vẫn còn tương đối mới, và không phải kernel Linux nào cũng đủ mới để hỗ trợ đầy đủ tính năng. Với hạ tầng cũ hoặc quản lý bởi bên thứ ba không cho tuỳ chỉnh kernel, Cilium có thể không phải lựa chọn khả thi.

Bảng so sánh nhanh

	Istio	Linkerd	Cilium
Kiến trúc proxy	Sidecar (Envoy)	Sidecar (Rust)	Không sidecar (eBPF)
Độ phức tạp cấu hình	Cao	Thấp	Trung bình
Overhead tài nguyên	Cao	Thấp	Thấp nhất
Phù hợp nhất khi	Cần nhiều tính năng traffic nâng cao	Muốn mTLS và số liệu nhanh gọn	Hạ tầng mới, muốn hiệu năng tối ưu

Mình đã chọn Linkerd

Cụm của mình có khoảng hai mươi service, phần lớn vấn đề là thiếu mTLS và thiếu khả năng quan sát khi một service gọi sang service khác thất bại. Không có nhu cầu định tuyến traffic phức tạp. Linkerd giải quyết đúng vấn đề đó mà không bắt mình học một hệ thống cấu hình mới.

Phần cuối của series này là nhật ký cài Linkerd thật lên cụm, kèm vài lỗi mình gặp phải và cách xử lý.