Change:
// If pod should not restart, make sure the status update does not transition // any terminated containers to a non-terminated state. allErrs = append(allErrs, ValidateContainerStateTransition(newPod.Status.ContainerStatuses, oldPod.Status.ContainerStatuses, fldPath.Child("containerStatuses"), oldPod.Spec.RestartPolicy)...) <del> allErrs = append(allErrs, ValidateContainerStateTransition(newPod.Status.InitContainerStatuses, oldPod.Status.InitContainerStatuses, fldPath.Child("initContainerStatuses"), oldPod.Spec.RestartPolicy)...) </del> <ins> allErrs = append(allErrs, ValidateInitContainerStateTransition(newPod.Status.InitContainerStatuses, oldPod.Status.InitContainerStatuses, fldPath.Child("initContainerStatuses"), &oldPod.Spec)...) </ins> // The kubelet will never restart ephemeral containers, so treat them like they have an implicit RestartPolicyNever. allErrs = append(allErrs, ValidateContainerStateTransition(newPod.Status.EphemeralContainerStatuses, oldPod.Status.EphemeralContainerStatuses, fldPath.Child("ephemeralContainerStatuses"), core.RestartPolicyNever)...) allErrs = append(allErrs, validatePodResourceClaimStatuses(newPod.Status.ResourceClaimStatuses, newPod.Spec.ResourceClaims, fldPath.Child("resourceClaimStatuses"))...)

Discussion:
I created a pod with sidecar container with following manifest: watch the pod readiness. in , it's mentioned "If a readinessProbe is specified for this init container, its result will be used to determine the ready state of the Pod." it's true only for = Always, sidecar container readniess result will be used in Pod ready state, neither "Never" or "OnFailure". I tested with v1.29.0 I expect "If a readinessProbe is specified for this init container, its result will be used to determine the ready state of the Pod." also applicable to = "Never" or "OnFailure". Set = "Never" or "OnFailure". No response <details</details<details</details<details</details<details</details<detailscontainerd --version containerd v1.7.11 </details<details</details
/sig node
/remove-kind bug /kind feature I think this is a feature request, because you want to do something different than the documentation.
can you please take a look It well may be a bug /cc
/assign
confirmed that this issue is reproduced. I'll take a look. /triage accepted This happens in a container with Always containerRestartPolicy from the pod with Never or OnFailure restartPolicy. I think this is a bug. /remove-kind feature /kind bug
/priority important-soon
After a quick debug, it seems that the problem is the apiserver who is preventing the initContainerStatus from being changed from terminated to non-terminated state.
created a PR to address this.
Just a small comment on whether we need a cherry pick. This only affects specific pods with the new beta feature enabled. I don't think it is justifiable to cherry-pick this
do you think this bug is critical enough to cherry-pick. Just discussed on sidecar WG and it feels that impact may be more dangerous than I undertsood. will summarize
IIUC it doesn't seem that critical to Istio, epsecially if its high risk to backport
the fix is relatively easy, but I am operating from the assumption that everything is high risk to backport =)
I confirmed that the bug is not only limited to the sidecar container with . Kubernetes cannot update the terminated sidecar container' statuses from Job without the bugfix (regardless of the ).

The sidecar container can continually restart but its container status will be stuck in the first terminated state. It seems like a quite critical bug for me.
Updated the PR description. 1.29: 1.28: