CFSDN nhấn mạnh vào giá trị tạo ra nguồn mở và chúng tôi cam kết xây dựng nền tảng chia sẻ tài nguyên để mọi nhân viên CNTT có thể tìm thấy thế giới tuyệt vời của bạn tại đây.

Bài viết trên blog CFSDN này phân tích ngắn gọn một số giải pháp đa cụm Kubernetes được tác giả sưu tầm và biên soạn. Nếu bạn quan tâm đến bài viết này thì nhớ like nhé.

Khi Kubernetes ngày càng được sử dụng rộng rãi trong các doanh nghiệp, ngày càng có nhiều công ty vận hành và duy trì nhiều cụm trong môi trường sản xuất. Bài viết này chủ yếu nói về một số suy nghĩ về Kubernetes đa cụm, bao gồm lý do nên chọn đa cụm, lợi ích của đa cụm và kế hoạch triển khai đa cụm.

Báo cáo sử dụng Kubernetes năm 2020 của VMware đã chỉ ra rằng 20% ​​tổ chức áp dụng kubernetes chạy hơn 40 cụm.

Tại sao doanh nghiệp cần nhiều cụm?

Khả năng mang theo của một cụm Kubernetes bị hạn chế.

Trước tiên, hãy xem mô tả về khả năng mang theo cụm đơn trong tài liệu chính thức:

Trong v1.12, Kubernetes hỗ trợ các cụm có tối đa 5000 nút. Cụ thể hơn, chúng tôi hỗ trợ các cấu hình đáp ứng tất cả các điều kiện sau:

• Không quá 5000 nút
• Tổng số Pod không vượt quá 150.000
• Tổng số không quá 300.000 container
• Không quá 100 Pod trên mỗi nút

Mặc dù Kubernetes hiện đã phát triển lên v1.20 nhưng khả năng mang của một cụm không thay đổi. Có thể thấy, việc nâng cao khả năng chịu tải của một cụm đơn lẻ không phải là hướng phát triển của cộng đồng.

Nếu quy mô kinh doanh của chúng tôi vượt quá 5.000 đơn vị thì doanh nghiệp phải xem xét nhiều cụm.

Kiến trúc đám mây lai hoặc nhiều đám mây xác định nhu cầu về nhiều cụm.

Cho đến nay, kiến ​​trúc multi-cloud hoặc hybrid cloud thực sự rất phổ biến.

Ví dụ, doanh nghiệp là một công ty toàn cầu và cung cấp các dịch vụ toàn cầu.

Hoặc như Sina Weiwei, hãy xây dựng trung tâm dữ liệu của riêng bạn + Alibaba Cloud và Alibaba Cloud được sử dụng để phục vụ lưu lượng truy cập linh hoạt.

Ngoài ra, đám mây công cộng không có nguồn tài nguyên khổng lồ như tưởng tượng. Ví dụ: khi một khách hàng hàng đầu của đám mây công cộng cần một số lượng lớn máy cho một chương trình khuyến mãi lớn, họ cần đăng ký trước với đám mây công cộng và sau đó đám mây công cộng sẽ chuẩn bị trước.

Để tránh bị ràng buộc bởi một nhà cung cấp duy nhất hoặc do cân nhắc về chi phí, các doanh nghiệp đã chọn kiến ​​trúc nhiều đám mây, điều này cũng xác định rằng chúng ta cần nhiều cụm.

Đừng bỏ trứng vào một giỏ.

Ngay cả khi hai điều kiện đầu tiên không được đáp ứng, chúng ta có nên triển khai tất cả khối lượng công việc vào một cụm không?

Nếu mặt phẳng điều khiển cụm bị lỗi, tất cả các dịch vụ sẽ bị ảnh hưởng.

Có thể bạn cho rằng bản thân mặt phẳng điều khiển Kubernetes có tính sẵn sàng cao (ba máy chủ api) và không có khả năng toàn bộ lớp điều khiển sẽ không khả dụng.

