Sidecar containers

[SergeyKanzhelev]

Enhancement Description

• One-line enhancement description (can be used as a release note): Kubernetes introduces the built-in support for sidecar containers pattern.
• Kubernetes Enhancement Proposal: TBD
• Discussion Link: Sidecar working group and KEP draft
• Primary contact (assignee): @SergeyKanzhelev
• Responsible SIGs: node
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): 1.27
  • Beta release target (x.y): TBD
  • Stable release target (x.y): TBD
• Alpha
  • KEP (k/enhancements) update PR(s):
  • Code (k/k) update PR(s):
  • Docs (k/website) update PR(s):

/sig node

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[dims]

cc @tzneal

[thockin]

Are we ready to milestone this to 1.27?

[dchen1107]

/label lead-opted-in
/milestone v1.27

[k8s-ci-robot]

@dchen1107: Can not set label lead-opted-in: Must be member in one of these teams: [release-team-enhancements release-team-leads sig-api-machinery-leads sig-apps-leads sig-architecture-leads sig-auth-leads sig-autoscaling-leads sig-cli-leads sig-cloud-provider-leads sig-cluster-lifecycle-leads sig-contributor-experience-leads sig-docs-leads sig-instrumentation-leads sig-k8s-infra-leads sig-multicluster-leads sig-network-leads sig-node-leads sig-release-leads sig-scalability-leads sig-scheduling-leads sig-security-leads sig-storage-leads sig-testing-leads sig-windows-leads]

In response to this:

/label lead-opted-in
/milestone v1.27

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[logicalhan]

/label lead-opted-in

[fpoirotte]

I see #3582 was closed a few days ago in favor of this KEP.
I have a use case where the onCompletion: TerminatePod flag in KEP #3582 would have met my requirements perfectly
(I have a pod with several containers and complex dependencies between the containers; when any of the containers dies/exits, I want to terminate the whole pod).

At the moment, I'm not entirely sure if/how this KEP would address my needs.
From what I understand, it seems like I would have to:

• set the pod's restartPolicy to Never
• turn all the containers into init containers and set their restartPolicy to Always (i.e. turn them into sidecar containers)
• introduce a new (regular) container that sleeps forever

Does that seem correct?

Best regards,
François

[thockin]

François, This KEP would not benefit you for this use case (or you'd be using it in an off-label way). What you want is something like #3676 (I think) which does not have an active KEP or owner at the moment.

[SergeyKanzhelev]

@thockin I think the "any" semantic for Pod termination fit into the KEP #3582. You basically marking all regular containers as one that will terminate the whole Pod on completion. I am not sure how many scenarios like this exist, but this is second one I stumbled onto.

[SergeyKanzhelev]

closing to reuse the original issue as @wojtek-t suggested

[SergeyKanzhelev]

#753

[salehsedghpour]

/remove-label lead-opted-in

[emirot]

This is what I am looking for.
If one container restart, I want the whole pod to restart.
There is many threads and discussions but it's not clear for me, how can I accomplish that ?

For example below, the container restarted but not the pod.

 3/3     Running   1 (90s ago)   12m