Is your feature request related to a problem? Please describe.
The Milvus operator currently lacks the ability to set a custom RuntimeClassName in the Kubernetes Deployment objects it manages. This parameter is crucial for specifying the container runtime configuration, especially when deploying on GPU nodes that can leverage them with Milvus v2.3 newly introduced GPU indexing acceleration.
Describe the solution you'd like.
To implement this feature, a new field can be added to the ComponentSpec struct to hold the RuntimeClassName.
This change allows users to specify a custom runtime class through the Milvus custom resource, thereby enabling more fine-grained control over the runtime environment.
Describe an alternate solution.
Another approach could be to use a mutating admission webhook that intercepts the Deployment objects created by the Milvus operator. The webhook could then modify the RuntimeClassName field before the object is actually committed to the Kubernetes API server. Albeit suboptimal, it could still be a strategy to implement this feature, given it is not a common configuration.
Anything else? (Additional Context)
Setting a custom RuntimeClassName is particularly important for deployments that require specialized runtime environments, such as those interacting with Kubernetes nodes equipped with GPUs.
Is there an existing issue for this?
Is your feature request related to a problem? Please describe.
The Milvus operator currently lacks the ability to set a custom
RuntimeClassName
in the Kubernetes Deployment objects it manages. This parameter is crucial for specifying the container runtime configuration, especially when deploying on GPU nodes that can leverage them with Milvus v2.3 newly introduced GPU indexing acceleration.Describe the solution you'd like.
To implement this feature, a new field can be added to the
ComponentSpec
struct to hold theRuntimeClassName
.Then, in the
updatePodTemplate
function withindeployment_updater.go
, theRuntimeClassName
can be set like so:This change allows users to specify a custom runtime class through the Milvus custom resource, thereby enabling more fine-grained control over the runtime environment.
Describe an alternate solution.
Another approach could be to use a mutating admission webhook that intercepts the Deployment objects created by the Milvus operator. The webhook could then modify the
RuntimeClassName
field before the object is actually committed to the Kubernetes API server. Albeit suboptimal, it could still be a strategy to implement this feature, given it is not a common configuration.Anything else? (Additional Context)
Setting a custom
RuntimeClassName
is particularly important for deployments that require specialized runtime environments, such as those interacting with Kubernetes nodes equipped with GPUs.