You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Kubernetes: Rework offers and resource handling (#4021)
* Switch the backend from ComputeWithFilteredOffersCached to
ComputeWithAllOffersCached. Kubernetes node offers don't depend on run
requirements, so all node offers are now cached once and
adjusted/filtered per requirements via get_offers_modifiers(), instead
of re-querying the cluster for every distinct requirements set.
* Emit a Kubernetes request of 0 when a resource range has no lower
bound (e.g. `cpu: ..4`). Previously no request was emitted, and since
Kubernetes defaults the request to the limit, `cpu: ..4` silently
behaved like `cpu: 4`. An explicit 0 request is less surprising and
matches how ranges behave elsewhere in dstack.
* Introduce ResourceRequests/ResourceLimits dataclasses that centralize
the translation between dstack ResourcesSpec and Kubernetes resource
maps, and back (from_kubernetes_map). Previously this logic was
duplicated and built ad hoc as dicts in _create_job_pod() and
get_instance_offers().
* Add adjust_resources_by_resource_requests() to cap an offer's
advertised resources to what was requested (used as the offer
modifier), and to reflect the actual pod requests on the provisioned
instance in run_job().
Copy file name to clipboardExpand all lines: mkdocs/docs/concepts/backends.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1247,9 +1247,9 @@ projects:
1247
1247
If you use ranges with [`resources`](../concepts/tasks.md#resources) (e.g. `gpu: 1..8` or `memory: 64GB..`) in fleet or run configurations, other backends collect and try all offers that satisfy the range.
1248
1248
1249
1249
The `kubernetes` backend handles it differently.
1250
-
1250
+
1251
1251
* For `gpu`, if you specify a range (e.g. `gpu: 4..8`), the `kubernetes` backend only provisions pods with the GPU count equal to the lower limit (`4`). The upper limit of the GPU range is always ignored.
1252
-
* For other resources such as `cpu`, `memory`, and `disk`, the `kubernetes` backend passes the lower and upper limits of the range as Kubernetes [requests and limits](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) respectively. If the upper limit is not set, the Kubernetes limit is also not set.
1252
+
* For other resources such as `cpu`, `memory`, and `disk`, the `kubernetes` backend passes the lower and upper limits of the range as Kubernetes [requests and limits](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) respectively. If the lower limit is not set, the Kubernetes request is set to `0`, unlike Kubernetes, where the request defaults to the limit if not set. If the upper limit is not set, the Kubernetes limit is also not set.
0 commit comments