Nova FAQ

General

Can Nova run on any cloud provider? What about on-premises?

Nova is designed to manage fleets of CNCF-conformant Kubernetes workload clusters regardless of whether they run on public cloud or on-premises infrastructure. This includes distributions such as Amazon EKS, Google GKE, Microsoft AKS, Oracle OKE, OpenShift, and other conformant Kubernetes distributions.

Nova is regularly tested on EKS, GKE, and AKS. If you are interested in using Nova with another Kubernetes distribution or managed service, please contact info@elotl.co.

Can Nova manage workload clusters across regions and cloud providers?

Yes. A Nova fleet can include workload clusters spanning multiple regions, cloud providers, and on-premises environments. Nova treats these as a single logical compute fabric while applying placement policies across the fleet.

How and where is data for the Nova Control Plane stored?

Nova stores control plane data in a dedicated Nova etcd instance.

This etcd instance runs as part of the Nova Control Plane and is separate from the Kubernetes datastore used by the hosting cluster. The Nova etcd instance is backed by a PersistentVolumeClaim (PVC) in the Kubernetes hosting cluster where the Nova Control Plane is installed.

Because the Nova Control Plane depends on this PVC-backed etcd datastore, the hosting cluster must have a working storage provisioner and default StorageClass before Nova is installed.

What is the difference between Concepts and Advanced Use Cases?

The Concepts section explains how Nova works, including scheduling, placement behavior, workload movement, and system metadata.

The Advanced Use Cases section demonstrates how those capabilities are applied to solve real-world scenarios such as GPU workload placement, disaster recovery, and KubeRay integration.

Scheduling

When should I use annotation-based scheduling versus policy-based scheduling?

Use annotation-based scheduling when a workload should always run on a specific workload cluster. It is also an excellent way to get started with Nova, allowing you to quickly validate a deployment or perform an initial proof of concept without first creating a SchedulePolicy.

Use policy-based scheduling when workload placement should be determined dynamically using namespace selectors, resource selectors, cluster selectors, and placement behavior. This approach scales well as your environment grows and enables more advanced capabilities such as grouping, spread scheduling, fill-and-spill scheduling, and automatic workload movement.

For more information, see - Policy-based Scheduling - Labels and Annotations

What happens when multiple SchedulePolicies match the same workload?

If multiple SchedulePolicies match a workload, Nova sorts the matching policies lexicographically by name and applies the first policy in the sorted list.

What Kubernetes resource types can Nova schedule?

Nova supports the Kubernetes resource types commonly used to define application workloads.

For the complete list of supported resource types, see API Resources.

Can Nova move workloads automatically?

Yes. Nova can move workloads automatically when placement requirements change, such as updates to SchedulePolicy resources or changes in workload cluster resource availability.

For more information, see Concepts → Workload Movement.

Can Nova create workload clusters on demand?

Yes. Nova supports just-in-time workload clusters by creating or resuming workload clusters when additional capacity is needed.

When a supported cluster autoscaler (such as Elotl Luna or Kubernetes Cluster Autoscaler) is available, Nova prefers to use the autoscaler to provision additional capacity before creating a new workload cluster.

For more information, see Just-in-Time Workload Clusters.

Does Nova require a cluster autoscaler?

No. Nova's just-in-time workload cluster capability works independently of a cluster autoscaler.

When Elotl Luna or Kubernetes Cluster Autoscaler is available, Nova integrates with and prefers those autoscalers for node provisioning and scaling whenever they can satisfy workload placement.

What objects does Nova track and manage?

Nova primarily tracks and manages top-level Kubernetes objects that are created in the Nova Control Plane and match Nova scheduling rules.

At a high level, Nova is aware of:

• Workload clusters registered with the Nova Control Plane.
• SchedulePolicy resources that define how workloads should be selected and placed.
• ScheduleGroup resources created by Nova to track groups of related resources that should be scheduled together.
• Supported top-level Kubernetes resources, such as Deployment, StatefulSet, Service, Namespace, and other supported API resources.
• Supported custom resources, such as KubeRay resources, when those resource types are installed and supported by Nova.

Nova uses these objects to determine:

• which resources should be scheduled,
• which workload clusters are eligible,
• whether related resources should be grouped,
• whether the workload or group fits on an eligible workload cluster,
• and where the workload should be placed.

When Nova places a top-level object on a workload cluster, the Nova agent creates or updates the corresponding object in that workload cluster. Kubernetes then handles any child objects created by that top-level object.

For example, if Nova schedules a Deployment, the Nova agent creates the Deployment in the selected workload cluster. The Kubernetes control plane in that workload cluster is then responsible for creating and managing the Deployment’s child resources, such as ReplicaSet and Pod objects.

