Kubernetes v1.34: Pod Replacement Policy for Jobs Goes GA
The Pod replacement policy feature for Kubernetes Jobs has reached general availability. By default, Jobs immediately replace terminating or failed Pods, potentially exceeding parallelism. This can cause issues for applications expecting single instances per index, like some machine learning frameworks. It can also lead to scheduling delays, unnecessary scaling, and temporary quota bypasses. The new feature allows users to control this behavior with the .spec.podReplacementPolicy field. The TerminatingOrFailed policy, the default, recreates Pods as soon as they start terminating. The Failed policy, however, only creates a new Pod after the old one has completely terminated and entered the Failed phase. For Jobs with a Pod Failure Policy, the Failed replacement policy is mandatory. The status of terminating Pods can be checked using kubectl get job myjob -o=jsonpath='{.status.terminating}'. An example demonstrates how setting the policy to Failed prevents a new Pod from starting until the terminating Pod has fully completed. This enhancement aims to provide more robust control over Job Pod lifecycle management.
.spec.podReplacementPolicyfield. TheTerminatingOrFailedpolicy, the default, recreates Pods as soon as they start terminating. TheFailedpolicy, however, only creates a new Pod after the old one has completely terminated and entered theFailedphase. For Jobs with a Pod Failure Policy, theFailedreplacement policy is mandatory. The status of terminating Pods can be checked usingkubectl get job myjob -o=jsonpath='{.status.terminating}'. An example demonstrates how setting the policy toFailedprevents a new Pod from starting until the terminating Pod has fully completed. This enhancement aims to provide more robust control over Job Pod lifecycle management.