Kubernetes Indexed Jobs Track Which Shards Completed

Give the completion index an application meaning

An indexed batch is useful when an application can divide a fixed task into declared parts. A worker can use its index to select the assigned part, and another attempt for that index can refer to the same assignment. Kubernetes supplies the numbered position; the application supplies its meaning.

The Kubernetes v1.34 static-assignment example illustrates an application mapping each index to a work item. For an inference batch offer, establish the input revision, model revision and index-to-shard mapping before interpreting completion. Shard A in input revision D must remain identifiable when a different Pod attempts its index.

Keep the population within one identified Job and its fixed assignment. Index 0 from another Job is a different completion identity. If an offer combines several Jobs, it needs an application account connecting their assignments; adding their index numbers does not establish one batch's coverage.

References: [K134-STATIC][K134-API]

Read the required success population

The versioned Kubernetes v1.34 documentation assigns an Indexed Job indexes from 0 through .spec.completions minus one. Under ordinary all-index semantics, each index needs a successful Pod. Only the first successful Pod for an index counts toward completion.

More than one Pod can sometimes start for the same index. The controller deletes other running or completed Pods for that index when it detects them. This accounting rule prevents repeated success from supplying a different index; it does not promise that the application code executed once.

A custom .spec.successPolicy can instead declare success using a required index subset or a count of successful indexes. Read the offered policy before deciding that all indexes are required. The worked case below has no custom successPolicy, uses a fixed four-index population and stipulates no failure or other termination criterion intervening. It applies the documented v1.34 behavior, rather than assigning these assumptions to every Kubernetes platform.

References: [K134-JOB][K134-API]

IJ245: five successes leave index 3 uncovered

Fictional case IJ245 contains one Indexed Job J. Its four required indexes are 0, 1, 2 and 3. The application assigns them respectively to inference shards A, B, C and D of one fixed input revision, using one fixed model revision. The shards are stipulated to partition the intended input population completely without overlap.

At the first review point, an external historical attempt record lists five distinct Pods that succeeded, with completion indexes 0, 1, 1, 2, 2. This is an invented historical record, not an observed cluster, a live Pod inventory or a claim that J reports status.succeeded equal to five.

The successful-index set in that history is {0, 1, 2}. Its size is three. Comparing it with the required set {0, 1, 2, 3} leaves {3} missing. The two records for index 1 both refer to shard B's assignment; the two for index 2 both refer to shard C's assignment. Neither repeated assignment supplies shard D.

The evidence therefore supports five historical successful attempts across three required indexes. It does not meet J's stipulated all-index condition. Counting five successes against four required indexes discards the membership information that makes indexed completion useful.

References: [K134-JOB]

Close coverage and then account for terminal Complete

Later in IJ245, a sixth successful Pod record has index 3. The history now covers {0, 1, 2, 3}: six historical successful attempts, four distinct required indexes and no missing index. This additional record closes the stipulated coverage gap.

The API's status.completedIndexes field records completed-index membership. Its format compresses three or more consecutive indexes, so an acknowledged set {0, 1, 2} is represented as 0-2, and {0, 1, 2, 3} as 0-3. The historical record alone is not a supplied API observation. A fuller account separately states that J's controller has recorded the four-index set.

Terminal status needs another observation. Under the documented default v1.34 controller behavior, Complete is added after all Job Pods terminate. Coverage arithmetic supplies neither that termination observation nor its timing.

Finish the fictional controller account by separately stipulating that all J's Pods subsequently terminate and the controller records the Complete condition with status True. IJ245 then supports both full required-index coverage and terminal completion. It supplies no elapsed duration, throughput or GPU-use measurement.

References: [K134-API][K134-JOB]

Connect the completed indexes to accepted shard results

For IJ245, a useful application return identifies the accepted output for each of A, B, C and D, links it to J's corresponding index, and confirms the fixed input and model revisions. It also states the agreed result criterion. For example, the application owner might require a valid result for every intended input and successful assembly of those results into the batch output.

Extend the fictional case with those observations: the application owner establishes that the four accepted shard outputs cover their assigned inputs, use the intended revisions and satisfy the agreed result criterion. Together with the separately supplied controller observations, this supports acceptance of this stipulated batch. The acceptance conclusion comes from those added application facts.

The mapping matters even with four completed indexes. If an application mistakenly assigned every index to shard A and reported success for that work, four-index controller coverage would not establish processing of B, C and D. Numbered positions make the assignments accountable; they do not inspect the dataset.

Likewise, selecting one accepted output per shard does not count every write or external action performed by repeated attempts. Any required protection against repeated effects needs application evidence for those effects. The related API-idempotency guide addresses the scope in which a service recognizes equivalent requests.

Read the offer as a complete batch account

Ask the platform and application owners for an explanation that connects the named Job, release and success policy to the required index population, the completed population and any missing indexes. Have it identify the observation point for controller membership and terminal status, then connect the accepted outputs to the declared shards and revisions.

For IJ245, the first explanation stops at five historical attempts and leaves index 3 uncovered. The fuller explanation returns six historical attempts, all four required indexes, a later recorded terminal Complete, and separately accepted outputs for A through D. Those statements describe the additional evidence that resolves the original buyer question.

Requested .spec.parallelism is a desired concurrency setting; actual running Pod counts can differ. It supplies no batch duration or application acceptance result. Preserve those distinctions when an offer presents worker counts as evidence of delivery.

Use the related CronJob article when the question concerns schedules and overlapping Jobs. Use the distributed-training sampler article when the question concerns record occurrences assigned to training ranks. Here the decision is whether this Job's required completion indexes connect to the intended, accepted shard outputs.

References: [K134-JOB]

Use the physical service route when equipment work is also approved

If the wider project includes a separately approved equipment work package, Leviathan's rack-and-stack service and related project inquiry provide a route to discuss agreed mounting, IT cabling, labels and physical installation records. Bring the equipment list, site, released rack and cable plans, requested window and receiving team.

Kubernetes administration and batch-result acceptance remain with the appointed platform and application owners. Software commissioning is outside the standard rack-installation scope.

References: [L1]