On 4/21/22 16:07, McFly Marty wrote:
> The initial KEP Sidecar Container KEP
> been proposed about 4 years ago, lots of discussions on that
> demonstrates its huge popularity, today its prerequisite described in
> this KEP, that is Graceful Node Shutdown
> has been proposed and implemented.So shall we move it forward to
> implement the KEP and make it cover more user scenarios?
Well, there is no such KEP that covers more scenarios today. That is
kind of a blocker to do that :)
As you linked in the use cases below, there was that use case collection
and we created pre-proposals to further discuss which direction we want
to go. But that discussion to set our north star, didn't happen.
To continue to move, though, this other KEP was created by some
community members and myself (added them on Cc, just in case):
The idea was to solve a simpler problem as a way to also collect
feedback and gain more experience, while we decide what a more complex
solution should look like (the north star). This simple KEP is also
extensible to any of the pre-proposals we have so far (extensible in the
sense that we can incrementally add more complexity and features until
we reach what is proposed in a pre-proposal)
This KEP got one SGTM from Tim Hockin, but didn't make the cut for the
past k8s release during the sig-node meetings. I think from that point
onwards (a few months ago), progress was stalled.
> Here are some previous discussions links：
> * https://github.com/kubernetes/enhancements/issues/753
> * https://github.com/kubernetes/community/pull/2148
> * user case discussions：
> shows us
> that Envoy can transfer states between new and old instance, so what we
> should do on k8s side is supporting a mechanism to allow two sidecar
> containers both exists during upgrading Envoy sidecar container and kill
> the old one after upgrade complete.
Wow, that seems to go way more than the scope of any of the already
quite complex pre-proposals we have discussed.
My advice would be to not try to solve so many things, but define a
clear problem that has enough users and is extensible for incremental
improvements. But even if you do that, what is hard is to get things
moving. The things to discuss here are _hard_ things, that take time and
will have _lot of consequences_, so is usually hard to make progress
with those discussions with the people that needs to be involved.
> So maybe we can re-discuss API design here to make it cover more
> scenarios.It's amazing if we could move this forward because this KEP is
> pending for much long time and indeed it can solve many pain points we
> faced tody.
Count me in to help in the discussion in any way that I can.