Khi các doanh nghiệp mở rộng hoạt động (lượng users và resource tăng nhiều hơn), việc mở rộng Kubernetes triển khai single-cluster sang multi-cluster. Trong môi trường multi-cluster, giao tiếp giữa các cluster trở thành một lĩnh vực nghiên cứu quan trọng. Bài viết này giới thiệu các nguyên tắc cơ bản, ưu điểm và hạn chế của 5 giải pháp cho giao tiếp giữa các Kubernetes clusters.
1. Underlay Network (mạng nền tảng)
Loại network plugin này bao gồm macvlan, ipvlan, Kube-OVN underlay (mình sẽ đề cập các plugin này ở các bài viết sau) và các cloud VPC CNIs.
Nguyên tắc cơ bản:
Từ góc độ CNI (Container Network Interface), underlay network là phương pháp đơn giản nhất. Phương pháp này dựa vào cơ sở hạ tầng bên dưới để đạt được kết nối ở cấp độ network, như sử dụng VPC Peering trên các cloud-services hoặc cấu hình định tuyến và Layer 2 networks trong mạng vật lý. Khi underlying network được kết nối, các cross-cluster container networks sẽ kết nối với nhau.
Lợi ích:
- Rõ ràng về mặt kiến trúc, giao phó trách nhiệm giao tiếp cross-cluster cho underlay networks.
- Đơn giản từ góc độ CNI, không cần các thiết lập bổ sung.
Hạn chế:
- Phụ thuộc vào CNI cụ thể; underlay networks có các trường hợp sử dụng hạn chế và một số kịch bản chỉ có thể sử dụng overlay networks.
- Khó khăn trong các môi trường không đồng nhất, chẳng hạn như giữa cloud-services hoặc public và private clouds.
- Chỉ cung cấp giao tiếp container networks cơ bản mà không có các chức năng cao cấp như like service discovery, domain names, và network policies.
- Thiếu kiểm soát chi tiết, kết nối tất cả container networks của cluster cùng một lúc.
2. Overlay CNI Providing Cross-Cluster Communication
Khi không thể sử dụng underlay networks, một số CNIs cụ thể đạt được giao tiếp cross-cluster ở overlay level, chẳng hạn như Cilium Cluster Mesh, Antrea Multi-Cluster, và Kube-OVN with ovn-ic.
Nguyên Tắc Cơ Bản:
Các CNIs này thường chọn một tập hợp các nodes trong cluster làm gateway nodes, sau đó thiết lập các tunnels giữa chúng. Lưu lượng cross-cluster được chuyển tiếp qua các gateway nodes này.
Ưu Điểm:
- CNIs bao gồm chức năng cross-cluster mà không cần thêm thành phần bổ sung.
Hạn Chế:
- Phụ thuộc vào CNIs cụ thể, không thể đạt được giao tiếp giữa các CNIs khác nhau.
- Không xử lý được chồng chéo CIDR; cần lập kế hoạch trước các network segments.
- Ngoại trừ Cilium, các CNIs khác chỉ cung cấp giao tiếp mạng container cơ bản mà thiếu các chức năng cao cấp như khám phá dịch vụ cross-cluster và network policies.
- Thiếu kiểm soát chi tiết khi kết nối tất cả các mạng container của cluster cùng một lúc.
3. Submariner
Trước nhu cầu phổ biến về kết nối mạng cross-cluster, các triển khai tương tự dẫn đến nỗ lực trùng lặp giữa các CNIs khác nhau. Submariner, một plugin mạng độc lập và cross-cluster, cung cấp giải pháp chung có thể kết nối các clustervới các CNIs khác nhau thành một mạng duy nhất. Được tạo ra bởi các kỹ sư tại Rancher và hiện là dự án CNCF Sandbox với sự tham gia từ các kỹ sư của Red Hat.
Nguyên Tắc Cơ Bản:
Submariner chọn các gateway nodes trong cluster giao tiếp qua VXLAN. Lưu lượng cross-cluster được truyền qua VXLAN. Submarinerdựa vào CNI để gửi lưu lượng đầu ra đến mạng máy chủ, sau đó chuyển tiếp. Ngoài ra, Submariner triển khai một bộ CoreDNS để khám phá dịch vụ cross-cluster và sử dụng Globalnet Controller để giải quyết các vấn đề chồng chéo CIDR.
Ưu Điểm:
- Không phụ thuộc vào CNI, cho phép kết nối các cluster với các CNIs khác nhau.
- Thực hiện khám phá dịch vụ cross-cluster, hỗ trợ giải quyết dịch vụ và tên miền.
- Hỗ trợ giao tiếp giữa các cluster với CIDRs chồng chéo, tránh xung đột IP sau triển khai.
Hạn Chế:
- Không tương thích với tất cả các CNIs, đặc biệt là những như macvlan hoặc Cilium ngắn mạch nơi máy chủ không thể thấy lưu lượng.
- Gateway hoạt động ở chế độ active-passive, thiếu cân bằng tải ngang, có thể gây ra nodes thắt cổ chai trong các kịch bản lưu lượng cao.
- Thiếu kiểm soát chi tiết khi kết nối tất cả các mạng container của cluster cùng một lúc.
4. Skupper
Skupper được coi là giải pháp thú vị nhất, cho phép kết nối mạng lớp dịch vụ theo yêu cầu, tránh các vấn đề kiểm soát của kết nối toàn bộ. Nó sử dụng layer 7 message queue để đạt được điều này, hoàn toàn độc lập với underlay network và CNI, rất dễ để bắt đầu. Hiện tại, hầu hết các nhà đóng góp là kỹ sư từ Red Hat.
Nguyên Tắc Cơ Bản:
Không giống như các giải pháp trước sử dụng tunnel để kết nối trực tiếp các IP container, Skupper giới thiệu khái niệm VAN (Virtual Application Networks) để kết nối mạng ở layer 7. Thay vì kết nối IP trực tiếp, nó kết nối các dịch vụ. Skupper sử dụng message queue để gửi các gói giao tiếp cross-clusters.
Ưu Điểm:
- Tương thích tuyệt vời với CNI, hoàn toàn độc lập với hành vi CNI ở lớp ứng dụng cho kết nối gói tin.
- Dễ bắt đầu, không yêu cầu lập kế hoạch mạng phức tạp trước và không có yêu cầu không trùng lặp CIDR.
- Kết nối các dịch vụ theo yêu cầu thay vì toàn bộ mạng container, cho phép kiểm soát chi tiết với yêu cầu hạ tầng thấp hơn.
Hạn Chế:
- Hiện chỉ hỗ trợ giao thức TCP; các giao thức như UDP và ICMP gặp vấn đề.
- Thông tin IP bị mất khi các tin nhắn được chuyển qua message queue.
- Sử dụng message queue để chuyển tiếp có thể dẫn đến các vấn đề về hiệu suất như độ trễ và mất thông lượng.
- Do tính chất trạng thái của TCP, việc chuyển đổi hoàn toàn sang dạng message queue và đảm bảo tính tương thích là điều cần xem xét.
5. KubeSlice
KubeSlice là một dự án mới được thêm vào CNCF Sandbox gần đây. Các giải pháp dựa trên các tunnels không thể đạt được kiểm soát chi tiết và tính tương thích đầy đủ với CNI, trong khi các giải pháp dựa trên lớp ứng dụng không thể hỗ trợ đầy đủ các giao thức mạng. KubeSlice cung cấp một phương pháp mới, cố gắng giải quyết cả hai vấn đề này đồng thời.
Nguyên tắc cơ bản:
Ý tưởng cơ bản của KubeSlice là đơn giản và rõ ràng: chèn động một thẻ mạng vào một pod khi cần thiết, tạo ra một mạng overlay cho giao tiếp giữa các clusters trên thẻ này. Mạng overlay này sau đó thực hiện khám phá dịch vụ và chính sách mạng. Người dùng có thể tạo và tham gia mạng một cách linh hoạt qua các namespace hoặc các pod, đạt được kiểm soát linh hoạt chi tiết. Vì nó hoạt động trên một thẻ mạng thứ hai, nó tương thích cao với các giao thức mạng.
Ưu điểm:
- Tính tương thích cao với CNI, vì nó liên quan đến việc thêm một thẻ mạng bổ sung, không phụ thuộc vào CNI ban đầu và tránh xung đột địa chỉ mạng ban đầu.
- Tính tương thích cao với giao thức, vì nó sử dụng một thẻ mạng bổ sung cho chuyển tiếp dữ liệu, tương thích với tất cả các giao thức mạng.
- Tính linh hoạt cao, cung cấp các công cụ dòng lệnh để tạo và tham gia mạng một cách động, cho phép người dùng tạo nhiều mạng ảo giao cắt giữa các clusters khi cần thiết.
- Chức năng toàn diện, thực hiện khám phá dịch vụ, DNS, QoS, NetworkPolicy và giám sát trên mạng overlay bổ sung.
Hạn chế:
- Các ứng dụng cần nhận biết về thẻ mạng bổ sung và chọn mạng phù hợp, có thể đòi hỏi sửa đổi ứng dụng.
- Vì giao tiếp giữa các clusters sử dụng một thẻ mạng khác, không phải là địa chỉ IP chính của pod, các hệ thống bên ngoài như giám sát và theo dõi có thể đòi hỏi điều chỉnh.
- Tài liệu dường như là một dự án nội bộ được công bố mã nguồn mở, với nhiều phương pháp sử dụng và mô tả API không được giải thích rõ ràng, đòi hỏi người dùng phải đoán ý nghĩa của các tham số từ các tài liệu tham khảo.
- Mặc dù có vẻ là toàn diện, tài liệu cần cải thiện đáng kể để người dùng bên ngoài có thể sử dụng hiệu quả.
Theo dõi thêm các bài viết khác tại ant
