Đây là bản cập nhật của tôi , hiện chạy trên Kubernetes 1.14 với phiên bản CNI mới nhất kể từ tháng 2019 năm XNUMX.
Trước hết, tôi muốn cảm ơn nhóm Cilium: các bạn đã giúp tôi kiểm tra và sửa các tập lệnh giám sát số liệu.
Điều gì đã thay đổi kể từ tháng 2018 năm XNUMX
Đây là những gì đã thay đổi kể từ đó (nếu bạn quan tâm):
Flannel vẫn là giao diện CNI nhanh nhất và đơn giản nhất, nhưng vẫn không hỗ trợ chính sách mạng và mã hóa.
Romana không còn được hỗ trợ nữa nên chúng tôi đã xóa nó khỏi điểm chuẩn.
WeaveNet hiện hỗ trợ các chính sách mạng cho Ingress và Egress! Nhưng năng suất đã giảm.
Trong Calico, bạn vẫn cần định cấu hình thủ công kích thước gói tối đa (MTU) để có hiệu suất tốt nhất. Calico cung cấp hai tùy chọn để cài đặt CNI, vì vậy bạn có thể thực hiện mà không cần kho lưu trữ ETCD riêng:
- lưu trữ trạng thái trong API Kubernetes dưới dạng kho lưu trữ dữ liệu (kích thước cụm <50 nút);
- lưu trữ trạng thái trong API Kubernetes dưới dạng kho lưu trữ dữ liệu với proxy Typha để giảm tải cho API K8S (kích thước cụm > 50 nút).
Calico công bố hỗ trợ trên Istio để bảo mật cấp ứng dụng.
Cilium hiện hỗ trợ mã hóa! Cilium cung cấp mã hóa với các đường hầm IPSec và cung cấp giải pháp thay thế cho mạng WeaveNet được mã hóa. Nhưng WeaveNet nhanh hơn Cilium khi kích hoạt mã hóa.
Cilium giờ đây dễ triển khai hơn nhờ toán tử ETCD tích hợp.
Nhóm Cilium đã cố gắng giảm bớt trọng lượng của CNI bằng cách giảm mức tiêu thụ bộ nhớ và chi phí CPU, nhưng các đối thủ cạnh tranh của họ vẫn nhẹ hơn.
Bối cảnh điểm chuẩn
Điểm chuẩn được chạy trên ba máy chủ Supermicro không ảo hóa với bộ chuyển đổi Supermicro 10 Gb. Các máy chủ được kết nối trực tiếp với bộ chuyển mạch thông qua cáp DAC SFP+ thụ động và được cấu hình trên cùng một VLAN với các khung jumbo (MTU 9000).
Kubernetes 1.14.0 được cài đặt trên Ubuntu 18.04 LTS với Docker 18.09.2 (phiên bản Docker mặc định trong bản phát hành này).
Để cải thiện khả năng tái tạo, chúng tôi đã quyết định luôn định cấu hình phần chính trên nút đầu tiên, đặt phần máy chủ của điểm chuẩn trên máy chủ thứ hai và phần máy khách trên nút thứ ba. Để thực hiện việc này, chúng tôi sử dụng NodeSelector trong quá trình triển khai Kubernetes.
Chúng tôi sẽ mô tả kết quả điểm chuẩn theo thang điểm sau:
Chọn CNI làm điểm chuẩn
Đây chỉ là điểm chuẩn dành cho CNI từ danh sách trong phần Xem tài liệu chính thức của Kubernetes. Trong số 9 CNI, chúng tôi sẽ chỉ lấy 6 CNI: chúng tôi sẽ loại trừ những CNI khó cài đặt và/hoặc không hoạt động nếu không có cấu hình theo tài liệu (Romana, Contiv-VPP và JuniperContrail/TungstenFabric).
Chúng ta sẽ so sánh các CNI sau:
- Calico v3.6
- Canal v3.6 (về cơ bản là Flannel để kết nối mạng + Calico làm tường lửa)
- Cilium 1.4.2
- Vải nỉ 0.11.0
- Bộ định tuyến Kube 0.2.5
- DệtNet 2.5.1
Cài đặt
CNI càng dễ cài đặt thì ấn tượng đầu tiên của chúng ta càng tốt. Tất cả CNI từ điểm chuẩn đều rất dễ cài đặt (với một hoặc hai lệnh).
Như chúng tôi đã nói, các máy chủ và bộ chuyển mạch được cấu hình với các khung jumbo được kích hoạt (chúng tôi đặt MTU thành 9000). Chúng tôi sẽ rất vui nếu CNI tự động xác định MTU dựa trên cấu hình của bộ điều hợp. Tuy nhiên, chỉ có Cilium và Flannel mới làm được điều này. Các CNI còn lại có yêu cầu trên GitHub để thêm tính năng phát hiện MTU tự động, nhưng chúng tôi sẽ định cấu hình thủ công bằng cách thay đổi Bản đồ cấu hình cho Calico, Canal và Kube-router hoặc chuyển một biến môi trường cho WeaveNet.
Vấn đề với MTU không chính xác là gì? Sơ đồ này cho thấy sự khác biệt giữa WeaveNet với MTU mặc định và khung jumbo được bật:
MTU ảnh hưởng đến thông lượng như thế nào?
Chúng ta đã thấy MTU quan trọng như thế nào đối với hiệu suất, bây giờ hãy xem CNI của chúng ta tự động xác định nó như thế nào:
CNI tự động phát hiện MTU
Biểu đồ cho thấy bạn cần định cấu hình MTU cho Calico, Canal, Kube-router và WeaveNet để có hiệu suất tối ưu. Cilium và Flannel có thể tự xác định chính xác MTU mà không cần bất kỳ cài đặt nào.
Безопасность
Chúng ta sẽ so sánh bảo mật CNI ở hai khía cạnh: khả năng mã hóa dữ liệu được truyền và việc triển khai các chính sách mạng Kubernetes (dựa trên các thử nghiệm thực tế chứ không phải tài liệu).
Chỉ có hai dữ liệu mã hóa CNI: Cilium và WeaveNet. Mã hóa DệtNet được bật bằng cách đặt mật khẩu mã hóa làm biến môi trường CNI. TRONG WeaveNet mô tả nó một cách phức tạp nhưng mọi thứ đều được thực hiện đơn giản. Mã hóa lông mao được định cấu hình bằng lệnh, bằng cách tạo bí mật Kubernetes và thông qua sửa đổi daemonSet (phức tạp hơn một chút so với trong WeaveNet, nhưng Cilium có hướng dẫn từng bước ).
Về việc thực hiện chính sách mạng, họ đã thành công Calico, Canal, Cilium và WeaveNet, trong đó bạn có thể định cấu hình quy tắc Vào và Ra. Vì Bộ định tuyến Kube có các quy tắc chỉ dành cho Ingress và Flannel Không có chính sách mạng nào cả.
Dưới đây là kết quả chung cuộc:
Kết quả điểm chuẩn hiệu suất an toàn
Năng suất
Điểm chuẩn này cho thấy thông lượng trung bình trong ít nhất ba lần chạy của mỗi bài kiểm tra. Chúng tôi kiểm tra hiệu suất của TCP và UDP (sử dụng iperf3), các ứng dụng thực như HTTP (với Nginx và cuộn tròn) hoặc FTP (với vsftpd và cuộn tròn) và cuối cùng là hiệu suất ứng dụng bằng cách sử dụng mã hóa dựa trên SCP (sử dụng máy khách và máy chủ OpenSSH).
Đối với tất cả các thử nghiệm, chúng tôi đã thực hiện điểm chuẩn kim loại trần (đường màu xanh lá cây) để so sánh hiệu suất CNI với hiệu suất mạng gốc. Ở đây chúng tôi sử dụng cùng một tỷ lệ, nhưng về màu sắc:
- Vàng = rất tốt
- Cam = tốt
- Màu xanh = bình thường
- Đỏ = xấu
Chúng tôi sẽ không lấy các CNI được định cấu hình không chính xác và sẽ chỉ hiển thị kết quả cho các CNI có MTU chính xác. (Lưu ý: Cilium không tính toán chính xác MTU nếu bạn bật mã hóa, vì vậy bạn sẽ phải giảm MTU xuống 8900 theo cách thủ công trong phiên bản 1.4. Phiên bản tiếp theo, 1.5, tự động thực hiện việc này.)
Đây là kết quả:
Hiệu suất TCP
Tất cả CNI đều hoạt động tốt trong tiêu chuẩn TCP. CNI với mã hóa tụt hậu rất xa vì mã hóa đắt tiền.
Hiệu suất UDP
Ở đây cũng vậy, tất cả CNI đều đang hoạt động tốt. CNI với mã hóa cho thấy kết quả gần như tương tự. Cilium đi sau đối thủ một chút, nhưng nó chỉ chiếm 2,3% kim loại trần nên đây không phải là một kết quả tồi. Đừng quên rằng chỉ Cilium và Flannel mới tự xác định chính xác MTU và đây là kết quả của họ mà không cần bất kỳ cấu hình bổ sung nào.
Thế còn một ứng dụng thực tế thì sao? Như bạn có thể thấy, hiệu suất tổng thể của HTTP thấp hơn một chút so với TCP. Ngay cả khi bạn sử dụng HTTP với TCP, chúng tôi đã định cấu hình iperf3 trong điểm chuẩn TCP để tránh việc khởi động chậm có thể ảnh hưởng đến điểm chuẩn HTTP. Mọi người đã làm rất tốt ở đây. Bộ định tuyến Kube có lợi thế rõ ràng, nhưng WeaveNet hoạt động không tốt: kém hơn khoảng 20% so với kim loại trần. Cilium và WeaveNet với mã hóa trông thật đáng buồn.
Với FTP, một giao thức dựa trên TCP khác, kết quả sẽ khác nhau. Flannel và Kube-router thực hiện công việc, nhưng Calico, Canal và Cilium chậm hơn một chút và chậm hơn khoảng 10% so với kim loại trần. WeaveNet tụt lại phía sau tới 17%, nhưng WeaveNet được mã hóa lại dẫn trước Cilium được mã hóa 40%.
Với SCP, chúng ta có thể thấy ngay chi phí mã hóa SSH của chúng ta là bao nhiêu. Hầu như tất cả CNI đều hoạt động tốt, nhưng WeaveNet lại bị tụt lại phía sau. Cilium và WeaveNet có mã hóa được cho là kém nhất do mã hóa kép (SSH + CNI).
Dưới đây là bảng tóm tắt với kết quả:
Tiêu thụ tài nguyên
Bây giờ hãy so sánh cách CNI tiêu thụ tài nguyên khi tải nặng (trong quá trình truyền TCP, 10 Gbps). Trong các thử nghiệm hiệu suất, chúng tôi so sánh CNI với kim loại trần (đường màu xanh lá cây). Để tiêu thụ tài nguyên, hãy hiển thị Kubernetes thuần túy (đường màu tím) không có CNI và xem CNI tiêu thụ thêm bao nhiêu tài nguyên.
Hãy bắt đầu với bộ nhớ. Đây là giá trị trung bình cho RAM của các nút (không bao gồm bộ đệm và bộ đệm) tính bằng MB trong quá trình truyền.
Tiêu thụ bộ nhớ
Flannel và Kube-router cho kết quả xuất sắc - chỉ 50 MB. Calico và Canal mỗi nơi có 70. WeaveNet rõ ràng tiêu thụ nhiều hơn những cái khác - 130 MB và Cilium sử dụng tới 400.
Bây giờ hãy kiểm tra mức tiêu thụ thời gian của CPU. Đáng chú ý: sơ đồ không hiển thị tỷ lệ phần trăm mà là ppm, tức là 38 ppm đối với “sắt trần” là 3,8%. Dưới đây là kết quả:
mức tiêu thụ CPU
Calico, Canal, Flannel và Kube-router có hiệu suất CPU rất cao - chỉ hơn 2% so với Kubernetes không có CNI. WeaveNet tụt lại phía sau rất xa với thêm 5%, tiếp theo là Cilium ở mức 7%.
Dưới đây là tóm tắt về mức tiêu thụ tài nguyên:
Kết quả
Bảng với tất cả các kết quả:
Kết quả benchmark chung
Kết luận
Phần cuối cùng tôi sẽ bày tỏ ý kiến chủ quan của mình về kết quả. Hãy nhớ rằng điểm chuẩn này chỉ kiểm tra thông lượng của một kết nối trên một cụm rất nhỏ (3 nút). Nó không áp dụng cho các cụm lớn (<50 nút) hoặc kết nối song song.
Tôi khuyên bạn nên sử dụng các CNI sau tùy theo tình huống:
- Bạn có trong cụm của bạn không các nút có ít tài nguyên (vài GB RAM, nhiều lõi) và bạn không cần các tính năng bảo mật - hãy chọn Flannel. Đây là một trong những CNI hiệu quả nhất về mặt chi phí. Và nó tương thích với nhiều kiến trúc khác nhau (amd64, arm, arm64, v.v.). Ngoài ra, đây là một trong hai CNI (còn lại là Cilium) có thể tự động xác định MTU nên bạn không cần phải cấu hình gì cả. Bộ định tuyến Kube cũng phù hợp, nhưng nó không đạt tiêu chuẩn và bạn sẽ cần phải định cấu hình MTU theo cách thủ công.
- Nếu cần thiết mã hóa mạng để an toàn, hãy lấy DệtNet. Đừng quên chỉ định kích thước MTU nếu bạn đang sử dụng khung jumbo và bật mã hóa bằng cách chỉ định mật khẩu thông qua biến môi trường. Nhưng tốt hơn hết là hãy quên đi hiệu suất - đó là chi phí mã hóa.
- vì sử dụng bình thường khuyên nhủ một thứ vải trắng. CNI này được sử dụng rộng rãi trong các công cụ triển khai Kubernetes khác nhau (Kops, Kubespray, Rancher, v.v.). Giống như WeaveNet, hãy đảm bảo định cấu hình MTU trong ConfigMap nếu sử dụng khung jumbo. Nó là một công cụ đa chức năng, hiệu quả về mặt tiêu thụ tài nguyên, hiệu suất và bảo mật.
Và cuối cùng, tôi khuyên bạn nên theo dõi sự phát triển lông mao. CNI này có một nhóm rất năng động, làm việc rất nhiều về sản phẩm của họ (tính năng, tiết kiệm tài nguyên, hiệu suất, bảo mật, phân cụm...) và họ có những kế hoạch rất thú vị.
Sơ đồ trực quan để lựa chọn CNI
Nguồn: www.habr.com