Anyscale Connect bổ sung khả năng quan sát và gửi tác vụ cho KubeRay

Anyscale đã ra mắt KubeRay Connect dưới dạng bản xem trước riêng tư, bổ sung khả năng quan sát và gửi tác vụ cho các cụm KubeRay hiện có. Nhà vận hành có thể theo dõi trạng thái tác vụ Ray mà vẫn giữ nguyên cấu hình và công cụ KubeRay đang sử dụng.

Trong thông báo ngày 25 tháng 8 năm 2026, Anyscale cho biết Connect kết nối với các cụm KubeRay hiện có. Connect không trực tiếp tạo và quản lý các pod để chạy tác vụ, mà bổ sung tính năng của Anyscale vào mô hình trong đó KubeRay quản lý cụm. Tài liệu của công ty cũng nêu Connect không trực tiếp tạo hoặc quản lý cụm Ray.

Thời điểm công bố, Observe — công cụ hiển thị nhật ký và chỉ số — cùng Orchestrate — công cụ hỗ trợ gửi tác vụ và theo dõi trạng thái — đang ở giai đoạn xem trước riêng tư. Optimize, tính năng điều chỉnh hiệu suất và chi phí, được ghi là sẽ ra mắt sau. Người dùng cần đăng ký quyền truy cập để dùng bản xem trước riêng tư.

Connect bổ sung sidecar phục vụ quan sát vào cấu hình KubeRay hiện có. Các thành phần gồm Connector, có nhiệm vụ chỉnh sửa tài nguyên tùy chỉnh (CR) của KubeRay và đồng bộ trạng thái; Cluster Telemetry Gateway dựa trên OpenTelemetry Collector để thu thập nhật ký và chỉ số; cùng Observability API cung cấp dữ liệu quan sát cho bảng điều khiển. Anyscale cho biết tại thời điểm công bố, Connector được vận hành dưới dạng một pod duy nhất.

Theo tài liệu chính thức của Ray, nhật ký mặc định được lưu tại /tmp/ray/session_*/logs trên từng pod, còn Ray không cung cấp dịch vụ lưu trữ nhật ký. Vì vậy, cần có giải pháp thu thập và lưu giữ nhật ký riêng để điều tra nguyên nhân sau khi pod hoặc nút đột ngột ngừng hoạt động.

Cùng ngày, Anyscale cũng công bố GPU Health Observability dưới dạng bản xem trước riêng tư. Công ty cho biết công cụ này liên kết lỗi XID và ECC, trạng thái xung nhịp và bộ nhớ GPU với thông tin về tác vụ và nút Ray. Anyscale chưa đưa ra số liệu về mức thay đổi thời gian chẩn đoán sự cố hoặc độ sẵn sàng trong môi trường vận hành thực tế.

Bộ tự động mở rộng KubeRay của Ray điều chỉnh số lượng pod Ray theo nhu cầu tài nguyên của tác vụ và actor. Tiêu chí này khác với Kubernetes HPA thông thường, vốn dựa trên mức sử dụng CPU và bộ nhớ. Tài liệu Ray khuyến nghị đặt giá trị yêu cầu và giới hạn tài nguyên cho GPU và bộ nhớ bằng nhau nếu có thể.

Trong cấu hình mặc định, nút head là điểm lỗi đơn. Ray hướng dẫn cách ngăn pod head bị di dời trong quá trình bộ tự động mở rộng cụm hợp nhất các nút, đồng thời lưu ý cấu hình này không ngăn được sự cố nút.

Tài liệu Ray cho biết khi cấu hình tính năng chịu lỗi GCS, các ứng dụng Serve vẫn có thể xử lý tác vụ trong lúc nút head được khôi phục. Tuy nhiên, khả năng xử lý sự cố của actor và worker cũng như việc cập nhật cụm có thể bị hạn chế trong quá trình khôi phục.