Code change:
resource requests and limits for an init container are handled differently, as documented in [Resource sharing within containers](#resource-sharing-within-containers). <del> Also, init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` because they must run to completion before the Pod can be ready. </del> <ins> Regular init containers (in other words: excluding sidecar containers) do not support the `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` fields. Init containers must run to completion before the Pod can be ready; sidecar containers continue running during a Pod's lifetime, and _do_ support some probes. See [sidecar container](/docs/concepts/workloads/pods/sidecar-containers/) for further details about sidecar containers. </ins> If you specify multiple init containers for a Pod, kubelet runs each init container sequentially. Each init container must succeed before the next can run. When all of the init containers have run to completion, kubelet initializes the application containers for the Pod and runs them as usual. <ins> ### Differences from sidecar containers Init containers run and complete their tasks before the main application container starts. Unlike [sidecar containers](/docs/concepts/workloads/pods/sidecar-containers), init containers are not continuously running alongside the main containers. Init containers run to completion sequentially, and the main container does not start until all the init containers have successfully completed. init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` whereas sidecar containers support all these [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe) to control their lifecycle. Init containers share the same resources (CPU, memory, network) with the main application containers but do not interact directly with them. They can, however, use shared volumes for data exchange. </ins> ## Using init containers Because init containers have separate images from app containers, they

Related discussion:
text: restartPolicy under initContainers is not allowing to create Jobs specified into the below documents Error Message: Job in version "v1" cannot be handled as a Job: strict decoding error: unknown field "[0].restartPolicy" Document Link:
Hi I believe the error message you are getting is because you might have used feild under the section. But it is not allowed under the . /language en
Page related to the issue: /sig docs /sig node
Hi , Below is the Job configuration:
Could you please provide the code block with proper indentation?
updated above section
The indentation should be corrected as below
/kind bug
mentions a feature gate, but doesn't make it explicitly clear that you need to enable it. The feature gate is named . The fix I recommend: add a brand new page edit to direct readers to that new page /remove-kind bug I don't think there is anything actually incorrect. /triage accepted /retitle Unclear documentation about sidecar containers
Is anybody working to fix this issue? If no, i can take it.
/assign
Feel free to involve me, if you need any help.
Sure, Thank you.
PR raised to fix the issue .
Also see
To learn more, you can read (but not plagiarize)
Hi, I also having this problem I tried to add restartPolicy as to under containers and init containers, but I get the same error. I do not got any errors for the restartPolicy, but and are gave the error mentioned at the top. Im using Minikube, and my CC: Your suggestions highly appriciatable
Looks like you are using 1.27, but this feature was in 1.28.
Thanks I updated my k8s Even though I can not use and in both places. ( and I put this marker in the above comment). It says,