So sánh các cấu hình mạng Cilium trên cụm Kubernetes Hybrid Talos
Gần đây, tôi đã thử nghiệm với các cấu hình mạng khác nhau cho cụm Kubernetes Talos Linux được triển khai ở chế độ hybrid - với các nút điều khiển chạy trên AWS và một nút làm việc được lưu trữ trên-premises trong QEMU. Mục tiêu của tôi là đánh giá cách mà Cilium CNI hoạt động trong một thiết lập như vậy, đặc biệt là khi kết hợp với KubeSpan, lớp mạng mesh dựa trên WireGuard của Talos.
Mục tiêu của bài viết
Bài viết này sẽ chia sẻ những phát hiện của tôi từ ba cấu hình khác nhau, làm nổi bật những thách thức, kết quả hiệu suất, và các bài học rút ra cho các môi trường hybrid.
1. Cilium sử dụng WireGuard với KubeSpan tắt
Thí nghiệm đầu tiên của tôi là chạy mã hóa WireGuard gốc của Cilium khi đã tắt KubeSpan.
Trên lý thuyết, điều này nên cung cấp kết nối an toàn giữa các pod. Tuy nhiên, thực tế đã không diễn ra như vậy. Nguyên nhân nằm ở cách mà Cilium triển khai WireGuard - nó giả định rằng có kết nối IP trực tiếp giữa các nút.
Trong thiết lập hybrid của tôi, nút làm việc trên-premises nằm sau NAT, điều này khiến nó không thể truy cập từ các nút AWS. Vì Cilium không hỗ trợ các kỹ thuật vượt NAT (ví dụ: hole punching hoặc các cơ chế tương tự STUN), nên việc bắt tay WireGuard đã không thể thiết lập.
Đây chính là điểm mạnh của KubeSpan. Khác với việc triển khai của Cilium, KubeSpan được thiết kế cho các topo hybrid, đám mây và bị hạn chế NAT. Nó tự động xây dựng các đường hầm WireGuard qua các ranh giới, cho phép kết nối ngay cả khi các nút bị ẩn sau NAT.
Kết luận:
Nếu không có KubeSpan, Cilium WireGuard không khả thi trong các triển khai hybrid có NAT.
2. Định tuyến gốc để giảm encapsulation VXLAN
Thiết lập thứ hai khám phá định tuyến gốc của Cilium như một cách để giảm thiểu overhead của encapsulation VXLAN. VXLAN có thể hoạt động tốt trong các cụm được đặt gần nhau, nhưng nó thêm overhead, đặc biệt trong lưu lượng hybrid qua các nút.
Ban đầu, tôi giả định rằng định tuyến gốc sẽ không hoạt động bên ngoài các môi trường được kết nối chặt chẽ. Tuy nhiên, với một vài điều chỉnh, nó đã trở nên khả thi:
- Triển khai một DaemonSet để trích xuất địa chỉ cilium_host IP của mỗi nút.
- Gán một địa chỉ IP thứ cấp với mặt nạ subnet rộng hơn (ví dụ: /24).
- Kích hoạt
advertiseKubernetesNetworksđể các CIDR pod được chia sẻ giữa các nút. - Đảm bảo rằng các peer KubeSpan bao gồm các CIDR này trong
AllowedIPscủa chúng.
Giải pháp này đã cho phép Cilium hoạt động ở chế độ định tuyến gốc, bỏ qua encapsulation VXLAN ngay cả trong cụm hybrid.
Kết luận:
Với một số điều chỉnh tùy chỉnh, định tuyến gốc hoạt động qua các ranh giới NAT khi kết hợp với KubeSpan.
3. Kết quả thử nghiệm
Tôi đã thực hiện một loạt các benchmark hiệu suất TCP/UDP. Dữ liệu đầy đủ có sẵn ở đây, nhưng dưới đây là tóm tắt:
- Thử nghiệm Luồng: Các thử nghiệm này rất quan trọng trong việc đánh giá hiệu suất throughput của các pod và nút.
- Thử nghiệm RR (Request-Response): Những bài kiểm tra này cho phép chúng tôi đánh giá hiệu suất gói mỗi giây và độ trễ của các pod và nút.
- Thử nghiệm CRR (Connect-Request-Response): Bằng cách sử dụng kịch bản này, chúng tôi có thể đánh giá hiệu suất Kết nối Mới Mỗi Giây của các pod và nút.
KubeSpan đã được kích hoạt. Cài đặt Cilium:
yaml
k8sServiceHost: localhost
k8sServicePort: 7445
kubeProxyReplacement: true
enableK8sEndpointSlice: true
localRedirectPolicy: true
healthChecking: true
bpf:
masquerade: true
ipv4:
enabled: true
hostServices:
enabled: true
hostPort:
enabled: true
nodePort:
enabled: true
externalIPs:
enabled: true
hostFirewall:
enabled: trueTóm tắt thử nghiệm hiệu suất mạng - NÚT KHÔNG ĐƯỢC ĐẶT GẦN (AWS->ONPREM):
| Tình huống | Nút | Thử nghiệm | Thời gian | Thấp nhất | Trung bình | Cao nhất | P50 | P90 | P99 | Tỷ lệ giao dịch OP/s |
|---|---|---|---|---|---|---|---|---|---|---|
| pod-to-pod | same-node | TCP_CRR | 10s | 57µs | 67.26µs | 271µs | 65µs | 73µs | 101µs | 14822.78 |
| pod-to-pod | same-node | TCP_RR | 10s | 23µs | 33.84µs | 201µs | 33µs | 36µs | 49µs | 29445.81 |
| pod-to-pod | same-node | UDP_RR | 10s | 21µs | 33.42µs | 19.48ms | 33µs | 37µs | 50µs | 29795.95 |
4. Những điểm quan sát chính
- Độ trễ: Định tuyến gốc đã liên tục giảm 7–20ms giữa các nút.
- Thông lượng: Lợi ích là khiêm tốn, nhưng cải tiến rõ rệt hơn trong các kịch bản UDP.
- Đơn giản hóa: Loại bỏ VXLAN giảm overhead của encapsulation và làm cho đường dẫn dữ liệu trở nên minh bạch hơn.
5. Kết luận
Định tuyến gốc trong Cilium thực sự mang lại những cải tiến đo lường được trong các thiết lập hybrid, giảm độ trễ, thông lượng tốt hơn một chút và đường dẫn dữ liệu sạch hơn.
Tuy nhiên, những cải tiến này là gia tăng chứ không phải là thay đổi lớn. Với độ phức tạp của giải pháp cần thiết, tôi không coi nó là sẵn sàng cho sản xuất vào lúc này.
Tin tốt là cộng đồng Sidero đang tích cực cải tiến KubeSpan, và các phiên bản trong tương lai có thể hỗ trợ định tuyến gốc ngay từ đầu. Nếu điều đó xảy ra, chúng ta sẽ có thể kết hợp bảo mật và khả năng vượt NAT của KubeSpan với lợi ích hiệu suất của định tuyến gốc, mà không cần các mẹo tùy chỉnh.
