KubeRay v1.7 has been released. The update brings a beta History Server, improvements to RayJob management, and stronger security for Ray workloads running on Kubernetes.
The project, which wires Ray to Kubernetes, posted the new version to its repository. It's a minor release, but the changes hit three areas that matter for teams running Ray jobs on Kubernetes clusters.
A beta History Server
The headline addition is the History Server, which now ships in beta. It's a new component in the KubeRay control plane, built to give operators a dedicated place for Ray job history outside of a single cluster's lifespan.
Beta status means it's ready to test but not yet recommended for production. Teams that want to try it will need to opt in and deploy it separately from the core control plane.
RayJob management gets a refresh
RayJob is the KubeRay resource that handles the full lifecycle of a Ray job on Kubernetes. The v1.7 release refines how RayJob resources are created, updated, and cleaned up, which should cut down on manual steps for users.
The release notes don't go deep into the mechanics, but the direction is clear: managing Ray jobs through RayJob is smoother now.
Security hardening for Ray workloads
Security gets a quiet but important boost in v1.7. The release tightens protections around Ray workloads, addressing how Ray clusters are secured when they run inside Kubernetes.
Teams running Ray in shared or multi-tenant environments will want to read the release notes closely to see what changed and how it affects their deployments.
KubeRay v1.7 is available now from the project's GitHub repository. Existing users should review the release notes before upgrading, and anyone curious about the History Server should treat it as what it is: a beta feature that's still finding its legs.