Nova does not schedule each child Pod from a Deployment as a separate top-level Nova scheduling decision. Instead, Nova schedules the parent Deployment, and Kubernetes schedules the resulting Pods within the selected workload cluster.

This distinction is important when troubleshooting. If a Deployment was placed by Nova but its Pods are not running, first verify that Nova placed the Deployment on the expected workload cluster. Then troubleshoot the child Pods within that workload cluster using standard Kubernetes tools, such as kubectl describe pod, events, node availability, taints/tolerations, image pull errors, and resource requests.

For the full list of Kubernetes resource types Nova can schedule, see API Resources.

Operations

Are workload clusters locked down?

No.

Users with direct access to a workload cluster can perform normal Kubernetes CRUD operations on resources within that cluster, including resources managed by Nova.

However, changes made directly in a workload cluster are not reflected back to the Nova control plane. If a Nova-managed workload is later updated through the Nova control plane, those direct changes may be overwritten as Nova reconciles the workload to its desired state.

Organizations that want all workload changes to be managed consistently should restrict direct access to workload clusters and require that changes be made through the Nova control plane.

Does the Nova control plane require credentials for workload clusters? How do Nova agents authenticate?

No. During installation, each Nova agent securely registers with the control plane using limited credentials. The control plane then provisions the credentials required for ongoing agent operation.

For additional details, see the Introduction section on agent and control plane communication.

Does Nova work with GitOps tools such as Argo CD?

Yes.

Nova works with GitOps tools such as Argo CD because workloads are submitted to the Nova Control Plane as standard Kubernetes resources.

From a GitOps perspective, the Nova Control Plane can be treated like the target Kubernetes API endpoint. Argo CD, Flux, or another GitOps tool can apply manifests to the Nova Control Plane, and Nova then determines where those resources should run based on annotations or SchedulePolicy configuration.

This allows teams to continue using GitOps workflows while letting Nova handle multi-cluster placement across workload clusters.

For more information, see Using Argo CD with Nova.

Is Nova highly available?

Yes. Nova is itself a Kubernetes application and can be deployed in a highly available configuration using standard Kubernetes high availability practices.

How does Nova support disaster recovery?

Nova includes a Kubernetes-native recovery framework for orchestrating recovery workflows across workload clusters.

For more information, see Disaster Recovery and Failover.

Integrations

Can Nova schedule GPU workloads?

Yes.

Nova can schedule GPU workloads onto workload clusters with available GPU resources using standard Kubernetes resource requests and placement policies.

In addition to traditional GPU resource requests, Nova understands Kubernetes workloads that use NVIDIA Multi-Instance GPU (MIG) and Kubernetes Dynamic Resource Allocation (DRA), allowing these workloads to be placed appropriately across eligible workload clusters.

For more information, see GPU Workload Placement.

Does Nova support service meshes?

Yes. Nova schedules Kubernetes resources and therefore supports deploying service mesh components such as Istio.

Service discovery between clusters is provided by the service mesh rather than by Nova itself.

How does Nova handle service discovery between services running across multiple workload clusters?

Nova schedules Kubernetes resources across workload clusters, including resources such as Service, Deployment, and other supported API resources. However, Nova does not replace Kubernetes service discovery, DNS, ingress, gateways, service mesh, or other networking components.

Within a workload cluster, service discovery works the same way it does in Kubernetes. For example, a Service scheduled to a workload cluster is discoverable by workloads running in that same workload cluster according to normal Kubernetes DNS and networking behavior.

For services that need to communicate across workload clusters, the environment must provide the required cross-cluster connectivity and discovery mechanism. This might include external DNS, ingress, gateway configuration, a service mesh, cloud load balancers, or another networking solution.

Nova can help place related resources together by using placement policies such as grouping and co-location. If multiple services must communicate using standard in-cluster Kubernetes service discovery, they should generally be scheduled to the same workload cluster.

For more information, see Grouping and Co-location.

Can Nova work with KubeRay?

Yes.

Nova integrates with KubeRay through SkyRay, enabling Ray workloads to be deployed and scheduled across multiple workload clusters while leveraging Nova's placement capabilities.

For more information, see SkyRay: Multi-Cluster Ray Scheduling.

Can Nova help manage Argo Rollouts across multiple clusters?

Yes. Nova can deploy Argo Rollouts resources across multiple workload clusters and provides aggregated rollout status through the Nova control plane.

See the Multi-Cluster Canary Rollouts tutorial.

Stateful Workloads

How are persistent volumes handled during workload migration?

Stateful workloads should use storage that is accessible from both the source and destination workload clusters. Depending on the environment, this may include shared object storage, replicated storage systems, or cloud-native storage services.

Application-level data replication and storage architecture remain the responsibility of the workload itself.