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](https://github.com/kubernetes/enhancements/issues/3759#issuecomment-1410959250): >/label lead-opted-in >/milestone v1.27 > Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) 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 https://github.com/kubernetes/enhancements/issues/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 https://github.com/kubernetes/enhancements/issues/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