TL; DR: Tất cả CNI đều hoạt động như bình thường, ngoại trừ Kube-Router và Kube-OVN, Calico, ngoại trừ tính năng phát hiện MTU tự động, là tốt nhất.
Bài viết cập nhật các lần kiểm tra trước đây của tôi ( и ), tại thời điểm thử nghiệm, tôi đang sử dụng Kubernetes 1.19 trên Ubuntu 18.04 với CNI được cập nhật kể từ tháng 2020 năm XNUMX.
Trước khi chúng ta đi sâu vào các số liệu...
Có gì mới kể từ tháng 2019 năm XNUMX?
- Có thể kiểm tra trên cụm của riêng bạn: Bạn có thể chạy thử nghiệm trên cụm của riêng mình bằng công cụ của chúng tôi Điểm chuẩn mạng Kubernetes:
- Thành viên mới đã xuất hiện
- từ VMware Tanzu
- từ alauda.io
- Kịch bản mới: Các kiểm tra hiện tại chạy thử nghiệm hiệu suất mạng "Pod-to-Pod" và tập lệnh "Pod-to-Service" mới đã được thêm vào để chạy thử nghiệm gần với điều kiện thực tế hơn. Trong thực tế, Pod có API của bạn hoạt động với cơ sở dưới dạng dịch vụ chứ không phải thông qua địa chỉ IP của Pod (tất nhiên chúng tôi kiểm tra cả TCP và UDP cho cả hai trường hợp).
- Tiêu thụ tài nguyên: mỗi bài kiểm tra hiện có so sánh tài nguyên riêng
- Xóa kiểm tra ứng dụng: Chúng tôi không còn thực hiện kiểm tra HTTP, FTP và SCP nữa vì sự hợp tác hiệu quả của chúng tôi với cộng đồng và những người bảo trì CNI đã phát hiện ra khoảng cách giữa kết quả iperf so với TCP và kết quả cuộn tròn do khởi động CNI bị chậm (vài giây đầu tiên của Pod khởi động, không điển hình trong điều kiện thực tế).
- Nguồn mở: tất cả các nguồn kiểm tra (tập lệnh, cài đặt yml và dữ liệu “thô” gốc) đều có sẵn
Giao thức kiểm tra tham khảo
Giao thức được mô tả chi tiết Xin lưu ý rằng bài viết này nói về Ubuntu 18.04 với kernel mặc định.
Chọn CNI để đánh giá
Thử nghiệm này nhằm mục đích so sánh các CNI được định cấu hình với một tệp yaml (do đó, tất cả những tệp được cài đặt bởi tập lệnh, chẳng hạn như VPP và các tệp khác, đều bị loại trừ).
CNI được chúng tôi chọn để so sánh:
- Antrea v.0.9.1
- Calico v3.16
- Canal v3.16 (Mạng Flannel + Chính sách mạng Calico)
- Cilium 1.8.2
- Vải nỉ 0.12.0
- Bộ định tuyến Kube mới nhất (2020–08–25)
- DệtNet 2.7.0
Định cấu hình MTU cho CNI
Trước hết, chúng tôi kiểm tra tác động của việc phát hiện MTU tự động đến hiệu suất TCP:
Tác động của MTU đến hiệu suất TCP
Một khoảng cách thậm chí còn lớn hơn được tìm thấy khi sử dụng UDP:
Tác động của MTU đến hiệu suất UDP
Do tác động LỚN về hiệu suất được tiết lộ trong các thử nghiệm, chúng tôi muốn gửi thư hy vọng đến tất cả những người bảo trì CNI: vui lòng thêm tính năng phát hiện MTU tự động vào CNI. Bạn sẽ cứu được những chú mèo con, kỳ lân và thậm chí cả loài dễ thương nhất: Devop bé nhỏ.
Tuy nhiên, nếu bạn cần sử dụng CNI mà không hỗ trợ phát hiện MTU tự động, bạn có thể định cấu hình thủ công để đạt được hiệu suất. Xin lưu ý rằng điều này áp dụng cho Calico, Canal và WeaveNet.
Yêu cầu nhỏ của tôi tới các CNI đi kèm...
Kiểm tra CNI: Dữ liệu thô
Trong phần này, chúng ta sẽ so sánh CNI với MTU chính xác (được xác định tự động hoặc đặt thủ công). Mục tiêu chính ở đây là hiển thị dữ liệu thô dưới dạng biểu đồ.
Huyền thoại màu sắc:
- màu xám - mẫu (tức là sắt trần)
- màu xanh lá cây - băng thông trên 9500 Mbps
- màu vàng - băng thông trên 9000 Mbps
- màu cam - băng thông trên 8000 Mbps
- màu đỏ - băng thông dưới 8000 Mbps
- màu xanh - trung tính (không liên quan đến băng thông)
Tiêu thụ tài nguyên khi không tải
Trước hết, hãy kiểm tra mức tiêu thụ tài nguyên khi cụm đang “ngủ”.
Tiêu thụ tài nguyên khi không tải
Pod-to-Pod
Kịch bản này giả định rằng Pod máy khách kết nối trực tiếp với Pod máy chủ bằng địa chỉ IP của nó.
Kịch bản Pod-to-Pod
TCP
Kết quả TCP Pod-to-Pod và mức tiêu thụ tài nguyên tương ứng:
UDP
Kết quả UDP Pod-to-Pod và mức tiêu thụ tài nguyên tương ứng:
Pod-to-Service
Phần này phù hợp với các trường hợp sử dụng thực tế, Pod máy khách kết nối với Pod máy chủ thông qua dịch vụ ClusterIP.
Tập lệnh Pod-to-Service
TCP
Kết quả TCP Pod-to-Service và mức tiêu thụ tài nguyên tương ứng:
UDP
Kết quả UDP Pod-to-Service và mức tiêu thụ tài nguyên tương ứng:
Hỗ trợ chính sách mạng
Trong số tất cả những điều trên, người duy nhất không ủng hộ chính trị là Flannel. Tất cả những người khác thực hiện chính xác các chính sách mạng, bao gồm cả gửi đến và gửi đi. Bạn đã làm rất tốt!
mã hóa CNI
Trong số các CNI được kiểm tra, có những CNI có thể mã hóa trao đổi mạng giữa các Pod:
- Antrea sử dụng IPsec
- Calico sử dụng wireguard
- Cilium sử dụng IPsec
- WeaveNet sử dụng IPsec
Băng thông
Vì còn lại ít CNI hơn nên hãy đặt tất cả các kịch bản vào một biểu đồ:
Tiêu thụ tài nguyên
Trong phần này, chúng tôi sẽ đánh giá các tài nguyên được sử dụng khi xử lý giao tiếp Pod-to-Pod trong TCP và UDP. Không có ích gì khi vẽ biểu đồ Pod-to-Service vì nó không cung cấp thêm thông tin.
Để tất cả chúng cùng nhau
Hãy thử lặp lại tất cả các biểu đồ, chúng tôi đã giới thiệu một chút chủ quan ở đây, thay thế các giá trị thực tế bằng các từ “vwry fast”, “low”, v.v.
Kết luận và kết luận của tôi
Điều này hơi chủ quan vì tôi đang truyền đạt cách giải thích của riêng mình về kết quả.
Tôi rất vui vì CNI mới đã xuất hiện, Antrea hoạt động tốt, nhiều chức năng đã được triển khai ngay cả trong các phiên bản đầu tiên: phát hiện MTU tự động, mã hóa và cài đặt dễ dàng.
Nếu so sánh hiệu suất thì tất cả CNI đều hoạt động tốt, ngoại trừ Kube-OVN và Kube-Router. Kube-Router cũng không thể phát hiện MTU, tôi không tìm được cách định cấu hình nó ở bất kỳ đâu trong tài liệu ( một yêu cầu về chủ đề này đang mở).
Về mức tiêu thụ tài nguyên, Cilium vẫn sử dụng nhiều RAM hơn các loại khác, nhưng nhà sản xuất rõ ràng đang nhắm đến các cụm lớn, điều này rõ ràng không giống như thử nghiệm trên cụm ba nút. Kube-OVN cũng tiêu tốn rất nhiều tài nguyên CPU và RAM, nhưng nó là một CNI non trẻ dựa trên Open vSwitch (giống như Antrea, nó hoạt động tốt hơn và tiêu tốn ít năng lượng hơn).
Mọi người ngoại trừ Flannel đều có chính sách mạng. Rất có thể anh ta sẽ không bao giờ ủng hộ họ, vì mục tiêu đơn giản hơn củ cải hấp: càng nhẹ thì càng ngon.
Ngoài ra, trong số những thứ khác, hiệu suất mã hóa thật đáng kinh ngạc. Calico là một trong những CNI lâu đời nhất nhưng tính năng mã hóa chỉ mới được thêm vào vài tuần trước. Họ đã chọn wireguard thay vì IPsec và nói một cách đơn giản, nó hoạt động rất tốt và đáng kinh ngạc, làm lu mờ hoàn toàn các CNI khác trong phần thử nghiệm này. Tất nhiên, mức tiêu thụ tài nguyên tăng lên do mã hóa, nhưng thông lượng đạt được là xứng đáng (Calico cho thấy sự cải thiện gấp sáu lần trong thử nghiệm mã hóa so với Cilium, xếp thứ hai). Hơn nữa, bạn có thể kích hoạt wireguard bất cứ lúc nào sau khi triển khai Calico vào cụm và bạn cũng có thể vô hiệu hóa nó trong một thời gian ngắn hoặc vĩnh viễn nếu muốn. Tuy nhiên, nó cực kỳ tiện lợi! Chúng tôi xin nhắc bạn rằng Calico hiện không tự động phát hiện MTU (tính năng này được lên kế hoạch cho các phiên bản trong tương lai), vì vậy hãy đảm bảo định cấu hình MTU nếu mạng của bạn hỗ trợ Khung Jumbo (MTU 9000).
Ngoài ra, hãy lưu ý rằng Cilium có thể mã hóa lưu lượng giữa các nút cụm (chứ không chỉ giữa các Pod), điều này có thể rất quan trọng đối với các nút cụm công khai.
Để kết luận, tôi đề xuất các trường hợp sử dụng sau:
- Cần CNI cho một cụm rất nhỏ HOẶC Tôi không cần bảo mật: làm việc với Flannel, CNI nhẹ nhất và ổn định nhất (ông cũng là một trong những người già nhất, theo truyền thuyết ông được phát minh bởi Homo Kubernautus hoặc Homo Contaitorus). Bạn cũng có thể quan tâm đến dự án khéo léo nhất , kiểm tra!
- Cần CNI cho một cụm thông thường: một thứ vải trắng - lựa chọn của bạn, nhưng đừng quên định cấu hình MTU nếu cần. Bạn có thể dễ dàng và tự nhiên thực hiện các chính sách mạng, bật và tắt mã hóa, v.v.
- Cần CNI cho cụm quy mô (rất) lớn: Chà, thử nghiệm không cho thấy hành vi của các cụm lớn, tôi rất vui khi tiến hành thử nghiệm, nhưng chúng tôi không có hàng trăm máy chủ có kết nối 10Gbps. Vì vậy, tùy chọn tốt nhất là chạy thử nghiệm đã sửa đổi trên các nút của bạn, ít nhất là với Calico và Cilium.
Nguồn: www.habr.com