The binder is the only writer of a claim's placement, so budget and
capacity checks that admission already ran cannot be raced past by two
replicas. Every event collapses into one pass over all GPU objects,
which serializes the decisions without per-object locks, and claims
are read past the cache so a unit booked in the last pass is never
booked again from a stale view.
A VM starts through its launcher pod, which the pod webhook holds at a
scheduling gate. The pass creates the VMI's template claims, gathers
the whole set onto one node that every class of the set tolerates and
has room on, then pins the pod there and removes the gate in one
update, since the API server lets a pod's node affinity change only
while the pod is gated. A set that cannot be placed keeps its pod
gated with a condition on its claims and a Warning event on the VMI,
once per change of reason, so the VM waits for capacity instead of
being refused into KubeVirt's backoff. The set goes only to a node the
pod's own node selector and required affinity accept and, when the VMI
has a volume bound to a node's PersistentVolume, that volume reaches.
Gated pods go before moves and new orders.
A pin cannot be undone, so a pinned pod its node refuses for lack of
resources is deleted and the node is skipped for that set for ten
minutes, or until its allocatable, taints or readiness change. The
template claims of the set go with its failed VMI, so the controller
also keeps the rejection in memory for the VM's next VMI. Only a VMI
whose pod is already pinned is deleted to free a claim whose node
cannot keep it; a VMI whose pod is gated has its set gathered instead.
The full pass also moves held sets off nodes that cannot keep them,
rebinds Lost sets before new orders, and binds new orders onto the
fullest node with room. Finalizers and usage records run with the
feature disabled too, so turning GPU off never hangs a namespace or
class deletion. Each usage record is owned by its claim and sits under
no WorkloadMonitor, so no tenant label can add or drop one, and
garbage collection removes it with the claim. Without a monitor label
the Workload controller would take such a record for an orphan, so it
now leaves a record owned by a GPUClaim to that owner.
The claims one VM names move, go Lost and are rebound as a set. Every
pass restores that invariant before it places anything, gathering a
set left partly Lost, by a write that failed half way or by a VMI that
ended next to held members, onto one node or sending all of it to
Lost, so each later step only ever changes whole sets.
A Lost claim already counts against its tenant's budgets, so the pod
of its still running VMI is not counted again under a raw GPU key; for
node capacity it is, since the claim itself holds no units. A pod is a
VMI's launcher only when the VMI lists it in status.activePods,
because whoever creates a pod sets its owner reference. The KubeVirt
watches start once KubeVirt serves its kinds, whose CRDs a fresh
install adds after this controller starts.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Workloads tracking an object undergoing deletion can be reconciled when
the object is marked for deletion, but is not yet removed. After the
object is deleted, there is no event to trigger another reconciliation
of the workload and it might never get deleted until a global reconcile
happens or the controller is restarted. This patch ensures they are
requeued in the reconciliation loop.
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
* Count Workload resources for pods by requests, not limits
* Do not count init container requests
* Prefix Workloads for pods with `pod-`, just like the other types to
prevent possible name collisions (closes#787)
The previous version of the WorkloadMonitor controller incorrectly
summed resource limits on pods, rather than requests. This prevented it
from tracking the resource allocation for pods, which only had requests
specified, which is particularly the case for kubevirt's virtual machine
pods. Additionally, it counted the limits for all containers, including
init containers, which are short-lived and do not contribute much to the
total resource usage.
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
Aleksei Sviridkin