@kubernetes/sig-architecture
@kubernetes/sig-cluster-lifecycle
@kubernetes/sig-cluster-ops
@kubernetes/sig-scheduling

/sig architecture
/sig cluster-lifecycle
/sig cluster-ops
/sig scheduling

Is it not an issue though that while for initContainers it is a hard requirement for them to succeed for the actual workload to start, while potential shutdownContainers could only act on best effort with no solid guarantee that they will get executed as expected, introducing volatility to the design of deployed solution? Is it even worth having if it can not be guaranteed to execute?

i tend to agree with the above statement.

if you want to get more attention from maintainers try asking in these slack channels #sig-node or #sig-scheduling.

this is not related to code that these sigs maintain:
/remove-sig cluster-lifecycle cluster-ops
/sig node

Is it not an issue though that while for initContainers it is a hard requirement for them to succeed for the actual workload to start, while potential shutdownContainers could only act on best effort with no solid guarantee that they will get executed as expected, introducing volatility to the design of deployed solution? Is it even worth having if it can not be guaranteed to execute?

@goblain - perhaps I was not detailed enough in my feature request resulting in the above assumptions. I am not necessarily requesting that shutdownContainers succeed prior to POD termination. What I am requesting is, "upon POD termination", shutdownContainer(s) can be triggered.

[POD-workers] - State: Terminating
[shutdownContainer-1]: Starts as soon as the above POD is being "Terminated"
[shutdownContainer-2]: waiting on #1 to succeed

In this model, since the termination signal is sent to the POD (and since there is really no way to revert a termination signal), that's all we need to know to trigger a shutdownContainer sequence of jobs. They can trigger asynchronously with the termination signal or wait for the POD to be completely destroyed prior to kicking off -- it really doesn't matter as long as they are executed with or after the termination signal.

👍

Is this different that defer-containers proposal?
https://github.com/dhilipkumars/community/blob/9e81de385df8355af78b32ec0dd596cecda86a8a/contributors/design-proposals/defer-containers.md

The defer-container proposal would suffice and provide additional benefits. Seems like that proposal was started in 2017. How can we raise the priority?

/remove-sig architecture

/remove-sig scheduling
/sig apps

Defer containers proposal: kubernetes/community#483
Note there are a number of cases where defer containers could not be guaranteed to execute (e.g., preemption, OOM, disk full, other resource contention).

Comment on our current hooks generally: kubernetes/community#1171 (comment)

cc @kow3ns

when reviewing kubecon eu talks, I noticed tekton seems to have a similar issue, which they also solved via a "hack" (injecting a smart binary that handles the order).

https://youtu.be/4EyTGYB7GvA?t=913

So it seems there are a bunch of use-cases for "run a linear sequence of pods on the same node"), thus a native solution would be quite nice

@bobcatfish @mrbobbytables @rochaporto @afortiorama @clelange

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

One of the things I've suffered through is that preStop hooks all happen at once and the container they are associated with gets killed when that preStop is done. There may be some support containers that need to stay up while the main preStop hook happens. So maybe this needs to work with that. Maybe all de-init containers happen first, then prestop hooks, then actual pod death?

/cc

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

This may be covered by the Sidecar container use case?

@kfox1111 A sidecar container runs in parallel with the main application. Any sidecars would be stopped in conjunction with the main container. Check this old conversation of defer-containers (de-init containers) here: kubernetes/community#483

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

@fejta-bot: Closing this issue.

+1 - would be useful for example main container is generating some files (it could be database dump, could be unit test reports) - and deinit container - can upload these files somewhere. That way we can split responsibilities and remove some binaries from main container - responsible only for uploading the generated files.

This should be re-opened or a solution suggested.

Waiting for a proper solution, this could help : https://github.com/target/pod-reaper

/reopen

/remove-lifecycle rotten

@flavienbwk: You can't reopen an issue/PR unless you authored it or you are a collaborator.