PodGroup Lifecycle

PodGroup Lifecycle

FEATURE STATE: Kubernetes v1.37 [beta](disabled by default)

A PodGroup is scheduled as a unit and protected from premature deletion while its Pods are still running.

Ownership and lifecycle

PodGroups are owned by the workload controller that created them (for example, a Job) via standard ownerReferences. When the owning object is deleted, PodGroups are automatically garbage collected.

PodGroup names must be unique within a namespace and must be valid DNS subdomains.

Creation ordering

Controllers must create objects in this order:

  1. Workload — the scheduling policy template.
  2. PodGroup — the runtime instance.
  3. Pods — with spec.schedulingGroup.podGroupName pointing to the PodGroup.

If a PodGroup includes a podGroupTemplateRef that points to a Workload that does not exist (or is being deleted), the API server rejects the PodGroup creation request. The referenced Workload must exist before the PodGroup can be created.

If a Pod references a PodGroup that does not yet exist, the Pod remains pending. The scheduler automatically queues the Pod for scheduling once the PodGroup is created.

Deletion protection

A PodGroup cannot be fully deleted while any of its Pods are still running. A dedicated finalizer ensures that deletion is blocked until all Pods referencing the PodGroup have reached a terminal phase (Succeeded or Failed).

Controller-managed and user-managed PodGroups

In most cases, workload controllers (for example, Job) create PodGroups automatically (controller-managed). The controller determines the podGroupName for each Pod at creation time, similar to how a DaemonSet sets node affinity per Pod.

If you need more control over naming and lifecycle, you can create PodGroup objects directly and set spec.schedulingGroup.podGroupName in your Pod templates yourself (user-managed). This gives you full control over PodGroup creation and naming.

Limitations

  • All Pods in a PodGroup must use the same .spec.schedulerName. If a mismatch is detected, the scheduler rejects all Pods in the group as unschedulable.
  • All Pods in a PodGroup must use the same .spec.priority. If a mismatch is detected, the scheduler rejects all Pods in the group as unschedulable.
  • All Pods in a PodGroup must use the same .spec.preemptionPolicy. If a mismatch is detected, the scheduler rejects all Pods in the group as unschedulable.
  • The spec.schedulingGroup field on a Pod is immutable. Once set, a Pod cannot move to a different PodGroup.
  • The maximum number of PodGroupTemplates in a single Workload is 8.
  • The scheduler does not update status information regarding the ongoing operational state of a PodGroup or subsequent scheduling attempts after initial placement. Consequently, the PodGroup status is not updated when existing Pods fail, are evicted, or terminate, or when newly observed Pods fail to schedule.

What's next

Last modified June 24, 2026 at 2:31 PM PST: Update docs for Workload-aware preemption beta promotion (326022dff5)