Quy mô mặt phẳng điều khiển Kubernetes bị giới hạn theo ba trục độc lập: số nút, mức biến động của đối tượng và lượng trạng thái thường trú. Tăng số kube-apiserver có thể giúp xử lý thêm yêu cầu, nhưng không giải quyết mọi giới hạn và còn có thể làm tăng mức sử dụng bộ nhớ. Đội vận hành cần xác định trục nào đang cạn tài nguyên trước khi thay đổi cấu hình.
Ba cụm Kubernetes có thể cùng gặp sự cố dù áp lực đặt lên mặt phẳng điều khiển hoàn toàn khác nhau. Theo phân tích của The New Stack về khả năng mở rộng mặt phẳng điều khiển Kubernetes, trường hợp đầu tiên là một hệ thống huấn luyện từng duy trì vài nghìn nút trong nhiều tháng, sau đó tăng lên 15.000 nút khi một đợt chạy mới bắt đầu. Kube-apiserver tiêu thụ thêm bộ nhớ và etcd bắt đầu báo lỗi.
Trường hợp thứ hai chưa bao giờ vượt quá vài nghìn nút nhưng lại gặp tình trạng nghiêm trọng hơn. Đây là một nền tảng tác tử, nơi các phiên liên tục được tạo, tạm dừng, tiếp tục và hủy hàng nghìn lần mỗi phút. Mỗi lần chuyển trạng thái đều tạo ra một thao tác ghi.
Trường hợp thứ ba chỉ có 200 trình vận hành cùng hàng chục nghìn đối tượng gần như không thay đổi. Mỗi máy chủ giao diện lập trình ứng dụng giữ một bản sao của toàn bộ số đối tượng đó trong bộ nhớ.
Hai trong ba trường hợp phục vụ khối lượng công việc trí tuệ nhân tạo, nhưng loại khối lượng công việc không phải khác biệt quyết định. Các cụm đang cạn tài nguyên theo ba hướng độc lập. Cách sửa một hướng không tự động giải quyết hai hướng còn lại. Điều này cũng cần được tính đến khi triển khai tác tử trí tuệ nhân tạo trên Kubernetes.
Ba dạng giới hạn quy mô
Ba giới hạn quy mô của mặt phẳng điều khiển Kubernetes là số nút, mức biến động và lượng trạng thái. Số nút tạo áp lực từ nhịp sống và hợp đồng thuê, mức biến động làm tăng thao tác ghi, còn lượng trạng thái làm tăng bộ nhớ thường trú trên từng máy chủ giao diện lập trình ứng dụng.
Hướng dẫn phổ biến thường lấy số nút làm thước đo chính. Cách nhìn đó hữu ích ở quy mô thông thường, nhưng có thể khiến đội vận hành tối ưu sai vấn đề khi tải ghi hoặc lượng trạng thái mới là giới hạn thực tế.
Giới hạn bởi số nút
Giới hạn này thường xuất hiện trong các cụm huấn luyện và học tăng cường có cấu trúc lớn, đồng nhất. Theo số đo được The New Stack công bố, 100.000 nút gửi nhịp sống sau mỗi 10 giây sẽ tạo khoảng 10.000 thao tác ghi mỗi giây. Phần lớn công việc của mặt phẳng điều khiển khi đó là tiếp nhận thông báo rằng các nút vẫn đang hoạt động.
Giới hạn bởi mức biến động
Giới hạn này có thể xảy ra trong một cụm không quá lớn. Nền tảng tác tử thường đặt nhiều phiên trên một nhóm pod worker nhỏ hơn. Vòng đời của từng tác tử được biểu diễn bằng tài nguyên tùy chỉnh, vì vậy các tài nguyên tùy chỉnh trở thành nhóm đối tượng tồn tại ngắn nhưng bị ghi thường xuyên nhất. Tốc độ ghi không còn tỷ lệ trực tiếp với số máy.
Giới hạn bởi lượng trạng thái
Giới hạn này xuất hiện khi cụm có nhiều loại đối tượng nhưng phần lớn ít thay đổi. Chi phí chính không nằm ở thao tác ghi mà ở lượng byte thường trú, nhân với số máy chủ giao diện lập trình ứng dụng đang giữ bản sao. Trong trường hợp này, bổ sung máy chủ có thể làm áp lực bộ nhớ nặng hơn.
Một cụm có thể chạm giới hạn trên một trục trong khi hai trục còn lại vẫn thấp. Vì thế, cấu hình chỉ dựa trên số nút có thể xử lý đúng vấn đề của cụm huấn luyện nhưng không giúp được nền tảng tác tử hoặc cụm nền tảng nặng trạng thái.
Vì sao thêm máy chủ chưa chắc có ích
Thêm kube-apiserver cung cấp thêm năng lực xử lý yêu cầu, nhưng mỗi máy chủ mới cũng sao chép toàn bộ bộ nhớ đệm theo dõi. Nếu lượng trạng thái thường trú là giới hạn, việc mở rộng theo chiều ngang có thể làm tăng chính mức sử dụng bộ nhớ mà đội vận hành đang cố giảm.
Các cụm vượt xa 5.000 nút đã chạy trong môi trường sản xuất bằng thành phần thượng nguồn tiêu chuẩn, theo The New Stack. Sự khác biệt không nằm ở một bản Kubernetes tùy biến đặc biệt mà ở việc đội vận hành quyết định rõ loại dữ liệu nào được giữ trong từng kho và thành phần nào cần lưu đối tượng nào.
Mục tiêu không chỉ là đạt quy mô lớn. Phần còn thiếu là một bộ cấu hình đã được kiểm thử, có thể chỉ ra cách ghép các thành phần cho từng dạng áp lực. Đây cũng là một phần của bài toán rộng hơn về hạ tầng trí tuệ nhân tạo và cách vận hành.
Điểm phân tách và công thức cấu hình
Điểm phân tách là ranh giới hợp đồng giữa hai thành phần Kubernetes, thường nằm tại một kết nối mạng. Công thức cấu hình là tập hợp thiết lập được xây quanh các ranh giới đó và được kiểm thử ở quy mô xác định. Cách tiếp cận này cho phép thay đổi một thành phần mà không phải sửa mã Kubernetes thượng nguồn.
Thành phần phía sau một điểm phân tách có thể được thay thế mà không cần sửa mã thượng nguồn. Có thể hình dung các điểm này như đường may trên áo: chỉnh tại đúng đường may vẫn giữ được cấu trúc, còn cắt ở vị trí khác có thể phá hỏng toàn bộ thiết kế.
Một công thức cấu hình phải chạy được, cho kết quả đạt hoặc không đạt rõ ràng và được kiểm tra liên tục. Quy trình kiểm thử liên tục giúp phát hiện khi một bản phát hành mới làm thay đổi giả định ban đầu.
Bốn điểm phân tách của mặt phẳng điều khiển
Bốn điểm phân tách gồm hợp đồng lưu trữ, hợp đồng về trạng thái sống của nút, trục phân mảnh và mức thường trú của bộ nhớ đệm. Mỗi điểm tác động đến một loại áp lực khác nhau, từ tải ghi và nhịp sống của nút đến cách chia đối tượng và lượng bộ nhớ mà kube-apiserver giữ lại.
Hợp đồng lưu trữ
Hợp đồng lưu trữ xác định kho nào giữ từng loại tài nguyên và chủ yếu giảm áp lực do biến động. Không phải mọi trạng thái trong cụm đều cần mức bền vững giống nhau. Sự kiện, hợp đồng thuê của nút và hợp đồng thuê phục vụ bầu chọn lãnh đạo đều có tính tạm thời. Chúng không nhất thiết phải dùng cùng một kho nhất quán, bền vững và được nhân bản bằng Raft như các đối tượng triển khai.
Đề xuất cải tiến Kubernetes 4743 xác định ranh giới cho giao diện lưu trữ. Tùy chọn định tuyến máy chủ etcd hiện có thể đưa các loại tài nguyên tích hợp tới những hệ thống phía sau khác nhau. Lập luận này không có nghĩa etcd là vấn đề hoặc cần bị thay thế. Một kho nhất quán đa dụng không nên phải nhận toàn bộ lưu lượng của dữ liệu không đòi hỏi độ bền tương đương.
Khoảng trống hiện tại là tùy chọn định tuyến chỉ nhận biết tài nguyên tích hợp. Nền tảng bị giới hạn bởi mức biến động chưa thể chuyển chính các tài nguyên tùy chỉnh đang tạo ra cơn bão ghi sang kho khác.
Hợp đồng về trạng thái sống của nút
Hợp đồng về trạng thái sống của nút xác định cách tín hiệu sống đi vào mặt phẳng điều khiển và trực tiếp giảm áp lực từ số nút. Một tầng hướng về nút có thể nhận các lần gia hạn rồi chỉ truyền tiếp thay đổi trạng thái thực sự. Cơ chế làm mới hợp đồng thuê trong bộ nhớ của etcd cũng có thể giảm chi phí của từng lần gia hạn.
Hai biện pháp có thể được dùng cùng nhau. Biện pháp thứ nhất đặt một tầng hướng về nút trước mặt phẳng điều khiển. Biện pháp thứ hai đưa mỗi lần gia hạn qua cơ chế làm mới hợp đồng thuê trong bộ nhớ của etcd thay vì thực hiện đầy đủ một lần xác nhận Raft. Vì thay đổi nằm trong chính etcd, lợi ích không chỉ dành cho cụm rất lớn mà còn có thể áp dụng tới cụm ba nút.
Trục phân mảnh
Trục phân mảnh xác định cách bộ điều khiển, bộ nhớ đệm và kho dữ liệu cùng chia đối tượng. Nếu các thành phần không dùng cùng một trục, bộ điều khiển sẽ thường xuyên phải tìm đối tượng nằm trong phân mảnh khác, làm giảm hiệu quả của việc mở rộng theo chiều ngang.
Đề xuất cải tiến Kubernetes 5866 đưa ra cơ chế lọc theo khoảng giá trị băm cho lưu lượng giao diện lập trình ứng dụng. Đây mới là nền móng. Hoạt động phối hợp, phân mảnh lại và chia nhỏ trình quản lý bộ điều khiển vẫn nằm ngoài phạm vi của đề xuất và cần được phát triển thêm.
Mức thường trú của bộ nhớ đệm
Mức thường trú của bộ nhớ đệm quyết định kube-apiserver giữ những đối tượng nào trong bộ nhớ. Máy chủ chỉ giao tiếp với bộ lập lịch không nhất thiết phải lưu thường trú mọi đối tượng. Theo kết quả thử nghiệm được The New Stack dẫn lại, nguyên mẫu chia hai phân mảnh giảm lượng bộ nhớ cấp phát của mỗi phân mảnh xuống xấp xỉ một nửa.
Vẫn tồn tại một mức sàn. Khi mọi bộ nhớ đệm có thể tắt đều đã bị vô hiệu hóa, một máy chủ giao diện lập trình ứng dụng còn giữ khoảng 0,9 KB cho mỗi đối tượng kiểm soát truy cập dựa trên vai trò. Các thành phần theo dõi của bộ cấp quyền vẫn giữ những đối tượng này.
Khả năng kiểm soát mức thường trú chưa có trong bản thượng nguồn. Đề xuất cải tiến Kubernetes 5866 lọc lưu lượng đi ra nhưng bộ nhớ đệm vẫn lưu tất cả đối tượng. Các nhánh nguyên mẫu và bản cập nhật đề xuất mới ở giai đoạn xem xét.
Năm cấp cấu hình theo quy mô nút
Năm cấp cấu hình đi từ cụm sẵn sàng cao tối đa 5.000 nút đến mô hình lát cắt phân mảnh chưa được xây dựng. Bảng này mô tả thành phần, điểm phân tách và mức bằng chứng cho từng cấp. Số nút được dùng làm thước đo vì đây là trục duy nhất đã có đủ số liệu kiểm thử để tạo thành các cấp cấu hình.
Thành phần và mức bằng chứng của từng cấp
| Cấu hình | Quy mô | Thành phần | Điểm phân tách | Mức bằng chứng |
|---|---|---|---|---|
| Sẵn sàng cao cổ điển | Tối đa 5.000 nút | 2 đến 3 mặt phẳng điều khiển giống nhau | Không có | Đã đo |
| Tách theo vai trò | 5.000 đến 20.000 nút | Tách nhóm máy cho giao diện lập trình ứng dụng, bộ lập lịch, trình quản lý bộ điều khiển và etcd | Điểm 4 | Đã phát hành, chưa đo lợi ích |
| Tầng nút | 20.000 đến 65.000 nút | Tách theo vai trò, cộng tầng hướng về nút để nhận hợp đồng thuê | Điểm 1 và 2 | Đã đo với một trường hợp |
| Kho phân vùng | Xấp xỉ 100.000 nút | Tầng nút, cộng việc chia loại tài nguyên sang các kho độc lập | Điểm 1 trên điểm 2 | Đã được trình diễn bên ngoài |
| Lát cắt phân mảnh | Vượt các mức trên | Nhiều đơn vị phân mảnh, mỗi đơn vị gồm bộ điều khiển và máy chủ giao diện lập trình ứng dụng gắn với một khoảng giá trị băm | Điểm 3 và 4 | Chưa tồn tại |
Các con số và mức bằng chứng trong bảng do The New Stack công bố. Bậc cuối được đưa vào dù chưa được xây dựng để chỉ rõ hướng phát triển còn thiếu.
Khoảng trống của các cấp cấu hình
Chưa có công thức đã qua kiểm thử quy mô dành riêng cho cụm bị giới hạn bởi mức biến động hoặc lượng trạng thái. Các cấu hình trên cũng không phải một bản phân phối mới. Chúng dùng tệp thực thi thượng nguồn tiêu chuẩn cùng cấu hình được kiểm tra trong quy trình tích hợp liên tục, nhờ đó thay đổi làm sai giả định có thể xuất hiện trước tiên dưới dạng lỗi kiểm thử.
Những nội dung cộng đồng còn có thể hoàn thiện
Cộng đồng Kubernetes còn thiếu cấu hình lưu trữ theo từng tài nguyên tùy chỉnh, cơ chế kiểm soát mức thường trú hoàn chỉnh và công thức đã kiểm thử cho các cụm chịu tải ghi hoặc lượng trạng thái lớn. Dữ liệu vận hành từ những cụm này có thể giúp kiểm chứng các điểm phân tách và xác định cấu hình phù hợp.
- Cấu hình lưu trữ theo từng tài nguyên tùy chỉnh sẽ mở rộng điểm phân tách đầu tiên. Chưa có đề xuất cải tiến cho phần này, nên số liệu tốc độ ghi từ các cụm chịu biến động thực tế là dữ liệu hữu ích cho nhóm phụ trách cơ chế giao diện lập trình ứng dụng.
- Đề xuất cải tiến Kubernetes 5866 và phần mở rộng về mức thường trú liên quan tới điểm phân tách thứ ba và thứ tư. Các nhánh nguyên mẫu đang được xem xét và thiết kế chưa được chốt.
- Cộng đồng vẫn thiếu công thức cho cụm vượt 20.000 nút, cụm có biến động ghi nghiêm trọng hoặc cụm giữ quá nhiều trạng thái. Kinh nghiệm vận hành từ các hệ thống này có thể bổ sung phần hướng dẫn còn trống.
Cụm huấn luyện, nền tảng tác tử và cụm nền tảng chạm ba giới hạn khác nhau. Các thành phần phải được ghép theo áp lực thực tế thay vì chỉ theo số nút.
Nếu đang vận hành Kubernetes ở quy mô lớn, hãy đối chiếu biểu đồ mặt phẳng điều khiển với ba trục trên trước khi bổ sung tài nguyên.