Trên thực tế, điều này không xảy ra. Chúng tôi đã nhiều lần xử lý những thất bại tương tự trong môi trường sản xuất. Nếu một ứng dụng (thường là ứng dụng cần gọi giao diện api-server) gọi api-server với số lượng lớn, nó sẽ khiến máy chủ api lần lượt bị treo và cuối cùng không khả dụng. Cho đến khi ứng dụng bị lỗi được tìm thấy và xóa đi.

Do đó, trong môi trường sản xuất, trước hết, quyền truy cập api-server cần phải được kiểm soát chặt chẽ, thứ hai, cần phải thực hiện thử nghiệm và thứ ba, các ứng dụng kinh doanh và cơ sở hạ tầng có thể được triển khai riêng biệt. Trên thực tế, việc lựa chọn giữa một cụm và nhiều cụm cũng tương tự như bài toán “chọn một siêu máy tính hay nhiều máy thông thường”. Sau này, sự phát triển của điện toán phân tán cho thấy mọi người đều chọn nhiều máy thông thường.

Lợi ích của nhiều cụm

Đa cụm có hiệu suất tốt hơn ở ba khía cạnh sau:

• sẵn có
• Sự cách ly
• Khả năng mở rộng

Kiến trúc ứng dụng đa cụm

Thực tế có hai mô hình để xây dựng kiến ​​trúc ứng dụng nhiều cụm.

• Bản sao: Sao chép ứng dụng sang nhiều vùng khả dụng hoặc trung tâm dữ liệu, với mỗi cụm chạy một bản sao hoàn chỉnh của ứng dụng. Chúng ta có thể dựa vào Smart DNS (trong GCP có khái niệm Global Load Balancer) để định tuyến lưu lượng truy cập đến cụm gần người dùng nhất nhằm đạt được độ trễ mạng tối thiểu. Nếu một trong các cụm của chúng tôi bị lỗi, chúng tôi có thể định tuyến lưu lượng truy cập đến các cụm hoạt động tốt khác để triển khai chuyển đổi dự phòng.
• Chia theo dịch vụ: Triển khai ứng dụng theo các cụm khác nhau tùy theo mức độ phù hợp với hoạt động kinh doanh. Mô hình này cung cấp khả năng cách ly rất tốt nhưng việc phân chia dịch vụ phức tạp hơn.

Kế hoạch thực hiện đa cụm cộng đồng

Trên thực tế, cộng đồng đã khám phá các phương pháp hay nhất về Kubernetes đa cụm. Hiện tại, chủ yếu có hai loại sau.

Kubernetes lấy trung tâm.

Tập trung vào việc hỗ trợ và mở rộng các nguyên tắc Kubernetes cốt lõi cho các trường hợp sử dụng nhiều cụm, cung cấp mặt phẳng quản lý tập trung cho nhiều cụm. Dự án liên kết cụm Kubernetes thực hiện phương pháp này.

Cách tốt nhất để hiểu liên kết cụm là trực quan hóa các siêu cụm trên nhiều cụm Kubernetes. Hãy tưởng tượng một mặt phẳng điều khiển logic sắp xếp nhiều nút chính Kubernetes, tương tự như cách mỗi nút chính điều khiển các nút trong cụm riêng của nó.

Trên thực tế, liên kết cụm về cơ bản thực hiện hai việc:

• Phân phối tài nguyên trên các cụm: Bằng cách trừu tượng hóa ba khái niệm Mẫu, Vị trí và Ghi đè, các tài nguyên (chẳng hạn như Triển khai) có thể được triển khai đến các cụm khác nhau và có thể đạt được quy mô đa cụm.
• Khám phá dịch vụ đa cụm: hỗ trợ Dịch vụ đa cụm và Ingress. Tính đến thời điểm hiện tại, dự án liên bang vẫn đang ở trạng thái alpha và khi chúng tôi chọn triển khai nó, nó sẽ yêu cầu một lượng công việc phát triển nhất định.

