A GPU Rollout Can Hold More Resources Than Its Surge Count

Separate the desired, non-terminating, available and terminating populations

For a buyer comparing rollout capacity, the first question is which population a replica number describes. This explanation uses the archived Kubernetes v1.34 documentation and Kubernetes API v0.34.0 definitions for a Deployment using RollingUpdate.

The desired target is spec.replicas. In the pinned API, status.replicas counts targeted non-terminating Pods. The availableReplicas field counts available non-terminating Pods: ready for at least minReadySeconds. Those available Pods are already inside the non-terminating population. The updatedReplicas and readyReplicas fields describe overlapping subsets too.

A GPU allocation account needs a different grouping: distinct allocations still held at the same observation time. A desired target is not an additional resource holder, and an available Pod must not be counted again after its allocation has already been included.

References: [KA]

Deletion begins a transition before resources are released

During a rolling update, the Deployment changes the old and new ReplicaSet populations. The v1.34 Deployment documentation explicitly warns that terminating Pods can keep consuming resources beyond replicas plus maxSurge. Its Pod lifecycle account describes deletion as the beginning of tracked shutdown, with containers stopping asynchronously.

For a capacity comparison, a deletion timestamp therefore establishes a lifecycle transition. It does not establish that an allocation is available for another Pod. The useful evidence is whether the particular allocation remains held or has actually been released.

The GPU scheduling reference explains that device plugins expose custom schedulable GPU resources. Establish what each resource unit represents in the offered arrangement before translating Pod counts into hardware. ROLL-8 below explicitly supplies exclusive whole GPUs and one retained allocation per Pod; that relationship must not be assumed for a different allocation model.

References: [KD][KL][KG]

ROLL-8: five non-terminating Pods can coexist with seven held GPUs

Consider one fictional Deployment with a desired count of four, maxSurge of 25% and maxUnavailable of 25%. These are supplied example inputs. Kubernetes rounds a percentage surge upward and a percentage unavailability allowance downward: ceil(4 × 0.25) = 1 surge Pod, and floor(4 × 0.25) = 1 unavailable Pod. Desired plus surge is therefore five.

Now stipulate one current, reconciled snapshot. Five non-terminating Pods belong to this Deployment, and four of those five are available. Two additional, distinct Pods from the same Deployment are terminating. Every one of these seven Pods still holds one separate exclusive whole-GPU allocation in an eligible eight-GPU pool. There are no other occupants, no GPU sharing and no additional placement constraints.

The allocation account is five held by non-terminating Pods plus two held by terminating Pods: 5 + 2 = 7 GPUs. Free capacity is 8 − 7 = 1 GPU. Counting only the five non-terminating Pods would incorrectly report 8 − 5 = 3 free GPUs, overlooking the two retained allocations.

The four available Pods are a subset of the five. Adding four to five and then adding the two terminating Pods would count the available population twice. Conversely, subtracting the one-Pod unavailability allowance from occupied GPUs would mix an availability constraint with resource ownership. Neither calculation describes this pool.

This is a conditional comparison of supplied states, not a simulated controller event sequence, a global peak bound, a cluster-size recommendation, a measured workload or a continuity and performance promise.

References: [KD][KA][KG]

The later release changes headroom without changing the five-Pod count

At a later stipulated observation, the two terminating containers have finished and their two GPU allocations have actually been released. Hold everything else equal: the same five non-terminating Pods retain their five GPUs, four remain available, and the eligible pool still contains eight GPUs.

The new account is five held and 8 − 5 = 3 free. The non-terminating count remained five across the two observations. The two extra free GPUs came from the separately established allocation releases. Reinterpreting the earlier five-Pod count cannot produce that change.

A five-GPU pool could not support the earlier seven simultaneous exclusive allocations. It would be short by two GPUs under the stated premises. A real deployment with only five eligible GPUs would need a different state than the seven-allocation snapshot; the example supplies no evidence for which Pods would wait, where they might run or how its controller would progress.

Compare the proposed capacity with the overlap it must support

An offer described as four replicas with one surge replica identifies a rollout allowance. It leaves the temporary allocation envelope incomplete until the supplier accounts for allocations retained by departing Pods. ROLL-8 shows the consequence: the same desired-plus-surge arithmetic can accompany seven held GPUs before release and five afterward.

Ask the platform provider to connect its capacity claim to the actual controller, GPU allocation model and simultaneous workload population. The comparison needs the eligible pool, distinct retained allocations and the observation time they describe. Combining a five-Pod status view from one moment with a termination view from another cannot establish ROLL-8's simultaneous seven allocations.

If the offer is limited to five exclusive GPU resources, establish which overlap its included rollout behavior can support within that limit. If the offered evidence shows seven allocations, establish the eligible resources supporting all seven. Choosing a larger pool still requires the actual workload and placement analysis; this example establishes the accounting question rather than the purchase quantity.

Treat terminating-Pod telemetry as a version-qualified observation

In the archived v1.34 documentation, tracking through status.terminatingReplicas is an alpha feature introduced in v1.33 and disabled by default. Its presence cannot be assumed for an offered cluster. The API defines this population using a non-null deletionTimestamp and a Pod phase that has not yet reached Failed or Succeeded.

A missing field supplies no count of zero. Even a present, current Pod count does not identify the retained GPU allocations by itself. ROLL-8 supplies those allocations separately. For an actual capacity claim, the platform provider needs evidence of resource ownership and release that fits its supported implementation.

References: [KD][KA]

Keep eviction, request completion and other rollout strategies in their own scope

Use the related PDB guide to evaluate covered eviction permission, the endpoint-termination guide to follow requests already accepted, and the replica-versus-node guide to distinguish workload demand from worker capacity. Each answers a different decision around the same transition. Four available Pods in ROLL-8 do not establish completed responses or sufficient performance for a particular demand.

The related llm-d 1.0 analysis follows cache, priority and revision coordination, including spare-accelerator needs for a named replacement-before-drain strategy. That discussion is scoped to its serving arrangement and strategy. This Deployment calculation does not assume every rollout uses DisaggregatedSet, or transfer that controller's revision behavior to an ordinary Deployment.

Connect a separately selected equipment addition to physical installation

If the capacity decision separately leads to equipment that needs installation, Leviathan's Complete Physical Infrastructure Deployment service can discuss agreed receiving, rack integration, onsite installation, IT cabling and physical handoff records. Use the related service and project inquiry with a nonconfidential equipment list, quantities, destination, connection requirements and receiving platform team to discuss scope and availability.

Kubernetes administration, rollout execution and application acceptance remain with the appointed platform and software providers. The physical inquiry begins with the equipment package selected through that separate capacity decision.

References: [L1]