Change:
must execute again. Changes to the init container spec are limited to the container image field. <del> Altering an init container image field is equivalent to restarting the Pod. </del> <ins> Directly altering the `image` field of  an init container does _not_ restart the Pod or trigger its recreation. If the Pod has yet to start, that change may have an effect on how the Pod boots up. For a [pod template](/docs/concepts/workloads/pods/#pod-templates) you can typically change any field for an init container; the impact of making that change depends on where the pod template is used. </ins> Because init containers can be restarted, retried, or re-executed, init container <del> code should be idempotent. In particular, code that writes to files on `EmptyDirs` </del> <ins> code should be idempotent. In particular, code that writes into any `emptyDir` volume </ins> should be prepared for the possibility that an output file already exists. Init containers have all of the fields of an app container. However, Kubernetes

Discussion:
K8S v1.23 doc about init containers have these two lines: 1“Changes to the init container spec are limited to the container image field. Altering an init container image field is equivalent to restarting the Pod.” 2“The Pod will not be restarted when the init container image is changed, or the init container completion record has been lost due to garbage collection.” so which one is true? altering an init container image will restart the pod or not?
/language en /kind support
/retitle Init containers concept page is confusing -
There's a difference between changing the string that represents the URI of an image, and changing the image that the URI represents. I think the page is talking about 2 different things, but not very clearly. (aside: Docker uses the term URI or URL for images, but the rest of the world of IT uses the term URI to mean web s)
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
We can mention the Pod image field as - and can mention init container image as (changing image from the repository.)
/remove-kind support
/sig node /triage accepted /priority backlog
If someone can give me the correct idea behind each of those two statements, I would be glad to make the change to the docs and create a pull req.
/assign
Raised the PR for this.