-
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
Allow startup probes on user containers #12565
Conversation
/cancel-approve |
/remove-approve |
Codecov Report
@@ Coverage Diff @@
## main #12565 +/- ##
=======================================
Coverage 87.48% 87.49%
=======================================
Files 195 195
Lines 9718 9721 +3
=======================================
+ Hits 8502 8505 +3
Misses 931 931
Partials 285 285
Continue to review full report at Codecov.
|
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.
If we allow the user to add a StartupProbe, don't we need to ensure that activator (via the optimisation where it checks QP readiness directly) doesn't start routing to the user container before it's passing?
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
/test pull-knative-serving-istio-latest-no-mesh |
Test error: Error: error creating the clusters: error creating clusters: error creating cluster: exit status 1, output: "Default change: VPC-native is the default mode during cluster creation for versions greater than 1.21.0-gke.1500. To create advanced routes based clusters, please pass the |
/test pull-knative-serving-upgrade-tests |
/test pull-knative-serving-istio-latest-no-mesh |
I think introducing this attribute is a bit more complex and we probably need to document all the scenarios to help us understand the implications. For example - we rewrite the user container's readiness probe to go via the queue proxy. I believe we even default to a TCP probe when one is not set. Thus the queue proxy is aware of the application's 'readiness'. But this readiness probe should occur after the startupProbe which currently the queue proxy isn't aware of. There's probably other edge cases/scenarios that I haven't thought of |
/hold |
Going to close this for now as it's not a trivial update |
Fixes #10037
Proposed Changes
startupProbe
to the list of allowed fields for containers, updates the schemas, and adds some tests.Release Note
/assign @dprotaso @julz