ResourceClaim [page]deterministic

`apiVersion: resource.k8s.io/v1`

`import "k8s.io/api/resource/v1"`

## ResourceClaim {#ResourceClaim}

ResourceClaim describes a request for access to resources in the cluster, for use by workloads. For example, if a workload needs an accelerator device with specific properties, this is how that request is expressed. The status stanza tracks whether this claim has been satisfied and what specific resources have been allocated.

<hr>

<table> <thead><tr><th>Field</th><th>Description</th></tr></thead> <tbody> <tr> <td><code>apiVersion</code><br/><em>string</em></td> <td>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</td> </tr> <tr> <td><code>kind</code><br/><em>string</em></td> <td>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</td> </tr> <tr> <td><code>metadata</code><br/><em><a href="">ObjectMeta</a></em></td> <td>Standard object metadata</td> </tr> <tr> <td><code>spec</code>&nbsp;<strong>*</strong><br/><em><a href="">ResourceClaimSpec</a></em></td> <td>Spec describes what is being requested and how to configure it. The spec is immutable.</td> </tr> <tr> <td><code>status</code><br/><em><a href="">ResourceClaimStatus</a></em></td> <td>Status describes whether the claim is ready to use and what has been allocated.</td> </tr> </tbody> </table>

## ResourceClaimSpec {#ResourceClaimSpec}

ResourceClaimSpec defines what is being requested in a ResourceClaim and how to configure it.

<hr>

<table> <thead><tr><th>Field</th><th>Description</th></tr></thead> <tbody> <tr> <td><code>devices</code><br/><em><a href="">DeviceClaim</a></em></td> <td>Devices defines how to request devices.</td> </tr> </tbody> </table>

## ResourceClaimStatus {#ResourceClaimStatus}

ResourceClaimStatus tracks whether the resource has been allocated and what the result of that was.

<hr>

<table> <thead><tr><th>Field</th><th>Description</th></tr></thead> <tbody> <tr> <td><code>allocation</code><br/><em><a href="">AllocationResult</a></em></td> <td>Allocation is set once the claim has been allocated successfully.</td> </tr> <tr> <td><code>devices</code><br/><em><a href="">AllocatedDeviceStatus array</a></em></td> <td>Devices contains the status of each device allocated for this claim, as reported by the driver. This can include driver-specific information. Entries are owned by their respective drivers.</td> </tr> <tr> <td><code>reservedFor</code><br/><em><a href="">ResourceClaimConsumerReference array</a></em><br/><em>patch strategy: merge on key <code>uid</code></em></td> <td>ReservedFor indicates which entities are currently allowed to use the claim. A Pod which references a ResourceClaim which is not reserved for that Pod will not be started. A claim that is in use or might be in use because it has been reserved must not get deallocated. In a cluster with multiple scheduler instances, two pods might get scheduled concurrently by different schedulers. When they reference the same ResourceClaim which already has reached its maximum number of consumers, only one pod can be scheduled. Both schedulers try to add their pod to the claim.status.reservedFor field, but only the update that reaches the API server first gets stored. The other one fails with an error and the scheduler which issued it knows that it must put the pod back into the queue, waiting for the ResourceClaim to become usable a …(trimmed)