Lấy mạng làm trung tâm.

Cách tiếp cận lấy mạng làm trung tâm tập trung vào việc tạo kết nối mạng giữa các cụm để các ứng dụng trong cụm có thể giao tiếp với nhau.

Hỗ trợ đa cụm của Istio, phản chiếu dịch vụ Linkerd và cổng Mesh của Consul đạt được kết nối mạng thông qua các giải pháp lưới dịch vụ.

Giải pháp còn lại là giải pháp của Cilium dành cho mạng nhiều cụm. Bản thân Cilium là một mạng CNI, thiếu chức năng quản trị dịch vụ.

Giải pháp Cilium Cluster Mesh giải quyết việc định tuyến Pod IP trên nhiều cụm Kubernetes thông qua đường hầm hoặc định tuyến trực tiếp mà không cần bất kỳ cổng hoặc proxy nào. Tất nhiên chúng ta cần lập kế hoạch POD CIDR của từng cụm.

• Mỗi cụm Kubernetes duy trì cụm etcd riêng, chứa trạng thái của cụm. Trạng thái từ nhiều cụm không bao giờ được trộn lẫn vào etcd.
• Mỗi cụm hiển thị etcd của riêng nó thông qua một tập hợp các proxy etcd. Tác nhân Cilium chạy trong các cụm khác kết nối với tác nhân etcd để theo dõi các thay đổi và sao chép trạng thái liên quan đến nhiều cụm sang cụm của chính chúng. Việc sử dụng proxy etcd đảm bảo khả năng mở rộng của người theo dõi etcd. Quyền truy cập được bảo vệ bởi chứng chỉ TLS.
• Truy cập từ cụm này sang cụm khác luôn ở chế độ chỉ đọc. Điều này đảm bảo rằng miền lỗi không thay đổi, tức là một lỗi trong một cụm không bao giờ lan truyền sang các cụm khác.
• Cấu hình được thực hiện thông qua tài nguyên bí mật Kubernetes đơn giản, chứa thông tin địa chỉ của tác nhân etcd từ xa cũng như tên cụm và chứng chỉ cần thiết để truy cập tác nhân etcd.

nghĩ

Ở trên chúng ta đã nói về hai giải pháp để triển khai Kubernetes nhiều cụm. Trên thực tế, đó không phải là A hay B.

Ví dụ: khi chúng tôi đang trong quá trình triển khai các cụm lớn, nhiều công ty chỉ sử dụng Kubernetes để giải quyết các vấn đề về triển khai. Để khám phá dịch vụ, hãy chọn lãnh sự, zk và các trung tâm đăng ký khác. Để quản lý tệp cấu hình, hãy sử dụng trung tâm cân bằng tải không sử dụng Dịch vụ trong kubernetes.

Kết hợp hai lựa chọn là cách tốt nhất vào lúc này.

Liên kết cụm giải quyết các vấn đề triển khai và phát hành. Lưới dịch vụ giải quyết vấn đề truy cập lưu lượng nhiều cụm. Tuy nhiên, tại thời điểm này, các Pod trong cụm khối lượng công việc, mặt phẳng điều khiển của lưới dịch vụ và cổng đều cần kết nối với trung tâm đăng ký bên ngoài. Cấu trúc cụ thể như sau:

Liên kết gốc: https://mp.weixin.qq.com/s/ZmrpMbKEHDXSowUtbSM_rg.

Cuối cùng, bài viết phân tích ngắn gọn về một số giải pháp đa cụm Kubernetes kết thúc ở đây. Nếu bạn muốn biết thêm về phân tích ngắn gọn về một số giải pháp đa cụm Kubernetes, vui lòng tìm kiếm các bài viết CFSDN hoặc tiếp tục duyệt các bài viết liên quan. tất cả sẽ ủng hộ blog của tôi trong tương lai! .