-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add startup probe support to Knative Service #15309
base: main
Are you sure you want to change the base?
Conversation
/assign @skonto More info in the links above. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #15309 +/- ##
==========================================
- Coverage 84.79% 84.76% -0.03%
==========================================
Files 218 218
Lines 13504 13519 +15
==========================================
+ Hits 11451 11460 +9
- Misses 1687 1691 +4
- Partials 366 368 +2 ☔ View full report in Codecov by Sentry. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ReToCode The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@dprotaso gentle ping. |
startupProbeMaxDuration := int32(0) | ||
for _, container := range podSpec.Containers { | ||
if container.StartupProbe != nil { | ||
maxSuccessDuration := container.StartupProbe.PeriodSeconds * | ||
container.StartupProbe.SuccessThreshold * | ||
container.StartupProbe.TimeoutSeconds | ||
|
||
maxFailDuration := container.StartupProbe.PeriodSeconds * | ||
container.StartupProbe.FailureThreshold * | ||
container.StartupProbe.TimeoutSeconds | ||
|
||
maxDuration := max(maxSuccessDuration, maxFailDuration) | ||
if maxDuration > startupProbeMaxDuration { | ||
startupProbeMaxDuration = container.StartupProbe.InitialDelaySeconds + maxDuration | ||
} | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorta inclined to think that the progressdeadline encapsulates all the (startup time + ready time).
So I'm thinking of not adding this extra time here just because there's a startup probe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably we can omit that and keep the K8s UX. It seems that the only validation that happens at the K8s side for progressdeadline is about MinReadySeconds
, https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/apps/validation/validation.go#L592. I am wondering how that field affects our stuff in case would want to set it (right now it is not exposed). 🤔
Fixes #10037
Context
see feature document: https://docs.google.com/document/d/1TmimPy7qNLtc5IHVFKEme8X-NiIUBtVgR44GlaTqoWs/edit?usp=sharing
Proposed Changes
ProgressDeadlineSeconds
is dynamically increased to the maximum duration a startup probe could take (worst case) to make sure the pod is not scaled to zero before the startup probes succeeded or failed.Release Note