Kubernetes v1.35 [alpha](disabled by default)A PodGroup is scheduled as a unit and protected from premature deletion while its Pods are still running.
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.
Controllers must create objects in this order:
Workload — the scheduling policy template.PodGroup — the runtime instance.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.
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).
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.
PodGroup must use the same .spec.schedulerName.
If a mismatch is detected, the scheduler rejects all Pods in the group as unschedulable.spec.schedulingPolicy.gang.minCount field on a PodGroup is immutable.
Once created, you cannot change the minimum number of Pods that must be schedulable for the group to be admitted.spec.schedulingGroup field on a Pod is immutable.
Once set, a Pod cannot move to a different PodGroup.PodGroupTemplates in a single Workload is 8.PodGroupScheduled condition reflects the outcome of the initial scheduling
attempt only. Once the condition is set to True, the scheduler does not update it
if Pods later fail, are evicted, or stop running.PodGroupTemplates.basic and gang.