Mark pod-startup-liveness-probe-holdoff KEP as implementable

[matthyx]

No description provided.

[derekwaynecarr]

Prior to marking implementable, we should clarify if there is a feature gate for this item, and how we will roll the feature out across a set of releases.

[thockin]

Because of the torrent of excellent KEPs, I have not seen this one.

I am not sure this is the right API -- does it have any meaning to readiness probes or just liveness probes? I don't see how it has utility for readiness.

In kubernetes/kubernetes#27114 (comment) we looked at a different take on this API - it is more precise in its meaning and rather than add yet another behavior modifier to probe, it can reuse the probe structure directly.

If this (or similarly orthogonal -- I am not attached to it) was considered and discarded, please explain why?

[matthyx]

Hi @thockin glad to see you back on this subject.

Well, I thought you agreed since you have remained quiet for some time in the PR (kubernetes/kubernetes#71449).
In the meantime, I have also reached sig-node for their review...

To come back to your proposal for a third probe, do you still think it is simplier to explain to other people why they should implement a StartupProbe in order to prevent LivenessProbe from killing their containers?

To me it made more sense to expand the current LivenessProbe, and while it doesn't really have an effect on ReadinessProbe, I thought for consistency it wouldn't hurt to let it this way :-)

Please let me know how to make sure we don't waste another release cycle for that feature.
Thanks.

[thockin]

I feel pretty strongly that something like a startupProbe would be net simpler to comprehend than a new field on liveness.

I think you are on EU time, and I feel very guilty that I lost track of this KEP. I feel bad that this could miss the boat because of me, so here's what I proposed to @dchen1107 and @yujuhong -- I'll retitle this KEP to be a bit more generic and approve it. They are both OK with the general idea here. We can haggle over the exact shape of the API in the coming days.

[thockin]

Thanks!

/lgtm
/approve

[matthyx]

@thockin thanks a lot for your help, looks like it wasn't merged after your LGTM because you're not an approver for sig-node...

I have updated the design for startupProbe, let's make sure we can still include it in 1.15

[matthyx]

@thockin I have checked with @justaugustus and we'll need to create an exception request...
Probably before doing so we should agree on the design and if you could help me with the graduation criteria (this is still very cryptic for me)?
I will describe the test plan once we have the implementation...

[thockin]

File that exception. I will circle back to this ASAP

[thockin]

Thanks!

/lgtm
/approve

[derekwaynecarr]

I am fine w/ iterating on this more during PR process. The general shape and need of the problem is clear.

We will follow-up with exception.

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: derekwaynecarr, matthyx, thockin

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• keps/sig-node/OWNERS [derekwaynecarr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment