Home > Back-end >  Why container restart policy is defined in Pod specification?
Why container restart policy is defined in Pod specification?

Time:10-13

Does anyone know why restartPolicy field is defined on the Pod level instead of the container level?

It would seem that this setting is more closely related to the container, not the Pod.

Then how to controll restart policy of single container in multi-container Pod?

CodePudding user response:

i think restart policy is part of the POD spec

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: 1st
    image: image-1
    command: ["./bash", "-test1"]
  - name: 2nd
    image: image-2
    command: ["./bash", "-test2"]
  restartPolicy: Never

restart policy gets set the at POD spec level, and get applied to all the containers in POD even if init container is there.

If there are multi containers inside the POD, we have to consider those as tightly coupled.

Official documents says something like this : link

Pods that run multiple containers that need to work together. A Pod can encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers form a single cohesive unit of service—for example, one container serving data stored in a shared volume to the public, while a separate sidecar container refreshes or updates those files. The Pod wraps these containers, storage resources, and an ephemeral network identity together as a single unit.

Note: Grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled.

If you want to restart the single container in POD you won't be able to do it, you have keep that container out of POD then by POD design.

Even if you will see the container restart policy it's talk about the : POD spec restart policy only.

  • Related