Skip to main content
To make sure that GPU capacity is always available for your nodes (virtual machines, VMs), you can reserve GPUs. A reservation represents a capacity block group, and it reserves a specific number of GPUs that are allocated to your infrastructure. GPUs from a reservation remain available, even if a VM is stopped. Without reservations, GPU capacity is taken from a shared pool and returned when a VM is stopped (for example, by you or a maintenance event). To start using reservations, send a request to your Nebius manager. In this request, specify how many GPUs you would like to reserve and for what period. If you are not in contact with a Nebius manager, you can ask technical support to connect you with one. After reservations are ready, you can add them to your existing node groups or create new ones with reservations. You can also check your capacity block groups on the Limits page and get detailed information about them. For more information, see List of capacity block groups.
GPUs allocated from reservations do not count towards quotas on the number of GPUs.

​
How to add reservations to node groups

Node groups of a regular type with GPUs support reservations. Preemptible node groups and node groups without GPUs do not support reservations.
To configure reservations, use the --template-reservation-policy-* parameters when creating or updating a node group:
  • Create a node group: 
    nebius mk8s node-group create \
   ... \
   --template-reservation-policy-policy <auto|forbid|strict> \
   --template-reservation-policy-reservation-ids <reservations>
  • Update a node group: 
    nebius mk8s node-group update \
   ... \
   --template-reservation-policy-policy <auto|forbid|strict> \
   --template-reservation-policy-reservation-ids <reservations>
Description of the parameters:
  • --template-reservation-policy-policy: Policy for reservation usage. Supports the following values:
    • auto: Node group resources are allocated from reservations. If no reservations are currently available, the node group runs without them. In this case, resources for the node group are provided from the common pool.
      The auto value is default. If you don’t have any reservations and you don’t set the --template-reservation-policy-policy parameter, the auto value applies and the node group runs without reservations.
    • forbid: Node group resources are provided from the common pool; no reservations are used.
    • strict: Node group resources are exclusively allocated from reservations. The node group doesn’t run without the reservations.
  • --template-reservation-policy-reservation-ids (optional): IDs of specific reservations (capacity block groups). Use this parameter only if you need specific reservations. Specify the IDs in the order in which reservations should apply. For instance, resources should be allocated from the first specified reservation. When it is exhausted or expired, the service uses resources from the second specified reservation, and so on. Make sure to select reservations that have enough capacity and that do not expire in several days.
To find out how different combinations of parameter values impact the result, see the table below:
policyreservation-idsBehavior
autoNot specified

Managed Kubernetes tries to launch a node group in any available and suitable reservation. If none is found, resources for all nodes in the node group are provided from the common pool, not from a reservation.

If a reservation doesn’t have enough capacity for the whole node group, it uses all the resources available in this reservation and also takes resources from the common pool. In other words, resources for some nodes are provided from the reservation, and resources for the rest of the nodes are provided from the common pool.

autoSpecifiedManaged Kubernetes tries to launch a node group in one of the specified reservations. If none of them fit (for example, they are not currently active or there are not enough GPUs), the same logic of the auto policy applies.
forbidNot specifiedNode group resources are provided from the common pool. No reservations are used.
forbidSpecifiedNot supported. If you apply this combination, it will result in a validation error.
strictNot specifiedManaged Kubernetes tries to launch a node group in any available and suitable reservation. If none is found, a request for creating or updating a node group fails.
strictSpecifiedManaged Kubernetes tries to launch a node group in one of the specified reservations. If none of them fit, a request for creating or updating a node group fails.

​
What’s next

To find information about reservations, check the pages of your VMs (nodes). The VM page and the list of VMs show what reservation policy you have configured and what reservations currently apply. For more information, see How to find information about reservations for an already configured VM. For details about how billing works when you use reservations, see Billing for reservations.

​
See also